Kubernetes容器编排中的Pod调度策略与资源配额管理实战

Kubernetes容器编排中的Pod调度策略与资源配额管理

网站运维和SRE团队在Kubernetes集群管理中面临的核心挑战是：如何在多租户环境下合理分配计算资源，同时保障关键业务的SLO。Kubernetes的Pod调度策略和资源配额机制是解决这一问题的关键工具链。本文从生产环境实战出发，拆解调度策略的配置方法和资源配额的最佳实践。

DevOps实践中Pod调度策略的分层设计

Kubernetes调度器通过Predicate（过滤）和Priority（打分）两个阶段决定Pod的调度目标。生产环境需要根据业务优先级进行分层调度：

第一层：节点选择约束
通过nodeSelector和nodeAffinity控制Pod只能在特定节点池调度。核心数据库Pod必须落在高IOPS节点，训练任务Pod必须落在GPU节点。

# nodeAffinity：将Redis Pod调度到高IOPS节点池
apiVersion: v1
kind: Pod
metadata:
  name: redis-main
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node-pool
            operator: In
            values: ["high-io"]
          - key: storage-type
            operator: In
            values: ["nvme-ssd"]
  containers:
  - name: redis
    image: redis:7.2
    resources:
      requests:
        memory: "32Gi"
        cpu: "8"
      limits:
        memory: "64Gi"
        cpu: "16"

第二层：Pod反亲和性
同一Deployment的多个副本分散到不同节点和可用区，避免单点故障：

# Pod反亲和性：同一服务副本必须分散到不同节点和可用区
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway
spec:
  replicas: 6
  template:
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values: ["api-gateway"]
              topologyKey: topology.kubernetes.io/zone
          - weight: 50
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values: ["api-gateway"]
              topologyKey: kubernetes.io/hostname

监控告警体系中的资源配额与LimitRange配置

资源配额（ResourceQuota）防止团队间资源抢占，LimitRange防止Pod申请过多资源。两者配合使用：

# ResourceQuota：限制dev命名空间的资源总量
apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "100"
    requests.memory: "200Gi"
    limits.cpu: "200"
    limits.memory: "400Gi"
    pods: "500"
    persistentvolumeclaims: "50"
    services.loadbalancers: "5"

---
# LimitRange：限制单个Pod的资源范围
apiVersion: v1
kind: LimitRange
metadata:
  name: dev-limits
  namespace: dev
spec:
  limits:
  - type: Container
    default:
      cpu: "2"
      memory: "4Gi"
    defaultRequest:
      cpu: "500m"
      memory: "512Mi"
    max:
      cpu: "16"
      memory: "32Gi"
    min:
      cpu: "100m"
      memory: "128Mi"

关键经验：LimitRange的default值一定要设置。没有设置resources的Pod会使用default值，避免”零资源”Pod抢占节点资源。

故障应急响应：调度异常的诊断与处理流程

Pod长时间Pending是SRE最常见的告警之一。诊断流程：

# Step 1: 查看Pod事件
kubectl describe pod <pod-name> -n <namespace> | tail -20

# Step 2: 查看调度器日志
kubectl logs -n kube-system -l component=kube-scheduler --tail=100

# Step 3: 常见Pending原因及处理
# 原因A: Insufficient cpu/memory
#   -> 扩容节点池 或 降低Pod的requests
# 原因B: node(s) didn't match node selector
#   -> 检查nodeAffinity与节点label是否匹配
# 原因C: node(s) had taints that the pod didn't tolerate
#   -> 添加toleration或移除节点taint

# Step 4: 快速释放资源
# 找出资源占用最多的Pod
kubectl top pods -A --sort-by=memory | head -20
kubectl top pods -A --sort-by=cpu | head -20

# Step 5: 驱逐低优先级Pod
kubectl annotate pod <low-priority-pod> cluster-autoscaler.kubernetes.io/safe-to-evict=true

混沌工程验证调度策略的鲁棒性

调度策略的可靠性需要通过混沌工程验证。核心场景：

节点故障模拟：强制驱逐一个可用区的所有Pod，验证反亲和性策略是否真正将副本分散到多个AZ。

资源压力模拟：在集群负载80%时触发水平扩容，验证HPA和Cluster Autoscaler的协同是否正常。

# Chaos Mesh：模拟节点网络分区
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: az-partition-test
  namespace: chaos-testing
spec:
  action: partition
  mode: one
  selector:
    labelSelector:
      "topology.kubernetes.io/zone": "us-east-1a"
  direction: both
  target:
    selector:
      labelSelector:
        "topology.kubernetes.io/zone": "us-east-1b"
    mode: all
  duration: "300s"

# 验证指标：
# 1. API可用性是否保持 > 99.9%
# 2. 跨AZ流量是否增加（预期行为）
# 3. 新Pod是否调度到健康的AZ

CI/CD流水线中的调度策略自动化验证

调度策略的变更必须经过自动化验证才能上线。在CI/CD中集成策略测试：

# 使用kwok（Kubernetes WithOut Kubelet）做轻量调度模拟
# 安装kwok
kwokctl create cluster --nodes 10 --pod-number 1000

# 部署调度策略
kubectl apply -f scheduling-policies.yaml

# 运行调度测试
kubectl apply -f test-pods.yaml
kubectl wait --for=condition=PodScheduled pod --all --timeout=60s

# 验证调度分布
kubectl get pods -A -o wide | awk '{print $8}' | sort | uniq -c
# 预期：Pod均匀分布在10个节点上，偏差不超过20%

# 清理
kwokctl delete cluster

日志分析在调度问题排查中至关重要。将kube-scheduler的日志接入ELK或Loki，配合Grafana Dashboard做调度延迟和失败率的可视化。当调度失败率超过1%时触发P2告警，避免问题累积到用户可感知的程度。