為什么需要Pod？

Pod是K8S的調度單位。

回顧容器和K8S的關系

• 容器的本質？
  • 一個視圖被隔離，資源受限的進程
  • 容器里PID=1的進程就是應用本身
    • 管理虛擬機=管理基礎設施
    • 管理容器=直接管理應用
• K8S？
  • K8s是云時代的操作系統
  • 容器鏡像是K8S這個操作系統的軟件安裝包

真實操作系統的例子

• 一個Helloworld程序由多個進程組成
• 四個進程共享helloworld的資源，相互協作，完成helloworld的工作

兩者對比

• k8s=操作系統
• 容器=進程
• pod=進程組

進程組

• 對于上面擁有4個進程的helloworld程序，怎么用容器跑起來？
• 方法一：在一個docker里面啟動4個進程
  • 問題：容器是單進程模型，PID=1的進程比如說是main進程，其他三個進程怎么管理？
  • 解決方法：
    • 應用程序本身具有進程管理的能力，helloworld程序具備systemd的能力。
    • 或者，PID=1的進程改為systemd
      • 這樣，管理容器=管理systemd！=直接管理應用本身。

Pod=進程組

來自Borg的思考

Borg部署的應用，往往存在著類似進程與進程組的關系，必須部署在同一臺機器上，共享一些信息。

為什么Pod是原子調度單位？

• 舉例：兩個容器緊密合作
  • App，業務容器，寫日志
  • Log，轉發日志到ES
• 內存要求
  • APP：1G
  • Log：0.5G
• 可用內存
  • Node_A : 1.25G
  • Node_B : 2G
• 如果App被調度到了Node_A上，Log資源不足就調度不過來了
• Task co-scheduling問題的解決方案
  • Mesos：資源囤積（reource hoarding）
    • 所有設置了Afinity約束的任務都達到了，才開始統一調度
    • 問題：調度效率損失、死鎖
  • Google Omega：樂觀調度處理沖突
    • 先不管沖突，在沖突發生時會有機制進行回滾來處理問題
    • 問題：負載
  • K8S：Pod打包部署

再次理解Pod

• 親密關系-調度解決
  • 兩個應用需要部署在同一個宿主機上
• 超親密關系-pod解決
  • 會直接發生文件交換
  • 會使用localhost或socket文件進行本地通信
  • 會頻繁的RPC調用
  • 會共享某些Linux namespace（一個容器加入另一個容器的network namespace，這樣就可以看到對方的網絡設備）

Pod的實現機制

Pod要解決的問題

• 如何讓一個Pod里的容器之間最高效地共享某些資源和數據？
  • 容器之間是被Linux Namespace和cgroups隔離開的

1 共享網絡

• 容器A和B
  • 通過Infra Container的方式共享同一個Network Namespace
    • 鏡像：k8s.gcr.io/pause；匯編語言編寫的，永遠處于暫停狀態，大小100-200KB
  • 直接使用localhost通信
  • 看到的網絡設備和Infra容器看到的完全一樣
  • 一個Pod只有一個IP地址，也就是這個pod的Network Namespace對應的IP地址
    • 所有網絡資源，都是一個Pod一份，被該Pod中的所有容器共享
  • 整個Pod的生命周期和Infra容器一致，而與容器A和B無關

2 共享存儲

• 設置一個Pod級別的Volumn
• 各個容器去掛載這個Volumn，然后就可以看到（/opt/tiger/...）

詳解容器設計模式

舉例：WAR包+Tomcat的容器化

• 方法一：把WAR包和Tomcat打包進一個鏡像
  • 無論是WAR更新和Tomcat更新都需要重新制作鏡像
• 方法二：鏡像里只打包Tomcat，用數據卷容宿主機上將WAR包掛載進Tomcat容器
  • 需要分布式存儲系統
• 更通用的做法？

InitContainer

• InitContainer會比spec.containers定義的用戶容器先執行，并且嚴格按照定義的順序依次執行
• /app是個Volumn
• Tomcat容器同樣掛載了該Volumn到自己的webapps目錄下
• 當Tomcat容器啟動是，它的webapp目錄下就一定會有sample.war

容器設計模式：Sidecar

• 通過在Pod里定義專門容器，來執行主業務容器需要的輔助功能
• 比如：
  • Init Container把war包復制到Volumn里面
  • 需要SSH進去執行的腳本
  • 日志收集
  • Debug應用
  • 應用監控
• 優勢：
  • 將輔助功能和祝業務容器解耦，實現獨立發布和能力重用

Sidecar：應用與日志收集

• 業務容器將日志寫在Volumn里
• 日志容器共享該Volumn從而將日志轉發到遠程存儲當中
  • Fluentd等

Sidecar：代理容器

• 代理容器對業務容器屏蔽被代理的服務集群（consul、服務發現？），簡化業務代碼的實現邏輯
• 提示：
  • 容器之間通過localhost直接通信
  • 代理容器的代碼可以被全公司重用

Sidecar：適配器模式

• 適配器模式將業務暴露出來的接口轉化為另一種格式
• 舉例：
  • 業務暴露出來的監控接口是/metrics
  • 監控系統需要的接口是/healthz
  • monitoring adapter將/metrics轉化為/healthz以適配新的監控系統
• 提示：
  • 容器之間通過localhost通信
  • 代理容器的代碼可以被全公司重用

總結

• Pod是K8s項目里實現容器設計模式的核心機制
• 容器設計模式是K8s進行復雜應用編排的基礎依賴
• 所有設計模式的本質都是：解耦和重用

總結

以上是生活随笔為你收集整理的Pod和容器设计模式的全部內容，希望文章能夠幫你解決所遇到的問題。

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