首先我們要明確一個概念，Kubernetes并不是只支持Docker這一個容器運行時，通過我的另一篇文章什么是Kubernetes的CRI-容器運行時接口介紹的內容，我們知道Kubernetes通過CRI這個抽象層，支持除Docker之外的其他容器運行時，比如rkt甚至支持客戶自定義容器運行時。因此，借助CRI這個抽象層，使得Kubernetes不依賴于底層某一種具體的容器運行時實現技術，而是直接操作pod，pod內部再管理多個業務上緊密相關的用戶業務容器，這種架構便于Kubernetes做擴展。這是第一個原因。

第二個原因，我們假設Kubernetes沒有pod的概念，而是直接管理容器，那么一組容器作為一個單元，假設其中一個容器死亡了，此時這個單元的狀態應該如何定義呢？應該理解成整體死亡，還是個別死亡？

這個問題不易回答的原因，是因為包含了這一組業務容器的邏輯單元，沒有一個統一的辦法來代表整個容器組的狀態，這就是Kubernetes引入pod的概念，并且每個pod里都有一個Kubernetes系統自帶的pause容器的原因，通過引入pause這個與業務無關并且作用類似于Linux操作系統守護進程的Kubernetes系統標準容器，以pause容器的狀態來代表整個容器組的狀態。

第三也就是最后一個原因，pod里所有的業務容器共享pause容器的IP地址，以及pause容器mount的Volume，通過這種設計，業務容器之間可以直接通信，文件也能夠直接彼此共享。

Kubernetes里的每個pod都有唯一的IP地址。Pod的IP地址可以通過命令kubectl describe pod來查看：

這個IP地址用來支持Kubernetes的底層網絡借助Flannel,openswitch等虛擬二層網絡技術來實現集群內任意兩個pod之間的TCP/IP通信。也就是說，一個Pod內的容器與另外主機的pod容器能夠直接通信。

Pod被創建后，會被Kubernetes master調度到某個具體的node上進行綁定：

上圖中藍色高亮區域代表的就是這個被觀察的pod被分配到的node的名稱。

pod和node綁定之后，node上的kubelet進程會對pod進行初始化操作，啟動相關的Docker容器。

上圖紅色區域顯示了Docker容器從正在從遠端pull鏡像，到pull完成，到創建Docker容器運行實例，到最終啟動實例的狀態遷移過程。
要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":

總結

以上是生活随笔為你收集整理的为什么Kubernetes要引入pod的概念，而不直接操作Docker容器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。