K8s worker节点CRI-O的演变

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容器运行时接口来管理。

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

上图,显示了在Red Hat OpenShift 4.x中CRI-O如何工作。

K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址