K8s worker节点CRI-O的演变

女爷i 2022-12-04 02:18 219阅读 0赞

> **原文发表于[kubernetes中文社区][kubernetes]，为作者原创翻译 ，[原文地址][Link 1]**
> 
> **更多kubernetes文章，请多关注[kubernetes中文社区][kubernetes]**

**目录**

CRI-O的演变

阶段0：Docker是主导者

阶段1：CRI（容器运行时接口）

阶段2：CRI-O和OCI

OpenShift进入k8s世界

Red Hat OpenShift适用于CRI-O

--------------------

## ##

### ![2020090510494368.png][] ###

### CRI-O的演变 ###

仅仅几个月前，我从未将容器称为容器……我曾经将它们称为docker容器……当听说OpenShift即将迁移到CRI-O时，我认为是时候必须了解k8s worker节点的演变了。

如果你看一下k8s架构的发展，工作节点运行容器的方式已经发生了重大的变化和优化。

### 阶段0：Docker是主导者 ###

### ![2020090510500837.png][] ###

它以简单的kubelet体系结构，作为工作节点代理通过api-server从主节点接收来自管理员的命令。

Kubelet使用Docker运行时来启动Docker容器（从镜像仓库中拉出镜像）。一切都很好……直到具有更好性能和独特优势的其他容器运行时开始出现在市场上，我们意识到，如果我们可以即插即用这些运行时就很好了……我们决定使用适配器/代理设计模式解决此问题。这就进入了下一个阶段。

> 演变就是要适应生态系统的变化

### 阶段1：CRI（容器运行时接口） ###

![20200905105026704.png][]

容器运行时接口（CRI）规范是在K8s 1.5中引入的。CRI还包括缓冲区，gRPC API和类库。通过在kubelet中运行的gRPC客户端和在CRI Shim中运行的gRPC服务器，这带来了抽象层，并充当了适配器。这允许以更简单的方式运行各种容器运行时。

在继续之前……我们需要了解容器运行时应具有的所有功能--用于管理容器运行时，下载镜像，解压缩它们，运行镜像，以及处理网络，存储。很好...直到我们开始意识到这就像一块巨石！！！

让我将这些功能分为2个层次。

*  高级别 —镜像管理，传输，解压缩镜像和API，以发送命令来运行容器，网络，存储（例如：rkt，docker，LXC等）。
 *  低级别  -运行容器。

如果将这些功能拆分为可以与各种开源选项集成并匹配的组件，这样可以提供更多的优化和效率。这是有意义的……我们用来解决此问题的的设计/架构模式是什么呢？分层模式...对吗？这就进入了了下一个阶段。

### 阶段2：CRI-O和OCI ###

### ![20200905105032272.png][] ###

因此，OCI（Open Container Initiative，开放容器计划）提出了明确的容器运行时和镜像规范，该规范有助于实现多平台支持（Linux，Windows，VM等）。Runc是OCI的默认实现，它是容器运行时的底层。

现代的容器运行时基于此分层体系结构，其中Kubelet通过CRI-gRPC与容器运行时对话，而容器运行时通过OCI运行容器。

CRI有多种实现，例如Dockershim，CRI-O，containerD。

在第1阶段快要结束时，我提到了创建端到端容器管理工具包的灵活性……

### OpenShift进入k8s世界 ###

### ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70][] ###

*  podman：无守护程序的容器引擎，用于开发管理和运行OCI容器，并使用Docker CLI语言
 *  skopeo：管理容器的CLI工具。我最喜欢skopeo的功能之一就是能够在远程镜像仓库上检查镜像，而无需下载或解包！！！……并且它已经发展成为成熟的用于远程镜像仓库的镜像管理工具，包括对镜像进行签名，在镜像仓库之间复制并保持远程镜像仓库同步。这大大加快了容器构建，管理和部署的速度……
 *  buildah：逐步帮助构建OCI镜像的工具！!!! ..是的……前几天我在玩。我不必想象镜像的组成，也不必编写复杂的Dockerfile。相反，我一次只构建镜像一层，对其进行测试，然后回滚（如果需要），一旦我满意，就可以提交它到镜像仓库...那太酷了！！！
 *  cri-o：k8s的轻量级容器运行时。
 *  OpenShift：一个企业级别Kubernetes 容器平台，可以实现全堆栈自动化运维，以管理混合云和多云部署。

### Red Hat OpenShift适用于CRI-O ###

Red Hat OpenShift 4.x选择CRI-O作为默认的容器运行时。在我看来，这个决定中的许多内容都可以归结为选择基于CoreOS构建不可变的基础架构，并在该基础架构上运行OpenShift4.x。CRI-O以CoreOS为基础是显而易见的，而且，CRI-O由k8s社区（完全开放源代码，非常精简）直接控制k8s容器运行时接口来管理。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70 1][]

[CRI-O是][CRI-O][Kubernetes最佳运行时的6个原因][CRI-O]。

[上图][Link 2]，显示了在Red Hat OpenShift 4.x中CRI-O如何工作。

[kubernetes]: https://www.kubernetes.org.cn/
[Link 1]: https://www.kubernetes.org.cn/8334.html
[2020090510494368.png]: /images/20221123/d41f1582049a434e8f8a0c61378093cc.png
[2020090510500837.png]: /images/20221123/ffa38c74345f4f94b7faff51985d1ea2.png
[20200905105026704.png]: /images/20221123/e9f344bc52a243928331469e16716487.png
[20200905105032272.png]: /images/20221123/a6fca5db83054d59b8750a2c489baa17.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70]: /images/20221123/711fc9ebcc9b4b9484c4597d2522fe97.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70 1]: /images/20221123/c1d59706362b4d799c97eed9b9c3bfcf.png
[CRI-O]: https://www.projectatomic.io/blog/2017/06/6-reasons-why-cri-o-is-the-best-runtime-for-kubernetes/
[Link 2]: https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine