簡介
容器並不是軟件開發的銀彈，沒有任何一種技術能解決軟件開發中的所有問題
當我們採用容器化技術的時候，摒棄了傳統的物理機或者虛擬機的部署方式，以一種更加輕快，便捷的方式來部署我們的應用。到容器化的進階，再加上kubernetes對容器的編排技術，使得容器化的利益進一步擴大。但是對於kubernetes來說，直接調度編排管理的基本單位並非容器，而是另外一種結構體。
假設容器中同時運行著多個不相關的進程，這些進程的持續運行，管理，以及輸入輸出日誌會是容器的責任。如果這些不相關的進程同時都有標準的輸出，而此時我們很難確定每個進程具體輸出了什麼內容。另一方面，每個容器是一個邏輯的運行單位，有著自己的命名空間，IP以及端口和其他信息，假如非一個團隊開發的不同進程監聽了相同的端口號，必將發生資源的爭奪衝突。雖然多個進程運行在同一個容器中，無論是通過進程間通信還是通過存儲文件進行共享文件都很容易，但是Docker和kubernetes還是期望每個進程都運行在自己的容器中，除非是和自己相關的子進程。如果你的多個進程有著依賴關係（例如：一個進程的啟動依賴於另外一個進程），這樣的多個進程推薦運行在相同的容器中。
由於不推薦將無關的進程運行在同一個容器中，但是特殊情況下還存在要求多個相關進程運行於同一個容器的需求，kubernetes提供了一種更高級的結構來把容器捆綁在一起，並將這種結構作為調度部署的基本單元，這個結構就是Pod。
Pod是一組並置的容器，是kubernetes中基本的構建模塊。但是這並不意味著一個Pod總是包含多個容器，在實際應用中每個Pod只有一個容器是最常見的部署方式。這裡要注意一點，雖然對於kubernetes來說，並不關心Pod位於哪個節點上，但是一個Pod的多個容器位於多個節點是不允許的，換句話說，同一個Pod的多個容器總是運行在同一個集群節點上。
kubernetes部署和操作的基本單位是Pod
隔離
相同Pod下運行的容器之間可以共享一些資源，但是並非全部資源（話句話說，這些容器並非完全隔離的），kubernetes通過配置可以讓同一個Pod內的容器共享相同的linux命名空間和network等資源，所以這些容器共享相同的主機名和網絡接口，話句話說，這些容器在Pod中可以進行IPC通信，就像在局域網中一樣。既然共享相同的IP和端口號，那麼多個容器就不能綁定到相同的端口，否則會出現端口衝突，所以這也是官方推薦一個Pod只運行一個容器的原因之一。
每個Pod都有自己獨立的Ip和端口空間，所以不同的Pod內的容器永遠不會發生端口衝突。同一個Pod中的容器具有相同的loopback，因此可以通過localhost與同一Pod中的其他容器進行通信
Pod網絡
在同一個kubernetes集群中的Pod就和局域網內的每臺服務器一樣，他們共享一個網絡地址空間，這個網絡是通過軟件基於真實鏈路來實現的。所以只要知道一個Pod的IP地址就可以進行訪問，這個通信過程不通過網關，在通信上性能非常好。由於kubernetes把資源進行了抽象，所以Pod無論位於哪個服務器節點上，對於同一個集群內的Pod來說都一樣。
Pod使用多個容器
在多數情況下，我還是建議每個Pod運行一個容器，但是如果你的多個容器有互相依賴關係（比如一個容器的啟動依賴於另外一個容器），就需要把多個容器部署到一個Pod。一個Pod中運行一個容器更多的是基於應用分層的考慮，例如：一個應用的容器需要調用一個數據庫的容器，這兩個容器應該分配到不同的Pod中，不僅僅是為了提高集群機器的利用率，更是為了之後不同層次的擴容。對於kubernetes來說，操作和部署的基本單位是Pod，所以kubernetes擴容的單位是Pod並非容器，如果我們的應用層有性能瓶頸，我們就可以單獨的對應用層的Pod進行單獨擴容，其他層的Pod保持不變，這不僅僅是節省資金成本的問題了，而是橫向擴展的靈活性問題。
●程序員修神之路--打通Docker鏡像發佈容器運行流程
●程序員修神之路--容器技術為什麼會這麼流行(記得去抽獎)
●程序員修神之路--kubernetes是微服務發展的必然產物
●程序員過關斬將--要想獲取我的用戶信息，就得按照規矩來
●程序員過關斬將--更加優雅的Token認證方式JWT
閱讀更多 心萊科技 的文章
