部署与运维

不是 kubeadm 敲一遍就完事：inventory 怎么写、离线源怎么配、装完先验什么。

• →按规划写出 inventory.ini 与 group_vars，跑完一次完整部署
• →说清 kubespray 与 kubeadm 的关系，出错时知道该看哪一层
• →部署完成后按验收清单确认集群可用

同一份 playbook，配置写法决定了集群是能用两年还是三个月后推倒重来。

• →逐项解释 k8s-cluster.yml 里影响长期运维的关键变量
• →配置容器运行时、镜像仓库镜像源与证书有效期
• →用 addons.yml 选择随集群一起装的组件，并说明为什么不全开

手上快十倍靠的不是记命令，是把 kubectl 输出、kustomize 分层和 helm 发布用在对的地方。

• →用 -o jsonpath、--sort-by、events 等把 kubectl 用出调查工具的样子
• →用 kustomize 分层管理多环境清单，不再复制粘贴 YAML
• →判断什么该用 helm、什么该用原生清单，并处理 release 卡住的情况

cordon、drain、delete 三步之间的差别，决定了一次夜间维护是平稳还是事故。

• →安全地把一台节点摘出集群做维护，再原样放回去
• →处理 drain 卡住的三类常见原因（PDB、DaemonSet、本地存储）
• →给新节点扩容并确认它真正参与了调度

3 台变 5 台、换掉一台坏掉的管理节点、证书还有 30 天到期 —— 都是不能试错的操作。

• →在不中断服务的前提下增删一台控制面节点
• →同步处理 etcd 成员变更，避免 quorum 丢失
• →检查并轮转集群证书，处理已过期的场面

升级本身不难，难的是升到一半发现回不去。先把回滚路径想清楚再动手。

• →查清目标版本的 API 弃用项与组件版本偏差约束
• →按控制面 → 节点的顺序完成一次滚动升级
• →给每一步准备可执行的回滚动作，而不只是「再升回去」

集群其它东西都能重建，etcd 不能。这一节练的是「真的能恢复」，不是「有备份」。

• →做一次快照备份，并在测试环境完整恢复出集群
• →处理 etcd 空间告警：defrag、compact 与告警解除
• →判断 etcd 集群是否健康，读懂成员列表与 endpoint status

在模拟终端里接手一台刚刚失联的节点，从现象一路追到根因。

• →按固定顺序收敛 NotReady 的可能原因，而不是随机试
• →在节点侧读 kubelet 日志与 containerd 状态，判断断点在哪一层
• →给出处置动作，并说明什么情况下该直接摘掉这台节点