云原生运维怎么做？从部署到监控的实操路径

小王刚接手公司新上线的电商后台，发现服务一到大促就卡顿，日志散在十几台机器上，扩容要手动改配置、重启服务，半夜告警来了手忙脚乱——这不是运维，是“救火员”。换成云原生运维后，他把整套服务打包成容器，用 YAML 文件定义扩缩容规则，流量高峰自动加副本；故障时秒级定位到某 Pod 内存溢出，回滚版本只需一条命令。云原生运维不是堆新工具，而是换一套做事逻辑。

第一步：把应用真正“容器化”

别只把 jar 包塞进 Docker 就算完事。得让应用天生适配云环境：配置外置（用 ConfigMap 或环境变量）、日志输出到 stdout/stderr（别写本地文件）、健康检查接口写好（/healthz）。比如 Spring Boot 项目，application.yml 里数据库地址别硬编码，改成：

spring:
  datasource:
    url: ${DB_URL:jdbc:mysql://mysql:3306/app}

启动容器时传 -e DB_URL=jdbc:mysql://prod-mysql:3306/app，环境一换，配置自动跟着变。

第二步：用声明式 YAML 管理一切

Kubernetes 不是远程执行命令的工具，它是“说清楚你要什么，它来搞定怎么实现”。比如部署一个带自动扩缩的 API 服务，写一个 deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: server
        image: registry.example.com/api:v1.2
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 30

然后 kubectl apply -f deployment.yaml，副本数、探针、镜像版本全被记录在案，谁改了什么，Git 里一目了然。

第三步：监控不靠“刷屏”，靠指标驱动

别再守着 Grafana 看 CPU 曲线猜问题。云原生运维盯三个核心指标：延迟（P95 响应时间超 500ms？）、错误率（HTTP 5xx 比例突增？）、饱和度（Pod 内存使用率持续 90%+？）。用 Prometheus 抓取应用暴露的 /metrics 接口，比如 Java 应用加个 Micrometer 依赖，一行代码就能输出 JVM 内存、HTTP 调用次数等指标。

第四步：CI/CD 流水线跑通“提交即上线”

开发 push 代码到 Git，自动触发构建镜像、推送到仓库、更新 Kubernetes 集群。关键不是快，是可追溯：每次上线对应唯一镜像 tag（如 v1.2.3-20240520-abc7d），回滚就是 kubectl set image deploy/api-server server=registry.example.com/api:v1.2.2。流水线脚本里加一句：if [ $(kubectl get pod -l app=api-server | wc -l) -lt 3 ]; then exit 1; fi —— 副本没拉起来，发布直接失败，不糊弄。

第五步：权限和网络，从“开放”变成“最小够用”

别让所有服务都能互相 telnet。用 Kubernetes NetworkPolicy 限制通信，比如订单服务只能访问 MySQL 和 Redis，不能连用户服务；用 RBAC 给运维账号分配精确权限：“能看所有命名空间的 Pod，但不能删 Deployment”。权限不是上线后补的，是写 YAML 时就定死的。

云原生运维不是把老流程套上新名词，而是把“人肉操作”变成“机器可读、可验证、可重复”的动作。你不需要第一天就搞齐全套，先从一个非核心服务开始：容器化、写好健康检查、用 YAML 部署、接上基础监控——跑通闭环，比堆十个工具更重要。