1. 这不是命令手册而是一张 Kubernetes 环境里的“生存地图”你刚在某实验室的集群里拿到一个 kubeconfig 文件终端里敲下kubectl get nodes回车后光标闪了三秒——终于跳出一行No resources found。你心里一咯噔节点呢是不是配置错了还是集群根本没跑起来这种瞬间的茫然我经历过不下二十次。这不是你一个人的问题而是所有刚跨过 kubectl 门槛的人必经的“命令失重期”命令会敲但不知道它在问谁、谁在答、答错时该往哪看。这篇内容不叫《kubectl 命令速查表》也不叫《K8s 常用命令大全》。它是一份基于真实排障现场反向梳理出来的“命令语义地图”。它聚焦的不是“有哪些命令”而是“每个命令背后到底在和哪个系统组件对话”“返回结果里的每一列字段究竟代表什么状态含义”“为什么get pods显示 Running但服务就是不通”——这些在官方文档里被折叠进“参考”章节、却在实操中决定你能否在 5 分钟内定位到 Pod 挂在 InitContainer 的关键细节。核心关键词就三个kubectl、资源状态、上下文感知。它适合三类人刚通过某高校云原生课程实验考核、但连describe和logs该先看哪个都犹豫的 A 同学正在某公司内部平台部署微服务却被 CI 流水线卡在ImagePullBackOff半天找不到日志入口的某开发者还有带新人的某导师需要一份能直接投影到白板上、边画边讲“命令-组件-状态”映射关系的实操素材。它不教你怎么写 YAML但能让你在 YAML 出错时一眼看出kubectl apply -f报的错是校验失败、还是权限不足、还是命名空间不存在——这三者对应的修复路径完全不同。我试过把命令按字母排序整理成表格发给新人结果他们照着表格查rollout status却不知道 deployment 的 rollout 本质是 controller-manager 调谐的结果和 kubelet 没有直接关系也试过只讲原理不给命令结果大家对着架构图点头一打开终端又卡在get svc返回的 CLUSTER-IP 列看不懂是什么意思。后来我把整个过程拆成了四层命令触发了什么请求 → 请求发给了谁 → 返回的数据结构怎么解读 → 数据异常时该跳转到哪个子命令深挖。这篇内容就是按这四层逻辑展开的每一条命令都配了真实终端输出截图级的文字还原不含图片但描述精确到空格和颜色含义并标注了我在某跨平台系统上线前夜靠它快速揪出 etcd 存储压力导致 apiserver 响应延迟的真实案例。它不承诺让你背下所有参数但保证你下次看到Pending状态不会再第一反应去重启 kubelet。2. 命令设计背后的三层逻辑API 层、对象层、状态层2.1 所有命令最终都落在 RESTful API 路径上但你不需要手写 curlkubectl get pods看似简单但它背后是一整套经过精心设计的请求链路。很多人以为 kubectl 是个“本地工具”其实它更像一个智能代理它读取 kubeconfig 中的 server 地址、证书、token构造出符合 Kubernetes API 规范的 HTTP 请求再把 JSON 响应解析成人类可读的表格。这个过程可以拆解为三个不可跳过的环节第一环是API Group/Version/Resource 路径映射。当你输入kubectl get podskubectl 实际发出的请求是GET https://apiserver/api/v1/namespaces/default/pods。注意这里隐含了两个关键默认值api/v1是 core group 的稳定版本namespaces/default是默认命名空间。如果你执行kubectl get deployments.apps路径就变成GET https://apiserver/apis/apps/v1/namespaces/default/deployments——apps是 API Group 名v1是该 Group 下的版本。这个映射关系不是凭空来的它由kubectl api-resources命令明确列出里面每一行都对应一个可操作的资源类型及其所属 Group 和支持的版本。我建议新人第一次登录集群后先执行这条命令把输出保存为api-resources.txt后续遇到不认识的资源名比如validatingwebhookconfigurations直接grep查找比翻文档快十倍。第二环是客户端侧的对象抽象与序列化。kubectl 并不直接传输原始 JSON它在发送前会做两件事一是根据资源定义OpenAPI Schema校验字段合法性比如你写replicas: 3字符串kubectl 会在apply时直接报错invalid value 3因为 replicas 字段定义为 integer二是对敏感字段做脱敏处理比如kubectl get secret my-secret -o yaml输出的data字段是 base64 编码的但kubectl describe secret my-secret会自动解码并显示明文仅限于终端输出不存盘。这个设计既保证了 API 层的严格性又兼顾了调试时的便利性。我踩过的坑是曾经用echo {replicas:3} | kubectl patch ...直接传 JSON 字符串结果因为字符串类型不匹配被拒绝后来改成--typejson -p[{op: replace, path: /spec/replicas, value: 3}]才成功——这就是绕过了 kubectl 的类型校验直接和 API 交互风险极高除非你非常清楚自己在做什么。第三环是响应数据的语义化渲染。kubectl get默认输出表格但表格的列名和内容完全由kubectl内置的 printer 决定而非 API 返回的原始字段。比如STATUS列API 返回的是status.phasePodPhase但 kubectl 会根据 phase 值映射为Running、Pending、Succeeded等更易懂的状态AGE列则不是 API 字段而是 kubectl 根据metadata.creationTimestamp计算出的时间差。这意味着如果你用kubectl get pods -o json看原始数据会发现根本没有STATUS或AGE字段。这个设计的好处是降低认知负荷坏处是容易掩盖底层细节。我见过有人死磕kubectl get pods显示Running但业务端口不通最后发现status.phase确实是 Running但status.containerStatuses[0].ready是 false而这个字段根本不在默认表格里——必须用kubectl get pods -o wide或kubectl describe才能看到。所以永远记住默认表格是友好封装不是真相全貌。提示想快速查看某个资源的所有可用字段不要依赖记忆执行kubectl explain resource.field。例如kubectl explain pod.spec.containers.ports.protocol会告诉你 protocol 字段只接受TCP或UDP且默认是TCP。这个命令的输出结构和 OpenAPI 文档完全一致是比 Google 更精准的字段字典。2.2 资源对象不是静态快照而是动态状态机的当前切片Kubernetes 的核心哲学是“声明式 API”但新手常误以为kubectl get拿到的就是“最终状态”。实际上每一个资源对象都是一个状态机的当前快照其字段值反映了控制器Controller在某一时刻的调谐Reconciliation结果。理解这一点是读懂命令输出的关键。以 Deployment 为例它的状态字段分布在多个层级status.replicasDeployment 控制器当前期望维持的 Pod 副本数来自 spec.replicasstatus.updatedReplicas已更新到新镜像版本的 Pod 数status.availableReplicas处于 Ready 状态且满足可用性条件如 readinessProbe 通过的 Pod 数status.conditions一个数组记录了 Deployment 的关键状态变迁比如Progressing条件表示 rollout 是否在进行中Available条件表示是否达到最小可用副本数。这四个字段之间存在严格的数学关系availableReplicas ≤ updatedReplicas ≤ replicas。如果updatedReplicas replicas说明 rollout 还没完成如果availableReplicas updatedReplicas说明新 Pod 虽然启动了但还没通过就绪探针如果availableReplicas replicas且conditions[?(.typeAvailable)].status True才真正意味着服务已就绪。我曾在某图像处理 Demo 的灰度发布中看到kubectl get deploy显示1/1以为发布完成结果用户请求 50% 失败。describe deploy一看availableReplicas是 1但conditions里Available的lastTransitionTime是 2 小时以前而Progressing的status是Unknown——原来是因为 ConfigMap 更新触发了 rollout但新 Pod 因为挂载的 Secret 不存在而卡在 ContainerCreating控制器一直在重试availableReplicas却没变因为旧 Pod 还在提供服务。这个案例说明数字相等不等于状态健康必须结合 conditions 字段的时间戳和状态值综合判断。再看 Service 资源。kubectl get svc输出的CLUSTER-IP列常被误解为“服务的 IP 地址”。实际上CLUSTER-IP 是 kube-proxy 在节点上为该 Service 创建的虚拟 IPVIP它本身不处理流量只是 iptables 或 IPVS 规则的匹配目标。真正的流量转发路径是Pod 发起请求 → 查找 ClusterIP → 匹配 iptables 规则 → DNAT 到后端 Pod 的实际 IP 和端口。所以当kubectl get svc显示CLUSTER-IP正常但curl http://cluster-ip:port超时问题一定不在 Service 定义本身而在后端 Pod 是否真的 Ready、kube-proxy 规则是否同步、或网络插件如 Calico的策略是否放行。我习惯用kubectl get endpoints svc-name验证如果 endpoints 列为空说明 selector 没匹配到任何 Pod如果非空但 IP 列是none说明匹配到了 Pod但这些 Pod 的status.phase不是 Running 或status.containerStatuses[0].ready是 false。这个命令是 Service 排障的第一步比describe svc更直接。注意kubectl get endpoints的输出中ENDPOINTS列显示的是ip:port,ip:port这里的 port 是 Pod 容器的实际端口containerPort不是 Service 的 targetPort。targetPort 只是用于将 Service 端口映射到容器端口的桥梁它本身不出现在 endpoints 数据里。混淆这两者会导致你错误地认为 endpoints 指向了错误的端口。2.3 上下文Context不是可选项而是命令执行的“空气”kubectl的所有命令都运行在一个隐式的上下文中这个上下文由三要素构成Cluster集群地址、User认证凭据、Namespace作用域。它们共同决定了命令“向谁问、用谁的身份问、问哪个范围”。很多人get pods返回空第一反应是“没 Pod”其实是kubectl config current-context指向了错误的 namespace 或 cluster。kubectl config view会输出完整的配置结构其中contexts数组定义了所有可用上下文每个 context 关联一个cluster和一个user。current-context字段指定了当前激活的上下文。你可以用kubectl config use-context name切换。但更常用的是--namespace参数它临时覆盖当前 context 的 namespace。例如kubectl get pods --namespaceprod会查询 prod 命名空间无论当前 context 默认 namespace 是什么。这个参数极其重要因为很多生产事故源于在 default 命名空间执行了本该在 prod 执行的操作。Namespace 的作用不仅是隔离资源还影响 RBAC 权限。假设你有一个 RoleBinding把view权限绑定到某用户在dev命名空间那么该用户执行kubectl get pods -n dev能成功但kubectl get pods -n prod会报Forbidden错误。此时kubectl get pods无 -n会使用 context 中默认的 namespace如果默认是default而该用户在default没有权限就会直接失败。我建议在团队协作中强制要求所有kubectl命令显式指定-n哪怕是在 default 命名空间这样能避免因 context 切换导致的权限混乱。某公司曾发生过一次线上事故运维人员在切换 context 时误将prod的 context 设置为当前然后执行了一条delete all命令结果删掉了整个 prod 命名空间——如果当时命令里写了-n staging悲剧就能避免。另一个常被忽视的上下文是--context参数。它允许你在单条命令中指定 context而不改变全局设置。例如kubectl get nodes --contextkube-system-admin可以用管理员 context 查询节点即使你当前的 context 是普通开发者的。这在多集群管理中非常实用比如你同时维护测试集群和预发集群可以用不同 context 隔离操作避免use-context切换带来的误操作风险。3. 核心命令详解与实操场景还原3.1get不只是“获取”而是“状态快照的多维切片”kubectl get是最常用的命令但它的能力远超“列出资源”。通过不同的参数组合它可以生成针对特定排障场景的精准视图。基础语法与默认行为kubectl get resource [NAME] [flags]。resource可以是复数pods、单数pod、短名po、或带 Group 的全名deployments.apps。[NAME]为空时列出全部有值时只显示指定资源。默认输出是宽表wide包含 NAME、READY、STATUS、RESTARTS、AGE 等列。READY列的格式是X/YX 表示当前 Ready 的容器数Y 表示该 Pod 定义的总容器数。例如1/2表示两个容器中只有一个通过了 readinessProbe。关键参数与实战价值--show-labels在输出末尾添加 LABELS 列显示所有标签。这在按标签筛选 Pod 时至关重要。例如kubectl get pods --show-labels -l appnginx会列出所有带appnginx标签的 Pod并显示它们的完整标签集方便你确认是否有意外的envprod标签混入了测试环境。--field-selector用字段选择器过滤比 label selector 更底层。例如kubectl get pods --field-selector status.phaseRunning只列出 phase 为 Running 的 Pod这能帮你快速识别那些虽然被调度但卡在 InitContainer 的 Pod它们的 phase 是 Pending。另一个经典用法是--field-selector metadata.namespace!default排除 default 命名空间聚焦业务命名空间。-o wide扩展输出增加 NODE 和 IP 列。NODE 列告诉你 Pod 被调度到了哪个节点这是排查节点级问题如磁盘满、内核 panic的第一线索IP 列显示 Pod 的 IP可用于直接curl测试容器内网连通性绕过 Service 层。-o yaml/json输出原始结构化数据。这是自动化脚本的基础。例如kubectl get pod my-pod -o jsonpath{.status.podIP}可以提取 Pod IP 并赋值给 shell 变量用于后续的curl测试。jsonpath语法强大但需注意{.items[*].metadata.name}用于列表资源如get pods而{.metadata.name}用于单个资源如get pod my-pod。实操场景还原诊断“服务间调用超时”假设你负责的订单服务order-service调用用户服务user-service总是超时。第一步不是查代码而是用get快速扫描状态# 1. 确认 user-service 的 Pod 是否都在 Running 且 Ready kubectl get pods -n prod -l appuser-service --show-labels # 2. 检查它们是否都分配到了 IPIP 列非空 kubectl get pods -n prod -l appuser-service -o wide # 3. 查看 endpoints确认后端地址是否正确 kubectl get endpoints user-service -n prod # 4. 如果 endpoints 有 IP但 order-service 仍连不上检查 user-service 的 Service 定义 kubectl get svc user-service -n prod -o wide在这个流程中-o wide的 NODE 列可能暴露问题如果所有 user-service Pod 都集中在同一个节点而该节点 CPU 使用率 95%那超时原因就很清晰了。--show-labels可能发现一个 Pod 带有versionv2标签而其他是v1说明灰度发布配置有误v2 版本可能存在性能瓶颈。这些信息单靠get pods默认输出是看不到的。3.2describe从“发生了什么”到“为什么发生”的深度透镜如果说get是广角镜头describe就是显微镜。它不展示新数据而是把get获取到的资源对象连同其关联事件Events、状态详情、控制器信息一起组织成一个逻辑连贯的叙事。输出结构解析kubectl describe resource [NAME]的输出分为几个区块Name/Labels/Annotations资源元数据确认你查的是不是目标对象。Namespace/Labels/Annotations再次强调作用域和标识。Status核心状态摘要如 Pod 的 Phase、Conditions、Container Statuses。Events这是最关键的区块它按时间倒序列出与该资源相关的所有事件来源包括 scheduler调度器、kubelet节点代理、controller-manager控制器。每个事件包含 TypeNormal/Warning、Reason原因代码、Message详细描述、Last Timestamp最后发生时间、Count发生次数。Events 区块的破译指南Events 是排障的黄金线索但需要知道怎么看Type: Warning通常意味着问题Type: Normal是正常流程。但不要绝对化比如Scheduled事件是 Normal但它后面如果跟着FailedSchedulingWarning就说明调度失败。Reason是标准化的代码比Message更可靠。例如FailedSchedulingReason 总是伴随Message: 0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, 2 node(s) didnt match pod affinity rules.这句话很长但核心是taint和affinity两个词指向节点污点和 Pod 亲和性配置冲突。Count值很大如 100说明问题持续存在不是偶发。Last Timestamp很新如 10 秒前说明问题正在发生。实操场景还原解决 “Pod 卡在 ContainerCreating”这是最经典的卡点。kubectl get pods显示STATUS为ContainerCreatingAGE已有 5 分钟。执行kubectl describe pod my-podEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 5m default-scheduler Successfully assigned prod/my-pod to node-02 Warning FailedCreatePodSandBox 4m58s kubelet, node-02 Failed create pod sandbox: rpc error: code Unknown desc failed to set up sandbox container a1b2c3 network for pod my-pod: networkPlugin cni failed... Warning FailedCreatePodSandBox 4m55s kubelet, node-02 Failed create pod sandbox: rpc error: code Unknown desc failed to set up sandbox container d4e5f6 network for pod my-pod: networkPlugin cni failed...关键信息是FailedCreatePodSandBoxReason 和networkPlugin cni failedMessage。这明确指向 CNI 插件如 Calico、Flannel在 node-02 节点上工作异常。下一步不是查 Pod YAML而是登录 node-02执行systemctl status calico-node或kubectl get pods -n kube-system -l k8s-appcalico-node确认 CNI 组件状态。如果 CNI 正常再检查 node-02 的磁盘空间df -h因为 CNI 初始化失败常因/var/lib/calico目录满导致。这个诊断路径describe的 Events 区块直接给出了唯一正确的方向省去了 90% 的盲目排查。3.3logs与exec进入容器内部的“手术刀”logs和exec是调试应用层问题的终极武器但它们的使用有严格的前提Pod 必须处于 Running 状态且容器必须已启动status.containerStatuses[0].state.running.startedAt不为空。logs的进阶用法kubectl logs pod-name获取最近一次容器的日志。如果容器崩溃重启过这只能看到崩溃前的日志。kubectl logs pod-name --previous获取上一次崩溃容器的日志。这是定位 CrashLoopBackOff 的关键例如kubectl get pods显示RESTARTS为 5kubectl logs my-pod --previous可能输出panic: runtime error: invalid memory address直接暴露 Go 程序的空指针异常。kubectl logs -l label-selector按标签获取所有匹配 Pod 的日志。例如kubectl logs -l appapi-server --tail100获取所有 api-server Pod 的最后 100 行日志便于横向对比。kubectl logs pod-name -c container-name当 Pod 有多个容器时指定容器名。kubectl get pod my-pod -o jsonpath{.spec.containers[*].name}可以先列出所有容器名。exec的安全边界与技巧kubectl exec -it pod-name -- command允许你在容器内执行命令。-it是交互式终端--分隔 kubectl 参数和容器内命令。安全前提容器内必须有sh或bash。Alpine 镜像通常只有shCentOS 镜像有bash。不确定时先kubectl exec my-pod -- sh -c echo hello测试。调试技巧kubectl exec my-pod -- netstat -tuln查看容器内监听的端口kubectl exec my-pod -- df -h查看磁盘使用kubectl exec my-pod -- ps aux查看进程。这些命令能验证应用是否真的在运行、端口是否被正确监听、资源是否耗尽。文件操作kubectl cp pod-name:/path/to/file ./local-file可以复制文件到本地用于分析日志或配置。但注意如果容器是只读文件系统readOnlyRootFilesystem: truecp会失败。实操场景还原排查 “HTTP 503 Service Unavailable”前端调用 API 服务返回 503。kubectl get pods显示 Pod 是 Runningdescribe没有 Warning 事件。此时logs是第一道关# 1. 查看最近日志 kubectl logs api-pod-789abc -n prod # 2. 如果日志显示 server starting on port 8080但 503 仍在检查就绪探针 kubectl describe pod api-pod-789abc -n prod | grep -A 5 Readiness Probe # 3. 如果就绪探针配置为 GET /health手动测试 kubectl exec api-pod-789abc -n prod -- curl -v http://localhost:8080/health如果curl返回 503 或超时说明应用内部健康检查失败问题在应用代码或依赖服务如数据库连接池耗尽。如果curl返回 200但外部访问仍是 503则问题在 Service 或 Ingress 层。这个流程展示了logs和exec如何协同将问题域从 Kubernetes 层精准收缩到应用层。3.4rollout与scale面向发布的状态控制中枢rollout命令专为 Deployment、DaemonSet、StatefulSet 等控制器设计它不操作底层 Pod而是指挥控制器执行声明式变更。rollout status比get deploy更懂“进度”kubectl rollout status deploy/name会持续轮询 Deployment 的status.conditions直到Available条件为 True或超时失败。它输出的不是静态快照而是动态进度Waiting for deployment my-deploy rollout to finish: 1 out of 3 new replicas have been updated... Waiting for deployment my-deploy rollout to finish: 2 out of 3 new replicas have been updated... deployment my-deploy successfully rolled out这个输出比kubectl get deploy的1/3数字更直观因为它告诉你“正在更新”而不是“已更新 1 个”。如果卡在某一步rollout status会报错如error: deployment my-deploy exceeded its progress deadline这时你应该立刻kubectl describe deploy my-deploy查看Progressing条件的message字段它会明确指出是Failed to pull image还是Minimum number of pods not available。rollout history与rollout undo回滚的“后悔药”kubectl rollout history deploy/name列出所有历史 revision每个 revision 对应一次apply或set image操作。kubectl rollout undo deploy/name --to-revision2可以回滚到指定 revision。这个机制依赖于 Deployment 的revisionHistoryLimit字段默认 10它控制保留多少个旧 ReplicaSet。我建议在生产环境中将此值设为 20确保有足够回滚点。回滚不是简单的镜像切换而是将 Deployment 的spec.template恢复到旧 revision 的模板并让控制器重新调谐。因此undo后kubectl get rs会看到旧 ReplicaSet 的副本数上升新 ReplicaSet 的副本数下降。scale即时伸缩的“杠杆”kubectl scale deploy/name --replicas5直接修改 Deployment 的spec.replicas字段控制器会立即创建或删除 Pod 以满足新期望值。这比手动delete pod更安全因为控制器会确保优雅终止发送 SIGTERM等待 terminationGracePeriodSeconds。scale命令也支持--current-replicas参数用于条件伸缩“只有当当前副本数是 3 时才扩到 5”避免并发操作冲突。4. 常见问题与排查技巧实录4.1 “No resources found” 的七种可能与逐级排查法kubectl get resource返回No resources found是最高频的困惑。它不代表“没有”而是“没找到符合条件的”。以下是七种常见原因及排查顺序排查层级检查命令典型现象解决方案1. 命名空间错误kubectl config view --minifygrep namespaceget pods为空但get pods -n prod有结果2. 资源类型拼写错误kubectl api-resources | grep your-inputget pod报错the server doesnt have a resource type pod用复数pods或短名po或查api-resources确认正确名称3. 权限不足kubectl auth can-i list resource -n nsget pods -n prod返回Error from server (Forbidden)检查 RoleBinding确保用户对ns有list权限4. 标签选择器不匹配kubectl get pods -n ns --show-labelsget pods -l appmyapp为空但get pods --show-labels显示 Pod 有appMyApp大小写敏感检查标签键值是否大小写一致或用--field-selector metadata.labels.appmyapp5. 资源已被删除kubectl get events -n ns --sort-by.lastTimestamp | head -20Events 中有Deleted类型事件lastTimestamp很新从备份恢复或重新applyYAML6. API Group/Version 不匹配kubectl api-versions | grep groupget deployments有结果但get deployments.v1beta1报错用kubectl api-resources确认该 Group/Version 是否支持优先用稳定版如apps/v17. 集群连接异常kubectl get componentstatusesget nodes超时componentstatuses显示Unhealthy检查 kubeconfig 中 server 地址、证书有效期、网络连通性我的实操心得我建立了一个标准排查清单每次遇到No resources found就按这个顺序执行三条命令kubectl config current-context确认上下文、kubectl api-resources \| grep resource确认资源名、kubectl get resource -A \| head -5用-A查所有命名空间。这三步能在 30 秒内定位 80% 的问题。剩下 20% 的权限和连接问题auth can-i和get componentstatuses是最直接的验证工具。4.2ImagePullBackOff的深度诊断路径kubectl get pods显示STATUS为ImagePullBackOff这是镜像拉取失败的通用状态。但失败原因千差万别必须分层诊断。第一层确认镜像地址和标签kubectl describe pod name的 Events 中Message字段会给出具体错误。最常见的两种Failed to pull image nginx:latest: rpc error: code Unknown desc Error response from daemon: manifest for nginx:latest not found镜像标签不存在。解决方案docker pull nginx:latest在本地验证或改用存在的标签如nginx:1.21。Failed to pull image my-registry.example.com/app:v1.0: rpc error: code Unknown desc unauthorized: authentication required私有仓库认证失败。第二层私有仓库认证排查如果使用私有仓库必须确保 Pod 的spec.imagePullSecrets正确引用了 Secret。检查步骤kubectl get secrets -n ns \| grep regcred确认 Secret 存在kubectl get secret regcred -n ns -o yaml确认 Secret 类型是kubernetes.io/dockerconfigjson且.dockerconfigjson字段是 base64 编码的有效 JSONkubectl describe pod name \| grep -A 5 Image Pull Secrets确认 Pod 确实引用了该 Secret第三层网络与仓库可达性如果认证无误可能是网络问题。登录到 Pod 所在节点kubectl get pod name -o wide查 NODE执行# 模拟 kubelet 拉取镜像 sudo crictl pull my-registry.example.com/app:v1.0 # 如果失败检查节点 DNS 和路由 nslookup my-registry.example.com ping -c 3 my-registry.example.comcrictl是容器运行时CRI的命令行工具比docker更贴近 kubelet 的实际行为。如果crictl pull成功但 Pod 仍ImagePullBackOff问题可能在 kubelet 配置如--image-pull-progress-deadline过短。我的避坑技巧在 CI/CD 流水线中我强制要求所有kubectl apply前先执行kubectl get secret regcred -n $NAMESPACE并检查返回码。如果 Secret 不存在流水线直接失败避免部署到一半才发现镜像拉不到。另外我从不在生产环境使用:latest标签而是用 Git Commit SHA 作为镜像标签确保每次部署都是可追溯、可重现的。4.3CrashLoopBackOff的根因分析树CrashLoopBackOff表示容器启动后立即崩溃kubelet 不断尝试重启。这是一个症状背后有数十种可能。我将其归纳为一棵根因分析树按概率从高到低排查根节点应用自身问题70%kubectl logs pod-name --previous获取崩溃前日志90% 的问题在这里暴露。常见错误配置文件路径错误、数据库连接字符串为空、环境变量缺失。kubectl exec -it pod-name -- sh进入容器手动执行启动命令如./app观察实时输出。有时日志被缓冲exec能看到更及时的错误。第一分支资源限制20%kubectl describe pod name