关于后端:为什么K8S要选择抛弃Docker

博客:cbb777.fun

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

github: https://github.com/anneheartrecord

下文中我说的可能对，也可能不对，鉴于笔者程度无限，请君自辨。有问题欢送大家找我探讨

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 的相干代码

它是 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 的反对

关于后端:为什么K8S要选择抛弃Docker

K8S 与 Docker

Dockershim 是什么？

从可扩展性的角度看问题