1. Kubernetes与Swap的恩怨情仇
作为容器编排领域的霸主，Kubernetes对系统资源管理有着近乎偏执的要求。其中最具争议性的就是它对swap内存的"零容忍"政策。当你在凌晨三点被报警叫醒，发现整个Kubernetes集群因为一次计划内重启而陷入瘫痪，而罪魁祸首竟是那个默默无闻的swap分区时，这种设计选择就显得尤为刺眼。
我清楚地记得第一次遭遇这个问题的场景：那是在一个内存配置为64GB的生产节点上，系统自动创建了一个小小的2GB swap分区。就是这个看似无害的配置，让kubelet在节点重启后陷入了崩溃循环。通过journalctl -u kubelet看到的错误信息直白得令人心痛："running with swap on is not supported, please disable swap!"
2. 问题诊断：从表象到根源
2.1 症状识别
当Kubernetes节点因为swap问题无法启动时，通常会表现出以下典型症状：
- kubectl get nodes显示节点状态为NotReady
- describe node输出中包含MemoryPressure和NodeStatusUnknown警告
- kubelet日志中明确出现swap相关的错误信息
- systemd不断尝试重启kubelet但总是失败
2.2 深入排查
完整的诊断流程应该包括以下步骤：
bash复制# 检查节点状态
kubectl get nodes -o wide
kubectl describe node <问题节点名称>
# 检查kubelet状态
systemctl status kubelet -l
# 查看详细日志
journalctl -u kubelet -f --no-tail
在我的案例中，日志明确显示："failed to run Kubelet: running with swap on is not supported"。这为我们指明了方向。
3. 应急处理：快速恢复服务
3.1 临时解决方案
最快速的恢复方法是临时关闭swap：
bash复制sudo swapoff -a
sudo systemctl restart kubelet
这个命令会立即停用所有swap设备，通常几分钟内就能看到pod开始重新调度。但要注意，这只是临时措施——系统重启后swap又会自动启用。
3.2 验证恢复
恢复后应该检查：
bash复制# 确认swap已关闭
free -h
swapon --show
# 检查节点状态
kubectl get nodes
# 检查pod恢复情况
kubectl get pods -n kube-system
kubectl get pods -A -o wide | grep <节点名称>
4. 永久解决方案：彻底禁用swap
4.1 现代Linux系统的处理方式
在采用systemd的现代Linux发行版上，禁用swap需要多步操作：
- 首先确认swap配置情况：
bash复制# 查看swap分区信息
sudo fdisk -l | grep swap
sudo blkid | grep swap
# 检查/etc/fstab中的swap配置
grep swap /etc/fstab
# 查看systemd管理的swap单元
systemctl --type=swap --all
- 永久禁用swap：
bash复制# 临时关闭
sudo swapoff -a
# 注释掉/etc/fstab中的swap行
sudo sed -i '/swap/s/^/#/' /etc/fstab
# 禁用systemd swap单元
sudo systemctl mask dev-sdX.swap # 替换为实际的swap单元名
# 验证
sudo swapon --show
4.2 不同发行版的注意事项
- Ubuntu/Debian：可能需要额外处理cloud-init的配置
- RHEL/CentOS：检查/etc/sysconfig/kubelet中的配置
- CoreOS/Flatcar：swap配置可能通过Ignition文件管理
5. 高级方案：配置Kubernetes容忍swap
如果你确实需要保留swap（比如内存有限的开发环境），可以配置kubelet参数：
5.1 修改kubelet配置
bash复制sudo mkdir -p /etc/systemd/system/kubelet.service.d
# 对于kubeadm部署的集群
sudo cat <<EOF | sudo tee /etc/systemd/system/kubelet.service.d/90-local.conf
[Service]
Environment="KUBELET_EXTRA_ARGS=--fail-swap-on=false"
EOF
# 重载配置
sudo systemctl daemon-reload
sudo systemctl restart kubelet
5.2 kubeadm集群的特殊处理
对于kubeadm初始化的集群，可以在init时添加参数：
bash复制sudo kubeadm init --ignore-preflight-errors=Swap
或者在join节点时：
bash复制sudo kubeadm join --ignore-preflight-errors=Swap <控制平面地址>
6. 生产环境的最佳实践
经过多次实战教训，我总结出以下经验：
- 内存规划：生产节点应配置充足物理内存，避免依赖swap
- 一致性检查：将swap检查纳入部署前检查清单
- 监控报警：对节点的swap使用情况进行监控
- 文档记录：明确记录每个节点的swap配置状态
一个实用的检查脚本：
bash复制#!/bin/bash
# 检查swap状态
check_swap() {
if swapon --show | grep -q .; then
echo "发现启用的swap设备："
swapon --show
return 1
fi
if grep -q "^[^#].*swap" /etc/fstab; then
echo "/etc/fstab中配置了swap："
grep swap /etc/fstab
return 1
fi
if systemctl --type=swap --all | grep -q "loaded active mounted"; then
echo "发现活动的systemd swap单元："
systemctl --type=swap --all
return 1
fi
echo "系统swap已正确禁用"
return 0
}
# 检查kubelet配置
check_kubelet() {
if ! grep -q "fail-swap-on=false" /etc/systemd/system/kubelet.service.d/*; then
echo "kubelet未配置容忍swap"
return 1
fi
echo "kubelet已配置容忍swap"
return 0
}
# 执行检查
check_swap
check_kubelet
7. 为什么Kubernetes讨厌swap？
这个设计选择背后有几个技术考量：
- 性能可预测性：swap会引入不可预测的延迟
- 调度准确性：kube-scheduler需要准确评估节点资源
- 内存压力处理：Kubernetes有自己的一套内存不足处理机制
- 稳定性保障：避免因swap抖动导致的性能波动
然而这个决定也一直存在争议，特别是在边缘计算和资源受限环境中。从Kubernetes 1.22开始，社区已经开始重新审视这个问题，未来可能会有更灵活的策略。
8. 故障复盘与经验总结
那次生产事故教会了我几个重要教训：
- 自动化部署中必须包含swap检查步骤
- 系统基线镜像应该默认禁用swap
- 监控系统需要覆盖swap使用情况
- 文档知识库中要记录这类"隐藏"的配置要求
最讽刺的是，那个引发问题的swap分区只有2GB大小，而节点有64GB物理内存，实际上几乎不会被用到。但正是这个"几乎不会用到的"配置，导致了整个节点的瘫痪。这提醒我们：在生产环境中，任何配置都不应该被忽视，特别是那些看似无害的默认设置。