CRI-O的演变
仅仅几个月前，我从未将容器称为容器……我曾经将它们称为docker容器……当听说OpenShift即将迁移到CRI-O时，我认为是时候必须了解k8s worker节点的演变了。
如果你看一下k8s架构的发展，工作节点运行容器的方式已经发生了重大的变化和优化。
阶段0：Docker是主导者
它以简单的kubelet体系结构，作为工作节点代理通过api-server从主节点接收来自管理员的命令。
Kubelet使用Docker运行时来启动Docker容器（从镜像仓库中拉出镜像）。一切都很好……直到具有更好性能和独特优势的其他容器运行时开始出现在市场上，我们意识到，如果我们可以即插即用这些运行时就很好了……我们决定使用适配器/代理设计模式解决此问题。这就进入了下一个阶段。
演变就是要适应生态系统的变化
阶段1：CRI（容器运行时接口）
容器运行时接口（CRI）规范是在K8s 1.5中引入的。CRI还包括缓冲区，gRPC API和类库。通过在kubelet中运行的gRPC客户端和在CRI Shim中运行的gRPC服务器，这带来了抽象层，并充当了适配器。这允许以更简单的方式运行各种容器运行时。
在继续之前……我们需要了解容器运行时应具有的所有功能--用于管理容器运行时，下载镜像，解压缩它们，运行镜像，以及处理网络，存储。很好...直到我们开始意识到这就像一块巨石！！！
让我将这些功能分为2个层次。
- 高级别 —镜像管理，传输，解压缩镜像和API，以发送命令来运行容器，网络，存储（例如：rkt，docker，LXC等）。
- 低级别 -运行容器。
如果将这些功能拆分为可以与各种开源选项集成并匹配的组件，这样可以提供更多的优化和效率。这是有意义的……我们用来解决此问题的的设计/架构模式是什么呢？分层模式...对吗？这就进入了了下一个阶段。
阶段2：CRI-O和OCI
因此，OCI（Open Container Initiative，开放容器计划）提出了明确的容器运行时和镜像规范，该规范有助于实现多平台支持（Linux，Windows，VM等）。Runc是OCI的默认实现，它是容器运行时的底层。
现代的容器运行时基于此分层体系结构，其中Kubelet通过CRI-gRPC与容器运行时对话，而容器运行时通过OCI运行容器。
CRI有多种实现，例如Dockershim，CRI-O，containerD。
在第1阶段快要结束时，我提到了创建端到端容器管理工具包的灵活性……
OpenShift进入k8s世界
- 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容器运行时接口来管理。
上图，显示了在Red Hat OpenShift 4.x中CRI-O如何工作。
