容器和K8s介绍

1. 容器运行时


定义： 容器本身就是一个进程，那么在方便用户对其进行管理的软件就是容器运行时。

  1. 比较火的容器运行时就是Docker，之后又增加了containerd、runc等组件。
  2. 当收到创建容器的指令之后，会由docker-daemon->containerd->containerd-shim->runC创建，runC创建完之后就会退出。
  3. containerd-shim会成为容器的父进程，负责收集容器进程的状态, 上报给Containerd, 并在容器中pid 为 1 的进程退出后接管容器中的子进程进行清理, 确保不会出现僵尸进程。

2. CRI

  1. CRI全称是(Container Runtime Interface) 容器运行时接口，从字面的意思可以猜到是一个与容器运行时进行交互的接口。
  2. 只要按照CRI的接口规范实现相关接口就可以接入K8S。

3. kubernetes(k8s)


k8s架构图如上图所示

  • k8s: 容器编排工具。使用k8s能够更好，更方便的对容器进行管理。k8s并不是直接接管理容器，而是以pod为最小单位。
  1. k8s由两大部分组成，master和node，master为控制端，node为工作节点。
  2. master节点: 由三个组件完成，分别是 apiserver、scheduler、controller-manager，还有一个etcd主要是负责相关数据存储。
  3. node节点: 组件kubelet,主要服务，定期从kube-apiserver组件接收新的或修改的Pod规范，并确保Pod及其容器在期望规范下运行。同时该组件作为工作节点的监控组件，向kube-apiserver汇报主机的运行状况.

4. 各个组件详细介绍

1) apiserver

  1. 它是集群管理API的统一入口。
  2. API Server 作为Kubernetes 系统的入口，封装了核心对象的增删改查操作。APIServer 以 RESTFul 接口方式提供给外部客户端和内部组件调用，API Server 再对关的资源数据（ 全量查询 + 变化监听）进行操作，以达到实时完成相关的业务功能。
    1.1)apiserver的安全认证机制
    ApiServer采用https+ca签名证书强制双向认证，也就说是想顺利访问通ApiServer接口需要持有对应的证书

2) controller-manager

2.1) Replication Controller

  1. 确保任何时候ReplicaSet管理的Pod副本数量都为期望值
  2. 只有当Pod的重启策略为Always，Replication Controller才会管理
    2.2) node controller
    Kubelet 在启动时会通过 API Server 注册自身的节点信息，并定时向 API Server 汇报
    状态信息。API Server 在接收到信息后将信息更新到 Etcd 中。Node Controller 通过 API Server 实时获取Node 的相关信息，实现管理和监控集群中的各个 Node 节点的相关控制功能。
    2.3) ResourceQuota Controller
    资源配额管理控制器用于确保指定的资源对象在任何时候都不会超量占用系统上物理
    资源。
    2.4) namespace controller
    用户通过apiserver创建namespace，apiserver会将namespace的信息存储入etcd中。
    namespaceController通过apiserver读取维护这些namespace的信息，若ns被标记为删除状态，namespaceController会将其状态改为Terminating
    2.5) service account controller
    服务账号控制器主要在命名空间内管理 ServiceAccount，以保证名为
    default 的 ServiceAccount 在每个命名空间中存在。
    2.6) token controller
    令牌控制器作为 Controller Manager 的一部分，主要用作：监听 serviceAccount 的
    创建和删除动作以及监听 secret 的添加、删除动作。
    2.7) service controller
    服务控制器主要用作监听 Service 的变化。比如：创建的是一个 LoadBalancer 类型的
    Service，Service Controller 则要确保外部的云平台上对该 Service 对应的 LoadBalancer 实例被创建、删除以及相应的路由转发表被更新。
    2.8) endpoint controller
    Endpoints 表示了一个 Service 对应的所有 Pod 副本的访问地址，而 Endpoints Controller 是负责生成和维护所有 Endpoints 对象的控制器。Endpoint Controller 负责监听 Service 和对应的 Pod 副本的变化。定期关联 Service 和 Pod (关联信息由Endpoint 对象维护)，以保证 Service 到Pod 的映射总是最新的。
    3) scheduler
    Scheduler 是负责整个集群的资源调度的，主要的职责如下所示：
  • 主要用于收集和分析当前 Kubernetes 集群中所有 Node 节点的资源 (包括内存、CPU 等) 负载情况，然后依据资源占用情况分发新建的 Pod 到 Kubernetes 集群中可用的节点
  • 实时监测 Kubernetes 集群中未分发和已分发的所有运行的 Pod
  • 实时监测 Node 节点信息，由于会频繁查找 Node 节点，所以 Scheduler 同时会缓存一份最新的信息在本地
  • 在分发 Pod 到指定的 Node 节点后，会把 Pod 相关的 Binding 信息写回 API Server，以方便其它组件使用
    4) Kubelet
    kubelet 是负责容器真正运行的核心组件，主要的职责如下所示：
  • 负责 Node 节点上 Pod 的创建、修改、监控、删除等全生命周期的管理
  • 定时上报本地 Node 的状态信息给 API Server
  • kubelet 是 Master 和 Node 之间的桥梁，接收 API Server 分配给它的任务并执行
  • kubelet 通过 API Server 间接与 Etcd 集群交互来读取集群配置信息
  • kubelet 在 Node 上做的主要工作具体如下：
  1. 设置容器的环境变量、给容器绑定 Volume、给容器绑定 Port、根据指定的 Pod 运行一个单一容器、给指定的Pod 创建 Network 容器
  2. 同步 Pod 的状态
  3. 在容器中运行命令、杀死容器、删除 Pod 的所有容器
    5) kube-proxy
  • kube-proxy 是为了解决外部网络能够访问集群中容器提供的应用服务而设计的，Proxy 运行在每个 Node 上。
  • 每创建一个 Service，kube-proxy 就会从 API Server 获取 Services 和 Endpoints 的配置信息，然后根据其配置信息在 Node 上启动一个 Proxy 的进程并监听相应的服务端口。
  • 当接收到外部请求时，kube-proxy 会根据 Load Balancer 将请求分发到后端正确的容器处理。
  • kube-proxy 不但解决了同一宿主机相同服务端口冲突的问题，还提供了 Service 转发服务端口对外提供服务的能力。
  • kube-proxy 后端使用随机、轮循等负载均衡算法进行调度。
    6) kubectl
    Kubectl 是 Kubernetes 的集群管理命令行客户端工具集。通过 Kubectl 命令对 API Server 进行操作，API Server 响应并返回对应的命令结果，从而达到对 Kubernetes 集群的管理。

5. 核心资源对象

  1. Pod
    Pod 是一组紧密关联的容器集合，它们共享 PID、IPC、Network 和 UTS namespace，是 Kubernetes 调度的基本单位。Pod 的设计理念是支持多个容器在一个 Pod 中共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。我们知道容器本质上就是进程，那么 Pod 实际上就是进程组了，只是这一组进程是作为一个整体来进行调度的。
  2. Label
    Label 标签在 Kubernetes 资源对象中使用很多，也是非常重要的一个属性，Label 是识别 Kubernetes 对象的标签，以 key/value 的方式附加到对象上（key 最长不能超过 63 字节，value 可以为空，也可以是不超过 253 字节的字符串）上面我们定义的 Nginx 的 Pod 就添加了一个 app=nginx 的 Label 标签。Label 不提供唯一性，并且实际上经常是很多对象（如 Pods）都使用相同的 Label 来标志具体的应用。Label 定义好后其他对象可以使用 LabelSelector 来选择一组相同 Label 的对象（比如 Service 用 Label 来选择一组 Pod）。Label Selector 支持以
    下几种方式：
    • 等式，如 app=nginx 和 env!$production
    • 集合，如 env in (production, qa)
    • 多个 Label（它们之间是 AND关系），如 app=nginx,env=test
  3. Namespace
    Namespace（命名空间）是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的 Pods、Services、Deployments 等都是属于某一个 Namespace 的（默认是 default），比如上面我们的Nginx Pod 没有指定 namespace，则默认就在 default 命名空间下面，而 Node, PersistentVolumes 等资源则不属于任何 Namespace，是全局的。
    无状态应用，所有的pod无依赖关系，无指定节点运行、无特殊处理的方式部署
  4. Deployment
    在k8s中，pod是最小的控制单元，但是k8s很少直接控制pod，一般都是通过pod控制器来完成，而Deployment就是其中一种。
  5. Service
    Service 是应用服务的抽象，通过 Labels 为应用提供 负载均衡和服务发现。匹配 Labels 的 Pod IP 和端口列表组成 Endpoints，由 kube-proxy 负责将服务 IP 负载均衡到这些 Endpoints 上。每个 Service 都会自动分配一个 cluster IP（仅在集群内部可访问的虚拟地址）和 DNS 名，其他容器可以通过该地址或 DNS 来访问服务，而不需要了解后端容器的运行。
posted @ 2023-04-07 17:44  Dus  阅读(242)  评论(0)  编辑  收藏  举报