Kubernetes 排程器實現初探

作者| 阿里雲智慧事業群高階開發工程師 蕭元

Kubernetes作為一個分散式容器編排排程引擎，資源排程是它的最重要的功能。在 Kubernetes叢集中，排程器作為一個獨立模組執行。本文將介紹 Kubernetes 排程器的實現原理，工作流程， 以及未來發展。

Kubernetes 中的排程器，是作為單獨元件執行，一般執行在 Master 中，和 Master 數量保持一致。透過 Raft 協議選出一個例項作為 Leader 工作，其他例項 Backup。 當 Master 故障，其他例項之間繼續透過 Raft 協議選出新的 Master 工作。

其工作模式如下：

• 排程器內部維護一個排程的 pods 佇列 podQueue， 並監聽 APIServer；

• 當我們建立 Pod 時，首先透過 APIServer 往 ETCD 寫入 Pod 後設資料；

• 排程器透過 Informer 監聽 Pods 狀態，當有新增 Pod 時，將 Pod 加入到 podQueue 中；

• 排程器中的主程式，會不斷的從 podQueue 取出的 Pod，並將 Pod 進入排程分配節點環節；

• 排程環節分為兩個步奏， Filter 過濾滿足條件的節點 、 Prioritize 根據 Pod 配置，例如資源使用率，親和性等指標，給這些節點打分，最終選出分數最高的節點；

• 分配節點成功， 呼叫 apiServer 的 binding pod 介面， 將pod.Spec.NodeName設定為所分配的那個節點；

• 節點上的 kubelet 同樣監聽 ApiServer，如果發現有新的 pod 被排程到所在節點，在節點上拉起對應的容器

• 假如排程器嘗試排程 Pod 不成功，如果開啟了優先順序和搶佔功能，會嘗試做一次搶佔，將節點中優先順序較低的 pod 刪掉，並將待排程的 pod 排程到節點上。 如果未開啟，或者搶佔失敗，會記錄日誌，並將 pod 加入 podQueue 隊尾。

kube-scheduling 是一個獨立執行的元件，主要工作內容在 Run 函式 。 這裡面主要做幾件事情：

• 初始化一個 Scheduler 例項 sched，傳入各種 Informer，為關心的資源變化建立監聽並註冊 handler，例如維護 podQuene；

• 註冊 events 元件，設定日誌；

• 註冊 http/https 監聽，提供健康檢查和 metrics 請求；

• 執行主要的排程內容入口 sched.run() 。 如果設定 --leader-elect=true ，代表啟動多個例項，透過Raft選主，例項只有當被選為master後執行主要工作函式sched.run。

排程核心內容在 sched.run() 函式，它會啟動一個 go routine 不斷執行sched.scheduleOne， 每次執行代表一個排程週期。

func (sched *Scheduler) Run() {
    if !sched.config.WaitForCacheSync() {
        return
    }
    go wait.Until(sched.scheduleOne, 0, sched.config.StopEverything)
}

我們看下 sched.scheduleOne 主要做什麼：

func (sched *Scheduler) scheduleOne() {
  pod := sched.config.NextPod()
  .... // do some pre check
  scheduleResult, err := sched.schedule(pod)
    if err != nil {
        if fitError, ok := err.(*core.FitError); ok {
            if !util.PodPriorityEnabled() || sched.config.DisablePreemption {
                ..... // do some log
            } else {
                sched.preempt(pod, fitError)
            }
        }
    }
    ... 
    // Assume volumes first before assuming the pod.
    allBound, err := sched.assumeVolumes(assumedPod, scheduleResult.SuggestedHost)
    ...     
    fo func() {
        // Bind volumes first before Pod
        if !allBound {
            err := sched.bindVolumes(assumedPod)
            if err != nil {
                klog.Errorf("error binding volumes: %v", err)
                metrics.PodScheduleErrors.Inc()
                return
            }
        }
      err := sched.bind(assumedPod, &v1.Binding{
            ObjectMeta: metav1.ObjectMeta{Namespace: assumedPod.Namespace, Name: assumedPod.Name, UID: assumedPod.UID},
            Target: v1.ObjectReference{
                Kind: "Node",
                Name: scheduleResult.SuggestedHost,
            },
        })
    }
}

在sched.scheduleOne 中，主要會做幾件事情：

• 透過sched.config.NextPod(), 從 podQuene 中取出 pod;

• 執行sched.schedule，嘗試進行一次排程;

• 假如排程失敗，如果開啟了搶佔功能，會呼叫sched.preempt 嘗試進行搶佔，驅逐一些 pod，為被排程的 pod 預留空間，在下一次排程中生效;

• 如果排程成功，執行 bind 介面。在執行 bind 之前會為 pod volume 中宣告的的 PVC 做 provision。

sched.schedule 是主要的 pod 排程邏輯：

func (g *genericScheduler) Schedule(pod *v1.Pod, nodeLister algorithm.NodeLister) (result ScheduleResult, err error) {
    // Get node list
    nodes, err := nodeLister.List()
    // Filter
    filteredNodes, failedPredicateMap, err := g.findNodesThatFit(pod, nodes)
    if err != nil {
        return result, err
    }
    // Priority
    priorityList, err := PrioritizeNodes(pod, g.cachedNodeInfoMap, metaPrioritiesInterface, g.prioritizers, filteredNodes, g.extenders)
    if err != nil {
        return result, err
    }

    // SelectHost
    host, err := g.selectHost(priorityList)
    return ScheduleResult{
        SuggestedHost:  host,
        EvaluatedNodes: len(filteredNodes) + len(failedPredicateMap),
        FeasibleNodes:  len(filteredNodes),
    }, err
}

排程主要分為三個步奏：

• Filters： 過濾條件不滿足的節點；

• PrioritizeNodes： 在條件滿足的節點中做 Scoring，獲取一個最終打分列表 priorityList；

• selectHost: 在 priorityList 中選取分數最高的一組節點，從中根據 round-robin 方式選取一個節點。

接下來我們繼續拆解， 分別看下這三個步奏會怎麼做

Filters

Filters 相對比較容易，排程器預設註冊了一系列的 predicates 方法， 排程過程為併發呼叫每個節點的 predicates 方法。最終得到一個 node list，包含符合條件的節點物件。

func (g *genericScheduler) findNodesThatFit(pod *v1.Pod, nodes []*v1.Node) ([]*v1.Node, FailedPredicateMap, error) {
    if len(g.predicates) == 0 {
        filtered = nodes
    } else {
        allNodes := int32(g.cache.NodeTree().NumNodes())
        numNodesToFind := g.numFeasibleNodesToFind(allNodes)
        checkNode := func(i int) {
            nodeName := g.cache.NodeTree().Next()
      // 此處會呼叫這個節點的所有predicates 方法
            fits, failedPredicates, err := podFitsOnNode(
                pod,
                meta,
                g.cachedNodeInfoMap[nodeName],
                g.predicates,
                g.schedulingQueue,
                g.alwaysCheckAllPredicates,
            )
            if fits {
                length := atomic.AddInt32(&filteredLen, 1)
                if length > numNodesToFind {
            // 如果當前符合條件的節點數已經足夠，會停止計算。
                    cancel()
                    atomic.AddInt32(&filteredLen, -1)
                } else {
                    filtered[length-1] = g.cachedNodeInfoMap[nodeName].Node()
                }
            }
        }
    // 併發呼叫checkNode 方法
        workqueue.ParallelizeUntil(ctx, 16, int(allNodes), checkNode)
        filtered = filtered[:filteredLen]
    }
    return filtered, failedPredicateMap, nil
}

值得注意的是， 1.13 中引入了 FeasibleNodes 機制，為了提高大規模叢集的排程效能。允許我們透過 bad-percentage-of-nodes-to-score 引數， 設定 filter 的計算比例（預設 50%）， 當節點數大於 100 個， 在 filters的過程，只要滿足條件的節點數超過這個比例，就會停止 filter 過程，而不是計算全部節點。

舉個例子，當節點數為 1000， 我們設定的計算比例為 30%，那麼排程器認為 filter 過程只需要找到滿足條件的 300 個節點，filter 過程中當滿足條件的節點數達到 300 個，filter 過程結束。 這樣 filter 不用計算全部的節點，同樣也會降低 Prioritize 的計算數量。 但是帶來的影響是 pod 有可能沒有被排程到最合適的節點。

Prioritize

Prioritize 的目的是幫助 pod，為每個符合條件的節點打分，幫助 pod 找到最合適的節點。同樣排程器預設註冊了一系列 Prioritize 方法。這是 Prioritize 物件的資料結構：

// PriorityConfig is a config used for a priority function.
type PriorityConfig struct {
    Name   string
    Map    PriorityMapFunction
    Reduce PriorityReduceFunction
    // TODO: Remove it after migrating all functions to
    // Map-Reduce pattern.
    Function PriorityFunction
    Weight   int
}

每個 PriorityConfig 代表一個評分的指標，會考慮服務的均衡性，節點的資源分配等因素。 一個 PriorityConfig 的主要 Scoring 過程分為 Map 和 Reduce：

• Map 過程計算每個節點的分數值

• Reduce 過程會將當前 PriorityConfig 的所有節點的打分結果再做一次處理。

所有 PriorityConfig 計算完畢後，將每個 PriorityConfig 的數值乘以對應的權重，並按照節點再做一次聚合。

workqueue.ParallelizeUntil(context.TODO(), 16, len(nodes), func(index int) {
        nodeInfo := nodeNameToInfo[nodes[index].Name]
        for i := range priorityConfigs {
            var err error
            results[i][index], err = priorityConfigs[i].Map(pod, meta, nodeInfo)
        }
    })
    for i := range priorityConfigs {
        wg.Add(1)
        go func(index int) {
            defer wg.Done()
            if err := priorityConfigs[index].Reduce(pod, meta, nodeNameToInfo, results[index]);
        }(i)
    }
    wg.Wait()
    // Summarize all scores.
    result := make(schedulerapi.HostPriorityList, 0, len(nodes))
    for i := range nodes {
        result = append(result, schedulerapi.HostPriority{Host: nodes[i].Name, Score: 0})
        for j := range priorityConfigs {
            result[i].Score += results[j][i].Score * priorityConfigs[j].Weight
        }
    }

此外 Filter 和 Prioritize 都支援 extener scheduler 的呼叫，本文不做過多闡述。

目前 Kubernetes 排程器的排程方式是 Pod-by-Pod，也是當前排程器不足的地方。主要瓶頸如下：

• Kubernetes 目前排程的方式，每個 pod 會對所有節點都計算一遍，當叢集規模非常大，節點數很多時，pod 的排程時間會非常慢。 這也是 percentage-of-nodes-to-score 嘗試要解決的問題；

• pod-by-pod 的排程方式不適合一些機器學習場景。 Kubernetes 早期設計主要為線上任務服務，在一些離線任務場景，比如分散式機器學習中，我們需要一種新的演算法 gang scheduler，pod 也許對排程的即時性要求沒有那麼高，但是提交任務後，只有當一個批次計算任務的所有 workers 都執行起來時，才會開始計算任務。 pod-by-pod 方式在這個場景下，當資源不足時非常容易引起資源死鎖；

• 當前排程器的擴充套件性不是十分好，特定場景的排程流程都需要透過硬編碼實現在主流程中，比如我們看到的 bindVolume 部分， 同樣也導致 Gang Scheduler 無法在當前排程器框架下透過原生方式實現。

社群排程器的發展，也是為了解決這些問題：

• 排程器 V2 框架，增強了擴充套件性，也為在原生排程器中實現 Gang schedule 做準備；

• Kube-batch： 一種 Gang schedule 的實現 ；

• poseidon： Firmament 一種基於網路圖排程演算法的排程器，poseidon 是將 Firmament 接入 Kubernetes 排程器的實現 。

參考文獻

[1]
[2] https://jvns.ca/blog/2017/07/27/how-does-the-kubernetes-scheduler-work/