K8S集群节点NotReady?别急着重启,先检查swap分区这个隐藏开关(附永久关闭swap方法)
K8S集群节点NotReady别急着重启先检查swap分区这个隐藏开关凌晨三点手机突然响起刺耳的告警声——K8S集群中三个工作节点同时显示NotReady状态。作为运维工程师你的第一反应可能是立即重启节点或服务。但请先停下即将敲下reboot命令的手指因为90%的类似问题根源往往藏在一个容易被忽视的角落swap分区。1. 为什么swap会成为K8S的隐形杀手当节点突然变成NotReady状态时多数工程师会本能地检查网络连接、API服务或资源占用。但很少有人会第一时间想到问题的元凶可能是那个看似无害的swap分区。要理解这一点我们需要从K8S的内存管理机制说起。K8S设计之初就假设主机没有启用swap。这是因为性能不可预测性swap使用磁盘空间作为虚拟内存其速度比物理内存慢几个数量级。当容器进程被交换到磁盘时性能断崖式下跌会导致调度系统误判节点状态。资源统计失真kubelet计算Pod内存使用量时无法准确统计swap用量可能造成资源分配超卖。OOM Killer干扰Linux内核的OOM Killer会优先终止使用swap的进程而K8S需要精确控制哪些容器可以被终止。通过以下命令可以快速验证swap是否开启free -h | grep Swap如果看到类似下面的输出说明swap正在运作Swap: 2.0Gi 512Mi 1.5Gi2. 系统化排查NotReady节点的黄金流程遇到节点NotReady时建议按照以下优先级进行排查2.1 第一步基础服务检查在尝试任何复杂操作前先用这些命令快速定位问题层级# 检查kubelet服务状态 systemctl status kubelet -l # 查看容器运行时状态 crictl ps -a | grep -v Running # 检查关键组件日志 journalctl -u kubelet --since 1 hour ago | grep -i error2.2 第二步内存与swap专项检测当基础服务正常但节点仍不可用时需要深入内存子系统# 检查当前swap使用情况 cat /proc/swaps # 查看内存压力指标 cat /proc/pressure/memory关键指标解读指标正常范围危险阈值说明swapused%0%30%swap使用比例memory.pressure60%80%内存压力指数kubelet_memory_usage70%90%kubelet内存占用2.3 第三步网络连通性验证虽然本文聚焦swap问题但网络检查仍是必备步骤# 检查到API Server的连通性 nc -zv API_SERVER_IP 6443 # 验证kube-proxy是否正常 curl -k https://localhost:10249/healthz3. 彻底关闭swap的两种武器发现swap是罪魁祸首后你需要掌握临时禁用和永久关闭两种解决方案。3.1 临时禁用swap立即生效对于生产环境紧急恢复执行# 立即禁用所有swap设备 sudo swapoff -a # 验证是否生效 free -h | grep Swap这个命令的效果是即时的但重启后失效。适合用于快速验证问题是否确实由swap引起。3.2 永久关闭swap需重启为确保配置持久化需要修改以下文件注释掉/etc/fstab中所有swap相关行sudo sed -i /swap/s/^/#/ /etc/fstab调整内核参数适用于Ubuntu/Debianecho vm.swappiness0 | sudo tee -a /etc/sysctl.conf sudo sysctl -p对于使用cloud-init的云主机还需检查sudo cat /etc/cloud/cloud.cfg.d/* | grep swap不同Linux发行版的永久关闭方法对比发行版配置文件关键操作生效方式Ubuntu/etc/fstab注释swap行重启CentOS/etc/default/grub添加noswap参数更新grubRHEL/etc/sysconfig/kubelet设置--fail-swap-onfalse重启kubelet4. 生产环境最佳实践与陷阱规避即使关闭了swap在生产环境中仍需注意以下细节4.1 内存预留策略在/var/lib/kubelet/config.yaml中配置systemReserved: memory: 1Gi cpu: 500m4.2 cgroup v2的特殊处理如果使用cgroup v2默认于Ubuntu 22.04需要额外配置sudo mkdir /etc/systemd/system/kubelet.service.d cat EOF | sudo tee /etc/systemd/system/kubelet.service.d/90-swap.conf [Service] EnvironmentKUBELET_EXTRA_ARGS--fail-swap-onfalse EOF4.3 常见误操作黑名单✗ 直接删除swap文件而不禁用swap✗ 仅执行swapoff -a不做持久化配置✗ 在K8S配置中设置--fail-swap-onfalse绕过检查曾经有团队在关闭swap后遇到节点频繁重启最终发现是因为没有同步调整Pod的memory request/limit导致调度器过度分配内存。建议使用以下命令检查资源分配合理性kubectl get pods --all-namespaces -o json | jq .items[] | {name: .metadata.name, requests: .spec.containers[].resources.requests.memory, limits: .spec.containers[].resources.limits.memory}
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2503711.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!