实验基线：Kubernetes v1.37.0、kubectl v1.37.0。先在测试环境执行，记录变更前状态与回滚点；生产集群不得直接照抄节点地址、网段、存储类或资源额度。
先理解 Kubernetes 在解决什么问题
Kubernetes 接收“期望状态”，持续把实际状态拉回期望状态。创建 Deployment 时，你提交的不是一串启动命令，而是一份可持久化的 API 对象；控制器观察对象，创建 ReplicaSet 与 Pod，调度器选择节点，kubelet 再让容器运行时落地。排障时应沿着这条控制链逐层定位，不能只盯着容器日志。
核心组件与数据流
| 组件 | 职责 | 首先检查 |
|---|---|---|
| kube-apiserver | 所有资源操作的统一入口 | 认证、授权、准入与 API 可用性 |
| etcd | 保存集群状态 | 成员健康、磁盘延迟、备份 |
| scheduler | 为未绑定 Pod 选择节点 | 事件、资源请求、亲和性与污点 |
| controller-manager | 运行内置控制循环 | 期望副本与实际副本差异 |
| kubelet | 落实 PodSpec 并汇报节点状态 | 容器运行时、镜像、探针、挂载 |
| kube-proxy/数据面 | 实现 Service 转发 | EndpointSlice、规则与 CNI |
用三个命令建立观察习惯
kubectl api-resources
kubectl get nodes -o wide
kubectl get pods -A -o wideapi-resources告诉你资源是否 namespaced、简称和 API 组；后两条建立“集群—节点—工作负载”的基线。再用 kubectl get --raw='/readyz?verbose' 检查 API Server 依赖项。若无管理员权限，应由平台团队执行该检查。
13 章学习顺序
- 完成本章架构地图与实验约定。
- 搭建隔离实验环境，再掌握 kubeadm 生产检查。
- 熟练 kubectl 与 kubeconfig。
- 依次学习 Pod、工作负载、配置、网络、存储。
- 进入调度与伸缩、安全、可观测性。
- 最后理解 API/控制器，并完成升级、备份与灾备演练。
每一章都以“创建—观察—制造可控故障—恢复—清理”为闭环。只有能解释事件和状态变化，才算掌握，不以背命令为目标。
动手实验：跟踪一次 Deployment 的控制链
步骤 1：创建隔离命名空间和工作负载
kubectl create namespace architecture-lab
kubectl create deployment hello -n architecture-lab --image=nginx:1.27-alpine --replicas=2
kubectl expose deployment hello -n architecture-lab --port=80预期会出现一个 Deployment、一个 ReplicaSet、两个 Pod、一个 Service 和对应 EndpointSlice。用 ownerReferences 观察资源归属：
kubectl get deploy,rs,pod,svc,endpointslice -n architecture-lab
kubectl get rs -n architecture-lab -o jsonpath='{range .items[*]}{.metadata.name}{" -> "}{.metadata.ownerReferences[0].kind}{"/"}{.metadata.ownerReferences[0].name}{"\n"}{end}'
kubectl get pod -n architecture-lab -o jsonpath='{range .items[*]}{.metadata.name}{" -> "}{.metadata.ownerReferences[0].kind}{"/"}{.metadata.ownerReferences[0].name}{"\n"}{end}'你应看到 Deployment 管理 ReplicaSet，ReplicaSet 管理 Pod。Service 不直接创建 Pod，它只根据 selector 选择 Ready 后端。
步骤 2：制造期望状态偏差
POD=$(kubectl get pod -n architecture-lab -l app=hello -o jsonpath='{.items[0].metadata.name}')
kubectl delete pod "$POD" -n architecture-lab
kubectl get pod -n architecture-lab -wReplicaSet 控制器会补建新 Pod，这就是调谐循环。注意新 Pod 名称与 UID 都会变化，因此应用不能依赖 Pod 身份；需要稳定身份时使用 StatefulSet。
步骤 3：观察调度与节点执行
kubectl get pod -n architecture-lab -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,PHASE:.status.phase,READY:.status.containerStatuses[0].ready
kubectl describe pod -n architecture-lab -l app=hello
kubectl get events -n architecture-lab --sort-by=.metadata.creationTimestamp调度器只负责写入 spec.nodeName；真正拉镜像、建容器、执行探针并汇报状态的是目标节点 kubelet。遇到 Pending 看调度事件，遇到 ContainerCreating 看 kubelet、CNI、CSI 和镜像拉取。
组件故障与影响范围
| 故障 | 已有业务 | 新变更 | 处置重点 |
|---|---|---|---|
| API Server 不可用 | 现有容器通常继续运行 | 查询、发布和调度受阻 | 负载均衡、证书、etcd 连通性 |
| scheduler 不可用 | 已绑定 Pod 不受影响 | 新 Pod 保持 Pending | 调度器日志和租约 |
| controller-manager 不可用 | 现有副本继续 | 副本补偿和节点驱逐停止 | 领导选举与工作队列 |
| etcd 高延迟 | 数据面可能继续 | 整个控制面变慢 | 磁盘 fsync、成员和空间 |
| kubelet 不可用 | 容器可能暂时继续 | 节点状态、探针和新 Pod 失控 | 运行时、磁盘、证书、cgroup |
本章验收题
- 画出从 kubectl 到容器运行的调用链，并指出哪些步骤会写 etcd。
- 删除 Pod 后解释是谁补建、调度器做了什么、kubelet做了什么。
- 执行
kubectl delete namespace architecture-lab，确认实验资源全部清理。
可复现记录模板
每次实验记录：集群版本、容器运行时、CNI/CSI 版本、命名空间、使用的 YAML Git 提交、开始与结束时间。命令输出至少保留对象状态、事件、关键日志和回滚结果。文中的占位符必须替换成自己的值，生产执行前应由第二人复核。
故障处理原则
- 先缩小影响面，不删除现场。
- 按对象状态—事件—日志—依赖顺序收集证据。
- 提出可证伪假设，一次只改变一个变量。
- 验证恢复后清理临时权限、调试 Pod、端口转发和测试数据。
完成检查
- 命令退出码为 0，目标对象状态与预期一致。
- 保存执行前后 YAML、事件与关键日志，确认没有把测试命名空间以外的对象改动。
- 故障演练完成后执行清理或回滚，再进行下一章。