如何將Cloud Native Workload 映射到Kubernetes 控制器
原文鏈接：https://thenewstack.io/how-to-map-cloud-native-workloads-to-kubernetes-controllers/
作者：Janakiram MSV
譯者：殷龍飛
Kubernetes 不僅僅是一個容器管理工具。它是一個平臺，旨在處理包裝在任意數量的容器和組合中的各種工作負載。Kubernetes內置了多個控制器，可映射到雲原生架構的各個層。
DevOps工程師可以將Kubernetes控制器視爲指示團隊運行的各種工作負載的基礎架構需求的手段。他們可以通過聲明方法定義所需的配置狀態。例如，作爲ReplicationController的一部分部署的容器/pod保證始終可用。打包爲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作業對於安排定期作業（如數據庫備份或發送電子郵件）特別有用。
事件驅動層：無服務器
無服務器計算是指構建和運行不需要服務器管理的應用程序的概念。它描述了一種更細粒度的部署模型，其中捆綁爲一個或多個功能的應用程序上傳到平臺，然後執行，縮容和計費以響應當前所需的確切需求。
函數即服務（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服務器，Web服務器和數據庫）的域名系統（DNS）條目。遺留層是一個邏輯互操作性層，它將DNS記錄維護到衆所周知的外部端點。
微服務應用程序的每一層都可以映射到Kubernetes的一個控制器。根據他們希望部署的模式，DevOps團隊可以選擇適當的選項。在下一篇文章中，我們將討論將雲原生應用程序部署到Kubernetes的一些最佳實踐。
關於作者
Janakiram MSV是Janakiram＆Associates的首席分析師，也是國際信息技術學院的兼職教員。他還是Google合格雲開發人員，亞馬遜認證解決方案架構師，亞馬遜認證開發人員，亞馬遜認證SysOps管理員和Microsoft認證Azure專業人員。Janakiram是雲原生計算基金會的大使，也是最早的認證Kubernetes管理員和認證Kubernetes應用程序開發人員之一。他之前的經歷包括Microsoft，AWS，Gigaom Research和Alcatel-Lucent。