. 背景
        在一个单 Master 节点的 Kubernetes 集群基础上，计划添加一个新的 Worker 节点（名为 database）以进行扩容。
. 初始问题：节点加入失败
.问题1
       在 database 节点上执行 kubeadm join 命令后，节点能够短暂连接到集群，但随后 kubelet 报告 TLS 证书握手错误，并最终变为 NotReady 状态。

2.2 分析与解决

通过分析 journalctl -u kubelet -f 输出的日志，发现 kubelet 在尝试与 containerd 通信时失败（connection refused），并且在后续步骤中请求证书时被拒绝（Unauthorized）。

这通常是由于 CNI（容器网络接口）插件未能正确启动，导致 Pod 网络不可用，进而影响了 kubelet 与 API Server 的通信。

经过排查后原因是swap没有被禁用，虽然之前的 kubeadm join 预检提到了 swap 警告，但 kubelet 实际启动时却将其视为致命错误，直接导致其退出。

3. 问题2：Flannel Pod 拉取镜像超时

3.1 现象

在 Master 节点上检查 Flannel 相关 Pod 的状态：

3.2 问题分析

错误明确指出 kubelet 尝试拉取 registry.k8s.io/pause:3.6 镜像时超时。在中国大陆，访问 registry.k8s.io 域名通常需要翻墙或使用代理，这是导致超时的根本原因。

4. 解决方案：更换镜像源并配置

 修改containerd配置文件中的镜像源，后重启containerd，在 Master 节点上，删除旧的 Pod，触发重新创建：

kubectl delete pod kube-flannel-ds-7fbxv -n kube-flannel

然后查看节点状态依然在拉去旧的镜像源

kubectl describe pod kube-flannel-ds-tzsbx -n kube-flannel

继续排查后发现是config.toml中有默认配置，明确指定了 containerd 使用 registry.k8s.io/pause:3.6 作为 Pod Sandbox 的基础镜像。这个配置比 kubelet 命令行参数 --pod-infra-container-image 的优先级更高，或者直接由 containerd 层面处理，导致 kubelet 在尝试创建沙箱时总是去找 registry.k8s.io/pause:3.6

[root@database ~]# cat /etc/containerd/config.toml |grep pause
    pause_threshold = 0.02
    sandbox_image = "registry.k8s.io/pause:3.6"
You have new mail in /var/spool/mail/root

修改此项配置

sudo cp /etc/containerd/config.toml /etc/containerd/config.toml.bak
sudo vim /etc/containerd/config.toml
sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.9"  #修改配置项

重启worker节点的服务
sudo systemctl restart containerd
sudo systemctl restart kubelet

在Master 节点删除当前失败的 Flannel Pod
kubectl delete pod kube-flannel-ds-lpzzl -n kube-flannel

等待几秒钟后，查看节点状态，都显示正常，问题解决

[root@iZ2ze6sn544ngzrbbprfmcZ ~]# kubectl get pods -n kube-flannel
NAME                    READY   STATUS    RESTARTS   AGE
kube-flannel-ds-hghg6   1/1     Running   0          24h
kube-flannel-ds-tzsbx   1/1     Running   0          37m