博客: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的反对