作者 | 阿里云售后技術(shù)專家?聲東
成都創(chuàng)新互聯(lián)2013年開創(chuàng)至今，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元?dú)J南做網(wǎng)站,已為上家服務(wù),為欽南各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18982081108
導(dǎo)讀：當(dāng)我們嘗試去理解 K8s 集群工作原理的時(shí)候，控制器（Controller）肯定是一個(gè)難點(diǎn)。這是因?yàn)榭刂破饔泻芏?，具體實(shí)現(xiàn)大相徑庭；且控制器的實(shí)現(xiàn)用到了一些較為晦澀的機(jī)制，不易理解。但是，我們又不能繞過(guò)控制器，因?yàn)樗羌旱摹按竽X”。今天這篇文章，作者通過(guò)分析一個(gè)簡(jiǎn)易冰箱的設(shè)計(jì)過(guò)程，來(lái)幫助讀者深入理解集群控制器的產(chǎn)生，功能以及實(shí)現(xiàn)方法。
下圖是 K8s 集群的核心組件，包括數(shù)據(jù)庫(kù) etcd，調(diào)度器 Scheduler，集群入口 API Server，控制器 Controller，服務(wù)代理 kube-proxy 以及直接管理具體業(yè)務(wù)容器的 kubelet。
這些組件邏輯上可以被分為三個(gè)部分：
今天我們要講的就是集群控制器原理。
雖然控制器是 K8s 集群中比較復(fù)雜的組件，但控制器本身對(duì)我們來(lái)說(shuō)并不陌生的。我們每天使用的洗衣機(jī)、冰箱、空調(diào)等，都是依靠控制器才能正常工作。在控制器原理這一節(jié)，我們通過(guò)思考一個(gè)簡(jiǎn)易冰箱的設(shè)計(jì)過(guò)程，來(lái)理解 K8s 集群控制器的原理。
這個(gè)冰箱包括五個(gè)組件：箱體、制冷系統(tǒng)、照明系統(tǒng)、溫控器以及門。
冰箱只有兩個(gè)功能：
.jpg)
對(duì)于上邊的冰箱，我們可以簡(jiǎn)單抽象成兩個(gè)部分：統(tǒng)一的操作入口和冰箱的所有組件。
在這里，用戶只有通過(guò)入口，才能操作冰箱。這個(gè)入口提供給用戶兩個(gè)接口：開關(guān)門和調(diào)節(jié)溫控器。用戶執(zhí)行這兩個(gè)接口的時(shí)候，入口會(huì)分別調(diào)整冰箱門和溫控器的狀態(tài)。
但是這里有一個(gè)問(wèn)題，就是用戶通過(guò)這兩個(gè)接口，既不能讓冰箱內(nèi)部的燈打開，也不能調(diào)節(jié)冰箱的溫度。
控制器就是為了解決上邊的問(wèn)題產(chǎn)生的。控制器就是用戶的操作，和冰箱各個(gè)組件的正確狀態(tài)之間的一座橋梁：
冰箱有照明系統(tǒng)和制冷系統(tǒng)，顯然相比一個(gè)控制器管理著兩個(gè)組件，我們替每個(gè)組件分別實(shí)現(xiàn)一個(gè)控制器是更為合理的選擇。同時(shí)我們實(shí)現(xiàn)一個(gè)控制器管理器來(lái)統(tǒng)一維護(hù)所有這些控制器，來(lái)保證這些控制器在正常工作。
上邊的控制器和控制器管理器，看起來(lái)已經(jīng)相當(dāng)不錯(cuò)了。但是當(dāng)冰箱功能增加，勢(shì)必有很多新的控制器加進(jìn)來(lái)。這些控制器都需要通過(guò)冰箱入口，時(shí)刻監(jiān)控自己關(guān)心的組件的狀態(tài)變化。比如照明系統(tǒng)控制器就需要時(shí)刻監(jiān)控冰箱門的狀態(tài)。當(dāng)大量控制器不斷的和入口通信的時(shí)候，就會(huì)增加入口的壓力。
這個(gè)時(shí)候，我們把監(jiān)控冰箱組件狀態(tài)變化這件事情，交給一個(gè)新的模塊 SharedInformer 來(lái)實(shí)現(xiàn)。
SharedInformer 作為控制器的代理，替控制器監(jiān)控冰箱組件的狀態(tài)變化，并根據(jù)控制器的喜好，把不同組件狀態(tài)的變化，通知給對(duì)應(yīng)的控制器。通過(guò)優(yōu)化，這樣的 SharedInformer 可以極大的緩解冰箱入口的壓力。
SharedInformer 方便了控制器對(duì)冰箱組件的監(jiān)控，而這個(gè)機(jī)制最核心的功能，當(dāng)然是主動(dòng)獲取組件狀態(tài)和被動(dòng)接收組件狀態(tài)變化的通知。這兩個(gè)功能加起來(lái)，就是 ListWatcher。
假設(shè) SharedInformer 和冰箱入口通過(guò) http 協(xié)議通信的話，那么 http 分塊編碼（chunked transfer encoding）就是實(shí)現(xiàn) ListWatcher 的一個(gè)好的選擇?？刂破魍ㄟ^(guò) ListWatcher 給冰箱入口發(fā)送一個(gè)查詢?nèi)缓蟮却?，?dāng)冰箱組件有變化的時(shí)候，入口通過(guò)分塊的 http 響應(yīng)通知控制器。控制器看到 chunked 響應(yīng)，會(huì)認(rèn)為響應(yīng)數(shù)據(jù)還沒有發(fā)送完成，所以會(huì)持續(xù)等待。
以上我們從一個(gè)簡(jiǎn)易冰箱的進(jìn)化過(guò)程中，了解了控制器產(chǎn)生的意義，扮演的角色，以及實(shí)現(xiàn)的方式?，F(xiàn)在我們回到K8s 集群。K8s 集群實(shí)現(xiàn)了大量的控制器，而且在可以預(yù)見的未來(lái)，新的功能的控制器會(huì)不斷出現(xiàn)，而一些舊的控制器也會(huì)被逐漸淘汰。
目前來(lái)說(shuō)，我們比較常用的控制器，如 Pod 控制器、Deployment 控制器、Service 控制器、Replicaset 控制器等。這些控制器一部分是由 kube controller manager 這個(gè)管理器實(shí)現(xiàn)和管理，而像 route 控制器和 service 控制器，則由 cloud controller manager 實(shí)現(xiàn)。
之所以會(huì)出現(xiàn) cloud controller manager，是因?yàn)樵诓煌脑骗h(huán)境中，一部分控制器的實(shí)現(xiàn)，會(huì)因?yàn)樵茝S商、云環(huán)境的不同，出現(xiàn)很大的差別。這類控制器被劃分出來(lái)，由云廠商各自基于 cloud controller manager 分別實(shí)現(xiàn)。
這里我們以阿里云 K8s 集群 cloud controller manager 實(shí)現(xiàn)的 route? 控制器和 service 控制器為例，簡(jiǎn)單說(shuō)明 K8s 控制器的工作原理。
首先，用戶請(qǐng)求 API Server 創(chuàng)建一個(gè) LoadBalancer 類型的服務(wù)，API Server 收到請(qǐng)求并把這個(gè)服務(wù)的詳細(xì)信息寫入 etcd 數(shù)據(jù)庫(kù)。而這個(gè)變化，被服務(wù)控制器觀察到了。服務(wù)控制器理解 LoadBalancer 類型的服務(wù)，除了包括存放在 etcd 內(nèi)部的服務(wù)記錄之外，還需要一個(gè) SLB 作為服務(wù)入口，以及若干 endpoints 作為服務(wù)后端。所以服務(wù)控制器分別請(qǐng)求 SLB 的云 openapi 和 API Server，來(lái)創(chuàng)建云上 SLB 資源，和集群內(nèi) endpoints 資源。
在集群網(wǎng)絡(luò)一章中，我們提到過(guò)，當(dāng)一個(gè)節(jié)點(diǎn)加入一個(gè) K8s 集群的時(shí)候，集群需要在 VPC 路由表里增加一條路由，來(lái)搭建這個(gè)新加入節(jié)點(diǎn)到 Pod 網(wǎng)絡(luò)的主干道。而這件事情，就是路由控制器來(lái)做的。路由控制器完成這件事情的流程，與上邊服務(wù)控制器的處理流程非常類似，這里不再贅述。
基本上來(lái)說(shuō)，K8s 集群的控制器，其實(shí)扮演著集群大腦的角色。有了控制器，K8s 集群才有機(jī)會(huì)擺脫機(jī)械和被動(dòng)，變成一個(gè)自動(dòng)、智能、有大用的系統(tǒng)。
重慶分公司
重慶分公司
