博客: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两个服务
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| 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) {}
...
}
|
1
2
3
4
5
6
7
| 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的支持