控制器

在機器人學與自動化中,控制迴路是一種非終止迴路,用於調節系統的狀態。

以下是一個控制迴路的範例:房間中的恆溫器。

當您設定溫度時,就是在告訴恆溫器您的期望狀態。實際室溫是目前狀態。恆溫器的作用是讓目前狀態更接近期望狀態,方法是開啟或關閉設備。

在 Kubernetes 中,控制器是控制迴圈,負責監控您的叢集的狀態,然後在需要時進行變更或請求變更。每個控制器都嘗試將目前的叢集狀態朝期望狀態推進。

控制器模式

控制器至少追蹤一種 Kubernetes 資源類型。這些物件具有 spec 欄位,代表期望狀態。該資源的控制器負責使目前狀態更接近期望狀態。

控制器可能會自行執行動作;更常見的是,在 Kubernetes 中,控制器會向 API 伺服器 發送訊息,這些訊息會產生有用的副作用。您將在下方看到範例。

透過 API 伺服器控制

Job 控制器是 Kubernetes 內建控制器的範例。內建控制器透過與叢集 API 伺服器互動來管理狀態。

Job 是一種 Kubernetes 資源,會執行 Pod,或可能多個 Pod,以執行任務然後停止。

(一旦排程,Pod 物件就會成為 kubelet 的期望狀態的一部分)。

當 Job 控制器看到新任務時,它會確保在叢集的某處,一組節點上的 kubelet 正在運行適當數量的 Pod 以完成工作。Job 控制器本身不運行任何 Pod 或容器。相反地,Job 控制器會告知 API 伺服器建立或移除 Pod。控制平面的其他組件會根據新資訊採取行動(有新的 Pod 需要排程和運行),最終完成工作。

在您建立新的 Job 後,期望狀態是該 Job 完成。Job 控制器使該 Job 的目前狀態更接近您的期望狀態:建立執行您想要為該 Job 完成的工作的 Pod,以便 Job 更接近完成。

控制器也會更新設定它們的物件。例如:一旦 Job 的工作完成,Job 控制器會更新該 Job 物件,將其標記為 Finished(已完成)。

(這有點像某些恆溫器關閉指示燈,以表明您的房間現在已達到您設定的溫度)。

直接控制

與 Job 相反,某些控制器需要對叢集外部的事物進行變更。

例如,如果您使用控制迴圈來確保您的叢集中有足夠的節點,那麼該控制器就需要叢集外部的東西,以便在需要時設定新的節點。

與外部狀態互動的控制器從 API 伺服器取得其期望狀態,然後直接與外部系統通訊,使目前狀態更接近一致。

(實際上,有一個控制器可以水平擴展叢集中的節點。)

這裡的重點是,控制器進行一些變更以實現您的期望狀態,然後將目前狀態報告回叢集的 API 伺服器。其他控制迴圈可以觀察到報告的資料並採取自己的行動。

在恆溫器的範例中,如果房間非常冷,則另一個控制器也可能會打開防凍加熱器。對於 Kubernetes 叢集,控制平面透過擴展 Kubernetes 來實作,間接地與 IP 位址管理工具、儲存服務、雲端供應商 API 和其他服務協同運作。

期望狀態與目前狀態

Kubernetes 採用雲原生系統的觀點,並且能夠處理持續的變更。

您的叢集可能隨時都在變更,因為工作正在進行,並且控制迴圈會自動修復故障。這表示,您的叢集可能永遠不會達到穩定狀態。

只要叢集的控制器正在運行並能夠進行有用的變更,整體狀態是否穩定並不重要。

設計

作為其設計宗旨,Kubernetes 使用許多控制器,每個控制器管理叢集狀態的特定方面。最常見的是,特定的控制迴圈(控制器)使用一種資源作為其期望狀態,並具有另一種它管理的資源,以實現該期望狀態。例如,Job 的控制器追蹤 Job 物件(以發現新工作)和 Pod 物件(以運行 Job,然後查看工作何時完成)。在這種情況下,是其他東西建立 Job,而 Job 控制器建立 Pod。

擁有簡單的控制器比擁有一組相互關聯的單體式控制迴圈更有用。控制器可能會失敗,因此 Kubernetes 的設計允許這種情況發生。

運行控制器的方式

Kubernetes 隨附一組內建控制器,這些控制器在 kube-controller-manager 內運行。這些內建控制器提供重要的核心行為。

Deployment 控制器和 Job 控制器是作為 Kubernetes 本身一部分提供的控制器範例(「內建」控制器)。Kubernetes 讓您可以運行彈性的控制平面,因此如果任何內建控制器發生故障,控制平面的另一部分將接管工作。

您可以找到在控制平面外部運行的控制器,以擴展 Kubernetes。或者,如果您願意,您可以自己編寫新的控制器。您可以將自己的控制器作為一組 Pod 運行,或在 Kubernetes 外部運行。最適合的方式將取決於該特定控制器的功能。

下一步