[[383892]]

了解 Kubernetes 調(diào)度器是如何發(fā)現(xiàn)新的吊艙并將其分配到節(jié)點(diǎn)。

Kubernetes 已經(jīng)成為容器和容器化工作負(fù)載的標(biāo)準(zhǔn)編排引擎。它提供一個(gè)跨公有云和私有云環(huán)境的通用和開(kāi)源的抽象層。

對(duì)于那些已經(jīng)熟悉 Kuberbetes 及其組件的人，他們的討論通常圍繞著如何盡量發(fā)揮 Kuberbetes 的功能。但當(dāng)你剛剛開(kāi)始學(xué)習(xí) Kubernetes 時(shí)，嘗試在生產(chǎn)環(huán)境中使用前，明智的做法是從一些關(guān)于 Kubernetes 相關(guān)組件（包括 Kubernetes 調(diào)度器） 開(kāi)始學(xué)習(xí)，如下抽象視圖中所示：

Kubernetes 也分為控制平面和工作節(jié)點(diǎn)：

1. 控制平面： 也稱為主控，負(fù)責(zé)對(duì)集群做出全局決策，以及檢測(cè)和響應(yīng)集群事件。控制平面組件包括：

• etcd
• kube-apiserver
• kube-controller-manager
• 調(diào)度器

2. 工作節(jié)點(diǎn)： 也稱節(jié)點(diǎn)，這些節(jié)點(diǎn)是工作負(fù)載所在的位置。它始終和主控聯(lián)系，以獲取工作負(fù)載運(yùn)行所需的信息，并與集群外部進(jìn)行通訊和連接。工作節(jié)點(diǎn)組件包括：

• kubelet
• kube-proxy
• CRI

我希望這個(gè)背景信息可以幫助你理解 Kubernetes 組件是如何關(guān)聯(lián)在一起的。

Kubernetes 調(diào)度器是如何工作的

Kubernetes 吊艙pod 由一個(gè)或多個(gè)容器組成組成，共享存儲(chǔ)和網(wǎng)絡(luò)資源。Kubernetes 調(diào)度器的任務(wù)是確保每個(gè)吊艙分配到一個(gè)節(jié)點(diǎn)上運(yùn)行。

（LCTT 譯注：容器技術(shù)領(lǐng)域大量使用了航海比喻，pod 一詞，意為“豆莢”，在航海領(lǐng)域指“吊艙” —— 均指盛裝多個(gè)物品的容器。常不翻譯，考慮前后文，可譯做“吊艙”。）

在更高層面下，Kubernetes 調(diào)度器的工作方式是這樣的：

1. 每個(gè)需要被調(diào)度的吊艙都需要加入到隊(duì)列
2. 新的吊艙被創(chuàng)建后，它們也會(huì)加入到隊(duì)列
3. 調(diào)度器持續(xù)地從隊(duì)列中取出吊艙并對(duì)其進(jìn)行調(diào)度

調(diào)度器源碼（scheduler.go）很大，約 9000 行，且相當(dāng)復(fù)雜，但解決了重要問(wèn)題：

等待/監(jiān)視吊艙創(chuàng)建的代碼

監(jiān)視吊艙創(chuàng)建的代碼始于 scheduler.go 的 8970 行，它持續(xù)等待新的吊艙：

// Run begins watching and scheduling. It waits for cache to be synced, then starts a goroutine and returns immediately.
 
func (sched *Scheduler) Run() {
        if !sched.config.WaitForCacheSync() {
                return
        }
 
        go wait.Until(sched.scheduleOne, 0, sched.config.StopEverything)

負(fù)責(zé)對(duì)吊艙進(jìn)行排隊(duì)的代碼

負(fù)責(zé)對(duì)吊艙進(jìn)行排隊(duì)的功能是：

// queue for pods that need scheduling
        podQueue *cache.FIFO

負(fù)責(zé)對(duì)吊艙進(jìn)行排隊(duì)的代碼始于 scheduler.go 的 7360 行。當(dāng)事件處理程序觸發(fā)，表明新的吊艙顯示可用時(shí)，這段代碼將新的吊艙加入隊(duì)列中：

func (f *ConfigFactory) getNextPod() *v1.Pod {
        for {
                pod := cache.Pop(f.podQueue).(*v1.Pod)
                if f.ResponsibleForPod(pod) {
                        glog.V(4).Infof("About to try and schedule pod %v", pod.Name)
                        return pod
                }
        }
}

處理錯(cuò)誤代碼

在吊艙調(diào)度中不可避免會(huì)遇到調(diào)度錯(cuò)誤。以下代碼是處理調(diào)度程序錯(cuò)誤的方法。它監(jiān)聽(tīng) podInformer 然后拋出一個(gè)錯(cuò)誤，提示此吊艙尚未調(diào)度并被終止：

// scheduled pod cache
        podInformer.Informer().AddEventHandler(
                cache.FilteringResourceEventHandler{
                        FilterFunc: func(obj interface{}) bool {
                                switch t := obj.(type) {
                                case *v1.Pod:
                                        return assignedNonTerminatedPod(t)
                                default:
                                        runtime.HandleError(fmt.Errorf("unable to handle object in %T: %T", c, obj))
                                        return false
                                }
                        },

換句話說(shuō)，Kubernetes 調(diào)度器負(fù)責(zé)如下：

• 將新創(chuàng)建的吊艙調(diào)度至具有足夠空間的節(jié)點(diǎn)上，以滿足吊艙的資源需求。
• 監(jiān)聽(tīng) kube-apiserver 和控制器是否創(chuàng)建新的吊艙，然后調(diào)度它至集群內(nèi)一個(gè)可用的節(jié)點(diǎn)。
• 監(jiān)聽(tīng)未調(diào)度的吊艙，并使用 /binding 子資源 API 將吊艙綁定至節(jié)點(diǎn)。

例如，假設(shè)正在部署一個(gè)需要 1 GB 內(nèi)存和雙核 CPU 的應(yīng)用。因此創(chuàng)建應(yīng)用吊艙的節(jié)點(diǎn)上需有足夠資源可用，然后調(diào)度器會(huì)持續(xù)運(yùn)行監(jiān)聽(tīng)是否有吊艙需要調(diào)度。

了解更多

要使 Kubernetes 集群工作，你需要使以上所有組件一起同步運(yùn)行。調(diào)度器有一段復(fù)雜的的代碼，但 Kubernetes 是一個(gè)很棒的軟件，目前它仍是我們?cè)谟懻摶虿捎迷圃鷳?yīng)用程序時(shí)的首選。

學(xué)習(xí) Kubernetes 需要精力和時(shí)間，但是將其作為你的專業(yè)技能之一能為你的職業(yè)生涯帶來(lái)優(yōu)勢(shì)和回報(bào)。有很多很好的學(xué)習(xí)資源可供使用，而且 官方文檔 也很棒。如果你有興趣了解更多，建議從以下內(nèi)容開(kāi)始：

• Kubernetes the hard way
• Kubernetes the hard way on bare metal
• Kubernetes the hard way on AWS