2026 年了,还在手写 YAML?AI 辅助运维工具实测

「零壹运维 · 零到壹，永不宕」

当你第五次手写 resources.requests.memory: "256Mi" 的时候，有没有想过——这活儿为什么不能让 AI 来干？

一、先说说手写 YAML 有多痛

运维圈有个梗：K8s YAML 是一门信仰，缩进错一格，集群当场教你做人。

手写 YAML 的日常：

• ❌ 缩进写错，kubectl apply 直接报 bad indentation
• ❌ livenessProbe 和 readinessProbe 傻傻分不清，端口写错但不报错，流量直接黑洞
• ❌ HPA 里的 apiVersion 换 K8s 版本就得查一次
• ❌ PodDisruptionBudget、NetworkPolicy 这类”偶尔用一次”的资源，每次都要翻文档
• ❌ Helm values.yaml 写了 200 行，变量引用写错也不报错，等到 template 渲染才炸

2026 年，这些痛点终于有了真正好用的 AI 方案。今天实测 4 类工具，告诉你哪些真能用、哪些是噱头。

二、工具全景：4 类 AI 运维辅助

三、实测一：kubectl-ai——命令行里直接说人话

安装

# 安装 kubectl-ai 插件
kubectl krew install ai

# 或直接下载二进制
curl -Lo kubectl-ai https://github.com/sozercan/kubectl-ai/releases/latest/download/kubectl-ai_linux_amd64
chmod +x kubectl-ai && mv kubectl-ai /usr/local/bin/

配置 API Key

export OPENAI_API_KEY="sk-xxxx"
# 或配置兼容 OpenAI 格式的本地模型（Ollama/DeepSeek）
export OPENAI_ENDPOINT="http://localhost:11434/v1"
export OPENAI_DEPLOYMENT_NAME="deepseek-r1:7b"

实测效果

场景 1：生成一个 Deployment

kubectl ai "创建一个 nginx deployment，3 个副本，CPU limit 500m，内存 limit 512Mi，带 readiness 探针"

输出：

apiVersion:apps/v1
kind:Deployment
metadata:
name:nginx
spec:
replicas:3
selector:
matchLabels:
app:nginx
template:
metadata:
labels:
app:nginx
spec:
containers:
-name:nginx
image:nginx:1.25
resources:
requests:
cpu:"250m"
memory:"256Mi"
limits:
cpu:"500m"
memory:"512Mi"
readinessProbe:
httpGet:
path:/
port:80
initialDelaySeconds:5
periodSeconds:10

✅ 自动补全了 requests（AI 知道光有 limits 不规范）、selector.matchLabels、探针配置

场景 2：生成 HPA

kubectl ai "给 nginx deployment 创建 HPA，CPU 利用率超 70% 扩容，最少 2 个最多 10 个"

输出自动用 autoscaling/v2（不是老掉牙的 v1），并补全了 resource.target。

场景 3：生成 NetworkPolicy

kubectl ai "只允许 namespace=frontend 的 pod 访问 namespace=backend 的 8080 端口"

✅ 正确生成了 namespaceSelector + podSelector 组合规则，这个手写最容易出错

实测结论

四、实测二：K8sGPT——集群故障的”AI 医生”

K8sGPT 专门解决一个问题：你看到 Pod Pending/CrashLoopBackOff，不知道为什么。

安装

# Linux
curl -Lo k8sgpt https://github.com/k8sgpt-ai/k8sgpt/releases/latest/download/k8sgpt_linux_amd64
chmod +x k8sgpt && mv k8sgpt /usr/local/bin/

# macOS
brew install k8sgpt

# 配置 AI 后端
k8sgpt auth add --backend openai --model gpt-4o
# 或配置本地 Ollama
k8sgpt auth add --backend localai --model deepseek-r1:7b \
  --baseurl http://localhost:11434/v1

核心命令

# 扫描集群所有异常
k8sgpt analyze

# 分析并给出 AI 修复建议
k8sgpt analyze --explain

# 只分析特定 namespace
k8sgpt analyze --namespace production --explain

# 过滤特定资源类型
k8sgpt analyze --filter Pod --explain

# 输出 JSON 格式（接自动化流水线）
k8sgpt analyze --output json

实战诊断案例

案例 1：Pod OOMKilled 反复重启

$ k8sgpt analyze --explain
AI Analysis: Pod backend-7f6b9c4d-x2k9p is experiencing OOMKilled events.
  - Current memory limit: 256Mi
  - Peak usage observed: ~280Mi
  - Recommendation: Increase memory limit to 512Mi, or review memory leaks
in the application. Consider setting requests.memory >= 200Mi to
    avoid scheduling on under-resourced nodes.

案例 2：PVC Pending 排查

AI Analysis: PersistentVolumeClaim data-mysql-0 is stuck in Pending state.
  - StorageClass "fast-ssd" referenced but does not exist in cluster
  - Available StorageClasses: standard, gp2
  - Recommendation: Update PVC to use StorageClass "gp2" or create
    StorageClass "fast-ssd" with appropriate provisioner.

以前排这个要：kubectl describe pvc → 看 Events → 猜 StorageClass → 查 kubectl get sc，现在 AI 直接告诉你根因

MCP 集成（2026 新功能）

K8sGPT 现在提供 MCP Server，可以让支持 MCP 协议的 AI（如 Claude Desktop、Cursor）直接操作集群：

# 启动 K8sGPT MCP Server
k8sgpt serve --port 8080

# 在 Claude Desktop 的 mcp.json 中添加
{
"mcpServers": {
"k8sgpt": {
"command": "k8sgpt",
"args": ["serve", "--mcp"]
    }
  }
}

配置后，你可以直接在 Claude 对话框里说：**”帮我检查 production namespace 有没有异常 Pod”**——AI 直接操作集群返回分析结果。

五、实测三：GitHub Copilot / Cursor——IDE 内联 YAML 补全

如果你在 VS Code 或 Cursor 里写 K8s 配置，这是日常效率提升最大的方案。

效果展示

写到一半按 Tab，AI 直接补全：

# 你写了这些：
apiVersion:apps/v1
kind:Deployment
metadata:
name:redis
spec:
replicas:1
# 光标在这里，按 Tab...

# AI 补全结果（全部自动生成）：
selector:
matchLabels:
app:redis
template:
metadata:
labels:
app:redis
spec:
containers:
-name:redis
image:redis:7-alpine
ports:
-containerPort:6379
resources:
requests:
cpu:"100m"
memory:"128Mi"
limits:
cpu:"500m"
memory:"512Mi"
livenessProbe:
tcpSocket:
port:6379
initialDelaySeconds:15
periodSeconds:20

Cursor 的优势：Chat + 文件编辑

# 在 Cursor 中说：
"把这个 Deployment 加上 PodDisruptionBudget，保证滚动更新时最少 1 个可用"

Cursor 直接在当前文件追加 PDB 配置，并解释为什么这样写。

六、实测四：CAST AI——AI 自动做 Right-Sizing

手写 YAML 里最难的不是结构，而是资源配额填多少。

resources:
requests:
cpu:"???"# 填少了被 OOM，填多了浪费钱
memory:"???"
limits:
cpu:"???"
memory:"???"

CAST AI 的工作原理：

1. 观察 Pod 历史 CPU/内存使用量（默认 7 天）
2. 基于 P95 使用量 + 安全系数自动推荐
3. 可以开启自动应用（不用人工确认）

# 安装 CAST AI agent
helm repo add castai-helm https://castai.github.io/helm-charts
helm install castai-agent castai-helm/castai-agent \
  --namespace castai-agent --create-namespace \
  --set apiKey=<YOUR_API_KEY>

推荐建议示例：

📌 一个中等规模集群（50节点），Right-Sizing 后平均节省 30-50% 的云账单

七、4 类工具组合使用姿势

日常编写 YAML
     ↓
  Cursor / Copilot（IDE 内联补全，最低摩擦）
     ↓
应用上线后集群异常？
     ↓
  K8sGPT analyze --explain（AI 直接给修复建议）
     ↓
资源配额不知道填多少？
     ↓
  CAST AI / Goldilocks（历史数据推荐）
     ↓
临时生成一个不常用的资源（NetworkPolicy/PDB/RBAC）？
     ↓
  kubectl-ai（命令行自然语言生成）

八、踩坑提示：AI 生成 YAML 的 3 个坑

坑 1：API Version 可能过时

AI 有训练截止日期，可能生成 autoscaling/v1（已废弃）而不是 autoscaling/v2。

# 用这个验证 API Version 是否当前集群支持
kubectl api-versions | grep autoscaling
# 确认资源是否存在
kubectl explain hpa.spec.metrics

坑 2：生产环境不要盲目 apply

# 先 dry-run 验证语法和权限
kubectl apply -f generated.yaml --dry-run=server

# 用 diff 看变化
kubectl diff -f generated.yaml

坑 3：Helm Values 生成质量参差不齐

AI 对 Helm values.yaml 的理解依赖训练数据，冷门 Chart 可能生成错误的字段路径。

# 先查官方 values 结构
helm show values bitnami/kafka | less

# 用 helm template 验证渲染结果
helm template my-release bitnami/kafka -f ai-generated-values.yaml | less

九、工具选型速查

十、总结

2026 年，K8s 运维里 AI 能干的活：

不会被 AI 替代的：

• 架构设计（集群规划、存储选型、网络拓扑）
• 生产变更审批（AI 生成，人工 review + apply）
• 复杂故障根因分析（AI 能给方向，深挖还得人来）

工具链推荐组合（零成本版）：

Cursor（免费版）+ kubectl-ai（本地 Ollama）+ K8sGPT（本地 Ollama）+ Goldilocks

装完这一套，你的 K8s 运维效率大概提升 40-60%，YAML 手写比例降到 20% 以下。

剩下那 20%？高级 Helm Chart 模板化、多集群架构设计，AI 还暂时替代不了，那才是你的护城河。

「零壹运维 · 零到壹，永不宕」