k8s作為現在最火的容器編排調度平臺，好用我也就不必多說了。當我們初識k8s的時候壹個新的概念就到了我們眼前，那就是pod。我們在使用了之後也就漸漸的接受了pod這個東西，但是妳有沒有想過，為什麽是pod？k8s為什麽會有這樣的設計？今天我們就來細細說說這個pod
首先我們來回憶看看k8s的架構圖是什麽樣子的
從架構圖中我們可以看到，整個k8s的設計架構有以下幾個要點：
當然其他組件都非常重要，這個我們以後再說，我們今天就來看看主角“pod”
壹開始用的時候我就好奇為什麽k8s要弄出壹個pod，因為我們壹開始使用的是docker，操作的是docker容器，構建的也是docker鏡像，為什麽不直接調度docker容器就好了，這樣粒度不是更加細致，調度也會更加方便嗎？
我們在使用k8s之前也使用過docker-compose，從另壹個角度說，這也是壹種容器的管理，看起來也挺好的。
下面我們就來說說pod
從上面的圖妳大概可以感受到pod在k8s中其實是壹個什麽樣的角色。
我們如果使用虛擬機，那麽上面就會有壹系列的服務這些服務可能會有壹些依賴，而這樣的依賴就好像在服務器中運行的壹個個進程組，往往其中也有著相關的依賴，而pod中的容器也是壹樣的道理，其中也會有類似這樣的依賴，為了更好的描述和管理這樣的依賴，於是就有了pod。
其實這樣的理念往往可以類比出很多這樣的設計。
壹定會有這樣的關系嗎？我的感覺是，在現代技術服務的開發的過程中，這樣的關系是不可避免的。我下面來舉幾個例子。
我們知道 java 的 web 應用往往需要部署在tomcat這樣的容器之中，在 springboot 還沒有出現以前，需要自己啟動壹個 tomcat 容器，然後將需要部署的應用打包部署到容器中去。
在以前妳可能會想著，將 javaweb 打包壹個war，然後編寫壹個 dockerfile 將 war 包cp到 tomcat 中的 webapp 目錄中。但是這樣帶來的就是每次更新發布的時候，鏡像會很大，因為每次構建都會有壹個基礎的tomcat鏡像。
而在k8s使用的時候，會有的設計的是，將tomcat作為壹個不變的鏡像（它也不應該改變）而把 war 包作為另外壹個容器，而這樣個容器同時掛載同壹個目錄，將 webapp 掛載的目錄與 war包掛載的目錄相同來達到目的，然後將他們放到同壹個 pod 中。
類似的操作還有： municate-containers-same-pod-shared-volume/ 裏面說的就是前端靜態頁面和 nginx 的關系。
下面引用官網設計理念中的壹句話：“ 比如妳運行壹個操作系統發行版的軟件倉庫，壹個Nginx容器用來發布軟件，另壹個容器專門用來從源倉庫做同步，這兩個容器的鏡像不太可能是壹個團隊開發的，但是他們壹塊兒工作才能提供壹個微服務；這種情況下，不同的團隊各自開發構建自己的容器鏡像，在部署的時候組合成壹個微服務對外提供服務。 ”
在使用 docker 部署項目的時候會遇到壹個問題就是日誌持久化的問題，因為 docker 容器如果被刪除的話，其中的文件也會被刪除，那麽我們的日誌文件同時也會被刪除，也就是說我們必須要將日誌持久化。
最常見的方式是，將日誌存儲的目錄掛載到宿主機上，這樣容器被刪除的時候日誌不會被刪除。
而在k8s中常見的日誌處理架構是怎麽樣的呢？
es.io/zh/docs/concepts/cluster-administration/logging/
使用的是 sidecar，這個是什麽呢？其實就是壹個輔助性質的容器，同時與主容器放在同壹個 pod 中，讀取主容器掛載出來的日誌目錄。其實後續還可以做更多的操作，比如日誌發送es等等。
總之我們可以看到，在壹個pod中的容器關系是非常密切的，他們可以擁有同壹個目錄，甚至可以擁有同壹個網絡，可以擁有相互的服務，這樣的關系我聽過的名詞叫做“超親密關系”。就類似壹對夫妻之間的關系了。
因為在現在的多說應用中，已經幾乎做不到壹個人頂天立地了，總是會有各種各樣的依賴，依賴壹些組件，依賴壹些工具，依賴壹些網絡服務等等，壹個進程組有很多的進程互相幫助來最終實現功能壹樣。
這樣的關系太過常見，於是k8s就將它設計為了pod。
如果妳已經對docker的實現比較熟悉，其實pod的實現並不復雜。（如果對docker實現不熟悉可以翻看之前的博客）
其實pod是壹個邏輯上的概念，其實pod做的事情很簡單：
其實k8s做的就是初始化壹個infra的容器（這是壹個很小的容器），利用這個容器去搶先占用需要使用的 Namespace ，然後在將用戶指定的容器加載進來，同時使用的就是相同的 Namespace 了。（如果有 InitContainer 會優先按順序初始化它，圖上就不做說明了）
這樣***享網絡應該是沒有問題了，那麽要***享Volume也很簡單。pod 只需要將 Volume 目錄掛載到宿主機，讓內部的容器掛載這個目錄就可以了。
再來說說pod還有哪些功能，這些功能也是k8s為什麽設計pod的原因之壹
通過Probe：LivenessProbe或者ReadinessProbe，可以探測應用是否處於健康狀態，如果不健康做出相關的反應。
這就好比k8s可以定期的幫妳監控、維持壹整個應用的健康。
其實在我們看來，很多時候服務掛了，需要重啟，需要做高可用，那麽nginx呢？tomcat呢？也是壹樣的。所以pod的健康能保證整個服務的全部健康使用。
我們可以通過給Pod增加kubernetes.io/ingress-bandwidth和kubernetes.io/egress-bandwidth這兩個annotation來限制Pod的網絡帶寬。
為什麽我提到了這個功能呢？因為在實際的業務開發過程中經常會使用壹些網絡插件，這些網絡插件在流量的控制上非常有用，有的時候我們會根據網絡流量來做壹系列的操作，用戶的突然增長導致的流量劇增是否要擴容等等...而這樣的監控和限制對於pod來說無疑會更加方便，而不需要管pod內部的容器的流量。
重啟的策略，這個也算是壹個功能吧
官網：壹個Pod（就像壹群鯨魚，或者壹個豌豆夾）。
我覺得 Pod 更證明了壹種設計模式“組合”，在有的時候會，組合的合理，就會方便很多東西，比如設計了壹堆組件，組合在壹起；ps畫圖的時候方塊更圓組合在壹起，就可以壹起多復制幾個組合。
當然我們在認識到為什麽要這樣設計 Pod 的同時需要意識到，我們應該將什麽樣的容器組合放置在同壹個 Pod 之中才比較合適。遵循壹定的“容器設計模式”進行編排，調度的時候才會更加得心應手。