Kubernetes 提供了另一种容器运行时

  • Hrishikesh Barua
  • Rays

2017 年 5 月 9 日

话题:DevOpsKubernetes

传统上,Kubernetes容器运行时是绑定到 Docker 和 rkt 的。但是在过去数月中,这一情况发生了变化。Kubernetes 发布了自己的容器运行时接口(CRI,Container Runtime Interface)API,同时正在完成一个称为CRI-O的实现,力图构建 Kubernetes 和 OCI 兼容运行时之间的桥梁。这为 Kubernetes 以标准方式使用任何 OCI 兼容容器运行时铺平了道路。

Kubernetes 依赖于底层的容器运行时实现生命周期控制,例如 Pull、创建、删除等操作。运行时实现为实际的容器,从操作系统层面管理命名空间隔离和资源分配。早期,Docker 和 rkt 是通过非公开的 API紧密集成到 Kubernetes 源代码中的。要添加其它的运行时需要修补源代码,这是非常繁琐的,并且稳定性没有保证。为改进这一问题,在 Kubernetes 1.5 中以公开发表测试特性的形式引入了 CRI。CRI 提供了将容器运行时插入 Kubernetes 系统的通用接口,使用户可以运行 kubernetes 去编排并扩展他们的非 Docker 和非 rkt 架构。运行时也可以是runv这样的基于容器的 Hypervisor。

开放容器联盟(OCI,Open Container Initiative)是一个为标准化容器格式和运行时而组建的工业界联盟,它发布了容器运行时标准“runtime-spec”。当前该标准的实现包括runc、HyperHQ的 runv 以及一种基于 Intel Clear Containers的实现。CRI-O 项目是由Project Atomic/RedHat所启动的,还包括其它来自工业界的贡献者。它使用 OCI 兼容的运行时实现 Kubernetes CRI API,这意味着任何 OCI 兼容的运行时都可以通过 Kubernetes 的 CRI API 插入到 Kubernetes 中,而不必对每个运行时分别实现一个 CRI 适配器。

当前,Kubernetes 的 CRI 具有如下实现:

  • CRI-O:符合 OCI 的运行时;
  • rktlet:rkt 容器运行时;
  • Frakti:一种基于 Hypervisor 的容器运行时;
  • Docker CRI shim:支持 Docker 直接充当 CRI 适配器。

图片由http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html提供。

在 Kubernetes 部署中,Kubelet(在 Kubernetes 中称为 Minion)是在每台主机上的本地代理,与容器运行时进行通信。使用 CRI 后,Kubelet 可以通过 gRPC(一种开源的 RPC 框架)与 CRI 垫片(Shim)通信,其前端调用实际的运行时。Pod 是 Kubernetes 中的最小部署单元,其概念已经扩展为一个具有类似语义的概念,称为 PodSandbox。对于基于 Hypervisor 的运行时,PodSandbox 可理解成一个虚拟机。对于 Docker 等运行时,PodSandbox 可理解为 Linux 命名空间。

查看英文原文:Alternative Container Runtimes in Kubernetes

DevOpsKubernetes