Ubuntu上Kubernetes的資源調度策略

Ubuntu上Kubernetes資源調度策略
Kubernetes的資源調度策略是其核心功能之一，旨在將Pod高效、合理地分配到Ubuntu節點（或其他操作系統節點）上，確保資源充分利用、應用性能穩定及集群可靠性。這些策略涵蓋資源需求定義、節點選擇規則、調度階段流程、高級優化機制等多個維度，以下是具體內容：

1. 資源需求定義：Requests與Limits

Pod通過resources.requests（資源請求）和resources.limits（資源限制）明確其對計算資源（CPU、內存）的需求，是調度的基礎。

• Requests：定義Pod啟動時所需的最小資源量，調度器會確保節點有足夠的可用資源（如CPU≥100m、內存≥1Gi）才會將Pod調度到該節點。
• Limits：定義Pod能使用的最大資源量，當Pod嘗試突破限制時，Kubernetes會通過OOM Killer終止進程（內存）或限制CPU使用（CPU throttling），防止資源濫用。
  建議結合LimitRange為命名空間設置默認的requests/limits，避免用戶未指定導致的資源混亂。

2. 調度階段：預選（Predicates）與優選（Priorities）

Kubernetes調度器采用“預選+優選”的兩階段模型，確保Pod被分配到合適的Ubuntu節點：

• 預選階段（Predicates）：通過強制性規則過濾掉不滿足條件的節點。常見規則包括：
  • 節點資源充足（可用CPU≥Pod requests的CPU，可用內存≥Pod requests的內存）；
  • 節點標簽匹配（如Pod要求nodeSelector.zone=us-west-1，則只有帶該標簽的Ubuntu節點會被保留）；
  • 節點未處于NotReady狀態；
  • 節點未設置排斥Pod的Taint（污點，需Pod有對應Toleration容忍）。
• 優選階段（Priorities）：對通過預選的節點進行打分（0-10分），選擇得分最高的節點。常見打分規則包括：
  • 資源均衡（如NodeResourcesBalancedAllocation插件）：優先選擇CPU、內存利用率均衡的節點，避免資源碎片；
  • 負載最低（如LeastRequestedPriority插件）：優先選擇當前負載低的節點；
  • 親和性（如NodeAffinity插件）：優先選擇符合Pod親和性規則的節點（如“與同服務的其他Pod在同一節點”）。

3. 節點選擇規則：親和性與反親和性

通過**親和性（Affinity）和反親和性（Anti-Affinity）**規則，優化Pod在Ubuntu節點上的分布，提升性能或可靠性：

• 節點親和性（NodeAffinity）：讓Pod傾向于調度到特定標簽的Ubuntu節點。例如：

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/os
            operator: In
            values:
            - linux  # 選擇Ubuntu節點（Ubuntu通常標記為linux）
  

  支持requiredDuringScheduling（必須滿足）和preferredDuringScheduling（優先滿足）兩種模式。
• Pod親和性/反親和性（PodAffinity/PodAntiAffinity）：
  • 親和性：讓Pod與同服務的其他Pod分布在同一節點（如“Redis主從Pod放在同一節點”）；
  • 反親和性：讓Pod與同服務的其他Pod分布在不同節點（如“避免同一服務的多個Pod集中在單個節點，提升容錯性”）。

4. 資源保護：污點（Taints）與容忍（Tolerations）

通過污點和容忍機制，控制哪些Pod可以調度到Ubuntu節點：

• 污點（Taint）：在Ubuntu節點上設置污點（如kubectl taint nodes node1 key=value:NoSchedule），表示該節點“拒絕”調度無對應容忍的Pod。
• 容忍（Toleration）：在Pod定義中添加容忍（如tolerations: - key: "key" operator: "Equal" value: "value" effect: "NoSchedule"），允許Pod調度到帶對應污點的節點。
  常用于隔離生產環境與測試環境的節點，或保護關鍵系統節點（如Master節點）。

5. 資源配額：Namespace級別的資源限制

通過ResourceQuota限制命名空間內所有Pod的資源使用總量，防止某個團隊或應用過度占用Ubuntu節點資源。例如：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: ubuntu-quota
spec:
  hard:
    requests.cpu: "4"       # 命名空間內所有Pod的CPU總requests不超過4核
    requests.memory: "16Gi" # 內存總requests不超過16Gi
    limits.cpu: "8"         # CPU總limits不超過8核
    limits.memory: "32Gi"   # 內存總limits不超過32Gi
    pods: "20"              # Pod數量不超過20個

需配合LimitRange使用，確保Pod的資源請求在合理范圍內。

6. 自動伸縮：動態調整節點資源

通過Horizontal Pod Autoscaler（HPA）和Cluster Autoscaler實現資源動態調整：

• HPA：根據Pod的CPU/內存使用率（或其他指標，如QPS）自動調整Pod副本數，提升應用吞吐量。例如：

  apiVersion: autoscaling/v2
  kind: HorizontalPodAutoscaler
  metadata:
    name: php-apache-hpa
  spec:
    scaleTargetRef:
      apiVersion: apps/v1
      kind: Deployment
      name: php-apache
    minReplicas: 1
    maxReplicas: 10
    metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50  # 當CPU利用率超過50%時，擴容Pod
  

• Cluster Autoscaler：當集群資源不足（如所有Ubuntu節點都已滿負荷）時，自動添加新節點；當資源過剩時，刪除閑置節點，確保資源按需分配。

7. 高級優化：自定義調度器與優先級

• 自定義調度器：通過編寫自定義調度器（如基于Go語言實現），實現更復雜的調度邏輯（如特定拓撲結構的節點選擇、特殊硬件的分配）。自定義調度器需實現Scheduler接口，并通過schedulerName字段讓Pod使用該調度器。
• 優先級與搶占：為Pod設置priorityClassName（優先級類），高優先級Pod在資源不足時可以搶占低優先級Pod的資源（需開啟Preemption特性），確保關鍵業務運行。