k8s node NotReady

NotReady

如果 Kubernetes 节点状态为 NotReady，这意味着节点无法执行其预定功能，并且不可用于调度新的工作负载。节点可能变为 NotReady 的原因有多种，包括：

1. 网络问题：如果节点失去网络连接，它可能变为 NotReady。 ip -4 a
2. 资源耗尽：如果节点耗尽了 CPU 或内存等资源，它可能变为 NotReady。 free -h top
3. 节点故障：如果节点崩溃或经历硬件故障，它可能变为 NotReady。
4. Kubernetes 组件故障：如果节点上的关键 Kubernetes 组件（如 kubelet 或 kube-proxy）发生故障，节点可能变为 NotReady。

要排查 NotReady 节点，您可以：

1. 使用 kubectl 命令检查节点状态：kubectl get nodes
2. 使用 kubectl 命令检查节点日志：kubectl describe <node-name>，并将输出重定向到文件：kubectl describe node > node.log
3. 在节点上检查 kubelet 日志：journalctl -xeu kubelet，并将输出重定向到文件：journalctl -xeu kubelet > kubelet.log；使用 systemctl 查看 kubelet 状态：systemctl status kubelet
4. 检查节点上的系统日志：/var/log/messages
5. 使用 kubectl 命令检查 Kubernetes 事件日志：kubectl get events
6. 检查 docker 状态：systemctl status docker && systemctl status containerd，使用管道查看更多信息：| more
7. 在节点上检查 docker 日志：journalctl -xeu docker，并将输出重定向到文件：journalctl -xeu docker > docker.log
8. 检查磁盘空间：df -h | head

一旦确定了节点 NotReady 的根本原因，您可以采取适当的措施来解决问题。例如，如果节点由于资源耗尽而变为 NotReady，您可以为节点添加更多资源或调整运行在节点上的工作负载的资源限制。如果节点由于网络问题而变为 NotReady，您可以排查网络连接并修复任何问题。

/var/log/pods
/var/log/containers
crictl ps + crictl logs
docker ps + docker logs (in case when Docker is used)
kubelet logs: /var/log/syslog or journalctl

Case @1 may retry after sleeping

Issues

处理方案：

systemctl restart kubelet

Case @2 etcdserver: request timed out

controller.go:178] failed to update node lease, error: etcdserver: request timed out

request timed out

Case @ 3 container runtime status check may not have completed yet.

https://github.com/kubernetes/kubernetes/issues/101056

原因：
容器把docker搞崩了，然后节点就异常了！

处理方案：
for p in $(docker ps -q); do echo inspecting $p; docker inspect $p; echo complete; done;
ps -ef | grep 最后的id
kill 掉该进程

Case @4 invalid capacity 0 on image filesystem

Warning  InvalidDiskCapacity      101s                 kubelet          invalid capacity 0 on image filesystem

解决方案：systemctl restart containerd

Case @5 时间不一致

/var/log/messages systemd : time has been changed

原因：该节点时间和其他节点时间不一致导致。

Case @6 Error updating node status, will retry

解决方案：重启kubelet

kubelet 上报节点状态 源码分析：https://zhuanlan.zhihu.com/p/623840699

Case @7 dockerd 报错too many open files

https://blog.csdn.net/whatday/article/details/125481727

ls > /tmp/proc.log
cat /tmp/proc.log | wc -l

ll /proc/pid/fd/ 能看一些，详细的可以使用lsof 命令

Case@8 failed to update lease

E0522 00:38:34.444337 1421 controller.go:187] failed to update lease, error: Put “https://k8smaster.qfusion.irds:60443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/?timeout=10s”: net/http: request canceled (Client.Timeout exceeded while awaiting headers)

查看组件状态
ks get pod | grep etcd
ks get pod | grep apiserver

收集组件日志
ks logs --since “72h” etcd-qfusion01
ks logs --since “72h” kube-apiserver-qfusion01

Leases
Node heartbeats

Case@9 System OOM encountered, victim process: prometheus

原因：内存耗尽

排查：free -h

解决方案1：释放内存（或者重启宿主机）

# 释放pagecache
echo 1 > /proc/sys/vm/drop_caches
 
# 释放dentries和inodes
echo 2 > /proc/sys/vm/drop_caches
 
# 释放pagecache、dentries和inodes
echo 3 > /proc/sys/vm/drop_caches

扩展：驱逐

驱逐信号 描述
memory.available memory.available := node.status.capacity[memory] - node.stats.memory.workingSet

memory.available 的值来自 cgroupfs，而不是像 free -m 这样的工具。 这很重要，因为 free -m 在容器中不起作用，如果用户使用 节点可分配资源 这一功能特性，资源不足的判定是基于 cgroup 层次结构中的用户 Pod 所处的局部及 cgroup 根节点作出的。 这个脚本或者 cgroupv2 脚本 重现了 kubelet 为计算 memory.available 而执行的相同步骤。 kubelet 在其计算中排除了 inactive_file（非活动 LRU 列表上基于文件来虚拟的内存的字节数）， 因为它假定在压力下内存是可回收的。

例如，如果一个节点的总内存为 10GiB 并且你希望在可用内存低于 1GiB 时触发驱逐， 则可以将驱逐条件定义为 memory.available<10% 或 memory.available< 1G（你不能同时使用二者）。

• eviction-soft：一组驱逐条件，如 memory.available<1.5Gi， 如果驱逐条件持续时长超过指定的宽限期，可以触发 Pod 驱逐。
• eviction-soft-grace-period：一组驱逐宽限期， 如 memory.available=1m30s，定义软驱逐条件在触发 Pod 驱逐之前必须保持多长时间。