Kubernetes开发者必懂的运行时契约与部署链路

1. 为什么“Kubernetes 开发者指南”不是给运维看的说明书

很多人点开标题叫《Kubernetes 开发者指南》的文章，第一反应是：“哦，又是教我怎么装 kubelet、配 kubeadm、拉 etcd 镜像的？”——结果翻两页发现全是kubeadm init --pod-network-cidr=10.244.0.0/16这类命令，心里一沉：这不还是运维手册吗？我一个写 Java 微服务、跑 CI/CD 流水线、天天改 Deployment YAML 的人，真需要亲手在 Ubuntu 22.04 上从零搭控制平面？

不是。这篇指南的起点，就卡在“开发者”三个字的定义上。它不面向要管理 500 节点集群的 SRE，也不面向刚考完 CKA 想刷题的备考者；它面向的是你——那个早上 9:15 收到 PR 合并通知、10:00 就得把新版本推上测试环境、下午 3 点被 QA 打电话问“为什么 /healthz 返回 503”的后端工程师；是你——那个在本地用 Docker Compose 跑通了三体服务，一上 Kubernetes 就发现 ConfigMap 不生效、Secret 挂载路径权限报错、Liveness Probe 频繁重启 Pod 的前端+Node.js 全栈；是你——那个在 GitLab CI 里写了 17 行kubectl set image脚本，却始终搞不清kubectl rollout status和kubectl wait --for=condition=available到底该用哪个才算真正“部署完成”的 DevOps 轻量使用者。

所以，“开发者”在这里有明确定义：你不需要知道 etcd 的 WAL 日志如何刷盘，但必须清楚 Pod 的 terminationGracePeriodSeconds 是怎么和 Spring Boot 的 shutdown hook 协同工作的；你不必手写 Admission Webhook 的证书签发流程，但得能看懂 MutatingWebhookConfiguration 里 rules 字段匹配的是哪个 API Group/Version/Resource；你不用调优 kube-scheduler 的 predicate/priority 插件链，但得明白为什么把 resources.requests.cpu 设成 100m 而 limits.cpu 设成 500m，会导致你的 Python Flask 应用在压测时被 OOMKilled，而日志里只显示 “Exit Code 137”。

这背后是一条被长期模糊的分界线：Kubernetes 的“使用层”和“管理层”彻底分离了。过去三年我带过 12 个业务团队落地 K8s，最常听到的抱怨不是“集群起不来”，而是“我改了 YAML，为啥服务没更新？”、“我加了 HPA，CPU 用了 80%，Pod 就是不扩？”、“我本地 curl 通，进容器里 netstat -tuln 却看不到端口监听”——这些问题，90% 出现在开发者对 Kubernetes 的“运行时契约”（Runtime Contract）缺乏系统性认知，而非不会敲命令。

所谓“运行时契约”，就是 Kubernetes 对你写的代码、配置、镜像、网络、存储所做出的隐含承诺，以及它要求你必须履行的对应义务。比如：

• 它承诺：只要你把容器进程的主 PID（PID 1）保持运行，Pod 就算“就绪”；
• 它要求：你必须让这个进程能响应 SIGTERM，并在收到信号后优雅退出（否则 terminationGracePeriodSeconds 一到，直接 SIGKILL）；
• 它承诺：只要你声明了 readinessProbe，它就会定期调用并根据返回状态决定是否将流量导入该 Pod；
• 它要求：你的 probe 必须足够轻量、超时时间必须短于 failureThreshold × periodSeconds，否则会触发误判驱逐。

这些不是“最佳实践”，是 Kubernetes 内核级的行为逻辑。忽略它们，就像用 MySQL 却不理解事务隔离级别，表面能跑，一到高并发就出幻读。本系列的第一篇，就从这里切进去——不装集群，不配 RBAC，不碰 Helm Chart，只聚焦一个核心问题：当你执行kubectl apply -f deployment.yaml的那一刻，Kubernetes 内部到底发生了什么？你的代码、配置、镜像，是如何被翻译成真实运行的 Pod 的？理清这条链路，你才能从“命令执行者”变成“行为预判者”。

提示：本文所有实操均基于标准上游 Kubernetes v1.28+（非 OpenShift、非 Rancher 封装版），环境为 Ubuntu 22.04 LTS + containerd 1.7.x + kubectl v1.28.x。所有命令、YAML 片段均可直接复现，无需额外安装插件或魔改组件。

2. 从kubectl apply到真实 Pod：一条被拆解的完整生命周期链路

很多开发者以为kubectl apply是个“原子操作”：输入 YAML，回车，服务就活了。其实它是一条横跨客户端、API Server、Scheduler、Kubelet 的多跳链路，每一跳都藏着影响你开发体验的关键决策点。我们以一个最简 Deployment 为例，逐层拆解：

# demo-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-demo spec: replicas: 2 selector: matchLabels: app: nginx-demo template: metadata: labels: app: nginx-demo spec: containers: - name: nginx image: nginx:1.25-alpine ports: - containerPort: 80 livenessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 10 periodSeconds: 30 readinessProbe: httpGet: path: /readyz port: 80 initialDelaySeconds: 5 periodSeconds: 10

2.1 客户端校验：kubectl在你按下回车前就做了什么？

kubectl apply并非直连 API Server。它首先在本地完成三重校验：

1. Schema 校验：kubectl内置了所有 Kubernetes 原生资源的 OpenAPI v3 Schema。它会检查apiVersion是否合法（apps/v1存在）、kind是否拼写正确（Deployment不是Depolyment）、字段类型是否匹配（replicas必须是整数，不能是"2"字符串）。如果你用kubectl apply -f加载一个字段名写错的 YAML，错误信息会明确告诉你error: error validating "demo.yaml": error validating data: ValidationError(Deployment.spec): unknown field "replcias" in io.k8s.api.apps.v1.DeploymentSpec—— 这个提示来自客户端，根本没发请求。

2. Dry-run 预演：kubectl apply --dry-run=client会模拟整个 apply 流程，生成最终提交给 API Server 的对象（含默认值注入），但不实际发送。执行它，你会看到：

   kubectl apply -f demo-deployment.yaml --dry-run=client -o yaml

   输出中spec.replicas会显式写出2（即使你没写，默认值也会补全），spec.template.spec.containers[0].imagePullPolicy会变成IfNotPresent（这是image字段的默认策略）。这个能力极其重要：它让你在真正改动集群前，先看清 Kubernetes 会“自动帮你填什么”。

3. Server-side Apply（SSA）元数据注入：从 v1.23 起，kubectl apply默认启用 SSA。它会在对象 metadata 中注入managedFields，记录每个字段由谁（manager: kubectl-client-side-apply）、何时（time）、通过什么字段集（fieldsType: FieldsV1）管理。这意味着：

   • 如果你用kubectl edit直接修改 Pod 的 label，managedFields会标记该 label 由kubectl-edit管理；
   • 下次kubectl apply时，它只更新自己管理的字段（如spec.replicas），不会覆盖kubectl edit修改的 label；
   • 这解决了传统kubectl replace或patch导致的“字段覆盖冲突”问题，是开发者协作安全的底层保障。

注意：managedFields是 SSA 的核心，但它也带来一个经典坑——当你用kubectl apply创建资源，再用kubectl patch修改同一字段，后续apply可能因字段所有权冲突失败。解决方案是：要么全程用apply，要么patch后手动清理managedFields（不推荐），或改用kubectl apply --server-side --force-conflicts（v1.27+）。

2.2 API Server 接收：对象准入与默认值注入的“第一次变形”

当kubectl通过 HTTPS POST 将对象发送到https://<apiserver>/apis/apps/v1/namespaces/default/deployments，API Server 的处理远不止“存数据库”那么简单。它启动一个严格的准入（Admission）流水线：

关键洞察：kubectl apply提交的 YAML，和最终存入 etcd 的对象，很可能不同。默认值注入发生在 Mutating 阶段，且不可逆。例如，你删掉 YAML 中的livenessProbe，API Server 不会给你补上（因为这不是默认值），但如果你删掉spec.template.spec.dnsPolicy，它大概率会被补成ClusterFirst。验证方法：kubectl get deployment nginx-demo -o yaml对比原始文件，重点看spec.template.spec下哪些字段被自动添加了。

2.3 Controller Manager 介入：Deployment 控制器的“二次编排”

API Server 只负责“存”和“转”，真正的“业务逻辑”由 Controller Manager 承担。当你创建 Deployment，deployment-controller立即开始工作：

1. 生成 ReplicaSet：Deployment 本身不直接管理 Pod，它通过创建一个 ReplicaSet（RS）来间接管理。控制器会生成一个 RS 名称（如nginx-demo-7c8b9d4f5），其spec.replicas= Deployment 的spec.replicas，spec.selector= Deployment 的spec.selector，spec.template= Deployment 的spec.template（但会加上controller-revision-hash: 7c8b9d4f5注解）。

2. 滚动更新策略实现：当你修改 Deployment 的spec.template.spec.containers[0].image，控制器不会直接更新现有 RS。它会：

   • 创建一个新 RS（如nginx-demo-5f6b8c7d9），replicas初始为 0；
   • 按spec.strategy.rollingUpdate.maxSurge（默认 25%）和maxUnavailable（默认 25%）计算扩缩比例；
   • 逐步将旧 RS 的replicas减 1，新 RS 的replicas加 1，直到旧 RS 为 0，新 RS 达到目标副本数；
   • 关键点：整个过程 Pod IP 是变化的！因为每个 RS 管理独立的 Pod 集合，而 Pod IP 由 CNI 分配，每次新建 Pod 都会获得新 IP。这就是为什么你不能在代码里硬编码其他服务的 Pod IP。

3. 状态同步与回滚：控制器持续对比status.replicas（实际运行的 Pod 数）、status.updatedReplicas（已更新到新版本的 Pod 数）、status.availableReplicas（就绪且可用的 Pod 数）。kubectl rollout status deployment/nginx-demo就是轮询这三个字段，直到availableReplicas == replicas。如果更新失败（如新镜像拉不到），控制器会停止滚动，并将status.conditions中的Progressing设为False，Reason为ProgressDeadlineExceeded。

实操技巧：想立刻看到 Deployment 的滚动过程？执行kubectl rollout status deployment/nginx-demo --watch，它会实时打印Waiting for deployment "nginx-demo" rollout to finish: 1 out of 2 new replicas have been updated...。比kubectl get pods -w更精准，因为它关注的是控制器状态，而非单纯 Pod 状态。

2.4 Scheduler 与 Kubelet：Pod 的“出生”与“落地”

当 ReplicaSet controller 创建了一个新 Pod 对象（如nginx-demo-7c8b9d4f5-abcde），它只是个“待产通知书”。Pod 真正变成运行中的容器，还需 Scheduler 和 Kubelet 协作：

• Scheduler 选节点：它监听未调度的 Pod（spec.nodeName为空），根据nodeSelector、affinity、tolerations、资源请求（requests.cpu/memory）等规则，选择一个满足条件的 Node。注意：requests是调度的唯一依据！limits不参与调度，只用于 cgroups 限流。如果你设requests.cpu=100m, limits.cpu=500m，Scheduler 只看 100m 是否有空闲，但运行时 CPU 使用超 500m 会被 throttled。

• Kubelet 拉起容器：被选中的 Node 上的 Kubelet 发现一个新 Pod 被分配给自己，开始执行：

  1. 拉取镜像（按imagePullPolicy）；
  2. 创建 sandbox 容器（pause 容器，提供 Pod 网络命名空间）；
  3. 启动业务容器（nginx），挂载 volumes、注入 secrets/configmaps；
  4. 执行探针：initialDelaySeconds后开始readinessProbe，成功后将 Pod 状态设为Ready，Service Endpoints 才会加入该 Pod IP；livenessProbe失败则重启容器。

这里有个致命细节：readinessProbe成功，是流量进入的前提；livenessProbe失败，是容器重启的触发器。二者目的完全不同，绝不能混用！我见过太多人把/healthz同时配给两者，结果健康检查慢一点（如 DB 连接超时），livenessProbe频繁重启，形成雪崩。

3. 开发者必知的五个“隐形契约”：那些不写在文档里却决定成败的细节

Kubernetes 文档浩如烟海，但真正影响日常开发效率的，往往是那些散落在各处、没有单独章节、却无处不在的“隐形契约”。它们不构成错误，但一旦违背，就会导致行为不可预测、调试成本飙升。以下是我在 12 个团队中反复验证的五大核心契约：

3.1 容器进程必须是 PID 1，且必须能响应 SIGTERM

这是 Kubernetes 生命周期管理的基石。当你docker run -d nginx，容器内实际运行的是nginx:master process，它是 PID 1。Kubernetes 要求你的容器入口点（entrypoint）必须是长期运行的前台进程，且能捕获SIGTERM信号。

反例与后果：

• 用sh -c 'java -jar app.jar'启动 Java 应用：sh是 PID 1，java是子进程。SIGTERM发给sh，sh默认忽略，java进程收不到，terminationGracePeriodSeconds一到，Kubelet 直接SIGKILL，Spring Boot 的@PreDestroy方法根本没机会执行，DB 连接池来不及关闭，连接泄漏。
• 用nohup java -jar app.jar &：nohup启动后台进程，&让 shell 退出，容器立即结束（因为 PID 1 的sh退出了），Pod 状态变为Completed。

正确做法：

• Java：用exec java -jar app.jar（exec替换 shell 进程，让 java 成为 PID 1）；或使用 jib 构建镜像，它默认生成正确的 entrypoint。
• Node.js：CMD ["node", "server.js"]，确保server.js中监听process.on('SIGTERM', ...)。
• Python：CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app:app"]，gunicorn 会处理信号。

验证方法：进容器ps aux，确认你的应用进程 PID 是 1；然后kill -TERM 1，观察应用是否优雅退出（日志应有 shutdown 信息），而非立即消失。

3.2 ReadinessProbe 是“准入证”，LivenessProbe 是“重启开关”，二者不可互换

很多开发者认为“反正都是健康检查，配一个就行”。这是最大误区。它们解决的是完全不同的问题：

典型错误配置：

# 错！用同一个 endpoint 处理两种需求 readinessProbe: httpGet: path: /healthz port: 8080 livenessProbe: httpGet: path: /healthz port: 8080

当/healthz因 DB 连接超时返回 500，readinessProbe失败，流量被切走；但livenessProbe也失败，容器被重启——重启后又连不上 DB，再次失败，形成“重启风暴”。

正确姿势：

• /readyz：检查应用自身状态 + 关键依赖（DB 连接池、Redis 连接）；超时时间可稍长（如timeoutSeconds: 10），failureThreshold: 3。
• /healthz：只检查应用进程是否存活（如return 200），不连外部服务；超时极短（timeoutSeconds: 1），periodSeconds: 5。
• Spring Boot Actuator 用户：/actuator/health/readiness和/actuator/health/liveness是官方分离的 endpoint，直接用。

3.3 ConfigMap/Secret 的热更新不是“实时生效”，而是“下次挂载时生效”

开发者常抱怨：“我kubectl edit cm my-config改了配置，应用里怎么还是老值？”——因为 ConfigMap/Secret 以文件形式挂载到容器时，是一次性拷贝。修改 ConfigMap 后，已运行的 Pod 中的文件内容不会自动更新。

真相：只有以下情况，挂载的文件才会刷新：

• Pod 重建（如 Deployment 滚动更新）；
• 手动删除 Pod（kubectl delete pod xxx），由控制器重建；
• 使用subPath挂载单个 key 时，即使 ConfigMap 更新，该文件也不会更新（这是设计缺陷，v1.28 仍未修复）。

解决方案：

• 推荐：用volumeMounts整个挂载 ConfigMap，不指定subPath。这样当 ConfigMap 更新，Kubelet 会检测到 hash 变化，在几秒内（默认 60s，可调--sync-frequency）更新挂载点下的所有文件。
• 进阶：应用内监听文件变更（如 Linux inotify），读取新内容；或使用 Reloader 这类 Operator，监听 ConfigMap 变更并自动 rollout Deployment。
• 避坑：绝对不要在envFrom中引用 ConfigMap，因为环境变量在容器启动时注入，永远不变。

实操验证：kubectl exec -it <pod> -- ls -l /etc/config/查看文件 inode；改 ConfigMap 后再执行，inode 号变了，说明文件已更新。

3.4 Service 的 ClusterIP 是“虚拟 IP”，它的负载均衡发生在 kube-proxy 层，而非应用层

很多开发者以为curl http://my-service:8080是直接连到某个 Pod。其实中间隔着一层透明代理。kube-proxy 有三种模式：userspace（已废弃）、iptables、ipvs。当前主流是 ipvs，它在 Node 上创建一个虚拟 IP（VIP），并将流量通过 IPVS 规则转发到后端 Pod 的 IP:Port。

关键影响：

• 连接复用失效：HTTP/1.1 Keep-Alive 连接，在经过 kube-proxy 时，可能被转发到不同 Pod。因为 IPVS 默认是 rr（轮询）或 lc（最少连接），不保证同一 TCP 连接始终打到同一 Pod。
• 客户端看到的源 IP 是 Node IP：除非 Service 设置externalTrafficPolicy: Local，否则客户端真实 IP 会被 SNAT 成 Node IP，后端应用request.remote_addr拿到的是 Node 地址，不是用户真实 IP。
• Headless Service 例外：clusterIP: None的 Service 不走 kube-proxy，DNS 直接解析为 Pod IP 列表，客户端可自行做负载均衡（如 gRPC 的 round_robin 策略）。

调试技巧：

• 查看 kube-proxy 规则：ipvsadm -ln | grep <service-cluster-ip>，能看到后端 Pod IP 列表；
• 测试连接复用：用curl -H "Connection: keep-alive" http://my-service:8080多次，kubectl logs <pod>看日志，如果请求分散在多个 Pod，说明复用被打破了。

3.5 Pod 的 DNS 解析依赖于dnsPolicy和search域，而非宿主机配置

在容器里ping mysql能通，ping mysql.default.svc.cluster.local也能通，但ping mysql.prod.svc.cluster.local却不通？这往往不是网络问题，而是 DNS 解析策略。

Kubernetes 为 Pod 设置了默认的dnsPolicy: ClusterFirst，意味着：

• 所有 DNS 查询先发给集群 DNS 服务（CoreDNS）；
• CoreDNS 的search域按顺序尝试：<namespace>.svc.cluster.local→svc.cluster.local→cluster.local；
• 所以ping mysql会被自动补全为mysql.default.svc.cluster.local（假设 Pod 在 default 命名空间）；
• ping mysql.prod会被补全为mysql.prod.default.svc.cluster.local（错误！），而非mysql.prod.svc.cluster.local。

解决方案：

• 跨命名空间访问，必须用 FQDN：mysql.prod.svc.cluster.local；
• 或在 Pod 的dnsConfig中自定义search域：

  dnsConfig: searches: - prod.svc.cluster.local - default.svc.cluster.local

验证 DNS：进容器cat /etc/resolv.conf，确认nameserver是 CoreDNS 的 ClusterIP（如10.96.0.10），search域是否符合预期。

4. 本地开发与集群调试：一套不依赖kubectl exec的高效工作流

作为开发者，你不可能每次改一行代码就kubectl apply一次。高效的本地-集群协同，需要一套绕过“构建-推送-部署”循环的调试方案。以下是我验证过的、真正提升日均迭代速度的组合拳：

4.1 Skaffold：让kubectl apply变成Ctrl+S的自动化引擎

Skaffold 是 Google 开源的 Kubernetes 开发工具，核心价值是将本地文件变更、镜像构建、部署、日志流聚合封装成一键流水线。它不是替代kubectl，而是让kubectl的调用变得“无感”。

典型skaffold.yaml配置：

apiVersion: skaffold/v4beta1 kind: Config metadata: name: nginx-demo build: artifacts: - image: localhost:5000/nginx-demo context: . docker: dockerfile: Dockerfile local: push: false # 本地开发用，不推镜像仓库 deploy: kubectl: manifests: - k8s/deployment.yaml - k8s/service.yaml portForward: - resourceType: service resourceName: nginx-demo port: 80 localPort: 8080

工作流：

1. skaffold dev启动；
2. Skaffold 监听Dockerfile和src/目录变更；
3. 你改代码，保存；
4. Skaffold 自动：
   • docker build -t localhost:5000/nginx-demo .；
   • kubectl set image deployment/nginx-demo nginx=localhost:5000/nginx-demo；
   • kubectl rollout status deployment/nginx-demo；
   • kubectl port-forward service/nginx-demo 8080:80（自动维护）；
5. 你浏览器打开http://localhost:8080，看到最新代码效果。

优势：

• 镜像不推远程仓库，节省时间；
• portForward持久化，不用每次kubectl port-forward；
• 日志自动聚合：skaffold dev输出中，所有 Pod 日志按 namespace/pod 名分组显示，比kubectl logs -f deployment/nginx-demo清晰十倍。

注意：local.push: false要求集群的 containerd 或 dockerd 能拉取localhost:5000的镜像。Ubuntu 22.04 上，需在 containerd config 中添加untrusted_workload_registry = ["localhost:5000"]，并重启 containerd。

4.2 Telepresence：把本地进程“注入”到集群网络

Skaffold 解决了“改代码-看效果”，但有些场景仍需真集群环境：比如你的服务要调用集群内的 Kafka、Elasticsearch，或者依赖 Istio 的 mTLS。此时localhost:5000的镜像无法访问集群内部服务。

Telepresence 是开源的“本地-集群网络桥接”工具。它的工作原理是：在集群中部署一个双向代理（traffic manager），将你的本地进程注册为集群中的一个“虚拟 Pod”，所有发往该 Pod 的流量（如 Service DNS 解析）都被重定向到你的本地进程。

实操步骤：

1. telepresence connect：建立本地到集群的 VPN 连接；
2. telepresence intercept nginx-demo --port 8080：拦截nginx-demoService 的所有流量，转发到本地localhost:8080；
3. 本地启动你的开发服务器：npm run dev（监听 8080）；
4. 集群内其他服务（如curl http://nginx-demo:80）的请求，全部打到你本地进程；
5. 你本地进程调用http://elasticsearch:9200，DNS 解析为集群内 ES 的 ClusterIP，流量正常发出。

关键价值：

• 本地调试享受集群网络（Service、DNS、Ingress）；
• 无需构建镜像、无需部署 Pod；
• 支持多语言：Java、Python、Node.js、Go 均可；
• 可同时 intercept 多个服务，构建本地微服务联调环境。

避坑：Telepresence 会修改本地/etc/hosts和 DNS 配置，telepresence leave后务必检查是否恢复，避免影响其他网络工具。

4.3 kubectl debug：不侵入式诊断运行中 Pod 的终极手段

当线上 Pod 行为异常（CPU 飙高、内存泄漏、网络不通），kubectl exec -it <pod> -- sh是第一反应。但很多生产环境出于安全考虑，禁用了exec（securityContext.allowPrivilegeEscalation: false，或 PodSecurityPolicy 限制）。此时kubectl debug是救星。

kubectl debug的原理是：在目标 Node 上启动一个全新的、临时的、特权容器（ephemeral container），共享目标 Pod 的网络、IPC、PID 命名空间，从而获得对原 Pod 的完全可观测性。

典型用法：

# 为 nginx-demo-7c8b9d4f5-abcde 创建调试容器 kubectl debug -it nginx-demo-7c8b9d4f5-abcde --image=nicolaka/netshoot --target=nginx

• --image=nicolaka/netshoot：使用预装tcpdump、nslookup、strace、iftop的调试镜像；
• --target=nginx：指定调试容器共享 nginx 容器的命名空间（必须是 Pod 内容器名）；
• 进入后，ps aux看 nginx 进程，netstat -tuln看端口，tcpdump -i any port 80抓包，strace -p 1跟踪主进程系统调用。

优势：

• 无需修改原 Pod 配置，不重启；
• 不依赖exec权限，只要create ephemeralcontainersRBAC 权限即可；
• 调试容器退出后自动清理，不留痕迹。

权限配置：集群管理员需授予开发者kubectl create clusterrolebinding debug-role --clusterrole=system:debugger --user=<your-user>。

5. 从“能跑”到“稳跑”：开发者视角的可观测性基建清单

Kubernetes 的抽象带来了便利，也带来了黑盒。当服务不可用，你最先看什么？是kubectl get pods？还是kubectl describe pod？抑或直接去 Grafana 看指标？一个成熟的开发者，应该建立自己的“可观测性反射弧”——看到现象，立刻知道该查哪一层。

以下是我为业务团队梳理的、按排查优先级排序的“五层诊断清单”，每层对应一个命令或工具，10 秒内给出答案：

5.1 第一层：Pod 状态层 ——kubectl get pods -o wide

这是最快速的“生命体征扫描”。重点关注三列：

• STATUS：Running是常态；Pending表示调度失败（kubectl describe pod看 Events）；ContainerCreating表示镜像拉取或 volume 挂载慢；CrashLoopBackOff表示容器启动后立即退出（kubectl logs <pod> --previous看上一次日志）；
• READY：1/1表示 1 个容器全部就绪；0/1表示 readinessProbe 未通过；
• NODE：确认 Pod 被调度到哪个 Node，为下一层排查定位机器。

速查命令：

# 查看所有 Pod 状态，按状态分组统计 kubectl get pods --all-namespaces | awk '{print $3}' | sort | uniq -c | sort -nr # 查看特定 Pod 的详细状态和事件 kubectl get pod nginx-demo-7c8b9d4f5-abcde -o wide

5.2 第二层：事件层 ——kubectl describe pod和kubectl get events --sort-by=.lastTimestamp

kubectl describe是 Kubernetes 的“病历本”，它聚合了 Pod 的 Spec、Status、Events。其中Events部分（位于输出底部）是黄金信息源，记录了从调度、拉镜像、挂载 volume 到容器启动失败的完整时间线。

关键事件解读：

• FailedScheduling：调度失败，原因在Message字段，如0/3 nodes are available: 3 node(s) didn't match pod affinity/anti-affinity rules.；
• Failed：容器启动失败，Message显示Error: failed to start container "nginx": Error response from daemon: OCI runtime create failed: ...；
• BackOff：容器反复重启，Message显示Back-off restarting failed container，需结合kubectl logs --previous；
• Started/Created