如何將雲原生工做負載映射到 Kubernetes 中的控制器

做者：Janakiram MSV 譯者：殷龍飛 原文地址：https://thenewstack.io/how-to-map-cloud-native-workloads-to-kubernetes-controllers/

Kubernetes 不只僅是一個容器管理工具。它是一個平臺，旨在處理包裝在任意數量的容器和組合中的各類工做負載。Kubernetes內置了多個控制器，可映射到雲原生架構的各個層。

DevOps工程師能夠將Kubernetes控制器視爲指示團隊運行的各類工做負載的基礎架構需求的手段。他們能夠經過聲明方法定義所需的配置狀態。例如，容器/pod做爲ReplicationController的一部分部署保證始終可用。打包爲DaemonSet的容器保證在集羣的每一個節點上運行。聲明式的方法使DevOps團隊可以利用代碼控制基礎架構。下面討論的一些部署模式遵循不可變基礎結構的原則，其中每一個新的部署都會致使原子部署。

DevOps工程師能夠經過聲明方法定義所需的配置狀態——每一個工做負載映射到控制器。

瞭解雲原生用例

Kubernetes的控制平面不斷跟蹤部署，以確保它們符合DevOps定義的所需配置狀態。

Kubernetes的基本部署單位是一個pod。它是Kubernetes的基本構建塊，是Kubernetes對象模型中最小和最簡單的單元。pod表示集羣上正在運行的進程。不管服務是有狀態的仍是無狀態的，它老是打包並部署爲pod。

控制器能夠在集羣中建立和管理多個pod，處理在集羣範圍內提供自我修復功能的副本。例如，若是節點發生故障，控制器可能會經過在不一樣節點上安排相同的pod用來自動替換該故障pod。

Kubernetes配有多個控制器，能夠處理所需的pod狀態。如ReplicationController、Deployment、DaemonSet和StatefulSet控制器。Kubernetes控制器使用提供的pod模板，來建立其負責pod的所需狀態。與其餘Kubernetes對象同樣，Pod在YAML文件中定義並提交給控制平面。

在Kubernetes中運行雲原生應用程序時，運維人員須要瞭解控制器解決的用例，以充分利用平臺的特性。這有助於他們定義和維護應用程序的所需配置狀態。

上一節中介紹的每種模式都映射到特定的Kubernetes控制器，這些控制器容許對Kubernetes的工做負載進行更精確，細粒度的控制，可是採用自動化方式。

Kubernetes的聲明式配置鼓勵不可變的基礎架構。控制平面跟蹤和管理部署，以確保在整個應用程序生命週期中維護所需的配置狀態。與基於虛擬機的傳統部署相比，DevOps工程師將花費更少的時間來維護工做負載。利用Kubernetes原語和部署模式的有效CI/CD策略使運營商無需執行繁瑣的任務。

可擴展層：無狀態工做負載

無狀態工做負載在Kubernetes中打包並部署爲ReplicaSet。ReplicationController構成ReplicaSet的基礎，可確保在任何給定時間始終運行指定數量的pod副本。換句話說，ReplicationController確保一個pod或一組同類pod老是可用。

若是有太多pod，ReplicationController可能會終止額外的pod。若是太少，ReplicationController將繼續啓動其餘pod。與手動建立的pod不一樣，ReplicationController維護的pod在失敗，刪除或終止時會自動替換。在諸如內核升級之類的破壞性維護以後，在節點上從新建立pod。所以，即便應用程序只須要一個pod，也建議使用ReplicationController。

一個簡單的用例是建立一個ReplicationController對象，以無限期地可靠地運行pod的一個實例。更復雜的用例是運行橫向擴展服務的幾個相同副本，例如Web服務器。在Kubernetes中部署時，DevOps團隊和運營商將無狀態工做負載打包爲ReplicationControllers。

在最近的Kubernetes版本中，ReplicaSets取代了ReplicationControllers。它們都針對相同的場景，但ReplicaSet使用基於 集合的標籤選擇器 ，這使得可使用基於註釋的複雜查詢。此外，Kubernetes中的部署依賴於ReplicaSet。

Deployment是ReplicaSet的抽象。在Deployment對象中聲明所需狀態時，Deployment控制器會以受控速率將實際狀態更改成所需狀態。

強烈建議部署管理雲原生應用程序的無狀態服務。雖然服務能夠部署爲pod和ReplicaSet，但部署能夠更輕鬆地升級和修補應用程序。DevOps團隊可使用部署來升級pod，而沒法使用ReplicaSet完成。這樣就能夠在最短的停機時間內推出新版本的應用程序。部署爲應用程序管理帶來了相似於服務（PaaS）的功能。

持久層：有狀態的工做量

狀態工做負載能夠分爲兩類：須要持久存儲的服務（單實例）和須要以高可靠性和可用模式運行的服務（複製的多實例）。須要訪問持久存儲後端的pod與爲關係數據庫運行集羣的一組pod很是不一樣。雖然前者須要長期持久的持久性，但後者須要高可用性的工做量。Kubernetes解決了這兩種狀況。

能夠經過將底層存儲暴露給服務的捲來支持單個pod。能夠將卷映射到調度pod的任意節點。若是在集羣的不一樣節點上調度多個pod並須要共享後端，則在部署應用程序以前手動配置分佈式文件系統（如網絡文件系統（NFS）或Gluster）。雲原生態系統中提供的現代存儲驅動程序提供容器本機存儲，其中文件系統自己經過容器公開。當pod只須要持久性和持久性時，請使用此配置。

對於預計具備高可用性的場景，Kubernetes提供StatefulSets - 一組專門的pod，可確保pod的排序和惟一性。這在運行主要/輔助（之前稱爲主/從）數據庫集羣配置時尤爲有用。

與部署相似，StatefulSet管理基於相同容器規範的pod。與Deployment不一樣，StatefulSet爲其每一個pod保留惟一標識。這些pod是根據相同的規範建立的，但不可互換：每一個pod都有一個持久標識符，它能夠在任何從新安排時保留。

StatefulSet對須要如下一項或多項的工做負載很是有用：

• 穩定，獨特的網絡標識符。

• 穩定，持久的存儲。

• 有序，優雅的部署和擴展。

• 有序，優雅的刪除和終止。

• 有序的自動滾動更新。

Kubernetes對StatefulSets的處理方式與其餘控制器不一樣。當正在使用N個副本調度StatefulSet的pod時，將按順序建立它們，順序從0到N-1。當刪除StatefulSet的pod時，它們以相反的順序終止，從N-1到0。在將一個擴展操做應用於pod以前，它的全部前驅必須正在運行並準備就緒。Kubernetes確保在終止pod以前，其全部後繼者都徹底關閉。

當服務須要運行Cassandra、MongoDB、MySQL、PostgreSQL集羣或任何具備高可用性要求的數據庫工做負載時，建議使用StatefulSet。

並不是每一個持久性工做負載都必須是StatefulSet。某些容器依賴於持久存儲後端來存儲數據。爲了向這些類型的應用程序添加持久性，pod可能依賴於由基於主機的存儲或容器本機存儲後端支持的卷。

可並行化層：批處理

Kubernetes具備用於批處理的內置原語，這對於執行運行到完成做業或預約做業頗有用。

運行到完成做業一般用於運行須要執行操做和退出的進程。在處理數據以前運行的大數據工做負載就是這種工做的一個例子。另外一個示例是一個處理隊列中每條消息的做業，直到隊列變空。

做業是一個控制器，能夠建立一個或多個pod並確保指定數量的pod成功終止。當pod成功完成後，Job會跟蹤成功的完成狀況。達到指定數量的成功完成後，做業自己就完成了。刪除做業將清理它建立的pod。

Job還能夠用於並行運行多個pod，這使其成爲機器學習培訓工做的理想選擇。Job還支持並行處理一組獨立但相關的工做項。

當Kubernetes在具備GPU的硬件上運行時，機器學習培訓能夠利用Job。諸如Kubeflow之類的新興項目 - 一個致力於在Kubernetes上部署機器學習的簡單，可移植和可擴展的項目 - 將把原始資料做爲job包裝到機器學習培訓中。

除了運行並行化做業外，可能還須要運行預約做業。Kubernetes公開了CronJobs，它能夠在指定的時間點運行一次，也能夠在指定的時間點按期運行。Kubernetes中的CronJob對象相似於Unix中crontab（cron表）文件的一行。它以給定的時間表按期運行，以cron格式編寫。

Cron做業對於安排按期做業（如數據庫備份或發送電子郵件）特別有用。

事件驅動層：無服務器（Serverless）

無服務器計算（Serverless）是指構建和運行不須要服務器管理的應用程序的概念。它描述了一種更細粒度的部署模型，其中捆綁爲一個或多個功能的應用程序上傳到平臺，而後執行，縮容和計費以響應當前所需的確切需求。

函數即服務（FaaS）在無服務器計算的環境中運行，以提供事件驅動的計算。開發人員使用由事件或HTTP請求觸發的功能來運行和管理應用程序代碼。開發人員將小型代碼單元部署到FaaS，這些代碼根據實際須要做爲獨立組件執行，無需管理服務器或任何其餘底層基礎架構便可進行擴展。

雖然Kubernetes沒有集成的事件驅動原語來響應其餘服務引起的警報和事件，但仍有努力引入事件驅動的功能。該雲原生計算基金會 ，Kubernetes的託管者，一直專一於這些致力於無服務器的工做組。Apache OpenWhisk 、Fission 、Kubeless 、OpenFaaS 和 Oracle的Fn 等開源項目能夠在Kubernetes集羣中做爲事件驅動的無服務器層運行。

在無服務器環境中部署的代碼與打包爲pod的代碼根本不一樣。它由自治函數組成，能夠鏈接到可能觸發代碼的一個或多個事件。

當事件驅動計算——無服務器計算成爲Kubernetes不可或缺的一部分時，開發人員將可以部署響應Kubernetes控制平面生成的內部事件以及應用程序服務引起的自定義事件的函數。

遺留層：Headless Service

即便您的組織常用微服務架構構建和部署應用程序到雲上的容器中，也可能有一些應用程序繼續存在於Kubernetes以外。雲原生應用程序和服務必須與那些傳統的單一應用程序進行交互。

遺留層的存在是爲了實現互操做性，以暴露一組指向單體應用程序的Headless Service。Headless Service容許開發人員通自由地以本身的方式進行服務發現來減小與Kubernetes系統的耦合。Kubernetes中的Headless Services與ClusterIP、NodePort和LoadBalancer類型的服務不一樣。它們沒有分配給它們的Internet協議（IP）地址，但具備指向外部端點（如API Server、Web服務器和數據庫）的域名系統（DNS）條目。遺留層是一個邏輯互操做性層，它將DNS記錄維護到衆所周知的外部端點。

微服務應用程序的每一層均可以映射到Kubernetes的一個控制器。根據但願部署的模式，DevOps團隊能夠進行相應的選擇。在下一篇文章中，咱們將討論將雲原生應用程序部署到Kubernetes的一些最佳實踐。

關於做者

Janakiram MSV是Janakiram＆Associates的首席分析師，也是國際信息技術學院的兼職教員。他仍是Google認證雲開發人員，亞馬遜認證解決方案架構師，亞馬遜認證開發人員，亞馬遜認證SysOps管理員和Microsoft認證Azure專業人員。Janakiram是雲原生計算基金會的大使，也是最先的認證Kubernetes管理員和認證Kubernetes應用程序開發人員之一。他以前的經歷包括Microsoft、AWS、Gigaom Research和Alcatel-Lucent。