kubectl get查不到资源主因是命名空间或上下文不匹配；apply与create混用会导致注解冲突；exec失败多因容器无shell或状态异常；YAML缩进/拼写错误常被静默忽略，需dry-run校验。
kubectl get 命令查不到资源？先确认命名空间和上下文
默认 kubectl get pod 只查当前上下文的 default 命名空间，90% 的“查不到”问题出在这儿。比如你部署在 prod 空间，不加 -n prod 就看不到。
- 用
kubectl config current-context看当前上下文是否连对集群 - 用
kubectl config view --minify --output 'jsonpath={..namespace}'查默认命名空间（常为空，即 fallback 到 default） - 查所有命名空间的 Pod：
kubectl get pod -A；查特定命名空间：kubectl get pod -n logging - 如果资源存在但状态是
Pending或ImagePullBackOff，get仍能列出，但需配合describe看细节
apply 和 create 混用导致资源冲突？认准幂等性边界
kubectl apply 是声明式、支持多次运行；kubectl create 是命令式、重复执行直接报错 Error from server (AlreadyExists)。但很多人没意识到：用 apply 修改资源后，再用 create 同名资源会失败，反之亦然——因为二者维护的注解字段（kubectl.kubernetes.io/last-applied-configuration）不兼容。
- 团队协作或 CI 流水线中，统一用
apply；临时调试可create，但别混进脚本 -
apply时若 YAML 中删了字段，K8s 默认不删除（称为“字段保留”），要强制清空得加--prune（需配合-l标签） - 想彻底重置？先
delete -f xxx.yaml，再apply -f xxx.yaml；别依赖replace，它不处理依赖顺序
kubectl exec 进不去容器？检查容器状态和入口点
kubectl exec -it my-pod -- /bin/sh 报错 command terminated with exit code 126 或直接卡住，大概率不是权限问题，而是容器里压根没 /bin/sh，或者容器已崩溃但 Pod 还在 Running（比如 initContainer 失败后主容器没启）。
- 先看真实状态：
kubectl get pod my-pod -o wide确认STATUS是Running且READY是1/1（不是0/1） - 查日志定位启动失败：
kubectl logs my-pod（加-c container-name如果有多个容器） - Alpine 镜像常用
/bin/ash，Distroless 镜像可能连 shell 都没有——这时只能用debug方式临时注入工具容器（kubectl debug） - Pod 设置了
securityContext.runAsNonRoot: true但镜像以 root 启动？exec 会拒绝，得看kubectl describe pod里的 Events
配置文件写错却没报错？YAML 缩进和字段拼写最坑人
K8s API Server 对 YAML 解析宽容度高，很多低级错误（比如 spec.contianers 拼错、缩进多一个空格）不会立即报错，而是静默忽略字段——结果就是 Pod 起不来，但 kubectl get 显示 Running，实际容器根本没拉起来。
- 用
kubectl apply --dry-run=client -o yaml -f xxx.yaml先本地解析，能捕获缩进、字段名错误（注意：不校验字段值合法性） - 关键字段大小写敏感：
imagePullPolicy写成imagepullpolicy就失效；env下必须是- name:不是name: - 嵌套缩进必须用空格，不能用 Tab；map 下的 list 项（如
ports:）前面必须有短横-，漏了就变成字符串而非数组 - 不确定字段是否有效？查官方 schema：
kubectl explain pod.spec.containers.imagePullPolicy
真正麻烦的从来不是命令记不住，而是错误被 YAML 静默吞掉，或者状态看起来正常实则容器根本没跑。多看 describe 的 Events 段，比反复改 YAML 猜更快。
