实测AI生成K8s YAML的能力边界：标准化配置可用，生产环境仍有缺口

dbaplus社群 2026-09-20 07:15 广东  AI 写 YAML，到底到了什么水平？ 上个月我们组来了个新同事，入职第一天就干了一件让我有点”破防”的事。 当时有个新服务要上线，我正准备打开模板复制粘贴改一改，他直接丢了个 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 背后的东西。 作者丨筆星 来源丨网址： dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn  [跳转微信打开](https://wechat2rss.bestblogs.dev/link-proxy/?k=90cfd11f&r=1&u=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzkzMjYzNjkzNw%3D%3D%26mid%3D2247637970%26idx%3D1%26sn%3D4bdf047e17f50cd6349d7fe643b383c0)