還不會用 K8s 集群控制器？那你會用冰箱嗎？（多圖詳解）

作者 | 阿里云售后技術(shù)專家?聲東

導(dǎo)讀：當(dāng)我們嘗試去理解 K8s 集群工作原理的時候，控制器（Controller）肯定是一個難點。這是因為控制器有很多，具體實現(xiàn)大相徑庭；且控制器的實現(xiàn)用到了一些較為晦澀的機制，不易理解。但是，我們又不能繞過控制器，因為它是集群的“大腦”。今天這篇文章，作者通過分析一個簡易冰箱的設(shè)計過程，來幫助讀者深入理解集群控制器的產(chǎn)生，功能以及實現(xiàn)方法。

K8s 集群核心組件大圖

下圖是 K8s 集群的核心組件，包括數(shù)據(jù)庫 etcd，調(diào)度器 Scheduler，集群入口 API Server，控制器 Controller，服務(wù)代理 kube-proxy 以及直接管理具體業(yè)務(wù)容器的 kubelet。

這些組件邏輯上可以被分為三個部分：

• 核心組件 etc 數(shù)據(jù)庫；
• 對 etcd 進行直接操作的入口組件 API Server；
• 其他組件, 這里的“其他組件”之所以可以被劃分為一類，是因為它們都可以被看做是集群的控制器。

今天我們要講的就是集群控制器原理。

控制器原理

雖然控制器是 K8s 集群中比較復(fù)雜的組件，但控制器本身對我們來說并不陌生的。我們每天使用的洗衣機、冰箱、空調(diào)等，都是依靠控制器才能正常工作。在控制器原理這一節(jié)，我們通過思考一個簡易冰箱的設(shè)計過程，來理解 K8s 集群控制器的原理。

簡易的冰箱

這個冰箱包括五個組件：箱體、制冷系統(tǒng)、照明系統(tǒng)、溫控器以及門。

冰箱只有兩個功能：

• 當(dāng)有人打開冰箱門的時候，冰箱內(nèi)的燈會自動開啟；
• 當(dāng)有人按下溫控器的時候，制冷系統(tǒng)會根據(jù)溫度設(shè)置，調(diào)節(jié)冰箱內(nèi)溫度。

統(tǒng)一入口

對于上邊的冰箱，我們可以簡單抽象成兩個部分：統(tǒng)一的操作入口和冰箱的所有組件。

在這里，用戶只有通過入口，才能操作冰箱。這個入口提供給用戶兩個接口：開關(guān)門和調(diào)節(jié)溫控器。用戶執(zhí)行這兩個接口的時候，入口會分別調(diào)整冰箱門和溫控器的狀態(tài)。

但是這里有一個問題，就是用戶通過這兩個接口，既不能讓冰箱內(nèi)部的燈打開，也不能調(diào)節(jié)冰箱的溫度。

控制器

控制器就是為了解決上邊的問題產(chǎn)生的?？刂破骶褪怯脩舻牟僮?，和冰箱各個組件的正確狀態(tài)之間的一座橋梁：

• 當(dāng)用戶打開門的時候，控制器觀察到了門的變化，它替用戶打開冰箱內(nèi)的燈；
• 當(dāng)用戶按下溫控器的時候，控制器觀察到了用戶設(shè)置的溫度，它替用戶管理制冷系統(tǒng)，調(diào)節(jié)冰箱內(nèi)溫度。

控制器管理器

冰箱有照明系統(tǒng)和制冷系統(tǒng)，顯然相比一個控制器管理著兩個組件，我們替每個組件分別實現(xiàn)一個控制器是更為合理的選擇。同時我們實現(xiàn)一個控制器管理器來統(tǒng)一維護所有這些控制器，來保證這些控制器在正常工作。

SharedInformer

上邊的控制器和控制器管理器，看起來已經(jīng)相當(dāng)不錯了。但是當(dāng)冰箱功能增加，勢必有很多新的控制器加進來。這些控制器都需要通過冰箱入口，時刻監(jiān)控自己關(guān)心的組件的狀態(tài)變化。比如照明系統(tǒng)控制器就需要時刻監(jiān)控冰箱門的狀態(tài)。當(dāng)大量控制器不斷的和入口通信的時候，就會增加入口的壓力。

這個時候，我們把監(jiān)控冰箱組件狀態(tài)變化這件事情，交給一個新的模塊 SharedInformer 來實現(xiàn)。

SharedInformer 作為控制器的代理，替控制器監(jiān)控冰箱組件的狀態(tài)變化，并根據(jù)控制器的喜好，把不同組件狀態(tài)的變化，通知給對應(yīng)的控制器。通過優(yōu)化，這樣的 SharedInformer 可以極大的緩解冰箱入口的壓力。

ListWatcher

SharedInformer 方便了控制器對冰箱組件的監(jiān)控，而這個機制最核心的功能，當(dāng)然是主動獲取組件狀態(tài)和被動接收組件狀態(tài)變化的通知。這兩個功能加起來，就是 ListWatcher。

假設(shè) SharedInformer 和冰箱入口通過 http 協(xié)議通信的話，那么 http 分塊編碼（chunked transfer encoding）就是實現(xiàn) ListWatcher 的一個好的選擇?？刂破魍ㄟ^ ListWatcher 給冰箱入口發(fā)送一個查詢?nèi)缓蟮却?，?dāng)冰箱組件有變化的時候，入口通過分塊的 http 響應(yīng)通知控制器?？刂破骺吹?chunked 響應(yīng)，會認為響應(yīng)數(shù)據(jù)還沒有發(fā)送完成，所以會持續(xù)等待。

舉例說明

以上我們從一個簡易冰箱的進化過程中，了解了控制器產(chǎn)生的意義，扮演的角色，以及實現(xiàn)的方式。現(xiàn)在我們回到K8s 集群。K8s 集群實現(xiàn)了大量的控制器，而且在可以預(yù)見的未來，新的功能的控制器會不斷出現(xiàn)，而一些舊的控制器也會被逐漸淘汰。

目前來說，我們比較常用的控制器，如 Pod 控制器、Deployment 控制器、Service 控制器、Replicaset 控制器等。這些控制器一部分是由 kube controller manager 這個管理器實現(xiàn)和管理，而像 route 控制器和 service 控制器，則由 cloud controller manager 實現(xiàn)。

之所以會出現(xiàn) cloud controller manager，是因為在不同的云環(huán)境中，一部分控制器的實現(xiàn)，會因為云廠商、云環(huán)境的不同，出現(xiàn)很大的差別。這類控制器被劃分出來，由云廠商各自基于 cloud controller manager 分別實現(xiàn)。

這里我們以阿里云 K8s 集群 cloud controller manager 實現(xiàn)的 route? 控制器和 service 控制器為例，簡單說明 K8s 控制器的工作原理。

服務(wù)控制器

首先，用戶請求 API Server 創(chuàng)建一個 LoadBalancer 類型的服務(wù)，API Server 收到請求并把這個服務(wù)的詳細信息寫入 etcd 數(shù)據(jù)庫。而這個變化，被服務(wù)控制器觀察到了。服務(wù)控制器理解 LoadBalancer 類型的服務(wù)，除了包括存放在 etcd 內(nèi)部的服務(wù)記錄之外，還需要一個 SLB 作為服務(wù)入口，以及若干 endpoints 作為服務(wù)后端。所以服務(wù)控制器分別請求 SLB 的云 openapi 和 API Server，來創(chuàng)建云上 SLB 資源，和集群內(nèi) endpoints 資源。

路由控制器

在集群網(wǎng)絡(luò)一章中，我們提到過，當(dāng)一個節(jié)點加入一個 K8s 集群的時候，集群需要在 VPC 路由表里增加一條路由，來搭建這個新加入節(jié)點到 Pod 網(wǎng)絡(luò)的主干道。而這件事情，就是路由控制器來做的。路由控制器完成這件事情的流程，與上邊服務(wù)控制器的處理流程非常類似，這里不再贅述。

結(jié)束語

基本上來說，K8s 集群的控制器，其實扮演著集群大腦的角色。有了控制器，K8s 集群才有機會擺脫機械和被動，變成一個自動、智能、有大用的系統(tǒng)。