《Kubernetes與雲原生應用》系列之容器設計模式

http://www.infoq.com/cn/articles/kubernetes-and-cloud-native-app-container-design-pattern

 

《Kubernetes與雲原生應用》專欄是InfoQ向輕元科技首席架構師王昕約稿的系列文章。本專欄包含8篇內容，將會從介紹和分析Kubernetes系統以及雲原生應用入手，逐步推出基於Kubernetes的容器設計模式實踐案例，但願對計劃應用Kubernetes的朋友有所幫助。本文是該專欄的第三篇，閱讀本系列所有內容請在細說雲計算微信公衆號（CloudNote）回覆K8s。

1. Kubernetes系統架構與設計理念
2. 雲原生應用的設計理念與挑戰
3. Kubernetes與雲原生應用的容器設計模式
4. Kubernetes容器設計模式實踐案例-單節點多容器模式
5. Kubernetes容器設計模式實踐案例-多節點選舉模式
6. Kubernetes容器設計模式實踐案例-工做隊列模式
7. Kubernetes容器設計模式實踐案例-分散收集模式
8. 雲原生應用的容器設計模式綜述與展望

K8s與雲原生應用

過去兩年，容器和容器鏡像已經成爲了開發雲原生應用所必不可少的技術。K8s平臺的設計開發者以及K8s社區的技術人員，在不斷推動K8s做爲容器管理平臺的快速發展的同時，也在探索如何幫助應用的設計開發者更好地運用容器技術進行雲原生應用的開發。雲原生應用自己必然是分佈式系統，所以分佈式系統的經驗必然適用於雲原生應用；只是通常的雲原生應用，更多的藉助像K8s或Mesos這樣的平臺來解決主要的分佈式系統的問題。

 

筆者認爲K8s社區人員設計K8s系統是基於兩種很是重要的經驗：一是Google多年來運行大型分佈式系統的經驗，二是支撐快速更新、敏捷迭代的雲原生應用的經驗。前者保證了K8s系統自己的穩定性和擴展性，後者保證了K8s系統對其用戶，也就是雲原生應用的運維人員和開發人員的有效性。本文將主要介紹K8s系統對雲原生應用的支持。

K8s雲原生應用技術理念的支持

代碼倉庫與部署

雲原生應用理念要求嚴格區分應用的代碼和部署。在K8s集羣中與其相對應的就是Deployment操做對象。在K8s集羣中，每個微服務Service操做對象就是對應一個應用代碼倉庫，每一個Service對應多個Deployment，正好服務一個應用屢次部署的理念。

環境配置

雲原生應用理念要求將環境配置存在應用運行的環境中，在K8s集羣中，全部的環境配置都存在分佈式共享存儲Etcd中。K8s還有一些操做對象是用來專門存儲環境配置的。例如ConfigMap是存儲通用的配置變量的。ConfigMap有點兒像一個統一的配置文件，使用戶能夠將分佈式系統中用於不一樣模塊的環境變量統一到一個對象中管理；而它與配置文件的區別在於它是存在集羣的「環境」中的，而且支持K8s集羣中全部通用的操做調用方式。再好比Secret是專門用來存儲密鑰對象的，它使得在K8s集羣中用到密碼等私密信息時沒必要用明文環境變量來表示，從而增強密鑰傳遞和保存的安全性。

後臺支撐服務

雲原生應用理念要求將後臺支撐服務做爲掛載資源來使用。在K8s集羣中，全部的應用服務均可以被看成一種資源去訪問和引用。K8s集羣能夠經過SkyDNS在支持DNS域名服務，全部在集羣中部署的服務均可以經過以<name>.<namespace>模式的DNS域名來訪問。固然，後臺支撐服務也能夠是來自於集羣外。不論來自哪裏，這些服務均可以用以DNS:Port或IP:Port來標識的一個資源來表示，而資源的使用者能夠經過ConfigMap來存儲這個資源的配置，這樣須要訪問這個資源的應用就能夠同經過ConfigMap來引用這個資源。

無狀態微服務實例

雲原生應用理念要求應用是無狀態的，對應實際環境中，就是要求應用不該該將數據存儲在運行應用的主機節點上，全部狀態存儲在由雲環境統一管理的共享存儲之上，而這正是K8s中的微服務實例Pod的模型。在K8s集羣中，Pod能夠綁定多種存儲驅動，除了emptyDIR和hostPath之外，K8s支持的多種存儲驅動都是對接共享存儲的。因爲emptyDIR上存儲的東西是臨時可丟棄的，而hostPath主要用於測試，除此之外全部用於生產環境的存儲都是對接共享存儲的，所以能夠說，K8s的存儲機制是爲無狀態化的雲原生應用而設計的。

端口映射

雲原生應用理念要求應用能夠根據設定的端口直接對外發布服務。在K8s集羣中，集羣內部訪問服務的端口是經過ContainerPort屬性來設置的。對於須要集羣外客戶端訪問的服務，能夠有nodePort、loadBalancer和Ingress等模式接入外網訪問，其中nodePort是將服務發佈到K8s集羣中的每一個主機節點。

併發和水平擴展

雲原生應用理念要求應用能夠水平擴展以根據業務需求隨時擴展計算能力，而K8s的Replication Controller操做對象和Replica Set操做對象就是支持水平擴展能力的。

快速啓動和優雅終結

雲原生應用理念要求應用可以快速啓動和優雅地終結，這同時也要求雲平臺可以處理容器啓動和終結時的超時等故障狀況。在K8s集羣中，有兩個操做對象跟微服務實例的故障處理相關，一個是微服務實例Pod，另外一個是探針Probe。其中Pod的terminationGracePeriodSeconds屬性設置微服務終結時等待的時間，這段時間留給微服務自身在退出前釋放資源。其中Pod的activeDeadlineSeconds屬性設置微服務啓動時等待的時間，若是應用超過這個時間，就不符合「雲原生應用」的要求，要被雲平臺標識成啓動失敗了。Probe操做對象是K8s系統和應用用來檢查應用健康情況的。K8s系統提供兩種探針LivenessProbe和ReadynessProbe。前者探測容器是否還正常，後者探測容器是否能提供服務，前者是後者前提。

配置共享和環境隔離

雲原生應用理念要求儘可能保證開發、測試和生產環境的配置一致，可是同時這幾個不一樣的環境又應該是彼此隔離。在K8s集羣中，不一樣的環境能夠經過namespace進行隔離，保證彼此不互相干擾，例如能夠有dev、test、staging和production等4個不一樣環境。對於不一樣環境中應該保持相同的配置，能夠經過持續集成工具例如Jenkins Pipeline的腳本保持一致。

集中日誌處理

雲原生應用理念要求對應用日誌有集中的處理，這實際上是對應用管理平臺的要求。在K8s集羣中一個獲得普遍接受的日誌解決方案是fluentd+elasticsearch+Kibana的日誌收集處理方案，其中Fluentd用來收集日誌，Elasticsearch用來存儲、索引和查詢日誌，Kibana用來以圖形界面展現日誌的統計信息。

管理服務

雲原生應用理念要求將管理任務做爲一次性任務運行，至關於針對管理對象執行了一筆管理交易。K8s集羣中的Deployment操做對象就是對這一理念的最好反映。Deployment對象是用來管理Pod和ReplicaSet的，Pod是一個微服務實例，而ReplicaSet是一組相同的微服務實例，即最新版的Replication Controller。Deployment對Pod和ReplicaSet的管理操做，就至關於對K8s集羣中的服務作了一次交易，對服務作建立或者更新的操做。

K8s操做對象對雲原生應用理念的支持

從前面對K8s操做對象和雲原生應用理念的解讀能夠發現，以下圖所示，做爲一個容器編排管理系統，K8s對雲原生應用理念中全部非開發構建期的理念都有了很好的支持。

(點擊放大圖像)

K8s與容器設計模式

在程序設計領域，面向對象設計和麪向對象語言是你們最爲熟悉和強大的工具，而面向對象除了其強大的核心特性以外，還有人們經過實踐總結出來的一系列設計模式，能夠用來解決實際應用設計中的一些複雜問題。雲原生應用運行的環境都是複雜的分佈式環境，在這種狀況下，一些有用的設計模式能夠起到四兩撥千斤的做用，而K8s社區推出的容器設計模式，則是結合了K8s集羣的微服務模型提出的一系列可重用的解決典型分佈式系統問題的模式。容器設計模式與傳統的面向對象設計模式的最明顯地區別在於，容器設計模式是跨編程語言的，這個固然也來自於容器自己的編程語言無關性。

(點擊放大圖像)

跨鬥模式（Sidecar pattern）

是一種單節點多容器組合服務模式，多容器經過共享文件系統造成本地通訊，共同提供一個微服務。

外交官模式（Ambassador pattern）

是一種單節點多容器組合服務模式，應用容器和外交官容器共享一個網絡IP地址，應用容器利用這個可重用的外交官容器做爲代理來訪問遠程服務或資源。

適配器模式（Adapter pattern）

是一種單節點多容器提供服務模式，應用容器提供應用功能，同時和一個適配器容器共享文件系統和一個網絡IP地址，分佈式系統管理平臺能夠利用適配器容器的統一接口，從應用容器收集日誌和監控數據等信息。

選舉模式（Election pattern）

是一種多節點組合服務模式。一個可重用的選舉器容器跟應用容器組合起來，提供爲在分佈式系統中的多個應用實例選舉主控節點的問題。

工做隊列模式（Work queue pattern）

是一種多節點組合服務模式。應用容器跟可重用的隊列消息處理器，共同工做，能夠並行地處理隊列中海量的同類型並行計算業務。

分散收集模式（Scatter/gather pattern）

是一種多節點組合服務模式，經過先將大任務分割成諸多小任務處理，在收集彙總合併產生最終結果的模式，支持複雜任務的分佈式計算。

在本系列文章的後面幾篇中，做者將結合實踐案例介紹一些常見的容器設計模式。在本文中，咱們只是簡單介紹模式以留懸念。