Kubernetes必备知识: 容器接口CRI

所属技术领域:

K8s

|名词定义|

每种容器运行时各有所长,许多用户都希望Kubernetes支持更多的运行时。在Kubernetes 1.5发布版里,我们引入了CRI–一个能让kubelet无需编译就可以支持多种容器运行时的插件接口。CRI包含了一组protocol buffers,gRPC API,相关的库,以及在活跃开发下的额外规范和工具。CRI目前是Alpha版本。
支持可替换的容器运行时在Kubernetes中概念中并非首次。在1.3发布版里,我们介绍了rktnetes项目,它可以让rkt容器引擎作为Docker容器运行时的一个备选。然而,不管是Docker还是Rkt都需要通过内部、不太稳定的接口直接集成到kubelet的源码中。这样的集成过程要求十分熟悉kubelet内部原理,并且还会在Kubernetes社区引发巨大的维护反响。这些因素都在为容器运行时的初期造成了巨大的困难。我们通过提供一个清晰定义的抽象层消除了这些障碍,开发者可以专注于构建他们的容器运行时。这是很小的一步,但对于真正提供可插拔的容器运行时和构建一个更健康的生态系统却意义非凡。

|技术特点|

 CRI的由来
在CRI之前(Kubernetes v1.5之前)
Docker作为第一个容器运行时,Kubelet通过内嵌其中的dockershim操作Docker API来操作容器
artrkt作为一种容器运行时也合入了kubelet代码中,进一步提高维护的复杂度
hyber.sh加入社区后想成为第三个容器运行时
抽象一套条POD级别的容器接口,解耦Kubelet与容器运行时
定义通过gRPC协议通讯,gRPC在当时刚刚开源,gRPC性能优于http/REST模式
 CRI的设计

Kubernetes必备知识: 容器接口CRI

Kubernetes必备知识: 容器接口CRI
Kubernetes必备知识: 容器接口CRI

 CRIstreaming接口
Kubernetes必备知识: 容器接口CRI

 CRI的实现
1.CRI-containerd
基于containerd实现,有独立进程演进为位插件
Kubernetes必备知识: 容器接口CRI

2.CRI-O
直接在OCI上包装接口、同时实现对镜像存储的管理
Kubernetes必备知识: 容器接口CRI

 cri-tools相关工具
crictl:类docker的命令行工具,帮助用户和开发者调试容器问题
critest:用于验证CRI接口的测试工具,验证是否满足Kubelet要求
性能工具:测试接口性能
 生命周期管理
对于Pod和容器的生命周期管理,CRI提供了下面的机制:

service RuntimeService {
// Sandbox operations.
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) {}
// Container operations.
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) {}

}

在资源受限的隔离环境里的一组应用容器组成一个Pod。在CRI,这个环境被称为PodSandbox。我们故意留下一些空间,让容器运行时根据它们内部不同的原理来产生不同的PodSandbox。对于基于hypervisor的运行时,PodSandbox可能代表的是虚拟机。对于其他的,比如Docker,它可能是Linux命名空间。这个PodSandbox一定遵循着Pod的资源定义。在v1alpha1版API里,kubelet将创建pod级的cgroup限制下的一组进程,并传递给容器运行时,由此实现。

在Pod启动前,kubelet调用RuntimeService.RunPodSandbox来创建环境,包括为Pod设置网络(例如:分配IP)等。当PodSandbox启动后,就可以分别创建/启动/停止/移除独立的容器。为了删除Pod,kubelet会在停止和移除所有容器前先停止和移除PodSandbox。

Kubelet负责通过RPC来进行容器生命周期的管理,测试容器生命周期钩子和健康/可读性检查,同时为Pod提供重启策略。

|资料来源|

名词定义:https://www.kubernetes.org.cn/1079.html
技术特点:https://www.kubernetes.org.cn/1079.html

上一篇:动态 | 绿盟科技发布下一代网络安全预警决策体系


下一篇:Pod必备知识: ServiceAccounts