ref="/tag/272/" style="color:#8B0506;font-weight:bold;">配置文件写错，Pod就是起不来
上线前信心满满，结果执行kubectl apply -f deploy.yaml后，Pod卡在ImagePullBackOff。翻来覆去检查镜像名拼写、仓库权限，最后发现是配置文件里容器端口写成了字符串：
ports:\n - containerPort: \"8080\"Kubernetes要的是整数，不是字符串。这种低级错误在手写的YAML里太常见了，尤其赶时间的时候。
缩进不对，整个结构就乱套
YAML对缩进极其敏感。比如把env下面的- name多空了两个空格：
env:\n - name: DB_HOST\n value: mysql\n - name: DB_PORT # 这里少缩进了\n value: \"3306\"kubectl apply时不会直接报错，但环境变量可能没生效，服务连不上数据库。这时候查日志看到连接localhost:3306，才会意识到配置根本没传进去。
字段名拼错，Kubernetes默默忽略
把resources写成resouces，或者livenessProbe少了个e，Kubernetes不会报错，而是当成自定义字段直接忽略。结果就是没有资源限制，Pod被OOM kill；或是健康检查没触发，问题实例一直挂着。
这类问题最坑，因为命令能执行成功，但行为不符合预期。建议配合kubectl describe pod <pod-name>看Events和实际加载的配置。
命名空间不一致，资源找不到
本地测试用default命名空间，部署到生产却忘了在配置里指定namespace：
apiVersion: v1\nkind: Pod\nmetadata:\n name: my-app\n namespace: prod # 忘加这行\n...然后执行kubectl get pods -n prod发现没有，一通排查才发现Pod跑到default去了。跨命名空间的服务调用自然失败，网络策略也对不上。
用错API版本，老集群不认
新写的配置用了apps/v1，但公司内网的老集群还是Kubernetes 1.8，只支持extensions/v1beta1。apply时报错：the server could not find the requested resource。
这时候别急着改集群，先确认API版本兼容性。可以用kubectl api-versions查当前支持的版本，再调整配置文件里的apiVersion字段。
ConfigMap挂载路径覆盖原有文件
想通过ConfigMap注入配置文件，结果把/etc/nginx/nginx.conf整个目录挂载上去，把原有的静态页面和日志配置全覆盖了。Pod起来后Nginx启动报错，提示找不到index.html。
正确的做法是指定subPath，只替换目标文件：
volumes:\n - name: config\n configMap:\n name: nginx-config\ncontainers:\n - volumeMounts:\n - name: config\n mountPath: /etc/nginx/nginx.conf\n subPath: nginx.conf不然一不留神就把整个目录清空了。
别跳过kubectl diff和dry-run
上线前用kubectl diff -f deploy.yaml看看实际会变哪些配置，再用kubectl apply --dry-run=client -f deploy.yaml验证语法。这两个命令能挡住八成低级错误。别嫌麻烦，省下的排错时间不止十倍。