為什麼Kubernetes要引入pod的概念，而不直接操作Docker容器
首先我們要明確一個概念，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的原創文章，請關注公眾號"汪子熙":
