Kubernetes容器编排资源调度实战：从调度策略到弹性伸缩的完整方案

Kubernetes资源调度的底层逻辑

Kubernetes调度器的核心职责是将Pod分配到合适的Node上运行。默认调度器kube-scheduler基于预选（Predicate）和优选（Priority）两阶段工作：预选过滤掉不满足硬性条件的节点，优选对剩余节点打分排序，选择得分最高的节点。

理解调度器的决策逻辑是做好资源调度的基础。很多生产环境中的调度问题——Pod集中导致热点、资源碎片化、伸缩不及时——都源于对调度策略配置不当。

资源请求与限制的精确配置

资源请求（requests）和限制（limits）是调度决策的核心输入。requests决定Pod被调度到哪个Node，limits决定Pod运行时可使用的资源上限。

# 资源配置最佳实践
apiVersion: v1
kind: Pod
metadata:
  name: api-server
spec:
  containers:
  - name: app
    image: api-server:v2.1
    resources:
      requests:
        cpu: "500m"       # 调度时保证0.5核
        memory: "512Mi"   # 调度时保证512Mi内存
      limits:
        cpu: "2000m"      # 运行时上限2核
        memory: "2Gi"     # 运行时上限2Gi内存

常见的配置错误：

– requests和limits差距过大：比如requests 100m CPU但limits 4000m。这种配置会导致节点过度承诺（overcommit），当多个Pod同时请求峰值资源时触发OOM或CPU throttling
– 内存limits低于JVM堆内存：Java应用的Xmx必须小于limits.memory，留出堆外内存和容器开销，建议Xmx设为limits.memory的70%
– 不设置requests只设置limits：Kubernetes会将requests设为与limits相同值，导致资源预留远超实际使用量

生产环境建议CPU overcommit比例不超过3:1，内存overcommit比例不超过1.5:1。超过这个比例，在流量高峰时OOM Kill事件会显著增加。

节点亲和性与反亲和性策略

通过亲和性规则控制Pod的调度位置，是避免热点和提升可靠性的关键手段：

# 反亲和性：同一部署的不同副本分散到不同节点
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  template:
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values: ["api-server"]
              topologyKey: kubernetes.io/hostname
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-role
                operator: In
                values: ["compute"]

preferredDuringScheduling是软性约束，调度器尽量满足但不强制；requiredDuringScheduling是硬性约束，不满足就不调度。反亲和性用preferred更灵活，避免集群资源不足时Pod无法调度。

拓扑分布约束：比反亲和性更精细的打散

TopologySpreadConstraints是Kubernetes 1.19+提供的更精确的Pod分布控制机制：

# 按可用区均匀分布
topologySpreadConstraints:
- maxSkew: 1                    # 任意两个拓扑域的Pod数量差不超过1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
    matchLabels:
      app: api-server

maxSkew=1确保每个可用区的Pod数量差不超过1。whenUnsatisfiable: DoNotSchedule是硬性约束，如果没有足够的可用区来满足分布要求，Pod会保持Pending状态。

这种策略比反亲和性更适合大规模集群。反亲和性只能控制不在同一节点，拓扑分布约束可以按zone、rack等任意拓扑维度均匀打散。

弹性伸缩：HPA + VPA + Cluster Autoscaler协同

弹性伸缩不是单一的HPA配置，而是三层协同：

HPA（水平Pod自动伸缩）：基于指标调整Pod副本数

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 3
  maxReplicas: 50
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "1000"

HPA的扩展速度取决于两个因素：新Pod的启动时间和指标采集周期。对于Java等启动慢的应用，建议minReplicas设置足够应对常规峰值，HPA只应对突发流量。

VPA（垂直Pod自动伸缩）自动调整requests和limits。VPA适合长期运行的、资源使用模式稳定的服务。不建议在频繁伸缩的Deployment上使用VPA，因为VPA调整资源需要重启Pod。

Cluster Autoscaler根据Pending Pod自动扩容节点。检测到有Pod因为资源不足而Pending时，自动向云厂商请求新节点。缩容策略需要谨慎配置，确保不会在缩容时驱逐正在处理请求的Pod。

三层协同策略：HPA负责应对流量波动（秒-分钟级），VPA负责优化资源分配（小时-天级），Cluster Autoscaler负责集群容量调整（分钟级）。

调度排障：常见问题与诊断方法

Pod无法调度是最常见的调度问题。通过kubectl describe pod查看Events字段可以快速定位原因：

# 常见调度失败原因
# 1. Insufficient cpu/memory -> 节点资源不足，需要扩容或调整requests
# 2. Node(s) didn't match node selector -> 亲和性约束无法满足
# 3. PodToleratesNodeTaints -> 节点有污点且Pod没有对应容忍
# 4. Insufficient pci resources -> GPU/FPGA等专用资源不足

# 查看节点资源使用情况
kubectl top nodes

# 查看节点可分配资源
kubectl describe node <node-name> | grep -A5 Allocatable

# 查看调度器的调度决策日志
kubectl logs -n kube-system kube-scheduler-<node> --tail=100

资源碎片化是另一个隐蔽问题：每个节点都有些剩余资源，但无法凑出足够的空间来调度一个新Pod。解决方案是设置ResourcePolicy避免过度碎片化，或使用Descheduler定期重平衡Pod分布。

调度策略配置清单

1. 每个Deployment都配置requests和limits，CPU overcommit不超过3:1，内存overcommit不超过1.5:1
2. 关键业务配置podAntiAffinity，副本分散到不同节点
3. 跨可用区部署使用topologySpreadConstraints，maxSkew=1
4. HA场景配置PodDisruptionBudget，最小可用副本数大于等于2
5. HPA指标优先使用自定义指标（QPS、队列深度）而非CPU
6. VPA仅用于资源使用模式稳定的服务
7. Cluster Autoscaler配置合理的缩容冷却时间（大于等于10分钟）
8. 定期运行Descheduler重平衡Pod分布