談談Pod在微服務中的運用

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

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

1.咱們先來看一下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則是支持多個關係緊密進程很好的方式，更像是一個容器化的虛擬機。

Pod也提供探針功能，對容器服務進行健康檢查，目前有兩種方式：

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

好比一個容器服務對外提供Restful Service，服務可能會在某些狀況下hang或者響應時間變長，咱們就能夠定義一個URL做爲health check，一旦這個URL沒有正常響應，就認爲須要重啓服務，這時候就可使用 LivenessProbe。

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

在Pod的生命週期管理中，還提供了在容器啓動後(postStart) 和容器中止前(preStop)兩個handler，方便咱們在這兩個事件上添加自定義的hook操做。

好比咱們能夠定義在容器建立後，先執行一條命令把本身的應用複製到tomcat的webapps下，那麼直到這個hook操做完成，纔會進行容器啓動等後續操做。

2.接下來，咱們看看Pod有哪些主要的應用場景

Pod能夠用來承載垂直化的集成應用，好比LAMP，可是Pod的主要目的仍是支持須要一塊兒部署、一塊兒管理的輔助進程，包括：

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

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

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

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

若是但願瞭解更多相關解釋，推薦一篇關於這種容器組的設計模式的文章，也是微服務架構中很重要的思想：

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

下面咱們來看幾個實際的使用場景:

1）業務服務須要收集日誌

某服務模塊已經實現了一些核心的業務邏輯，而且穩定運行了一段時間，日誌記錄在了某個目錄下，按照不一樣級別分別爲 error.log、warning.log、info.log，如今但願收集這些日誌併發送到統一的日誌處理服務器上。

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

若是使用Pod的方式，經過簡單的編排，既能夠保持原有服務邏輯、部署方式不變，又能夠增長新的日誌收集服務。

並且若是咱們對全部服務的日誌生成有一個統一的標準，或者僅對日誌收集服務稍加修改，就能夠將日誌收集服務和其餘服務進行Pod編排，提供統1、標準的日誌收集方式。

這裏的「核心業務服務」、「日誌收集服務」分別是一個Docker鏡像，運行在隔離的容器環境中。

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

Docker Hub或者不少第三方的鏡像並無安裝sshd的服務，不方便咱們進入容器進行配置、代碼的修改、調試，不少時候須要從新構建鏡像、或者在鏡像基礎上安裝sshd的服務，這都須要時間和必定的學習成本。

而經過Pod的方式，咱們就能夠將現有鏡像和一個ssh、ftp鏡像進行編排，得到操做容器內數據的能力。

3）代碼自動更新

咱們部署了一個node.js的應用，並且部署了幾10、上百個節點，那麼我但願這個應用能夠定時的同步最新的代碼，以便自動升級線上環境。

這時，咱們固然也不但願改動原來的node.js 應用，能夠開發一個Git代碼倉庫的自動同步服務，而後經過Pod的方式進行編排，並共享代碼目錄，就能夠達到更新node.js應用代碼的效果。

而且這個同步服務還能夠同其餘使用Git代碼倉庫的服務編排，實現一樣的需求。

4）適配不一樣IaaS平臺的環境

咱們開發了一個節點管理的agent，這個agent須要讀取當前部署環境的一些信息，能夠經過底層平臺的API實現。

可是，當部署到AWS、阿里雲、青雲等不一樣平臺時，API就沒法統一了。這樣，咱們能夠實現不一樣平臺的適配服務來獲取各自的信息，而且和agent經過Pod編排部署，在不改變agent邏輯的狀況下，經過服務組合來適配於不一樣平臺。

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

3.最後，咱們一塊兒看看如何在時速雲平臺上進行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的這些特性，將服務進行更細力度的拆分，經過編排加強服務模塊，這樣既能夠減小重複的開發工做，下降服務的藕合度，也可使咱們的系統更輕量、更靈活。

Q&A

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來改變默認大小。