Kubernetes是实现自己的容器还是使用Docker容器，还是两者都使用？

Question

Kubernetes是实现自己的容器还是使用Docker容器或同时使用两者？

Kubernetes可以实现不是Docker容器的容器吗？

Answer 1

Kubernetes是一项集群技术和一个容器编排工具。它有助于部署容器，管理其生命周期，滚动更新，回滚，向上扩展，向下扩展，联网，路由以及在容器内运行应用程序服务所需的所有其他功能。

Docker是一种虚拟化技术，使应用程序，运行时环境和依赖项全部捆绑在一个n映像中，可以作为容器进行部署。

引擎盖下的K8使用docker来部署容器。除了docker。之外，还支持rkt和crio等其他容器技术

Answer 2

  

Kubernetes可以实现不是Docker容器的容器吗？

Kubernetes可以编排一个不是Docker容器的容器，这是由于 cri-o

如Kubic中所述：

  

与您所听到的相反，除了docker工具之外，还有更多的方法来运行容器。
  实际上，有越来越多的选项，例如：

• runc：一种CLI工具，用于根据 OCI 规范生成和运行容器。
  （OCI: Open Container Initiative：一个开放的治理结构，其明确目的是围绕容器格式和运行时创建开放的行业标准）

• rkt from CoreOS，现在（2019年6月）几乎死亡，死者为multiple pending security issues。

• frakti：用于Kubernetes的基于管理程序的容器运行时，它使Kubernetes可以通过 runV 直接在管理程序内部运行pod和容器。
  它重量轻且可移植，但与基于linux-namespace的容器运行时相比，具有独立内核的隔离能力更强。

• cri-containerd：Kubernetes容器运行时接口的容器化插件（它以独立的cri-containerd二进制文件的形式开始使用，现在已经失效（since March 2018）。{ {1}}正在从与cri-containerd通信的独立二进制文件过渡到内部 containerd的插件。

• 等等。

  

其中大多数遵循OCI standard定义runtimes start and run your containers的方式，但是它们缺乏与协调器交互的标准方式。
  对于诸如kubernetes之类的工具而言，这使事情变得复杂，该工具在容器运行时之上运行，以为您提供编排，高可用性和管理。

     

因此，Kubernetes引入了一个标准API，可以与容器运行时进行对话和管理。该API称为Container Runtime Interface (CRI), Dec. 2016。

     

诸如Docker之类的现有容器运行时使用“ shim”（dockershim）在Kubernetes和运行时之间进行接口，但是还有另一种方式，使用被设计为与CRI一起使用的接口。这就是CRI-O出现的地方。

     

CRI-O简介

     

CRI-O从一年前开始，最初是一个Kubernetes孵化器项目，为符合OCI的运行时实现了CRI接口。
  通过使用轻量级的runc运行时来实际运行容器，描述CRI-O的最简单方法是作为Docker引擎的轻量级替代方案，特别是设计用于与Kubernetes一起运行。      

从6th Sept 2018到CRI-O，它不再是一个孵化器项目，而是Kubernetes工具家族的正式组成部分。

因此，要了解Kubernetes及其协调的容器之间的关系，请务必进行严格的Cr-o操作。

请参见“ Cloud Native Computing Foundation adopts CRI-O container runtime+tutorial”

它包括架构模式：

  

启动新广告连播的顺序

     

  
1. Kubernetes控制平面与kubelet接触以发射吊舱。
  
2. containerd通过kubernetes CRI（容器运行时接口）将请求转发到CRI-O守护程序，以启动新的pod。
  
3. CRI-O然后使用kublet库从容器注册表中提取图像。
  
4. 使用容器/存储库将下载的图像解压缩到容器的根文件系统中。
  
5. 为容器创建rootfs之后，CRI-O会生成一个OCI运行时规范json文件，描述如何运行容器。
  
6. 然后，CRI-O使用该规范启动OCI兼容运行时，以运行容器进程。
     目前，默认OCI运行时为containers/image。
  
7. 每个容器都由单独的 conmon 过程进行监控。
  
8. 通过使用CNI (Container Network Interface)设置了Pod的联网功能，因此任何CNI插件均可与CRI-O一起使用。
  

Answer 3

Kubernetes在现有docker容器上实现了一个包装器，该包装器称为pods。使用pod而不是直接使用容器的原因是kubernetes需要更多信息来编排restart policy，liveness probe，readiness probe等容器。 liveness probe定义了pod内的容器是否存活，重新启动策略定义了容器失败时的处理方法。准备就绪探针定义容器已准备好开始投放。

因此，不是将这些属性添加到现有容器中，kubernetes决定将具有所有必要附加信息的包装器写入容器。