传统上， 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 命名空间。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论