AI 工具生成 Kubernetes YAML 实战：从 Prompt 到生产可用配置

写 Kubernetes YAML 是一件繁琐但要求严格的事情：字段名必须精确、缩进不能错、资源配额要合理、探针要正确配置……AI 工具可以大幅提速，但生成的 YAML 不能直接上线——需要懂得怎么提问、怎么审查。本文从实战角度讲解整个流程。

为什么 AI 生成 K8s YAML 效果好

Kubernetes YAML 有几个特点让 AI 特别擅长处理：

1. 高度结构化：YAML 有固定的 schema，AI 的生成内容格式正确率高
2. 模式固定：Deployment/Service/Ingress 等资源的“最佳实践”写法相对固定，AI 训练数据中有大量高质量示例
3. 枚举值有限：imagePullPolicy、restartPolicy 等字段只有固定几个值，不容易出错
4. 细节多：annotations、labels、affinity、PDB 等配置手写容易遗漏，AI 会自动补全

AI 的弱点：

• 不知道你的集群实际状态（Ingress class 名称、StorageClass 名称）
• 对最新 API 版本（如 autoscaling/v2 vs v2beta2）可能有混淆
• 不了解你的资源实际使用量，resources 配置需要根据监控数据调整

Prompt 工程：让 AI 给出生产级配置

基础模板 Prompt

为 [应用名称]([语言/框架]) 生成 Kubernetes 配置，要求：

应用信息：
- 镜像：[镜像地址:tag]
- 端口：[端口号]
- 健康检查路径：[路径]
- 预期 QPS：[数字]（用于 resources 估算）

需要生成的资源：
- Deployment（3副本，含 readiness/liveness probe，resource limits）
- Service（ClusterIP）
- Ingress（域名：[域名]，TLS：[是/否]，Ingress class：[nginx]）
- HPA（目标 CPU 70%，最少3副本最多10副本）
- PodDisruptionBudget（保证滚动更新时至少2个副本在线）
- ConfigMap（存储[配置内容]）

集群信息：
- Kubernetes 版本：1.30+
- 命名空间：[namespace]
- StorageClass：[存储类名]（如果需要持久化）

额外要求：
- 添加常用 labels（app、version、env）
- 非 root 用户运行
- 设置合理的 terminationGracePeriodSeconds

实际 Prompt 示例（Java Spring Boot 应用）

为 user-service (Java Spring Boot 3.2, Spring Boot Actuator) 生成 K8s 配置：

应用信息：
- 镜像：registry.cn-hangzhou.aliyuncs.com/mycompany/user-service:v2.1.0
- 端口：8080，管理端口 8081（Actuator）
- 健康检查：/actuator/health（readiness: /actuator/health/readiness, liveness: /actuator/health/liveness）
- 启动时间约 30-60 秒（JVM 预热）
- 生产 QPS 约 500，峰值 2000

需要生成：
- Deployment（5副本）
- Service（ClusterIP）
- Ingress（域名 user-api.company.com，HTTPS，Ingress class: nginx）
- HPA（CPU 60%目标，5-20副本）
- PDB（最少保留 4 副本在线）
- ConfigMap（应用配置）

集群：K8s 1.30，命名空间 production
要求：非 root，securityContext，合适的 startupProbe（JVM 预热）

AI 生成结果（重要片段）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
  namespace: production
  labels:
    app: user-service
    version: v2.1.0
    env: production
spec:
  replicas: 5
  selector:
    matchLabels:
      app: user-service
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2          # 滚动更新时最多多 2 个 Pod
      maxUnavailable: 0    # 滚动更新时不减少可用 Pod 数
  template:
    metadata:
      labels:
        app: user-service
        version: v2.1.0
    spec:
      terminationGracePeriodSeconds: 60   # Spring Boot 优雅关闭
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        fsGroup: 1000
      containers:
      - name: user-service
        image: registry.cn-hangzhou.aliyuncs.com/mycompany/user-service:v2.1.0
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 8080
        - name: management
          containerPort: 8081
        env:
        - name: JAVA_OPTS
          value: "-Xms512m -Xmx1536m -XX:+UseG1GC"
        - name: SPRING_PROFILES_ACTIVE
          value: "production"
        envFrom:
        - configMapRef:
            name: user-service-config
        resources:
          requests:
            cpu: "500m"
            memory: "1Gi"
          limits:
            cpu: "2000m"
            memory: "2Gi"

        # startupProbe：等待 JVM 预热（最多等 120 秒）
        startupProbe:
          httpGet:
            path: /actuator/health
            port: 8081
          initialDelaySeconds: 30
          periodSeconds: 10
          failureThreshold: 9    # 9 * 10s = 90s 最大等待

        # readinessProbe：检查应用是否准备好接收流量
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8081
          initialDelaySeconds: 0
          periodSeconds: 5
          failureThreshold: 3

        # livenessProbe：检查应用是否仍然存活
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8081
          initialDelaySeconds: 0
          periodSeconds: 10
          failureThreshold: 3

        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 5"]   # 等待 LB 摘除 Pod

---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: user-service-pdb
  namespace: production
spec:
  minAvailable: 4   # 滚动更新/节点维护时保证至少 4 个副本在线
  selector:
    matchLabels:
      app: user-service

---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: user-service
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: user-service
  minReplicas: 5
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # 5 分钟稳定窗口，避免频繁缩容
      policies:
      - type: Percent
        value: 25        # 每次最多缩容 25%
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
      - type: Percent
        value: 100       # 扩容更激进，快速响应流量
        periodSeconds: 30

AI 生成 YAML 的审查清单

在应用 AI 生成的 YAML 前，必须逐项检查：

# 创建文件 k8s-review-checklist.md（或作为团队标准流程）

## Deployment 审查清单
- [ ] image 地址和 tag 正确（不要用 :latest，用具体版本）
- [ ] resources.requests 和 limits 是否合理（基于实际监控数据）
- [ ] readinessProbe 路径是否存在且可访问
- [ ] livenessProbe 不要设置 initialDelaySeconds 为 0（容器刚起还没好）
- [ ] startupProbe 如果应用启动慢（JVM/大量初始化），必须配置
- [ ] terminationGracePeriodSeconds 是否足够（Web 服务器默认 30s 够，Spring Boot 需要 60s）
- [ ] securityContext.runAsNonRoot 是否已配置
- [ ] 环境变量中是否包含硬编码的密码（应该用 Secret）
- [ ] imagePullPolicy 生产环境应该是 IfNotPresent

## Service 审查清单
- [ ] selector 与 Deployment labels 一致
- [ ] port 和 targetPort 正确

## Ingress 审查清单
- [ ] ingressClassName 是否与集群实际 Ingress Class 一致（可能是 nginx 或其他）
- [ ] TLS Secret 是否已存在
- [ ] 域名是否正确

## HPA 审查清单
- [ ] API 版本：K8s 1.23+ 用 autoscaling/v2（不要用 v2beta2）
- [ ] minReplicas 不要小于 Deployment replicas（避免 HPA 立即缩容）
- [ ] scaleDown.stabilizationWindowSeconds 是否合理（避免频繁缩容）

## PDB 审查清单
- [ ] minAvailable 或 maxUnavailable 设置是否合理
- [ ] selector 是否与 Pod labels 一致

# 自动验证工具
# 1. kubeval：验证 YAML schema
pip install kubeval
kubeval deployment.yaml

# 2. kube-linter：检查最佳实践
docker run -v $(pwd):/dir stackrox/kube-linter lint /dir/deployment.yaml

# 3. trivy：扫描镜像安全和配置安全
trivy k8s --report summary deployment.yaml

# 4. 实际 dry-run（不创建资源，只验证）
kubectl apply --dry-run=server -f deployment.yaml

专业 K8s AI 工具

除了通用 AI 工具，有几款专为 K8s 设计的 AI 工具值得了解：

k8sgpt：AI 驱动的集群诊断

# 安装 k8sgpt
brew install k8sgpt  # macOS
# Linux：
curl -LO https://github.com/k8sgpt-ai/k8sgpt/releases/download/v0.3.x/k8sgpt_linux_amd64.tar.gz
tar -xzf k8sgpt_linux_amd64.tar.gz && sudo mv k8sgpt /usr/local/bin/

# 配置 AI 后端（支持 OpenAI、本地 Ollama 等）
k8sgpt auth add --backend openai --model gpt-4o
# 或使用本地 Ollama
k8sgpt auth add --backend localai --model qwen3:14b --baseurl http://localhost:11434/v1

# 分析集群中所有问题
k8sgpt analyze

# 输出示例：
# 0 default/pod/nginx-xxx (Kubernetes v1.30.2)
# Error: Pod is in a failed state
# Error Message: Back-off restarting failed container
# Solution: The container failed to start, likely due to an issue with the entrypoint or configuration.
#   Check the logs with: kubectl logs nginx-xxx
#   Possible causes:
#   1. Missing environment variable DATABASE_URL - check if Secret is mounted
#   2. Health check failing - verify /health endpoint returns 200 within 30s

# 分析特定命名空间
k8sgpt analyze --namespace production

# 过滤特定问题类型
k8sgpt analyze --filter Pod,Deployment

# 输出 JSON（用于告警系统集成）
k8sgpt analyze --output json

kubectl-ai：自然语言 kubectl

# 安装
brew install sozercan/tap/kubectl-ai  # macOS
# 其他平台参考 GitHub releases

# 配置（使用 OpenAI 或兼容 API）
export OPENAI_API_KEY=sk-...
export OPENAI_DEPLOYMENT_NAME=gpt-4o  # 或其他模型

# 自然语言描述，生成 kubectl 命令
kubectl ai "查看 production 命名空间中所有 CrashLoopBackOff 的 Pod"
# 生成：kubectl get pods -n production --field-selector=status.phase!=Running | grep CrashLoopBackOff

kubectl ai "找出使用内存最多的 5 个 Pod"
# 生成：kubectl top pods -A --sort-by=memory | head -6

kubectl ai "删除 staging 命名空间中超过 7 天的 Job"
# 生成：kubectl delete jobs -n staging $(kubectl get jobs -n staging -o jsonpath='{.items[?(@.status.completionTime)].metadata.name}' | tr ' ' '\n' | ...)

Helm AI Chart 生成

# 用 AI 快速生成 Helm Chart 骨架
# Cursor 中 Prompt：
"为 Python Flask 应用生成一个 Helm Chart，包含：
- Chart.yaml（apiVersion v2）
- values.yaml（含所有可配置项）
- templates/deployment.yaml
- templates/service.yaml
- templates/ingress.yaml
- templates/hpa.yaml
- templates/_helpers.tpl（命名模板）
遵循 Helm 最佳实践，支持通过 values.yaml 完全自定义"

# AI 生成完整 Helm Chart，通常 5-10 分钟完成
# 手动创建同样的 Chart 需要 1-2 小时

实用 Prompt 速查

# 常见 K8s 配置 AI 生成 Prompt

# 1. 带 GPU 的 Pod
"生成一个 K8s Pod 配置，需要 1 块 NVIDIA GPU（nvidia.com/gpu: 1），
 Pytorch 应用，镜像 pytorch/pytorch:2.4-cuda12.1-cudnn9，
 挂载 /data/models 目录（PVC 名称 models-pvc）"

# 2. StatefulSet（数据库）
"生成 MySQL 8.0 的 K8s StatefulSet 配置：
 3 副本主从架构，PVC 100GB（StorageClass: ceph-rbd），
 Service：一个 Headless Service，一个 ClusterIP，
 ConfigMap：包含 my.cnf 配置，Secret：MySQL root 密码"

# 3. CronJob
"生成 K8s CronJob，每天凌晨 2 点执行数据库备份：
 使用 mysql:8.0 镜像，环境变量从 Secret 读取 DB 连接信息，
 备份文件存到 PVC，CronJob 失败重试 3 次，历史保留 3 条"

# 4. NetworkPolicy
"为 production 命名空间生成 NetworkPolicy：
 只允许 frontend Pod 访问 backend Pod 的 8080 端口，
 backend Pod 只允许访问 postgres 的 5432 和 redis 的 6379，
 禁止所有 Pod 访问外网"

# 5. RBAC
"生成 K8s RBAC 配置：
 创建 ServiceAccount dev-deployer，
 只允许在 staging 命名空间 get/list/watch Deployments 和 Services，
 允许 update Deployments（用于 CI/CD 更新镜像），
 绑定到 dev-deployer ServiceAccount"

小结

AI 工具生成 K8s YAML 的效率提升是实质性的——从 1 小时手写减少到 5 分钟生成+审查——但前提是你要理解每个字段的含义，才能发现 AI 生成的错误。最佳实践是：用 AI 生成初稿，对照检查清单逐项审查，用 kubeval/kube-linter 自动验证，最后在测试环境 dry-run 确认。k8sgpt 这类专业工具更进一步，直接帮你分析集群问题、给出解决建议，是运维监控体系的有益补充。