系统架构 · 调度编排与控制面

场景 1 · 大促前把 HPA 从"抽风"调稳 —— 稳定窗口 + 缩容缓坡

大促压测时副本数 2→9→3 来回横跳: 每次缩掉的副本刚被流量打回原形又要冷启动, 扩容风暴白烧算力。把缩容侧的稳定窗口和速率上限显式写进 YAML。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 4
  maxReplicas: 20
  metrics:
    - type: Resource
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 65 } }
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0     # 扩容要快: 秒级响应流量洪峰
    scaleDown:
      stabilizationWindowSeconds: 300   # 显式写出来, 防止被人改成 0
      policies:
        - { type: Percent, value: 25, periodSeconds: 60 }  # 每分钟最多缩 25%

改完后副本曲线从锯齿变成台阶, 高峰期冷启动次数下降约 80%, 尾部延迟不再被"缩容-扩容"循环打爆。

场景 2 · 深夜告警: HPA 半小时扩缩 40 次 —— 指标源抖动排查

事故排查思路: 先看 HPA 事件还原扩缩原因, 再直接查 metrics API 看原始采样——发现采样窗只有 30 秒, 一次 GC 尖刺就够触发一次扩容。

$ kubectl describe hpa web -n shop | grep -B1 -A3 "SuccessfullyRescaled"
Warning  SuccessfullyRescaled  New size: 9; reason: cpu resource utilization
                               (percentage of request) above target
$ kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/shop/pods/web \
  | jq -c '.window, .containers[0].usage.cpu'
"30s"   "812m"   # 采样窗仅 30s — 一个 GC 尖刺即可让利用率翻倍
# 对策: behavior 稳定窗口 300s + target 从 60% 提到 70%, 宁可晚扩不乱扩

场景 3 · 自己写"证书过期自动轮换" controller —— Reconcile 正确模板

运维每周人肉检查证书到期日, 忘一次就是 P2 事故。用 controller-runtime 写成调谐循环: 到期前 30 天自动续, 每天巡检一次, 出错自动退避重试。

func (r *CertReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    var cert v1alpha1.Certificate
    if err := r.Get(ctx, req.NamespacedName, &cert); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)  // 被删了就别再动
    }
    if time.Until(cert.Status.NotAfter) > 30*24*time.Hour {
        return ctrl.Result{RequeueAfter: 24 * time.Hour}, nil // 没到期, 明天再看
    }
    if err := renewAndApply(ctx, r.Client, &cert); err != nil {
        return ctrl.Result{}, err        // 出错 → 队列指数退避, 自动重试
    }
    return ctrl.Result{RequeueAfter: 24 * time.Hour}, nil
}

场景 4 · 三个支付副本全在一台宿主机, 机柜断电整组团灭 —— 反亲和打散

不带反亲和时, 调度器完全可能把三个副本堆到同一节点。给核心服务加"尽量打散"的反亲和, 再用 PDB 兜底主动驱逐场景。

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:   # 尽量打散, 不至于 Pending
      - weight: 100
        podAffinityTerm:
          topologyKey: kubernetes.io/hostname
          labelSelector:
            matchLabels: { app: payments }
# 关键: 支付这类核心服务再配 PDB 兜底 — drain 节点时最多断 1 个副本

场景 5 · Flink 批处理把在线服务 CPU 挤到 95% —— 污点物理隔离批处理节点

离线批处理和在线业务混跑, 大任务一上在线接口 P99 翻倍。给批处理节点打污点 + 打标签, 让在线 Pod 根本进不来, 批处理也只进这些节点。

# 节点侧: kubectl taint nodes batch-01 dedicated=batch:NoSchedule
#         kubectl label  nodes batch-01 pool=batch
# Pod 侧: 双保险 — 容忍(进得去) + 选择器(只进去)
tolerations:
  - { key: dedicated, operator: Equal, value: batch, effect: NoSchedule }
nodeSelector:
  pool: batch
resources:
  requests: { cpu: "8", memory: 16Gi }   # 批处理如实申报, 不挤占在线业务

场景 6 · 结算 CronJob 重叠执行, 商户被扣两遍钱 —— Forbid + 幂等键 + 补跑窗口

控制面升级重启了 8 分钟, CronJob 错过触发点后又立即补跑, 和上一轮没跑完的实例叠在一起执行。三件套防住: 禁止重叠 + 幂等键 + 明确的补跑窗口。

schedule: "30 2 * * *"          # 注意: 默认按控制器时区(UTC)解释
concurrencyPolicy: Forbid       # 上一轮还没跑完 → 本轮跳过, 绝不叠加
startingDeadlineSeconds: 600    # 错过触发点 10 分钟内允许补跑, 再晚放弃
jobTemplate:
  spec:
    backoffLimit: 2             # 失败最多重试 2 次, 然后告警人工介入
    template:
      spec:
        restartPolicy: Never
        containers:
          - name: settle
            image: settle:v1.8
            env:
              - name: RUN_ID   # 幂等键: Pod 名带时间戳, 重试也不会重复扣款
                valueFrom: { fieldRef: { fieldPath: metadata.name } }

场景 7 · 把"每周清理过期归档"的人肉脚本封装成 Operator (CRD)

清理脚本散在 20 台机器的 crontab 里, 谁改过配置没人知道。把期望状态定义成 CRD, 运维动作变成调谐循环, kubectl 直接看结果。

apiVersion: ops.example.com/v1alpha1
kind: ArchiveCleanup            # CRD: 把运维手册变成 API 对象
spec:
  bucket: logs-prod
  keepDays: 30
  schedule: "0 3 * * 0"
status:                         # controller 调谐后回写实际状态
  lastCleanup: "2026-09-20T03:00:12Z"
  deletedObjects: 14823
# 关键: kubectl get archivecleanup 直接看运维结果, 不再 SSH 翻 cron 日志

场景 8 · 200 台节点 CPU 利用率常年 18% —— requests 乱填毁掉装箱

各组申报资源全靠拍脑袋, 六成 Pod 无脑填 100m, 调度器按声明值装箱, 机器"名义上满了实际很闲"。先用 VPA recommender 给建议值, 再压测校准。

$ kubectl top nodes --sort-by=cpu | head -3
NAME       CPU(cores)   CPU%    MEMORY
node-a31   812m         10%     42%      # 声明满了, 实际很闲
$ kubectl get pods -A -o json | jq '[.items[].spec.containers[].resources.requests.cpu // "unset"] | group_by(.) | map({cpu: .[0], n: length}) | sort_by(-.n)'
[{"cpu":"100m","n":4123},{"cpu":"500m","n":980},{"cpu":"unset","n":318}]
# → 六成 Pod 无脑填 100m; 按 VPA recommender 建议值 + 压测校准 requests

校准后集群从 200 台缩到 130 台, 同样的业务量, 一年省下几十万机器成本。

场景 9 · 大促核心支付要保命, 报表任务全部让路 —— PriorityClass 抢占

大促预热时资源紧张, 支付 Pod 调度不进去。给支付挂高优先级, 调度器自动驱逐低优先级报表腾位; 报表延后几分钟没人投诉, 支付上不去是 P0。

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata: { name: payment-critical }
value: 900000                    # 高于普通业务(0), 低于系统级(2000000000+)
preemptionPolicy: PreemptLowerPriority
---
# 被抢占 Pod 上会看到真实事件:
#   Preempted by pod "pay-7d9f4" on node "node-a31"
# 报表让位 → 支付上位; 资源回落后报表自动重新排队调度回来

场景 10 · 节点例行维护, drain 一条命令带走支付 leader —— 排水 + PDB

运维 kubectl drain 直接把持有租约的 leader 副本一起驱逐, 结算中断。给核心服务配 PodDisruptionBudget, 让主动驱逐(drain/缩容)永远保住最少副本数。

# PodDisruptionBudget: 主动驱逐(drain/缩容)时至少保 2 个副本在线
apiVersion: policy/v1
kind: PodDisruptionBudget
spec:
  minAvailable: 2
  selector: { matchLabels: { app: payments } }
# $ kubectl drain node-a31 --ignore-daemonsets --delete-emptydir-data
# → error when evicting pods/"payments-7d9f4" -n shop (will retry after 5s):
#   Cannot evict pod as it would violate the pod's disruption budget.
# → 等 leader 优雅切换后自动放行, 服务不断连