在機器人技術和自動化領域，控制迴路是一個非終止迴路，用於調節系統狀態。
這是控制迴路的一個示例：房間中的恆溫器。
設定溫度後，便會告訴恆溫器我們想要的狀態。實際室溫是當前狀態。恆溫器通過打開或關閉設備來使當前狀態更接近所需狀態。
在 Kubernetes 中，控制器是控制環，它們會監視集羣的狀態，然後再需要時進行更改或請求更改。每個控制器都會嘗試將當前集羣狀態移動到更接近所需狀態。
控制器模式
控制器跟蹤至少一種 Kubernetes 資源類型。這些對象的 spec 字段代表所需的狀態。該資源的控制器負責使當前狀態更接近於所需狀態。
控制器可以自行執行操作；更常見的是，在 Kubernetes 中，控制器會將具有有副作用的消息發送到 API 服務器。我們將在下面看到該示例。
通過 API 服務器進行控制
Job 控制器是 Kubernetes 內置控制器的一個示例。內置控制器通過與集羣 API 服務器進行交互來管理狀態。
Job 是一個 Kubernetes 資源，它運行 Pod 或可能是多個 Pod 來執行任務然後停止。
（一旦調度（敬請期待～～），Pod 對象將成爲 kubelet 所需狀態的一部分）。
當作業控制器看到一個新任務時，它確保在集羣中的某個位置，一組節點上的 kubelet 運行正確數量的 Pod 以完成工作。Job 控制器本身不會運行任何 Pod 或容器。而是，作業控制器通知 API 服務器創建或刪除 Pod。舵面中的其他組件根據新信息起作用（有新的 Pod 計劃和運行），最終完成工作。
創建新作業後，對該作業所期望的狀態是完成。Job 控制器使該 Job 的當前狀態更接近於我們想要的狀態：創建 Pod 來完成我們要對該 Job 進行的工作，從而使 Job 接近完成。
控制器還更新配置它們的對象。例如：完成作業的工作後，作業控制器將更新該作業對象以將其標記爲 “完成”。
（這有點像某些恆溫器如何關閉燈以指示我們的房間現在處於我們設定的溫度）。
直接控制
與 Job 相比，某些控制器需要對集羣外部的內容進行更改。
例如，如果我們使用控制循環來確保集羣中有足夠的節點，則該控制器需要當前集羣之外的內容以在需要時設置新的節點。
與外部狀態進行交互的控制器從 API 服務器中找到所需的狀態，然後直接與外部系統進行通信以使當前狀態更加緊密。
（實際上，有一個控制器可以水平伸縮集羣中的節點，請參閱集羣自伸縮（敬請期待～～））。
期望狀態與當前狀態
Kubernetes 採用雲原生系統試圖，並且能夠處理不斷的變化。
隨着工作的進行，我們的集羣可能隨時隨地發生變化，並且控制環會自動修復故障。這意味着，我們的集羣可能永遠無法達到穩定狀態。
只要我們集羣的控制器正在運行並且能夠進行有用的更改，總體狀態是否穩定都沒有關係。
設計
作爲其設置宗旨，Kubernetes 使用許多控制器，每個控制器管理集羣狀態的特定方面。最常見的是，特定的控制環（控制器）使用一種資源作爲其期望狀態，並使用另一種資源來設法使期望狀態發生。例如，用於 Job 的控制器跟蹤 Job 對象（以發現新作業）和 Pod 對象（以運行 Job，然後查看作業何時完成）。在這種情況下，其它東西將創建作業，而作業控制器將創建 Pod。
使用簡單的控制器而不是一組相互鏈接的單體控制迴路很有用。控制器可能會失敗，因此 Kubernetes 旨在解決這一問題。
注意：可以有多個控制器創建或更新相同類型的對象。在幕後，Kubernetes 控制器確保僅關注與控制資源鏈接的資源。
例如，我們可以具有 “部署和作業”；這些都創造了 Pod。作業控制器不會刪除我們的 Deployment 創建的 Pod，因爲控制器可以使用某些信息（標籤）來區分這些 Pod。
控制器運行方式
Kubernetes 帶有一組在 kube-controller-manager 內部運行的內置控制器。這些內置控制器提供了重要的核心行爲。
Deployment 控制器和 Job 控制器是 Kubernetes 本身的一部分（“內置” 控制器）控制器的示例。Kubernetes 允許我們運行彈性舵面，這樣，如果任何內置控制器出現故障，舵面的另一部分將接管工作。
我們可以找到在舵面之外運行的控制器來擴展 Kubernetes。或者，如果需要，我們可以自己編寫一個新的控制器。我們可以將自己的控制器作爲一組 Pod 運行，也可以在 Kubernetes 外部運行。最合適的選擇取決於特定控制器的功能。
下一步是什麼
- 閱讀有關 Kubernetes 舵面的信息
- 探索一些基本的 Kubernetes 對象
- 瞭解有關 Kubernetes API 的更多信息
- 如果要編寫自己的控制器，請參閱擴展 Kubernetes 中的擴展模式（敬請期待～～）