为什么K8S要选择抛弃Docker？

博客:cbb777.fun

全平台账号:安妮的心动录

github: https://github.com/anneheartrecord

下文中我说的可能对，也可能不对，鉴于笔者水平有限，请君自辨。有问题欢迎大家找我讨论

K8S与Docker

K8S是从14年发布的，到现在已经成为了容器编排领域的龙头，大部分的个人开发或者团队都会选择使用Kubernetes进行容器的管理

我们可以把集群简单的理解为：一组能够在一起协同工作的计算机

K8S虽然是现在容器编排领域的龙头，但是他也有他的缺点

1.虽然Kubernetes对外宣传的是单个集群最多支持5000结点，Pod总数不超过150000，容器总数不超过30000，但是在具体生产环境中，集群可能就2000左右

2.多集群管理还不够成熟，是K8S社区正在探索的方向

集群接口：

Cluster API也是Kubernetes社区中和多集群管理相关的项目，目标是通过声明式的API简化多集群的准备、 更新和运维工作，也就是通过声明式API定义机器和集群的状态

K8S的一些应用场景

1.应用分发 K8S提供了几种部署应用的最基本方式，分别是Deployment StatefulSet 和 DaemonSet 这些资源分别适用于无状态服务、有状态服务和节点上的 守护进程，这些资源能够提供最基本的策略但是无法应对更复杂的应用

2.批处理调度

3.硬多租户

K8S是容器编排领域的事实标准，而Docker从诞生之日到今天都在容器中扮演着举足轻重的地位，也一直是K8S的默认容器引擎，然而在2020年12月，K8S社区决定着手移除仓库中Dockershim的相关代码

Dockershim是什么？

它是Docker的垫片，K8S中的结点代理Kubelet为了访问Docker提供的服务，会先访问Dockershim，Dockershim会将请求转发给管理容器的Docker服务

移除的原因

• K8S引入容器运行时接口（CRI） 隔离不同容器运行时的实现机制，容器编排系统不应该依赖于某个具体的运行时隔离
• Docker没有支持也不打算支持K8S中的CRI接口，需要K8S社区在仓库中维护Dockershim

从可扩展性的角度看问题

K8S通过引入新的容器运行时接口将容器管理与具体的运行时解耦，不再依赖某个具体的运行时实现，K8S通过下面的一系列接口为不同模块提供了扩展性

K8S在较早期的版本中引入了CRD CNI CRI CSI等接口，而CRI是1.5版本引入的新接口，Kubelet可以通过这个接口使用各种各样的容器运行时，其实CRI的发布就意味着K8S一定会将Dockershim的代码从仓库中移除。

CRI是一系列用于管理容器运行时和镜像的GRPC接口，我们能在它的定义中找到RuntimeService和ImageService两个服务

service RuntimeService {  //Runtime的grpc接口 
    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 StartContainer(StartContainerRequest) returns (StartContainerResponse) {}
    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 ReopenContainerLog(ReopenContainerLogRequest) returns (ReopenContainerLogResponse) {}
    ...
}

service ImageService { //镜像的grpc接口 
    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) {}
}

而这些接口都是容器运行时需要暴露给Kubelet的接口

Kubernetes作为松散的开源社区，每个成员都只会在开源社区上花费有限时间，所以既然Docker社区没有打算支持K8s的CRI接口，维护Dockershim又需要很多精力，所以K8S会移除对Dockershim的支持