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特性），确保关键业务运行。

0 赞

0 踩