云原生落地：上了 Kubernetes 之后，真正决定成败的五个开关

CNCF 2025 年度调查里，98% 的组织已经在用云原生技术。所以问题不再是"要不要上"，而是同样的集群，为什么有的团队成本降了、故障少了，有的反而更贵更脆。差别通常集中在五个开关上。

开关一：requests 和 limits 是两件事

很多人把这两个字段当成同一个"资源上限"随手填，其实它们管的是两套机制。

• requests 决定调度：节点上剩余的 request 不够，Pod 就排不上去。对 CPU 来说，request 还是一个权重——节点争抢时，request 大的容器分到更多 CPU 时间。
• limits 决定后果：CPU 超限被内核按 CFS 周期节流，不杀进程，但延迟会抖；内存超限直接触发 OOM，容器被杀。

两个常见错误正好相反。一是把 requests 按峰值拍大，节点装箱率掉到三成，钱花在预留上；二是只写 limits 不写 requests，Kubernetes 会把 limit 复制成 request，等于用峰值占满节点。

比较稳的默认值：requests 按 P95 实际用量设，内存 limit 必须给（那是 OOM 安全边界），CPU limit 能不给就不给——延迟敏感的服务被节流，省下的那点 CPU 远不够赔用户。判断有没有被节流，看两个指标相除：container_cpu_cfs_throttled_periods_total / container_cpu_cfs_periods_total，长期高于 10% 就该查了。

开关二：弹性扩容看什么信号

默认 HPA 盯 CPU 利用率。这个信号对 Web 服务勉强够用，对队列消费、批量任务、异步推理几乎失效——消息堆在队列里，CPU 仍然很闲，扩容永远不会触发。

做法是把信号换成真正代表"用户在等"的指标：队列深度、P95 延迟、并发连接数。KEDA 可以把这些外部指标包装成标准 HPA，还能配多个触发器，取需求最大的那个。

另一个容易忽略的是伸缩行为。默认策略抖动明显，建议显式写死方向性差异：扩容快、缩容慢。下面这段是常见起点，数值要按自己的启动耗时调：

behavior:
  scaleUp:
    stabilizationWindowSeconds: 0        # 有人排队就立刻扩
    policies:
      - type: Percent
        value: 100
        periodSeconds: 60
  scaleDown:
    stabilizationWindowSeconds: 300      # 闲 5 分钟才缩，避开波峰
    policies:
      - type: Percent
        value: 50
        periodSeconds: 60

还有一笔账要提前算：从触发扩容到 Pod Ready，中间有调度、拉镜像、启动、预热。冷启动 40 秒的服务，给它配 minReplicas=1 就是在赌流量不会突增。弹性不等于秒级，保留量要按启动耗时倒推。

开关三：发布过程有没有把流量当回事

滚动更新只保证"旧 Pod 下线、新 Pod 上线"，不保证上线那一刻能接住请求。三个细节决定发布是否掉错误率：

• readinessProbe 必须配：没有它，容器一启动就被加进 Service，依赖还没连上就开始接流量。
• 优雅退出要成对配：preStop 钩子加上合理的 terminationGracePeriodSeconds，让在途请求处理完再退。只配一个等于没配。
• 用 PDB 兜住并发：节点缩容或滚动升级时，保证可用副本数不低于业务下限。

再往上一步是渐进式发布：先放 5% 流量，盯错误率和 P95 延迟，指标不达标自动回滚。这一步的价值不在发布本身，而在于把"回滚"从人的手速变成流水线的判定。

开关四：成本要能算到团队头上

容器化之后成本最常见的失控方式不是单价高，而是"没人认领"。三个动作按顺序做：

1. 打标签：工作负载必须有归属标签（业务、环境、负责人），否则账单只是一串数字。
2. 划边界：命名空间配 ResourceQuota 限总量，LimitRange 给默认值，避免单个服务吃光节点。
3. 看装箱率：拿真实用量除以 request 总量。这个比值长期低于 40%，说明要么 requests 虚高，要么该换更小的规格或做混部。

节点池按负载类型分层也很关键：通用型、内存型、GPU 型分开，别让一个内存型节点池被 CPU 密集任务占满，也别让 GPU 节点跑无状态 Web。

开关五：把架构做成"可被杀掉"

前四个开关都是运维层面的，最后一个在代码里：任何一个 Pod 是否能被随时杀掉而不影响用户。这一条不成立，前面所有弹性、发布、成本优化都会打折。

判断方法很土但有效：生产环境随机杀一个 Pod，看监控有没有波动。会话丢、任务丢、长连接断、本地文件丢，就说明还没到云原生那一步——只是把虚拟机里的进程装进了容器。

一张表收尾

落到华为云上，弹性这一层是现成的：CCE 的工作负载弹性覆盖 HPA、CustomedHPA、CronHPA、VPA 和基于历史数据的 AHPA；节点弹性由集群弹性引擎负责，突增流量还可以通过突发弹性引擎直接弹到 CCI，不必等节点创建。Autopilot 集群则省掉节点运维，按 Pod 规格计费，适合突发和 CI 这类短时负载。

最后回到那个数字：98% 的组织都在用云原生，但 GitOps 采用率在成熟度最低的一档是 0%，最高的一档是 58%。工具是同一批工具，差别在有没有把上面这些开关掰到对的位置。

参考：
Kubernetes 文档 · Resource Management for Pods and Containers（kubernetes.io/docs/concepts/configuration/manage-resources-containers/）
CNCF · 2025 Annual Survey Report（cncf.io）
华为云 · 云容器引擎 CCE 弹性伸缩概述（support.huaweicloud.com）