k8s节点not ready 的一次修复经历
情况描述
重启了k8s的一个节点。重启后，使用kubectl get node -o wide查看节点状态，发现节点显示 not ready.
解决过程
- 之前经历过一次，是重启kubelet服务弄好的
在重启的服务器上执行
sudo systemctl restart docker
sudo systemctl restart kubelet
重新查看node状态，还是not ready
-
查看节点描述信息
-
查看重启的服务器上的kubelet 服务状态
sudo systemctl status kubelet
发现kubelet启动失败了
- 查看重启的服务器上的kubelet 日志
journalctl -f -u kubelet.service
看到日志报错信息里，提示和swap 有关系。我顿时想到，k8s搭建的时候，需要关闭swap，会不会是因为重启了服务器，swap服务又启动起来了，导致当前节点的kubelet服务启动不起来？
解决方法很简单，就是关闭该服务器的swap服务。
# 下面这个命令是临时关闭swap
sudo swapoff -a
- 然后重启kubelet服务
sudo systemctl restart kubelet
再查看node状态，发现转换为ready了。 参考资料
总结
主要是因为重启了服务器，之前关闭的swap服务，又启动起来了，导致重启服务器的kubelet服务启动不起来
扩展
部署Kubernetes(k8s)时，为什么要关闭swap、selinux、防火墙？
不止部署k8s，许多公司在装机过程就就直接关闭了swap、selinux和防火墙
selinux，这个是用来加强安全性的一个组件，但非常容易出错且难以定位，一般上来装完系统就先给禁用了
iptables防火墙，会对所有网络流量进行过滤、转发，如果是内网机器一般都会直接关闭，省的影响网络性能，但k8s不能直接关了，k8s是需要用防火墙做ip转发和修改的，当然也看使用的网络模式，如果采用的网络模式不需要防火墙也是可以直接关闭的
swap，这个当内存不足时，linux会自动使用swap，将部分内存数据存放到磁盘中，这个这样会使性能下降，为了性能考虑推荐关掉
SWAP就不太一样了，SWAP是让你在明确的OOM和没有报错但是莫名其妙服务就不能用了之间二选一，对于集群化的服务（比如etcd）来说是挂掉一个实例和整个集群都出毛病之间二选一，一般正常人都知道该选哪个
