如何將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。