<s id="xcxsa"></s><rp id="xcxsa"></rp>

  • <span id="xcxsa"><pre id="xcxsa"><rt id="xcxsa"></rt></pre></span>
    <dd id="xcxsa"></dd><tbody id="xcxsa"></tbody>
        首頁 運維干貨Kubernetes 調度詳解

        Kubernetes 調度詳解

        運維派隸屬馬哥教育旗下專業運維社區,是國內成立最早的IT運維技術社區,歡迎關注公眾號:yunweipai
        領取學習更多免費Linux云計算、Python、Docker、K8s教程關注公眾號:馬哥linux運維

        本文從 Pod 和節點的配置開始,介紹了 Kubernetes Scheduler 框架、擴展點、API 以及可能發生的與資源相關的瓶頸,并展示了性能調整設置,涵蓋了 Kubernetes 中調度的大多方面。

        Kubernetes 調度詳解插圖

        Kubernetes Scheduler 是 Kubernetes 控制平面的核心組件之一。它在控制平面上運行,將 Pod 分配給節點,同時平衡節點之間的資源利用率。將 Pod 分配給新節點后,在該節點上運行的 kubelet 會在 Kubernetes API 中檢索 Pod 定義,根據節點上的 Pod 規范創建資源和容器。換句話說,Scheduler 在控制平面內運行,并將工作負載分配給 Kubernetes 集群。

        本文將對 Kubernetes Scheduler 進行深入研究,首先概述一般的調度以及具有親和力(affinity)和 taint 的驅逐調度,然后討論調度程序的瓶頸以及生產中可能遇到的問題,最后研究如何微調調度程序的參數以適合集群。

        調度簡介

        Kubernetes 調度是將 Pod 分配給集群中匹配節點的過程。Scheduler 監控新創建的 Pod,并為其分配最佳節點。它會根據 Kubernetes 的調度原則和我們的配置選項選擇最佳節點。最簡單的配置選項是直接在 PodSpec 設置 nodeName:

        apiVersion: v1
        
        kind: Pod
        
        metadata:
        
          name: nginx
        
        spec:
        
          containers:
        
          - name: nginx
        
            image: nginx
        
          nodeName: node-01
        

        上面的 nginx pod 默認情況下將在 node-01 上運行,但是 nodeName 有許多限制導致無法正常運行 Pod,例如云中節點名稱未知、資源節點不足以及節點網絡間歇性問題等。因此,除了測試或開發期間,我們最好不使用 nodeName。

        如果要在一組特定的節點上運行 Pod,可以使用 nodeSelector。我們在 PodSpec 中將 nodeSelector 定義為一組鍵值對:

        apiVersion: v1
        
        kind: Pod
        
        metadata:
        
          name: nginx
        
        spec:
        
          containers:
        
          - name: nginx
        
            image: nginx
        
          nodeSelector:
        
            disktype: ssd
        

        對于上面的 nginx pod,Kubernetes Scheduler 將找到一個磁盤類型為 ssd 的節點。當然,該節點可以具有其他標簽。我們可以在 Kubernetes 參考文檔中查看標簽的完整列表。

        地址:https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/

        使用 nodeSelector 有約束 Pod 可以在有特定標簽的節點上運行。但它的使用僅受標簽及其值限制。Kubernetes 中有兩個更全面的功能來表達更復雜的調度需求:節點親和力(node affinity),標記容器以將其吸引到一組節點上;taint 和 toleration,標記節點以排斥 Pod。這些功能將在下面討論。

        節點親和力

        節點親和力(Node Affinity)是在 Pod 上定義的一組約束,用于確定哪些節點適合進行調度,即使用親和性規則為 Pod 的節點分配定義硬性要求和軟性要求。例如可以將 Pod 配置為僅運行帶有 GPU 的節點,并且最好使用 NVIDIA_TESLA_V100 運行深度學習工作負載。Scheduler 會評估規則,并在定義的約束內找到合適的節點。與 nodeSelectors 相似,節點親和性規則可與節點標簽一起使用,但它比 nodeSelectors 更強大。

        我們可以為 podspec 添加四個相似性規則:
        – requiredDuringSchedulingIgnoredDuringExecution
        – requiredDuringSchedulingRequiredDuringExecution
        – preferredDuringSchedulingIgnoredDuringExecution
        – preferredDuringSchedulingRequiredDuringExecution

        這四個規則由兩個條件組成:必需或首選條件,以及兩個階段:計劃和執行。以 required 開頭的規則描述了必須滿足的嚴格要求。以 preferred 開頭的規則是軟性要求,將強制執行但不能保證。調度階段是指將 Pod 首次分配給節點。執行階段適用于在調度分配后節點標簽發生更改的情況。

        如果規則聲明為 IgnoredDuringExecution,Scheduler 在第一次分配后不會檢查其有效性。但如果使用 RequiredDuringExecution 指定了規則,Scheduler 會通過將容器移至合適的節點來確保規則的有效性。

        以下是示例:

        apiVersion: v1
        kind: Pod
        
        metadata:
          name: nginx
        
        spec:
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                - matchExpressions:
                  - key: topology.kubernetes.io/region
                    operator: In
                    values:
                    - us-east
        
              preferredDuringSchedulingIgnoredDuringExecution:
              - weight: 1
                preference:
                  matchExpressions:
                  - key: topology.kubernetes.io/zone
                    operator: In
                    values:
                    - us-east-1
                    - us-east-2
        
          containers:
          - name: nginx
            image: nginx
        

        上面的 Nginx Pod 具有節點親和性規則,該規則讓 Kubernetes Scheduler 將 Pod 放置在 us-east 的節點上。第二條規則指示優先使用 us-east-1 或 us-east-2。

        使用親和性規則,我們可以讓 Kubernetes 調度決策適用于自定義需求。

        Taint 與 Toleration

        集群中并非所有 Kubernetes 節點都相同。某些節點可能具有特殊的硬件,例如 GPU、磁盤或網絡功能。同樣,我們可能需要將一些節點專用于測試、數據保護或用戶組。我們可以將 Taint 添加到節點以排斥 Pod,如以下示例所示:

        kubectl taint nodes node1 test-environment=true:NoSchedule
        

        使用 test-environment=true:NoScheduletaint 時,除非在 podspec 具有匹配的 toleration,否則 Kubernetes Scheduler 將不會分配任何 pod:

        apiVersion: v1
        kind: Pod
        
        metadata:
          name: nginx
        
        spec:
          containers:
          - name: nginx
            image: nginx
        
          tolerations:
          - key: "test-environment"
            operator: "Exists"
            effect: "NoSchedule"
        

        taint 和 tolerations 共同發揮作用,讓 Kubernetes Scheduler 專用于某些節點并分配特定 Pod。

        調度瓶頸

        盡管 Kubernetes Scheduler 能選擇最佳節點,但是在 Pod 開始運行之后,“最佳節點”可能會改變。所以從長遠來看,Pod 的資源使用及其節點分配可能存在問題。

        資源請求(Request)和限制(Limit):“Noisy Neighbor”

        “Noisy Neighbor”并不特定于 Kubernetes。任何多租戶系統都是它們的潛在地。假設有兩個容器 A 和 B,它們在同一節點上運行。如果 Pod B 試圖通過消耗所有 CPU 或內存來創造 noise,Pod A 將出現問題。如果我們為容器設置了資源請求和限制就能控制住 neighbor。Kubernetes 將確保為容器安排其請求的資源,并且不會消耗超出其資源限制的資源。如果在生產中運行 Kubernetes,最好設置資源請求和限制以確保系統可靠。

        系統進程資源不足

        Kubernetes 節點主要是連接到 Kubernetes 控制平面的虛擬機。因此,節點上也有自己的操作系統和相關進程。如果 Kubernetes 工作負載消耗了所有資源,則這些節點將無法運行,并會發生各種問題問題。我們需要在 kubelet 中使用 –system -reserved 設置保留資源,以防止發生這種情況。

        搶占或調度 Pod

        如果 Kubernetes Scheduler 無法將 Pod 調度到可用節點,則可以從節點搶占(preempt)或驅逐(evict)一些 Pod 以分配資源。如果看到 Pod 在集群中移動而沒有發現特定原因,可以使用優先級類對其進行定義。同樣,如果沒有調度好 Pod,并且正在等待其他 Pod,也需要檢查其優先級。

        以下是示例:

        apiVersion: scheduling.k8s.io/v1
        kind: PriorityClass
        
        metadata:
          name: high-priority-nonpreempting
        
        value: 100000
        preemptionPolicy: Never
        globalDefault: false
        
        description: "This priority class will not preempt other pods."
        

        可以通過以下方式在 podspec 中為分配優先級:

        apiVersion: v1
        kind: Pod
        
        metadata:
          name: nginx
        
        spec:
          containers:
          - name: nginx
            image: nginx
        
          priorityClassName: high-priority-nonpreempting
        

        調度框架

        Kubernetes Scheduler 具有可插拔的調度框架架構,可向框架添加一組新的插件。插件實現 Plugin API,并被編譯到調度程序中。下面我們將討論調度框架的工作流、擴展點和 Plugin API。

        工作流和擴展點

        調度 Pod 包括兩個階段:調度周期(scheduling cycle)和綁定周期(binding cycle)。在調度周期中,Scheduler 會找到一個可用節點,然后在綁定過程中,將決策應用于集群。

        下圖說明了階段和擴展點的流程:

        調度工作流(來源:Kubernetes 文檔)

        工作流中的以下幾點對插件擴展開放:
        – QueueSort:對隊列中的 Pod 進行排序
        – PreFilter:檢查預處理 Pod 的相關信息以安排調度周期
        – Filter:過濾不適合該 Pod 的節點
        – PostFilter:如果找不到可用于 Pod 的可行節點,調用該插件
        – PreScore:運行 PreScore 任務以生成一個可共享狀態供 Score 插件使用
        – Score:通過調用每個 Score 插件對過濾的節點進行排名
        – NormalizeScore:合并分數并計算節點的最終排名
        – Reserve:在綁定周期之前選擇保留的節點
        – Permit:批準或拒絕調度周期結果
        – PreBind:執行任何先決條件工作,例如配置網絡卷
        – Bind:將 Pod 分配給 Kubernetes API 中的節點
        – PostBind:通知綁定周期的結果

        插件擴展實現了 Plugin API,是 Kubernetes Scheduler 的一部分。我們可以在 Kubernetes 存儲庫中檢查。插件應使用以下名稱進行注冊:

        // Plugin is the parent type for all the scheduling framework plugins.
        
        type Plugin interface {
        
         Name() string
        
        }
        

        插件還實現了相關的擴展點,如下所示:

        // QueueSortPlugin is an interface that must be implemented by "QueueSort" plugins.
        // These plugins are used to sort pods in the scheduling queue. Only one queue sort plugin may be enabled at a time.
        
        type QueueSortPlugin interface {
        
         Plugin
        
         // Less are used to sort pods in the scheduling queue.
        
         Less(*QueuedPodInfo, *QueuedPodInfo) bool
        
        }
        

        Scheduler 性能調整

        Kubernetes Scheduler 有一個工作流來查找和綁定 Pod 的可行節點。當集群中的節點數量非常多時,Scheduler 的工作量將成倍增加。在大型集群中,可能需要很長時間才能找到最佳節點,因此要微調調度程序的性能,以在延遲和準確性之間找到折中方案。

        percentageOfNodesToScore 將限制節點的數量來計算自己的分數。默認情況下,Kubernetes 在 100 節點集群的 50% 和 5000 節點集群的 10% 之間設置線性閾值。默認最小值為 5%,它要確保至少考慮集群中 5% 節點的調度。

        下面的示例展示了如何通過性能調整 kube-scheduler 來手動設置閾值:

        apiVersion: kubescheduler.config.k8s.io/v1alpha1
        
        kind: KubeSchedulerConfiguration
        
        algorithmSource:
        
          provider: DefaultProvider
        
        percentageOfNodesToScore: 50
        

        如果有一個龐大的集群并且 Kubernetes 工作負載不能承受 Kubernetes Scheduler 引起的延遲,那么更改百分比是個好主意。

        總結

        本文涵蓋了 Kubernetes 調度的大多方面,從 Pod 和節點的配置開始,包括 nodeSelector、親和性規則、taint 和 toleration,然后介紹了 Kubernetes Scheduler 框架、擴展點、API 以及可能發生的與資源相關的瓶頸,最后展示了性能調整設置。盡管 Kubernetes Scheduler 能簡單地將 Pod 分配給節點,但是了解其動態性并對其進行配置以實現可靠的生產級 Kubernetes 設置至關重要。

        原文鏈接:https://thenewstack.io/a-deep-dive-into-kubernetes-scheduling/
        (版權歸原作者所有,侵刪)

        本文鏈接:http://m.abandonstatusquo.com/40242.html

        網友評論comments

        發表評論

        您的電子郵箱地址不會被公開。

        暫無評論

        Copyright ? 2012-2022 YUNWEIPAI.COM - 運維派 京ICP備16064699號-6
        掃二維碼
        掃二維碼
        返回頂部
        十分钟免费观看视频高清下载