kubernets启动容器过程分析-摩杜云开发者社区

1. 背景

对于大数据组件，经常需要进行扩缩容的服务，例如Yarn nodemanager、Alluxio Worker。往往需要频繁的人工操作上线下线，非常繁琐，耗费较高的人力成本。

为了降低这种人工操作的成本，可以考虑将这些服务部署到kubernets中进行管理。本文通过介绍kubernets启动容器的过程，介绍期间经历的所有组件，帮助提升对kubernets的认知。

2. kubernets架构

一个kubernetes集群主要是由控制节点(master)、工作节点(node)构成，每个节点上都会安装不同的组件。

master：集群的控制平面，负责集群的决策 ( 管理 )

ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制

Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上

ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等

Etcd ：负责存储集群中各种资源对象的信息

node：集群的数据平面，负责为容器提供运行环境 ( 干活 )

Kubelet : 负责维护容器的生命周期，即通过控制docker，来创建、更新、销毁容器

KubeProxy : 负责提供集群内部的服务发现和负载均衡

Docker : 负责节点上容器的各种操作

下面，以部署一个nginx服务来说明kubernetes系统各个组件调用关系：

首先要明确，一旦kubernetes环境启动之后，master和node都会将自身的信息存储到etcd数据库中。
一个nginx服务的安装请求会首先被发送到master节点的apiServer组件。
apiServer组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上。在此时，它会从etcd中读取各个node节点的信息，然后按照一定的算法进行选择，并将结果告知apiServer。
apiServer调用controller-manager去调度Node节点安装nginx服务。
kubelet接收到指令后，会通知docker，然后由docker来启动一个nginx的pod。 pod是kubernetes的最小操作单元，容器必须跑在pod中至此。
一个nginx服务就运行了，如果需要访问nginx，就需要通过kube-proxy来对pod产生访问的代理。

这样，外界用户就可以访问集群中的nginx服务了。

3. k8s启动容器流程

kuberlet组件负责创建、更新、销毁容器。调用过程如下所示：

Untitled 1.png

3.1 调用CRI接口访问dockershim

在CRI诞生之前，架构没那么复杂，当时kubelet是能直接操作docker daemon的（kubelet --> docker）。但后来出现了rkt容器运行时，k8s又去主动对接rkt，随着容器运行时逐渐发展，k8s开发人员意识到容器运行时会越来越多，如果为每个都做开发对接，工作量太大、难以维护。于是就定义了统一的接口CRI。

CRI：Container Runtime Interface（容器运行时接口），是k8s抽象出来的一种标准协议,基于grpc+protocol buffer，规范了容器的上层基本行为，因此也称为high-level运行时（相对应的是low-level，即OCI）。CRI 基于 gRPC 定义了 RuntimeService 和 ImageService 等两个 gRPC 服务，分别用于容器运行时和镜像的管理。其接口如下所示：

RuntimeService接口负责管理容器：

service RuntimeService {
    rpc Version(VersionRequest) returns (VersionResponse) {}
    rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse) {}
    rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSandboxResponse) {}
    rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse) {}
    rpc PodSandboxStatus(PodSandboxStatusRequest) returns (PodSandboxStatusResponse) {}
    rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSandboxResponse) {}
    rpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse) {}
    rpc StopContainer(StopContainerRequest) returns (StopContainerResponse) {}
    rpc RemoveContainer(RemoveContainerRequest) returns (RemoveContainerResponse) {}
    rpc ListContainers(ListContainersRequest) returns (ListContainersResponse) {}
    rpc ContainerStatus(ContainerStatusRequest) returns (ContainerStatusResponse) {}
    rpc UpdateContainerResources(UpdateContainerResourcesRequest) returns (UpdateContainerResourcesResponse) {}
    rpc ExecSync(ExecSyncRequest) returns (ExecSyncResponse) {}
    rpc Exec(ExecRequest) returns (ExecResponse) {}
    //省略
}

ImageService负责管理镜像：

service ImageService {
    rpc ListImages(ListImagesRequest) returns (ListImagesResponse) {}
    rpc ImageStatus(ImageStatusRequest) returns (ImageStatusResponse) {}
    rpc PullImage(PullImageRequest) returns (PullImageResponse) {}
    rpc RemoveImage(RemoveImageRequest) returns (RemoveImageResponse) {}
    rpc ImageFsInfo(ImageFsInfoRequest) returns (ImageFsInfoResponse) {}
}

dockershim：

早期kubernetes版本，只支持docker engine一种特定的container runtime， docker engine本身并没有支持CRI接口规范，所以kubernetes project中包含了特定的代码来做这种转化，使得dockershim代码变成了kubernetes中kuberlet组件的一部分。

CRI规范推进以及kubernetes自身的发展:随着kubernetes发展，维护dockershim模块变成了一种巨大的负担。未来随着newer CRI runtime中将会引入以及cgroups v2以及user namespaces等新特性的支持，涉及到大量dockershim的兼容工作要做，移除dockershim对于未来推动CRI发展至关重要。

3.2 dockershim调用docker daemon

dockershim 收到请求后, 转化成 Docker Daemon 能识别的请求, 发到 Docker Daemon 上请求创建一个容器，请求到了 Docker Daemon 后续就是 Docker 创建容器的流程了。Docker Daemon架构图如下所示：

Untitled 2.png

Docker Daemon是Docker架构中运行在后台的守护进程，大致可以分为Docker Server、Engine和Job三部分。

Docker Daemon可以认为是通过Docker Server模块接受Docker Client的请求，并在Engine中处理请求，然后根据请求类型，创建出指定的Job并运行。运行过程的作用有以下几种可能：

向Docker Registry获取镜像。
通过graphdriver执行容器镜像的本地化操作。
通过networkdriver执行容器网络环境的配置。
通过execdriver执行容器内部运行的执行工作等。

3.3 Docker Engine调用containerd

Untitled 3.png

containerd 组件是从 Docker 1.11 版本正式从 dockerd 中剥离出来的，它的诞生完全遵循 OCI 标准，是容器标准化后的产物。containerd 完全遵循了 OCI 标准，并且是完全社区化运营的，因此被容器界广泛采用。

containerd 不仅负责容器生命周期的管理，同时还负责一些其他的功能：

镜像的管理，例如容器运行前从镜像仓库拉取镜像到本地；
接收 dockerd 的请求，通过适当的参数调用 runc 启动容器；
管理存储相关资源；
管理网络相关资源。

containerd 包含一个后台常驻进程，默认的 socket 路径为 /run/containerd/containerd.sock，dockerd 通过 UNIX 套接字向 containerd 发送请求，containerd 接收到请求后负责执行相关的动作并把执行结果返回给 dockerd。

如果你不想使用 dockerd，也可以直接使用 containerd 来管理容器，由于 containerd 更加简单和轻量，生产环境中越来越多的人开始直接使用 containerd 来管理容器。

3.4 containerd启动containerd-shim进程

containerd-shim 的意思是垫片，类似于拧螺丝时夹在螺丝和螺母之间的垫片。containerd-shim 的主要作用是将 containerd 和真正的容器进程解耦，使用 containerd-shim 作为容器进程的父进程，从而实现重启 containerd 不影响已经启动的容器进程。

shim 将 Containerd 进程从容器的生命周期中分离出来，具体的做法是 runc 在创建和运行容器之后退出，并将 shim 作为容器的父进程，即使 Containerd 进程挂掉或者重启，也不会对容器造成任何影响。这样做的好处很明显，你可以高枕无忧地升级或者重启 Containerd，不会对运行中的容器产生任何影响。

3.5 container-shim调用runC启动容器

在2015年前，都是以 docker 作为标准创建容器，那么 docker 接口的变化将导致社区中所有相关工具都要更新，不然就无法使用；如果没有标准，这将导致容器实现的碎片化，出现大量的冲突和冗余。这两种情况都是社区不愿意看到的事情，OCI（Open Container Initiative）就是在这个背景下出现的，它的使命就是推动容器标准化，容器能运行在任何的硬件和系统上，相关的组件也不必绑定在任何的容器运行时上。

RunC 是从 Docker 的 libcontainer 中迁移而来的，实现了容器启停、资源隔离等功能。Docker将RunC捐赠给 OCI 作为OCI 容器运行时标准的参考实现。通过执行RunC命令就可以启动容器。

4. k8s容器运行时架构总结

除了通过docker的方式管理容器。还可以直接调用cri-containerd和cri-o管理容器：

Untitled 4.png

cri-containerd：

cri-containerd和cri-o实现了CRI接口，cri-containerd包含在containerd组件中。通过Kubelet直接调用containerd可直接创建容器。

cri-o：

CRI-O 全称为 "Container Runtime Interface - OpenShift"，CRI-O对CRI和OCI的实现非常严格，为k8s的推荐的实现方式，例如，podman就实现了cri-o。cri-o架构如下：

Untitled 5.png