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

ServiceMesher2018-11-12 03:32:06

作者: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。

相關推薦

  • 雲原生可移植性的神話

  • Istio微服務平臺集成實踐

  • 服務網格是中間件的終結者嗎?

  • 使用Go語言操作Istio和其他Kubernetes CRD

  • 容器編排無法解決微服務的所有問題,你還需要服務網格

  • SOFAMesh(https://github.com/alipay/sofa-mesh)基於Istio的大規模服務網格解決方案

  • SOFAMosn(https://github.com/alipay/sofa-mosn)使用Go語言開發的高性能Sidecar代理

合作社區

參與社區

以下是參與ServiceMesher社區的方式,最簡單的方式是聯繫我!

  • 加入微信交流群:關注本微信公眾號後訪問主頁右下角有獲取聯繫方式按鈕,添加好友時請註明姓名-公司

  • 社區網址:http://www.servicemesher.com

  • Slack:https://servicemesher.slack.com (需要邀請才能加入)

  • GitHub:https://github.com/servicemesher

  • Istio中文文檔進度追蹤:https://github.com/servicemesher/istio-official-translation

  • Twitter: https://twitter.com/servicemesher

  • 提供文章線索與投稿:https://github.com/servicemesher/trans



閱讀原文

TAGS: