AI 写 K8s YAML 只需 30 秒，运维人的出路在哪？

上个月组里来了个新同事，入职第一天干的事就让我有点破防。

当时正好有个新服务要上线，我正准备打开模板复制粘贴改一改。他直接丢了个 Prompt 给 DeepSeek，30 秒就把 Deployment、Service、ConfigMap、Ingress 全生成了。我凑过去看了一眼，写得还真像回事：resource limits 有，readinessProbe 有，连 affinity 都配了。

当时心里说不上是什么感觉。算不上焦虑，但确实有点不舒服——你练了好几年的手艺，别人 30 秒就能干个八九不离十。

后来冷静下来想想，这事既没那么可怕，也没那么简单。

一、AI 写 YAML，到底到了什么水平？

为了搞清楚这个问题，我花了一周时间，专门拿各种 K8s YAML 的需求去测试 DeepSeek 和 ChatGPT。

先说结论：写标准化的 YAML，AI 目前已经够用了。

比如你让它写一个带 HPA 的 Spring Boot 服务 Deployment，它大概能生成下面这样的东西：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: devapp
  labels:
    app: devapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: devapp
  template:
    metadata:
      labels:
        app: devapp
    spec:
      containers:
      - name: devapp
        image: devapp:latest
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
          limits:
            cpu: 500m
            memory: 1Gi
        readinessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 60
          periodSeconds: 30
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: devapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: devapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

看着挺像那么回事对吧？该有的都有。但问题在于，让它写一个生产环境可用的 YAML，大概率会出问题。

我测试了十几个场景，总结出 AI 目前写 YAML 的几个典型问题：

1、不了解你的集群实际情况

AI 不知道你的节点配置、网络方案、存储类型。比如它会写 storageClassName: standard，但你集群里可能用的是 nfs-client 或 local-path；它会配 hostPort，但你的网络插件是 Calico，hostPort 可能跟 IPVS 冲突。

2、安全相关的配置经常缺失

我测试了好几次，AI 很少主动加上这些：

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false

Pod 级别的 securityContext、NetworkPolicy、PodDisruptionBudget，这些生产环境必须有的东西，AI 经常不写，除非你明确要求。

3、探针配置太“模板化”

initialDelaySeconds: 30 对所有服务都一样？一个轻量的 API 网关和一个需要加载大量缓存数据的微服务，启动时间能一样吗？AI 不了解你的应用启动特征，给出来的值只能当参考。

4、资源配额拍脑袋

requests: cpu 250m, memory 512Mi 这个值怎么来的？AI 不知道你的服务实际消耗多少资源。我见过 AI 给一个数据分析服务配了 256Mi 内存，结果 OOMKill 了。

5、复杂场景处理不了

比如要写一个：

• 带蓝绿部署的 ArgoCD Application
• 需要跨 namespace 访问的 ServiceAccount + RBAC
• 用 cert-manager 自动签发证书的 Ingress
• 需要结合 PodTopologySpread 做跨可用区调度的 StatefulSet

这类涉及多个 CRD 协作的复杂场景，AI 写出来的东西基本没法直接用，你得自己改大半。

二、那运维人的价值到底在哪？

说实话，写 YAML 本身从来不是运维的核心价值。你仔细想想，平时花时间最多的是写 YAML 吗？并不是。更多时间其实花在下面这些事上：

1、排查问题

服务挂了，Pod 一直 CrashLoopBackOff，你去看日志、看事件、看资源使用、看网络策略、看 DNS 解析——这个过程 AI 帮不了你。因为它看不到你集群的实时状态，不了解你的架构拓扑，不知道你上周刚改了哪个 ConfigMap。

2、做架构决策

这个服务用 Deployment 还是 StatefulSet？需不需要 PDB？HPA 的指标用 CPU 还是自定义指标？Service 用 ClusterIP 还是 Headless？这些决策需要对业务的理解、对集群的了解，以及对成本和可靠性的权衡。AI 可以给你选项，但最终拍板的人得是你。

3、处理“脏活累活”

etcd 磁盘满了怎么救？节点 NotReady 怎么排查？CoreDNS 解析偶尔超时是什么原因？iptables 和 IPVS 迁移会踩哪些坑？这些都是 AI 写不了的东西，因为它们依赖现场经验。

4、建立标准和规范

AI 可以帮你生成一个 Deployment 的 YAML，但谁来定义这个 YAML 必须符合什么标准？谁来写 admission webhook 做校验？谁来制定资源配额的策略？谁来设计命名规范和标签体系？这些是运维“基础设施”层面的工作，比写单个 YAML 重要得多。

三、我现在怎么用 AI 的？

想通之后，我调整了自己用 AI 的方式：不再让它“帮我写 YAML”，而是让它“帮我加速”。

场景一：快速生成草稿

以前写一个新服务的 YAML，我要么从旧服务复制粘贴，要么翻文档。现在我会让 AI 先生成一版草稿，然后我在这个基础上改。大概能省 60% 的时间。

Prompt 大概长这样：

帮我写一个 K8s Deployment YAML，要求：
- Spring Boot 服务，端口 8080
- 需要 readinessProbe 和 livenessProbe，使用 /actuator/health
- 资源限制：requests cpu 500m memory 1Gi，limits cpu 2 memory 2Gi
- 需要环境变量注入数据库连接（通过 ConfigMap）
- 使用非 root 用户运行
- 需要 PodDisruptionBudget，最少可用 2 个 Pod

注意，我会明确给出具体的参数值，而不是让 AI 自己决定。

场景二：解释和排错辅助

遇到不熟悉的 CRD 或者报错信息，直接丢给 AI 解释，比自己翻文档快很多。

这个 K8s 事件是什么意思？
"0/3 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate."

场景三：写文档和脚本

让 AI 帮我写运维操作手册、oncall 排查流程、批量操作的 Shell 脚本，这些它干得挺好的。

场景四：学习新东西

比如我想了解 Gateway API 怎么用，让 AI 给我讲一遍基本概念和示例，比直接啃官方文档效率高。

四、运维人真正需要担心的是什么？

如果 AI 写 YAML 不是威胁，那运维人真正应该担心什么？我觉得是两极分化。

一类运维人会越来越强：他们把 AI 当工具，用它处理重复劳动，把省下来的时间花在架构设计、性能优化、故障排查这些 AI 做不了的事情上。

另一类运维人会越来越危险：如果他们的工作就是每天复制粘贴 YAML、改配置、重启服务，那这些工作确实会被 AI 逐渐替代。不是明天，但趋势很明显。

还有一件事值得注意：AI 降低了写 K8s YAML 的门槛，这意味着开发人员会更多地自己写 YAML。

以前开发人员要部署一个服务，得找运维帮忙写 YAML、配 Ingress、设资源限制。现在他们可以直接让 AI 生成，然后自己 apply。这对运维来说意味着什么？意味着那些“写 YAML”的工单会越来越少。

但反过来，开发用 AI 生成的 YAML，往往在本地 minikube 上跑得好好的，一上生产集群就炸。因为 AI 不知道你的 CNI 是 Calico 还是 Flannel，不知道你的 StorageClass 叫什么，不知道你的节点拓扑长什么样。这时候运维的价值就不是“帮开发写 YAML”，而是“让开发写的 YAML 适配这个集群的现实”。

所以运维的工作重心会从“帮别人写 YAML”变成“让别人写的 YAML 不出问题”：通过工具、平台、规范、自动化来保障。

五、我的建议

说了这么多，给还在焦虑的同行几点建议：

1、把 AI 用起来，别抗拒

不管你接不接受，AI 工具已经在改变这个行业了。早点学会用它，你就比不学的人多了一个效率工具。抗拒它不会让它消失。

2、往上走，别往下卷

YAML 层面的工作会越来越自动化，这是趋势。你应该把精力放在架构设计、SRE 实践、可观测性建设、成本优化这些更高维度的事情上。这些是 AI 短期内替代不了的。

3、深入理解原理，别只停留在“会用”

AI 可以帮你写 YAML，但它没法帮你理解为什么 Pod 会卡在 ContainerCreating、为什么 Service 的流量不均匀、为什么滚动更新的时候会丢连接。这些底层原理的理解，是你和“会用 AI 的人”之间的差距。

4、建设平台和工具

如果你能把团队的 K8s 运维经验沉淀成平台、工具、规范，让开发人员能自助服务、让 YAML 的生成和校验自动化，那你的价值就不是“写 YAML 的人”，而是“让整个团队高效运转的人”。

5、保持学习

K8s 生态在快速演进：Gateway API、WASM、Serverless、eBPF……每一波新技术都会带来新的机会。AI 能帮你写 YAML，但它没法帮你判断下一步该学什么。

还有一个建议：别怕 AI，但得怕比你先用好 AI 的同行。工具本身不淘汰人，用工具的人淘汰不用工具的人。

六、写在最后

回到开头那个故事。

后来我和那个新同事聊了聊，发现他其实对 K8s 的理解并不深。AI 帮他生成的 YAML 能跑起来，但有一次出了问题：Pod 一直起不来，他看了半天没找到原因。最后还是我去排查的，发现是 securityContext 的 runAsUser 和宿主机的目录权限冲突了。

他生成的 YAML 里确实写了 runAsNonRoot: true，但他不知道这个配置在什么场景下会出问题。

AI 可以帮你写 YAML，但它没法帮你理解你写的 YAML。

这就是运维人的出路：不是和 AI 比谁写 YAML 快，而是比谁更懂这些 YAML 背后的东西。