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

传统上,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适配器。

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

图片由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命名空间。

Kubernetes 的详细介绍:请点这里
Kubernetes 的下载地址:请点这里

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

相关推荐