Kubernetes 已成為一種通用調度器

作者：Janakiram MSV是Janakiram & Associates的創始人、負責人兼首席分析師，曾先後供職於微軟、AWS和阿爾卡特-朗訊。

在計算機科學界，調度是指某種方式指定的工作被分配給能夠完成該工作的資源所採用的方法。這個古老的問題自IBM S/360在20世紀60年代問世以來就存在了。

只要有可能由一組資源來完成的作業，調度就至關重要。在操作系統這個環境中，作業可能是簡單的程序，而資源可能是CPU核心。與之相仿，操作系統中的調度器可能負責將代碼行與某個線程或信號關聯起來。

分散式計算將調度器的領域從內部進程和線程擴大到了物理機器集群。上世紀90年代，CORBA、DCOM和J2EE等分散式平台克服了對應用伺服器集群中的組件進行調度這個難題。

最近，亞馬遜EC2、Azure Fabric和OpenStack Nova等IaaS控制平面負責對物理主機上運行的虛擬機管理程序中的虛擬機進行調度。必須基於請求的資源將每個虛擬機放置在合適的主機上。

基於Apache Hadoop和MapReduce演算法的大數據工作負載高度依賴成熟可靠的調度演算法。HDFS即Hadoop的文件系統確保集群的所有節點都可以訪問數據集。該架構完全專註於資源的可靠性和可用性。

Cloud Foundry和Heroku之類的PaaS系統有複雜的放置邏輯，可對隔離環境中的服務進行調度。每個服務打包並部署到虛擬機或物理主機中運行的執行環境中。

容器的興起迫使業界重新審視資源調度器的設計。簡單性和可擴展性成為了新調度器的兩大考量因素。傳統應用伺服器面對的是少量伺服器，而容器管理平台的worker節點可以少則一個、多則幾千個。

Kubernetes和Mesosphere是資源調度器的現代典範。兩者都旨在抽取底層基礎設施，使調度任務對用戶來說透明化。

Kubernetes中的調度

Kubernetes調度器是該平台的關鍵組件之一。它在主節點上運行，與API伺服器和控制器密切配合。調度器負責匹配工作：將pod與節點匹配起來。你可以在本文中全面了解Kubernetes架構（https://thenewstack.io/kubernetes-an-overview/）。

調度器基於可用資源等多個因素為pod確定合適的節點。還可以通過節點親和性（node affinity）來影響調度器，其中pod請求具有特定特徵的節點。比如說，運行高I/O資料庫的有狀態pod可能向調度器請求擁有SSD存儲後端的節點。還可以確保將一組pod放置在同一節點上以避免延遲。這就是pod親和性。Kubernetes還支持自定義調度器，放置邏輯完全取決於第三方調度器。

Kubernetes調度器的最大優點在於簡單性。大多數上述放置策略實現起來很簡單。只需要pod和節點中適當包含或排除的一組標籤和注釋。一組節點和pod上的簡單鍵/值對就能提供複雜的放置策略。

Kubernetes調度器：pod和節點之外

Kubernetes現成為我們這個時代最好的資源調度器之一。這個功能強大的調度器既簡單，又可靈活擴展，讓我們能夠解決傳統分散式系統中存在的許多問題。

Kubernetes正迅速成為在高度分散式環境中調度和管理作業的首選控制平面。這些作業可能包括將虛擬機部署到物理主機上、將容器放置到邊緣設備中，或甚至將控制平面擴展到其他調度器（比如Serverless環境）。

KubeVirt是Kubernetes的虛擬機管理附件，旨在讓用戶可以在Kubernetes或OpenShift集群中讓虛擬機與容器一同運行。它擴展Kubernetes採用的方法是，藉助Kubernetes的自定義資源定義（CRD）API，為虛擬機和虛擬機集合添加資源類型。KubeVirt虛擬機在常規的Kubernetes pod中運行，它們可以訪問標準的pod網路和存儲資源，使用kubectl等標準的Kubernetes工具加以管理。

有了Mirantis的Virtlet項目，就可以在Kubernetes集群上運行虛擬機，好像它們是普通的pod。它使運維人員能夠使用標準的kubectl命令來管理虛擬機，並將它們作為「一等公民」引入到集群網路。使用Virtlet，可以構建更高級的Kubernetes對象，包括部署、有狀態服務集或守護進程集。

微軟的Virtual Kubelet項目是最值得關注的利用Kubernetes的調度器。Virtual Kubelet是在外部環境中運行的代理，被註冊為Kubernetes集群中的一個節點。該代理通過Kubernetes API創建節點資源。它用到了污點（taints）和容忍（tolerations）這些概念，通過調用原生API來調度外部環境中的pod。

Virtual Kubelet可與Azure Container Instances、Azure IoT Edge和AWS Fargate控制平面協同使用。

想詳細了解Virtual Kubelet的架構和部署指南，請參閱我之前寫的文章：https://thenewstack.io/lightning-fast-container-provisioning-with-microsofts-azure-container-instances/和https://thenewstack.io/explore-multicloud-deployments-aci-connector-kubernetes/。

未來之路－自定義調度器和自定義資源定義

上面討論的幾個項目只是冰山一角。隨著Kubernetes成為現代基礎設施的基礎，它正準備運行各種工作負載，包括ERP和CRM等傳統的業務應用軟體。

應用軟體開發商將高度依賴Kubernetes的兩項新興功能：自定義調度器和自定義資源定義（CRD）。

如前所述，Kubernetes中的自定義調度器讓開發人員可以定義自定義調度邏輯。pod的聲明可能包括自定義調度器的名稱，暗示控制平面繞過默認調度器。這是一種強大的機制，可以控制集群中pod的放置。

Portworx是一家雲原生存儲公司，它利用自定義調度器的功能開發出了STORK（面向Kubernetes的存儲調度器運行時環境）。它確保有狀態的pod總是放置在擁有Portworx驅動程序和存儲的節點上。這有助於實現作為容器部署的資料庫工作負載的高可用性。

Kubernetes中的自定義資源將對象生命周期管理的簡單性和強大功能擴展到了自定義類型。自定義資源是一種對象，可擴展Kubernetes API，或允許開發人員將自己的API添加到項目或集群。自定義資源定義（CRD）文件定義了讓API伺服器可以處理整個生命周期的自定義對象類型。將CRD部署到集群中促使Kubernetes API伺服器開始提供指定的自定義資源。

一旦CRD創建完畢，運維人員可以使用kubectl或第三方工具來管理第三方資源的生命周期，就像他們處理Kubernetes中的pod和部署那樣。獨立軟體開發商（ISV）可以將軟體打包並部署成一組CRD。

Kubernetes的可擴展性讓它成為一種通用的調度器和管理工具。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！