Ubuntu上Kubernetes资源调度策略

Ubuntu上Kubernetes资源调度策略
Kubernetes的资源调度策略是其核心功能之一，旨在将Pod高效、合理地分配到Ubuntu节点上，确保资源充分利用、应用性能稳定及集群可靠性。这些策略涵盖资源需求定义、节点选择规则、调度阶段流程、高级优化机制等多个维度，以下是具体内容：

1. 资源需求定义：Requests与Limits

Pod通过resources.requests（资源请求）和resources.limits（资源限制）明确其对计算资源（CPU、内存）的需求，是调度的基础。

• Requests：定义Pod启动时所需的最小资源量（如cpu: "250m"、memory: "128Mi"），调度器会确保节点有足够的可用资源（如CPU≥250m、内存≥128Mi）才会将Pod调度到该节点。
• Limits：定义Pod能使用的最大资源量（如cpu: "500m"、memory: "256Mi"），当Pod尝试突破限制时，Kubernetes会通过OOM Killer终止内存溢出的进程，或通过CPU throttling限制CPU使用率（如限制为50%），防止资源滥用。
  建议结合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节点。例如，要求Pod调度到Ubuntu节点（通常标记为kubernetes.io/os: linux）的配置：

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/os
            operator: In
            values:
            - linux
  

  支持requiredDuringScheduling（必须满足）和preferredDuringScheduling（优先满足）两种模式。
• Pod亲和性/反亲和性（PodAffinity/PodAntiAffinity）：
  • 亲和性：让Pod与同服务的其他Pod分布在同一节点（如“Redis主从Pod放在同一节点”），提升数据访问效率；
  • 反亲和性：让Pod与同服务的其他Pod分布在不同节点（如“支付服务的多个副本分散到不同Ubuntu节点”），提升高可用性。

4. 资源保护：污点（Taints）与容忍（Tolerations）

通过污点和容忍机制，控制哪些Pod可以调度到Ubuntu节点：

• 污点（Taint）：在Ubuntu节点上设置污点（如kubectl taint nodes node1 key=value:NoSchedule），表示该节点“拒绝”调度无对应容忍的Pod（如Master节点通常设置此污点，防止普通Pod调度过来）。
• 容忍（Toleration）：在Pod定义中添加容忍（如tolerations: - key: "key" operator: "Equal" value: "value" effect: "NoSchedule"），允许Pod调度到带对应污点的节点。
  常用于隔离生产环境与测试环境的节点，或保护关键系统节点。

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的资源请求在合理范围内（如未指定requests的Pod自动应用默认值）。

6. 自动伸缩：动态调整节点资源

通过以下机制实现资源动态调整，应对流量波动：

• Horizontal Pod Autoscaler（HPA）：根据Pod的CPU/内存使用率（或其他指标，如QPS）自动调整Pod副本数（如电商平台的限时抢购场景，HPA可将Pod副本从5个扩展到20个，高峰过后自动缩回）。
• Vertical Pod Autoscaler（VPA）：自动调整Pod的requests和limits（如增加CPU或内存），适合长期运行的应用（如数据库）。需注意：VPA与HPA不建议同时用于同一资源维度（如CPU）。
• Cluster Autoscaler：当集群资源不足（如所有Ubuntu节点都已满负荷）时，自动添加新节点；当资源过剩时，删除闲置节点，确保资源按需分配。

7. Ubuntu节点特定优化

针对Ubuntu系统的特性，可通过以下方式优化资源调度性能：

• NUMA架构优化：在NUMA架构的Ubuntu节点上，通过cpuManagerPolicy: static将容器绑定到特定CPU核心，减少内存访问延迟，提升性能。
• 内核参数调优：调整Ubuntu内核参数（如vm.swappiness降低交换空间使用、net.core.somaxconn增加TCP连接队列长度），优化容器运行环境。
• 镜像优化：使用轻量级Ubuntu基础镜像（如ubuntu:22.04替代ubuntu:latest），减少镜像大小和启动时间，降低资源消耗。