Kubernetes容器编排资源调度实战指南

Kubernetes的资源调度机制决定了Pod在集群中的运行位置，直接影响应用性能、可用性和资源利用率。默认调度器虽然能满足基础场景，但在生产环境中，精细化的资源调度配置是保障SRE稳定性工程的核心能力。从资源请求与限制的设定，到调度约束的策略编排，再到自定义调度器的扩展开发，每一层都存在实战中需要重点掌握的配置要点。

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

资源请求（requests）和限制（limits）是Kubernetes调度的基石。requests决定调度决策——调度器根据requests之和判断节点是否有足够资源；limits决定运行时约束——容器实际使用超过limits会被OOMKilled或CPU节流。

# 生产级Pod资源配置模板
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  namespace: production
spec:
  containers:
  - name: app
    image: registry.internal.com/api-server:v2.4.1
    resources:
      requests:
        cpu: "500m"        # 调度依据：保证0.5核CPU
        memory: "512Mi"     # 调度依据：保证512MB内存
        ephemeral-storage: "1Gi"
      limits:
        cpu: "2000m"       # 运行时上限：最多2核
        memory: "1Gi"      # 运行时上限：最多1GB
        ephemeral-storage: "2Gi"
    # 关键：requests/limits比例反映负载特征
    # CPU ratio 1:4 → 突发型负载，平均低但偶有峰值
    # Memory ratio 1:2 → 内存使用相对稳定，预留缓冲
  - name: sidecar-log
    image: registry.internal.com/log-collector:v1.2
    resources:
      requests:
        cpu: "50m"
        memory: "64Mi"
      limits:
        cpu: "200m"
        memory: "128Mi"

常见配置错误与诊断

生产环境中资源配置不当是导致服务不稳定的首要原因。以下是高频问题诊断：

# 问题1：OOMKilled频繁发生
# 诊断命令
kubectl describe pod <pod-name> | grep -A5 "Last State"
# 输出示例:
#   Last State:     Terminated
#     Reason:       OOMKilled
#     Exit Code:    137
# 修复: 调高memory limits，或优化应用内存使用

# 问题2：CPU节流导致延迟毛刺
# 诊断命令
kubectl top pod <pod-name> --containers
# 若CPU使用率接近limits但requests远低于limits
# 修复: 增大CPU requests，减少throttling时间

# 问题3：节点资源碎片化导致大Pod无法调度
# 诊断命令
kubectl describe node <node-name> | grep -A10 "Allocated resources"
# 输出示例:
#   Allocated resources:
#     CPU Requests: 3800m (95%)  # CPU几乎全部被requests占满
#     Memory Requests: 14Gi (87%)
# 修复: 调整小Pod的CPU requests，释放碎片空间

调度约束策略与拓扑分布

单靠资源请求/限制无法保证高可用部署。调度约束策略控制Pod在集群拓扑中的分布方式，是故障域隔离的关键配置。

Pod反亲和与拓扑分布约束

# 方案一：Pod反亲和性（旧方案，仍有广泛使用）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cache-cluster
spec:
  replicas: 6
  template:
    spec:
      affinity:
        podAntiAffinity:
          # 硬约束：同一节点不允许运行2个相同Pod
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: cache-cluster
            topologyKey: kubernetes.io/hostname
          # 软约束：尽量分散到不同可用区
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchLabels:
                  app: cache-cluster
              topologyKey: topology.kubernetes.io/zone

# 方案二：拓扑分布约束（推荐，控制力更强）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 9
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1           # 各zone间Pod数差不超过1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule  # 不满足时拒绝调度
        labelSelector:
          matchLabels:
            app: api-service
      - maxSkew: 1           # 各node间Pod数差不超过1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: ScheduleAnyway  # 软约束
        labelSelector:
          matchLabels:
            app: api-service

污点与容忍的节点隔离方案

污点（Taint）和容忍（Toleration）实现节点级别的隔离调度，适用于GPU节点、专用存储节点、故障节点等场景：

# GPU节点专用调度
# 1. 给GPU节点打污点
kubectl taint nodes gpu-node-01 nvidia.com/gpu=true:NoSchedule
kubectl taint nodes gpu-node-02 nvidia.com/gpu=true:NoSchedule

# 2. GPU工作负载配置容忍
apiVersion: v1
kind: Pod
metadata:
  name: model-training
spec:
  tolerations:
  - key: "nvidia.com/gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
  nodeSelector:
    accelerator: nvidia-a100  # 结合nodeSelector精准定位
  containers:
  - name: training
    image: registry.internal.com/training:v3.1
    resources:
      limits:
        nvidia.com/gpu: 2

优先级与抢占调度机制

集群资源不足时，优先级和抢占机制确保高优先级工作负载获得资源：

# 定义优先级类
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: critical-inference
value: 1000000
globalDefault: false
description: "生产环境推理服务，最高优先级"
preemptionPolicy: PreemptLowerPriority  # 允许抢占低优先级Pod

---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: batch-training
value: 100000
globalDefault: false
description: "离线训练任务，可被抢占"

---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: development
value: 10000
globalDefault: false
description: "开发测试环境，最低优先级"

抢占行为控制

当高优先级Pod因资源不足进入Pending状态时，调度器会选择低优先级Pod进行驱逐。抢占过程需要关注：Pod Disruption Budget（PDB）可能阻止某些Pod被驱逐；DaemonSet的Pod不参与抢占；被驱逐的Pod会有优雅终止期（默认30秒）。生产环境中应确保关键服务配置了PDB：

# 关键服务的Pod Disruption Budget
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-server-pdb
  namespace: production
spec:
  minAvailable: "50%"  # 至少保持50%副本可用
  selector:
    matchLabels:
      app: api-server

DevOps实践中的调度自动化

CI/CD流水线中的调度配置需要与部署流程深度集成。推荐实践：

# ArgoCD Application配置——自动同步调度策略
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-service
  namespace: argocd
spec:
  project: production
  source:
    repoURL: https://git.internal.com/platform/api-service
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
    retry:
      limit: 3
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

调度性能调优与监控体系

大规模集群（1000+节点）中，调度器本身可能成为瓶颈。监控指标和调优参数：

# kube-scheduler关键监控指标
# 1. 调度延迟(P99应 < 5s)
scheduler_scheduling_algorithm_duration_seconds_bucket

# 2. 调度失败率(应 < 1%)
scheduler_schedule_attempts_total{result="error"}

# 3. 抢占频率(频繁抢占说明资源规划有问题)
scheduler_preemption_attempts_total

# 调优参数(kube-scheduler启动参数)
--max-computation-time=10s        # 单次调度计算超时
--percentage-of-nodes-to-score=50 # 大集群只评估50%节点提升效率
--pod-max-in-unschedulable-pods-duration=300s  # Pending超时触发抢占

调度监控需要建立从调度延迟到应用SLA的全链路可观测性。当调度延迟异常升高时，排查路径为：检查集群资源碎片化程度 → 检查是否有大量Pending Pod → 检查调度器日志中的失败原因 → 评估是否需要扩容节点或调整资源配置策略。故障应急响应流程中，调度异常的P0级处理时限为15分钟内恢复调度能力。