云原生环境下的运维方式变化_传统运维与云原生对比

云原生运维以声明式配置、可观测性三合一、自动弹性伸缩和控制器自愈为核心，取代传统人肉操作；需通过 Helm/Kustomize 管理配置，统一指标日志链路，联动 HPA/VPA/Cluster Autoscaler，并依赖合理健康检查与服务网格策略。

手工救火 → 声明式配置：为什么 Git 里改一行 YAML 就能上线

传统运维靠人肉执行 ssh、vim、systemctl restart，环境差异导致“开发能跑，测试崩了，生产挂了”。云原生把“怎么做”变成“要什么”——用 Deployment、Service、Ingress 这类声明式资源描述终态，Kubernetes 自动对齐。Git 成为唯一真相源，每次 git commit 都自带审计日志和回滚锚点。

• 实操建议：所有应用配置必须走 Helm Chart 或 Kustomize，禁止直接 kubectl apply -f *.yaml 手动提交
• 容易踩的坑：没加 resourceRequests/limits，Pod 被 OOMKilled 后反复重启却查不到内存超限记录
• 性能影响：声明式操作本身不耗时，但控制器 reconcile 延迟（如网络策略生效慢）可能让服务短暂不可达

监控靠人盯屏 → 指标+日志+链路三合一自动下钻

传统运维靠 Zabbix 告警+人工翻日志，故障定位像破案；云原生要求指标（CPU/延迟/P95）、日志（结构化 JSON）、调用链（trace_id 关联）三者在统一平台可交叉下钻。比如 APM 报告某个微服务 P95 突增，点开就能看到对应 trace 的慢 SQL，再切到 LTS 查该 SQL 的完整日志上下文。

• 使用场景：排查“用户反馈下单卡顿”，不再需要分别登录数据库、中间件、应用服务器查日志
• 参数差异：prometheus scrape_interval 设太长（>30s）会漏掉短时毛刺；jaeger sampler.type 用 const=1 会压垮链路系统，建议用 ratelimiting
• 常见错误现象：日志没打 trace_id 字段，导致链路断在网关层，APM 只能看到“外部调用”黑盒

扩容靠打电话申请机器 → HPA + VPA + Cluster Autoscaler 联动伸缩

传统扩容是“提工单→等审批→装系统→配环境→上线”，周期以天计；云原生下，HPA 根据 CPU/自定义指标（如 QPS）自动扩缩 Pod 数量，VPA 动态调 Pod 的 requests，Cluster Autoscaler 在节点资源不足时自动加云服务器——三者配合，5 分钟内完成从 2 个 Pod 到 20 个 Pod + 新增 2 台 4C8G 节点的全过程。

• 实操建议：HPA 不要只看 CPU，务必接入业务指标（如 nginx_ingress_controller_requests_total），否则静态资源请求会干扰判断
• 容易踩的坑：VPA 和手动编辑 resources 冲突，导致 Pod 被反复驱逐；启用前先关掉 updateMode: Off 做观察
• 兼容性影响：某些老应用（如 Java 8u191 以下）不识别 cgroup v2，VPA 调整内存后 JVM 仍按旧值启动

故障恢复靠人肉切流 → 控制器自动愈合 + 服务网格熔断降级

传统故障恢复依赖 SRE 手动修改 DNS、Nginx upstream 或数据库主从切换；云原生中，Kubernetes Controller 检测到 Pod 崩溃后 5 秒内拉起新实例，Istio 的 DestinationRule 配置熔断策略（如连续 5 次 5xx 触发 60 秒熔断），VirtualService 实现灰度流量切分——整个过程无人值守。

• 使用场景：MySQL 主库宕机时，应用层无需改连接串，由服务网格自动将流量切到只读从库，并返回兜底数据
• 常见错误现象：没给 Istio 注入 sidecar，或 sidecar.istio.io/inject: "true" 写在 namespace annotation 而非 pod template，导致流量不走网格
• 关键细节：Kubernetes 的 livenessProbe 如果设置过短（如 3 秒检测一次），可能误杀正在加载大缓存的 Pod

云原生运维不是把脚本换成 YAML，而是把“人判断要不要做”变成“系统根据规则自动做”。最难的不是写 Deployment，是设计出能让控制器稳定收敛的健康检查逻辑和资源边界——这点，90% 的团队在压测阶段才第一次意识到。