Kubernetes是實現自己的容器還是使用Docker容器，還是兩者都使用？

Question

Kubernetes是實現自己的容器還是使用Docker容器，還是兩者都使用？

Kubernetes可以實現不是Docker容器的容器嗎？

Answer 1

Kubernetes是集群技術和容器編排工具。 它有助於部署容器，管理其生命周期，滾動更新，回滾，向上擴展，向下縮放，聯網，路由以及在容器內運行應用程序服務所需的所有其他功能。

Docker是一種虛擬化技術，使應用程序，運行時環境和依賴項全部捆綁在一起，並可以作為容器進行部署。

引擎蓋下的K8使用docker來部署容器。 除docker。外，還支持rkt和crio等其他容器技術

Answer 2

Kubernetes在現有的Docker容器上實現了一個包裝器，該包裝器名為pods。 使用pod而不是直接使用容器的原因是kubernetes需要更多信息來協調容器，例如restart policy ， liveness probe ， readiness probe 。 liveness probe定義了容器中的容器是否存活，重新啟動策略定義了容器失敗時的處理方法。 准備就緒探針定義容器已准備好開始服務。

因此，kubernetes並未將這些屬性添加到現有容器中，而是決定將包含所有必要附加信息的包裝器寫入容器。

Answer 3

Kubernetes可以實現不是Docker容器的容器嗎？

Kubernetes可以編排一個非Docker容器，這是因為cri-o

如Kubic中所述 ：

與您可能聽到的相反，有很多運行容器的方法，而不僅僅是docker工具。
實際上，有越來越多的選項，例如：

• runc ：一個CLI工具，用於根據OCI規范生成和運行容器。
  （ OCI：開放容器倡議 ：一種開放治理結構，明確目的是圍繞容器格式和運行時創建開放行業標准）

• 來自CoreOS的rkt現已死亡（2019年6月），並且存在多個未決的安全問題 。

• frakti ： Kubernetes的基於管理程序的容器運行時，它使Kubernetes可以通過runV在虛擬機管理程序中直接運行pod和容器。
  它重量輕且可移植，但是與基於linux-namespace的容器運行時相比，使用獨立內核可以提供更強的隔離性。

• cri-containerd ：Kubernetes容器運行時接口的容器化插件（它作為一個獨立的cri-containerd二進制文件開始，現已（ 自2018年3月起 ）報廢cri-containerd正在從一個可與containerd的獨立二進制文件過渡內插件containerd 。

• 和更多。

其中大多數遵循OCI標准，該標准定義了運行時如何啟動和運行容器 ，但是它們缺乏與編排器接口的標准方法 。
這使諸如kubernetes之類的工具變得復雜，該工具在容器運行時之上運行，以為您提供編排，高可用性和管理。

因此，Kubernetes引入了一個標准API，可以與容器運行時進行對話和管理。 該API稱為容器運行時接口（CRI），2016年12月 。

現有的容器運行時（例如Docker）使用“ shim”（ dockershim ）在Kubernetes和運行時之間進行接口，但是還有另一種方式，使用被設計為與CRI一起使用的接口。 這就是CRI-O出現的地方。

CRI-O簡介

CRI-O從一年多前開始，最初是一個Kubernetes孵化器項目，為符合OCI的運行時實現了CRI接口。
使用輕量級的runc運行時來實際運行容器，描述CRI-O的最簡單方法是作為Docker引擎的輕量級替代方案，特別是為與Kubernetes一起運行而設計的。

截至2018年9月6日， CRI-O不再是孵化器項目，而是Kubernetes工具家族的正式組成部分。

因此，有必要對cr-o進行嚴格的評估，以便獲得Kubernetes及其協調的容器之間的關系。

請參閱“ Cloud Native Computing Foundation采用CRI-O容器運行時+教程 ”

它包括體系結構架構：

啟動新Pod的順序

1. Kubernetes控制平面與kubelet接觸以發射吊艙。
2. kublet通過kubernetes CRI（容器運行時接口）將請求轉發到CRI-O守護程序，以啟動新的pod。
3. 然后，CRI-O使用containers/image庫從容器注冊表中提取圖像。
4. 使用容器/存儲庫將下載的圖像解壓縮到容器的根文件系統中。
5. 為容器創建rootfs之后，CRI-O會生成一個OCI運行時規范json文件，該文件描述了如何運行容器。
6. 然后，CRI-O使用該規范啟動OCI兼容運行時，以運行容器進程。
   目前，默認OCI運行時為runc 。
7. 每個容器都由單獨的conmon程序進行監視。
8. 通過使用CNI（容器網絡接口）來設置Pod的網絡 ，因此任何CNI插件均可與CRI-O一起使用。