核心原理

把 apiserver、etcd、scheduler、controller-manager、kubelet 串成一条链，之后每个故障都能定位到具体环节。

• →按顺序讲出 kubectl apply 之后发生的每一步，以及每步的负责组件
• →说清 apiserver 为什么是唯一入口，其它组件之间为什么不直接通信
• →知道每个控制面组件挂掉之后集群还能做什么、不能做什么

理解 reconcile，就理解了 K8s 的全部脾气：它不执行命令，它只是不停地把现状拉向期望。

• →解释期望态 / 实际态 / reconcile 三者的关系
• →读懂对象的 spec 与 status 分工，以及 ownerReferences 的级联删除
• →说清 finalizer 卡住时资源为什么删不掉，该怎么处理

选错工作负载类型，后面所有的滚动更新、扩缩容和存储绑定都会别扭。

• →给定一个业务形态，选出合适的工作负载类型并说明理由
• →讲清 StatefulSet 的稳定网络标识与 volumeClaimTemplates 意味着什么
• →配置滚动更新策略，控制发布过程中的可用副本数

requests 决定调度，limits 决定运行。这两个字段配错，集群要么调不满，要么一压就崩。

• →区分 requests 与 limits 的作用时机，说清三种 QoS 的驱逐顺序
• →用亲和性、污点容忍与拓扑分布约束控制 Pod 落点
• →读懂 Pending Pod 的 Events，判断是资源不足还是约束冲突

CrashLoopBackOff、Evicted、ContainerCreating —— 这三个状态背后是 kubelet 的三套完全不同的逻辑。

• →正确配置 startup / liveness / readiness 三种探针，避免自杀式重启
• →解释节点资源预留与驱逐阈值，算出一台节点真正可分配多少资源
• →按 Pod 状态选择正确的排查入口（describe、logs、events、节点侧）

「每个 Pod 一个可路由 IP」这条约定，是理解 Service、CNI 和所有网络故障的起点。

• →说出 K8s 网络模型的三条基本约定，以及 CNI 负责实现哪一部分
• →区分 ClusterIP、Headless、NodePort、LoadBalancer 的适用场景
• →追踪一次跨节点访问 Service 的完整数据路径

谁能动这个集群、能动到什么程度 —— 交付前必须回答清楚，交付后再补就是一场大手术。

• →区分认证与授权两个阶段，说清用户和 ServiceAccount 的不同来源
• →为一个团队设计最小权限的 Role / RoleBinding 组合
• →用 kubectl auth can-i 验证权限，排查 Forbidden 报错