k8s node 节点notereday , 节点日志一直报节点没有找到

当Kubernetes集群中的节点（node）状态显示为NotReady时，可能是由于各种原因导致的。其中一种可能的原因是节点无法被Kubernetes控制平面（control plane）找到。下面是一些可能的排查步骤：

思路

  1. 检查节点状态
    使用kubectl get nodes命令查看所有节点的状态。如果某个节点的状态为NotReady，则需要进一步检查该节点的详细状态。
  2. 检查节点上的kubelet进程
    在NotReady状态的节点上，检查kubelet进程是否正在运行。可以使用以下命令检查：
systemctl status kubelet

如果kubelet进程没有运行，则需要启动该进程。

  1. 检查节点证书

如果节点证书过期或被撤销，控制平面可能无法与该节点通信。可以使用以下命令检查节点证书：

openssl x509 -in /etc/kubernetes/pki/apiserver-kubelet-client.crt -text -noout

如果证书过期或被撤销，则需要重新颁发证书。

  1. 检查节点网络

如果节点无法访问控制平面，则可能是由于网络问题导致的。可以使用以下命令检查节点网络：

ping <apiserver-ip>

如果无法ping通apiserver，则需要检查网络配置和防火墙设置。

  1. 检查kubelet配置

如果kubelet的配置不正确，则可能导致节点无法被控制平面找到。可以使用以下命令检查kubelet的配置：

cat /etc/kubernetes/kubelet.conf
  1. 检查kube-proxy配置

如果kube-proxy的配置不正确，则可能导致节点无法被控制平面找到。可以使用以下命令检查kube-proxy的配置：

cat /var/lib/kube-proxy/config.conf

如果上述步骤都检查完毕，但是节点仍然无法被控制平面找到，则可以考虑重新启动kubelet和kube-proxy进程，并重新添加节点到Kubernetes集群中：

systemctl restart kubelet
systemctl restart kube-proxy
kubectl delete node <node-name>
kubectl uncordon <node-name>

其中​​<node-name>​​是节点的名称。如果节点的状态仍然显示为NotReady，则可能需要进行更深入的排查。

检查节点证书

因为如果节点证书过期或被撤销，控制平面可能无法与该节点通信，导致节点状态显示为NotReady。在检查节点证书之前，我们需要先确定节点证书的位置。在Kubernetes集群中，控制平面和节点之间进行通信时，使用TLS加密来保证通信的安全性。因此，每个节点都需要有一对TLS证书来进行身份验证和加密通信。具体而言，每个节点都需要以下两个证书：

  • 用于身份验证的客户端证书：apiserver-kubelet-client.crt
  • 用于加密通信的客户端私钥：apiserver-kubelet-client.key

这些证书和私钥通常存储在节点的​​/etc/kubernetes/pki​​目录下。因此，我们可以使用以下命令来检查节点证书的过期状态：

openssl x509 -in /etc/kubernetes/pki/apiserver-kubelet-client.crt -text -noout

上述命令可以将​​apiserver-kubelet-client.crt​​证书文件转换为可读的文本格式，并输出证书的详细信息，包括证书的过期时间。如果证书已过期，则需要重新颁发证书。重新颁发证书的具体步骤取决于你的证书颁发机构（CA）和证书管理工具。通常，可以使用以下步骤来重新颁发证书：

  1. 为该节点生成一个新的私钥和证书签名请求（CSR）。
  2. 将CSR发送到CA以获得新的证书。
  3. 将新证书和新私钥复制到节点上的​​/etc/kubernetes/pki​​目录下。
  4. 重新启动kubelet进程以使用新证书。

不建议将主节点的证书直接复制到问题节点上，因为证书是用于身份验证和加密通信的重要凭证，直接复制可能会导致安全问题。

如果问题节点的证书已过期或被撤销，建议按照上述步骤重新颁发证书。重新颁发证书的过程中，需要使用证书管理工具为该节点生成一对新的TLS证书和私钥，并将其复制到节点上的​​/etc/kubernetes/pki​​目录下。然后，需要重新启动kubelet进程以使用新证书。如果你的证书颁发机构提供了证书自动更新功能，也可以使用该功能自动更新节点证书。

另外，如果你使用的是自签名证书，可以通过以下步骤将主节点的证书复制到问题节点上：

  1. 在主节点上导出证书和私钥：
kubectl get secret -n kube-system <apiserver-kubelet-client-secret> -o jsonpath='{.data.ca\.crt}' | base64 --decode > ca.crt
kubectl get secret -n kube-system <apiserver-kubelet-client-secret> -o jsonpath='{.data.client\.crt}' | base64 --decode > client.crt
kubectl get secret -n kube-system <apiserver-kubelet-client-secret> -o jsonpath='{.data.client\.key}' | base64 --decode > client.key

其中​​<apiserver-kubelet-client-secret>​​是apiserver-kubelet-client证书的Secret名称。

  1. 将导出的证书和私钥复制到问题节点的/etc/kubernetes/pki目录下：
scp ca.crt client.crt client.key user@<problem-node-ip>:/etc/kubernetes/pki/

其中​​user​​是连接到问题节点的用户名，​​<problem-node-ip>​​是问题节点的IP地址。

  1. 重启kubelet进程：
systemctl restart kubelet

这将使kubelet使用新的证书和私钥进行身份验证和加密通信。

kubeadm部署的集群

对于使用kubeadm部署的集群，可以按照以下步骤处理该问题：

  1. 登录到主节点，并导出apiserver-kubelet-client证书的Secret：
kubectl get secret -n kube-system $(kubectl get sa -n kube-system kubelet -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.ca\.crt}' | base64 --decode > ca.crt
kubectl get secret -n kube-system $(kubectl get sa -n kube-system kubelet -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.client\.crt}' | base64 --decode > client.crt
kubectl get secret -n kube-system $(kubectl get sa -n kube-system kubelet -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.client\.key}' | base64 --decode > client.key
  1. 将导出的证书和私钥复制到问题节点的​​/etc/kubernetes/pki​​目录下：
scp ca.crt client.crt client.key user@<problem-node-ip>:/etc/kubernetes/pki/

其中​​user​​是连接到问题节点的用户名，``是问题节点的IP地址。

  1. 在问题节点上重启kubelet进程：
systemctl restart kubelet

这将使kubelet使用新的证书和私钥进行身份验证和加密通信。

  1. 检查kubelet进程状态：
systemctl status kubelet

确认kubelet进程已成功启动并运行正常。

注意：如果集群中有多个节点出现了类似的问题，需要在每个受影响的节点上重复上述步骤。