摘要：本文整理自時速云線上微信群分享第十期本文主要包括的基本概念使用場景，以及如何在時速云平臺上進行的編排部署，希望對大家在進行微服務架構實踐時有所幫助。問關于提供訪問容器數據的能力，中包含一個業務和一個服務，時速云的控制臺可以進入到容器內部。

本文整理自【時速云線上微信群分享】第十期

本文主要包括Pod的基本概念、使用場景，以及如何在時速云平臺上進行Pod的編排部署，希望對大家在進行微服務架構實踐時有所幫助。

Pod是 Kubernetes為部署、管理、編排容器化應用提出的概念，也是Kubernetes中的最小部署單元，直譯過來的意思是“豆莢”，既簡單又實用。

Pod是由一組緊耦合的容器組成的容器組，當然目前最流行的就是Docker容器，Pod就可以作為1或者多個Docker 容器的載體，當然也支持CoreOS的 rkt，并很容易擴展支持更多容器技術。

Pod中的所用容器會被一致調度、同節點部署，并且在一個“共享環境”中運行。這里的“共享環境”包括以下幾點：

1）所有容器共享一個IP地址和端口空間，意味著容器之間可以通過localhost高效訪問，不能有端口沖突

2）允許容器之間共享存儲卷，通過文件系統交互信息

3）容器之間可以通過IPC（inter-process communication)進行通信（目前這個feature還沒有實現，主要依賴于Docker對容器之間進程通信的支持，在Docker社區有issue track）
所以，如果按照每個Docker容器一個process的建議，Pod則是支持多個關系緊密進程很好的方式，更像是一個容器化的虛擬機。

1）LivenessProbe，用來檢測服務是否正常運行，如果定義的規則失敗了，系統就會殺掉這個容器，默認情況下自動創建一個新的容器。

比如一個容器服務對外提供Restful Service，服務可能會在某些情況下hang或者響應時間變長，我們就可以定義一個URL作為health check，一旦這個URL沒有正常響應，就認為需要重啟服務，這時候就可以使用 LivenessProbe。

2）ReadinessProbe，用來標識容器是否準備好提供正常服務，如果沒有啟動完成檢測失敗，系統會將該服務節點從服務代理的列表中刪除，用戶的請求就不會路由到該節點了。Pod定義和LivenessProbe類似：

在Pod的生命周期管理中，還提供了在容器啟動后(postStart) 和容器停止前(preStop)兩個handler，方便我們在這兩個事件上添加自定義的hook操作。

比如我們可以定義在容器創建后，先執行一條命令把自己的應用復制到tomcat的webapps下，那么直到這個hook操作完成，才會進行容器啟動等后續操作。

Pod可以用來承載垂直化的集成應用，比如LAMP，但是Pod的主要目的還是支持需要一起部署、一起管理的輔助進程，包括：

1）內容管理系統，文件和數據加載進程，本地cache管理進程等

2）日志壓縮、rotation、備份、快照等

3）數據變化監聽、日志和監控適配器，事件分發等

4）控制、管理、配置、升級程序

如果希望了解更多相關解釋，推薦一篇關于這種容器組的設計模式的文章，也是微服務架構中很重要的思想：

http://blog.kubernetes.io/201...

1）業務服務需要收集日志

某服務模塊已經實現了一些核心的業務邏輯，并且穩定運行了一段時間，日志記錄在了某個目錄下，按照不同級別分別為 error.log、warning.log、info.log，現在希望收集這些日志并發送到統一的日志處理服務器上。

這時我們可以修改原來的服務模塊，在其中添加日志收集、發送的服務，但這樣可能會影響原來服務的配置、部署方式，從而帶來不必要的問題和成本，也會增加業務邏輯和基礎服務的藕合度。

如果使用Pod的方式，通過簡單的編排，既可以保持原有服務邏輯、部署方式不變，又可以增加新的日志收集服務。

而且如果我們對所有服務的日志生成有一個統一的標準，或者僅對日志收集服務稍加修改，就可以將日志收集服務和其他服務進行Pod編排，提供統一、標準的日志收集方式。

這里的“核心業務服務”、“日志收集服務”分別是一個Docker鏡像，運行在隔離的容器環境中。

2）提供ssh、ftp訪問容器數據的能力

Docker Hub或者很多第三方的鏡像并沒有安裝sshd的服務，不方便我們進入容器進行配置、代碼的修改、調試，很多時候需要重新構建鏡像、或者在鏡像基礎上安裝sshd的服務，這都需要時間和一定的學習成本。

而通過Pod的方式，我們就可以將現有鏡像和一個ssh、ftp鏡像進行編排，獲得操作容器內數據的能力。

3）代碼自動更新

我們部署了一個node.js的應用，而且部署了幾十、上百個節點，那么我希望這個應用可以定時的同步最新的代碼，以便自動升級線上環境。

這時，我們當然也不希望改動原來的node.js 應用，可以開發一個Git代碼倉庫的自動同步服務，然后通過Pod的方式進行編排，并共享代碼目錄，就可以達到更新node.js應用代碼的效果。

并且這個同步服務還可以同其他使用Git代碼倉庫的服務編排，實現同樣的需求。

4）適配不同IaaS平臺的環境

我們開發了一個節點管理的agent，這個agent需要讀取當前部署環境的一些信息，可以通過底層平臺的API實現。

但是，當部署到AWS、阿里云、青云等不同平臺時，API就無法統一了。這樣，我們可以實現不同平臺的適配服務來獲取各自的信息，并且和agent通過Pod編排部署，在不改變agent邏輯的情況下，通過服務組合來適配于不同平臺。

其實，Kubernetes 的一些新的功能需求，也會建議先通過Pod的編排來解決，而不是直接修改Kubernetes的代碼，可見Pod還是用處多多的。

1）登錄到時速云公有云平臺，通過右側的導航，選擇“服務編排” -> “公有編排”，其中分為”Pod編排“和“Stack編排”兩類，點擊“Pod 編排”可以看到官方示例”ubuntu-mysql”，這個模版會將ubuntu和mysql兩個容器編排在一個Pod中。

2）點擊“部署”，可以預覽yaml格式的編排文件：

其中關鍵是存儲卷的配置，我們需要提前創建這個存儲卷，并修改yaml中的 disk 屬性，以匹配自己的存儲卷。

如果我們需要修改存儲卷名稱，或者對其他鏡像進行編排，可以復制這個模版，創建自己的Pod編排。注意：目前只有北京2區、杭州區支持存儲卷功能，所以請在這兩個區創建存儲和部署Pod。

創建成功后，可以在容器服務的列表中看到一個“多容器服務”：

點擊“查看所有服務地址”，可以看到對應的mysql和ubuntu的訪問地址。

通過ssh 登陸到22端口對應的服務地址，就可以直接訪問到mysql的數據了。

并且存儲卷中的數據會保存在獨立的分布式存儲系統中，保證數據的安全和高可用。

詳細信息可以參考官方文檔：

http://doc.tenxcloud.com/doc/...

所以，我們可以在很多實際的部署場景中充分發揮Pod的這些特性，將服務進行更細力度的拆分，通過編排增強服務模塊，這樣既可以減少重復的開發工作，降低服務的藕合度，也可以使我們的系統更輕量、更靈活。

1.問：關于“提供ssh、ftp訪問容器數據的能力”， pod中包含一個業務container和一個ssh服務container，時速云的控制臺可以進入到容器內部。那么ssh進入的container只是提供ssh服務的container，好像也沒辦法ssh到業務container。

答：業務應用Container和ssh服務container共享數據存儲，可以通過ssh訪問共享存儲，這樣也避免了修改“業務應用”中的不可變運行環境。（參考“不可變基礎設施”）

2.問：pod和swarm的最大區別是什么？我感覺差不多，是不是Pod更偏上層一些？

答：兩者沒有可比性。Pod只是一種容器的部署、管理方式，是kubernetes的最小部署和管理單元，是一組容器的集合；swarm是容器編排工具，和kubernetes屬于同一類。

3.問：一個pod最好包含幾個容器？啟動pod的配置文件里面能不能定義容器的大小？

答：Pod里面多少個容器理論上沒有特別的限制，目前我們一般是2-3個。Pod里面定義的容器，基本上就是對Docker容器的定義。Pod中支持Docker容器本身的絕大部分參數，比如cpu、memory、是否privilege、是否root等。Pod對Docker容器基本參數有所刪減，但從更高的層面進行了擴展。具體可以查看kubernetes文檔。

4.問：Pod中定義容器時包括pause嗎

答：每個Pod都會附帶一個pause容器，pause容器不執行實際的業務邏輯，只是對pod的網絡、IO等進行控制。

5.問：時速云對docker hub上的鏡像部署，也能提供ssh到容器內部的功能么？我的理解是，“打開web控制臺”是ssh到容器里。

答：嗯，web控制臺和ssh并不一樣。如果你使用scp、sftp傳送文件，則需要容器內安裝sshd服務。

6.問：Pod沒用過，不過用過docker compose， 它們倆有什么區別？

答：compose不支持緊耦合的容器組，也不支持容器共享存儲。

7.問：能定義容器（磁盤）的大小嗎？如果有的話，在哪兒修改？

答：docker daemon的參數包含磁盤的定義，指定devicemapper的option來改變默認大小。