当 AI 开始写 K8s YAML，运维人的出路在哪里？

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

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

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

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

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

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

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

apiVersion: apps/v1kind: Deploymentmetadata:  name: devapp  labels:    app: devappspec:  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/v2kind: HorizontalPodAutoscalermetadata:  name: devapp-hpaspec:  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 的几个典型问题：

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

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

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

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

• initialDelaySeconds: 30

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

• requests: cpu 250m, memory 512Mi

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

比如你要写一个：

• 带蓝绿部署的 ArgoCD Application

• 需要跨 namespace 访问的 ServiceAccount + RBAC

• 用 cert-manager 自动签发证书的 Ingress

• 需要结合 PodTopologySpread 做跨可用区调度的 StatefulSet

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

说实话，写 YAML 这件事本身，从来就不是运维的核心价值。你想想，你花时间最多的是写 YAML 吗？不是。你花时间最多的是：

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

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

etcd 磁盘满了怎么救？节点 NotReady 了怎么排查？CoreDNS 解析偶尔超时是什么原因？iptables 和 IPVS 迁移会遇到什么坑？——这些我在之前的文章里都写过，全是 AI 写不了的东西，因为它需要现场经验。

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

想通这些之后，我调整了自己用 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 不出问题”：通过工具、平台、规范、自动化来保障。

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

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

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

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

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

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 背后的东西。