当收到prometheus发送的告警邮件时，发现是k8s的两个节点down掉了，我的第一反应是服务器挂了？所以我第一时间就远程到这两个节点上，发现可以正常ssh连接到两台服务器，所以服务器本身是正常的。所以我继续查看k8s集群节点状态。

可以看到有两个工作节点状态为NotReady。我的第一想法是calico的问题。所以我进一步查看kube-system名称空间中Pod的状态。

发现calico-kube-controllers和calico-node的状态异常(图中为后截图，图中的pod状态不是当时的错误状态)，所以我继续看pod的状态。

发现calico-kube-controllers这个pod是因为调度到新的节点上了，这个节点上没有calico-kube-controllers镜像，需要重新拉取镜像，但由于镜像加速器和国外镜像被封的原因镜像拉取失败，所以pod创建失败，我从其他的节点导出镜像，重新导入到这个节点，pod成功启动。

接下来继续查看calico-node的详情查找问题。

发现pod调度到节点上后就没有下文了。所以我继续去查看节点的详情

发现“Conditions”中有kubelet stopped等字样，所以怀疑是节点上kubelet出问题了。使用systemctl status kubelet.service命令查看kubelet服务状态，发现是运行的，且没有什么特殊的异常错误。但是我还是重启了一下。发现pod和节点还是没有恢复。所以我继续查看目前两个异常pod的日志。通过命令kubectl logs calico-node-q8h9g -n kube-system查看pod的日志。

发现连接节点的10250端口失败，这个端口是kubele服务的监听端口，所以我就去问题节点上使用ss -tanlp |grep 10250查看发现kubelet服务的监听端口确实没有运行。但是在问题节点上查看 journalctl -fu kubelet日志。确实没有发现什么什么异常日志。

所以我就想看看kubelet到底为什么没有启动成功，所以我就直接执行kubelet的startup命令，直接在前端运行kubelet的启动命令，实时查看日志。

命令如下：

/usr/local/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/kubelet-bootstrap.kubeconfig --cert-dir=/etc/kubernetes/ssl --client-ca-file=/etc/kubernetes/ssl/ca.pem --kubeconfig=/etc/kubernetes/kubelet.kubeconfig --config=/etc/kubernetes/kubelet.json --container-runtime-endpoint=unix:///run/containerd/containerd.sock --v=2

发现是这个/etc/kubernetes/kubelet.kubeconfig这个文件过期了，所以查了下这个文件(部署一年了。忘了这个步骤。)，发现这个文件是自动生成的，接着我就把这个文件给删除了，重启kubelet服务，发现kubelet的10250端口还是没有正常运行，/etc/kubernetes/kubelet.kubeconfig这个文件也没有自动生成。这是什么情况，没办法，我只能去查看当时的部署文档了。发现有一个步骤是kubectl get csr,这个是查看 Kubernetes 集群中的 证书签名请求，这些请求通常由节点(如 Kubelet)或用户发起，目的是向集群的证书颁发机构(CA)申请新的客户端证书或更新过期证书。我就执行了这条命令。发现确实有两条问题节点的证书签名请求，所以我就通过命令kubectl certificate approve <csr-name>批准了两条证书签名请求。再到问题节点上查看kubelet的10250端口，ss -tanlp |grep 10250发现端口已经正常监听。

再次查看节点和pods状态，发现node已经是Ready状态了。Pod也是Running状态了。

这次的问题处理花了不少时间，主要是对组件的部署过程熟悉程度不够。