YAML 缩进和空格错误是 Kubernetes 配置中最常见的解析失败原因，必须严格遵循 2 空格缩进、冒号后加空格、字段对齐等规范；同时 imagePullPolicy、镜像引用、command/args 区分、探针类型、resources.requests 设置及 GPU 调度等均需按生产要求精准配置。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
yaml 缩进错一个空格，kubectl apply 就直接报 error parsing
DeepSeek 模型本身不写 YAML，但你在用它生成 K8s 配置时，最容易栽在缩进和冒号后空格上。Kubernetes 的 YAML 解析器极度严格：spec: 后面必须跟换行+缩进，image: 后必须有空格，env: 下的每个 - name: 必须对齐且顶格缩进 2 空格（不是 Tab）。常见错误现象是：kubectl apply -f xxx.yaml 报 error parsing xxx.yaml: error converting YAML to JSON: yaml: line X: did not find expected key。
- 用 VS Code 装
YAML插件（Red Hat 出品），开启editor.insertSpaces: true和editor.detectIndentation: false，强制统一为 2 空格 - 别信“复制粘贴自动生成的 YAML”，DeepSeek 输出里可能混入中文标点、全角空格或意外换行 —— 粘贴后先全选 →
Ctrl+Shift+P→ “Convert Indentation to Spaces” -
kind、apiVersion、metadata.name这三个字段缺一不可，漏掉任意一个都会触发no kind "xxx" is registered
imagePullPolicy: IfNotPresent 在生产环境几乎总是错的
DeepSeek 可能建议你设成 IfNotPresent 来“加快部署”，但这会掩盖镜像更新失效的问题。K8s 默认策略其实是 Always（当 :latest 或没标签时），而生产环境必须显式控制镜像版本与拉取行为。
- 永远用带摘要的镜像引用，比如
image: registry.example.com/model:1.2.0@sha256:abc123...，避免 tag 被覆盖导致行为漂移 - 如果确实要用 tag（如
:v2），则必须配imagePullPolicy: Always，否则节点缓存旧镜像，kubectl rollout restart也拉不到新版本 -
ImagePullBackOff错误常被误判为网络问题，其实八成是 secret 没绑对 —— 检查imagePullSecrets是否在spec下、名字是否和kubectl get secrets输出一致
容器启动后秒退？大概率是 command 和 args 搞反了
DeepSeek 生成的配置里经常把启动命令写成 command: ["python", "app.py"]，但实际容器镜像的 ENTRYPOINT 可能已是 ["python"]，这时该用 args 传参，否则会覆盖掉原入口点，导致进程找不到 app.py 或权限错误退出。
- 先确认基础镜像的
Dockerfile里是ENTRYPOINT还是CMD—— 前者固定入口，后者可被command覆盖；后者才是你该用args的场景 - 调试时临时加
command: ["/bin/sh", "-c"]+args: ["sleep 3600"]，进容器手动跑命令验证路径、权限、依赖 -
livenessProbe别用exec调curl，很多精简镜像根本没装curl—— 改用httpGet或检查本地 socket 文件更可靠
resources.requests 设太小，Pod 根本调度不出去
DeepSeek 可能按模型推理的理论内存算个数字填进去，但 K8s 调度器看的是 requests，不是 limits。哪怕你写了 limits: {memory: "16Gi"}，只要 requests.memory 是空或设成 "512Mi"，集群就认为这 Pod 只要 512Mi，可能被塞进只剩 1Gi 内存的节点，结果 OOM Kill。
-
requests必须 ≥ 容器稳定运行所需的最小资源，通常是观察kubectl top pods峰值后上浮 20% - GPU 场景下，
nvidia.com/gpu: 1必须出现在requests和limits里，只写在limits中会导致调度失败（报0/5 nodes are available） - 用了
HorizontalPodAutoscaler？那requests.cpu就是指标基准 —— 设太低会导致 HPA 过早扩容，设太高又压不住负载
DeepSeek 可以帮你补全字段、生成注释、甚至翻译 Helm values，但它不会知道你集群里节点的 GPU 型号、CNI 插件是否支持 hostNetwork、或者 Istio sidecar 注入后 initContainers 的执行顺序 —— 这些得靠你亲手试、亲手看 kubectl describe pod 里的 Events。
