节点不止一个时会有什么不同

一句话总结

节点变成多个之后，Kubernetes 的问题就从“Pod 起不来”变成了“哪个节点上的什么地方出错了”。答案通常不在 kubectl 里，而在那个节点内部。

为什么需要它

在只有一台机器的集群上练习时，节点就像背景一样。只有一个节点名称，调度、网络、维护都没有什么可操心的。但真实的集群有多个节点，CKA 实操考试也要求你通过 ssh 登录多个节点去工作。加入工作节点、清空一个节点、让 NotReady 的节点恢复，这些全都是在节点内部发生的事。

工作原理

节点的地址。kubelet 会把自己的地址注册为节点对象的 InternalIP，API 服务器、其他节点和 CNI 都通过这个地址找到这个节点。如果不单独指定地址，kubelet 会选择默认路由所经过的 NIC 的地址。在只有一块 NIC 的服务器上，这是对的，但在管理网络和集群网络分离的服务器上，就会注册错误的地址。因此，像 --node-ip（kubelet）、--apiserver-advertise-address（kubeadm）、--iface（Flannel）这样，同一个问题必须在每个组件里分别回答。本实验的 VM 中，第一块 NIC 的地址全都是 10.0.2.2，所以只要漏掉任何一处，症状就会立刻暴露出来。

加入。kubeadm join 用引导令牌向 API 服务器介绍自己，用 --discovery-token-ca-cert-hash 确认该 API 服务器是真的，然后获取 kubelet 要使用的证书，并写入 /etc/kubernetes/kubelet.conf。加入完成后，kubelet 会创建节点对象，CNI DaemonSet 要在该节点上启动 Pod，节点才会变为 Ready。

维护。kubectl cordon 只在节点上做禁止调度的标记。kubectl drain 在此之外还会驱逐 Pod——驱逐与删除不同，会遵守 PodDisruptionBudget。DaemonSet Pod 即使被驱逐，也会在同一个节点上重新生成，所以用 --ignore-daemonsets 跳过。维护结束后用 uncordon 恢复，但已经迁走的 Pod 不会回来。因为调度器只在放置新 Pod 时才做判断。

kubelet 是一项服务。控制平面组件以静态 Pod 运行，但启动这些静态 Pod 的 kubelet 本身由 systemd 管理。因此，kubelet 一旦终止，就没有主体来报告该节点的状态，节点会变为 NotReady，原因只留在 systemctl status kubelet 和 journalctl -u kubelet 里。这里 active（现在正在运行）和 enabled（开机时会启动）是不同的问题。kubeadm 在 join 时会直接启动 kubelet，但不会 enable，只会留下一条警告。

本实验环境与真实环境的相同与不同之处

先看相同之处。三台 VM 各自拥有内核、systemd 和 containerd，是真正的服务器，节点之间的流量走的是真实的网络。Flannel 的 VXLAN 通过 UDP 8472 发出，API 服务器通过 6443，kubelet 通过 10250 相互调用。所以只要有一处配置出错，症状就会与真实集群中的完全一样。

不同之处有两点。第一，eth1 不是真实的 NIC，而是仅连接本会话 VM 之间的虚拟 L2 网络。从外部看，VM 之间只有 UDP 4789 一个端口在传输，而且触及不到其他学员的 VM。第二，三台 VM 的第一块 NIC 都获得了同一个地址 10.0.2.2。这在真实服务器上很少见，但正因如此，“不明确指定地址时会选择什么”才会清晰地暴露出来，而不是模糊不清。依赖默认值的配置，在这个环境中必然失败。

在现场相遇的样子

本地部署的服务器经常分别设置管理网络、存储网络和服务网络的 NIC。如果在这样的服务器上用默认值安装 kubeadm，节点就会以管理网络的地址注册，Pod 之间的通信会经过存储网络的交换机，或者干脆不通。节点看起来全都是 Ready，所以要过很久才会发现。内核打补丁之后重启的节点回不来，也很常见。有人只是手动启动了服务而没有 enable，这件事在重启之前不会有任何症状。所以维护流程文档的最后一行，总是会写上“重启后确认是否恢复为 Ready”。维护不是在关闭节点的那一刻结束，而是在确认它恢复的那一刻结束，没有确认的重启，就等于预约了下一次故障。

下一项实验要做什么

通过 ssh 登录三个节点确认 NIC，用 eth1 的地址搭建控制平面，并告诉 Flannel 隧道要使用的 NIC。让两个工作节点加入，确认能否真正访问其他节点的 Pod，接着清空 node01 进行维护，并在节点内部让重启后迟迟不恢复的 node02 重新恢复。