使用k8s集群已经有将近半年的时间 了，这期间用过kubeadm、kubespray等工具，从安装体验上来讲，还是rancher最为方便快捷，
因此，经过一段时间的调研，最终确定使用rancher的rke来部署高可用k8s集群，3*controlplane+3*etcd+n*worker,部署起来
还是相当顺利的，但是中途也遇到几次问题，
集群中有worker节点发生宕机，无法ssh登录，因为用的是阿里云的ecs, 账号由运维掌控，出现这种故障完全没有头绪，只能硬着
头皮重启， 后又接连遇到这种未知原因宕机，因为看不到日志，完全束手无策，只能重启机器（重启得邮件申请走流程，那叫一个漫长）
今天又一次出现节点异常状况 ，我首先发现kubectl top node
10.1.25.207显示有问题，于是试图ssh登录这台机器查看情况，发现登录无效，同时也无法查看该节点上的pod日志，无法使用exec进入该节点的容器，但是通过kubectl还是可以看到该节点上的窗口信息
➜ ~ kubectl get po -owide --all-namespaces|grep '10.1.25.207'
cattle-system cattle-node-agent-5td8l 1/1 Running 0 9d 10.1.25.207 10.1.25.207 <none> <none>
cert-manager hissing-indri-webhook-ca-sync-4mwrw 0/1 Completed 0 14d 10.1.74.6 10.1.25.207 <none> <none>
default productpage-v1-74888c4bf5-lv9xx 2/2 Running 0 8d 10.1.74.196 10.1.25.207 <none> <none>
default reviews-v1-75b979578c-v585g 2/2 Running 0 8d
这很奇怪，无法知悉这台机器的真实运转状况，遂找到运维，运维通过阿里云终端控制台查到以下日志
SLUB: Unable to allocate memory on node -1
找到一个相关的issue
由此怀疑是内核版本引起，遂查看内核版本
# uname -r
3.10.0-957.21.3.el7.x86_64
还找到了这个内核问题的pr
果然版本很低，于是先将内核升级到最新稳定版本4.4.189-1.el7.elrepo.x86_64
将内核升级至最新长期支持的版本过程如下：
sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
sudo rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
sudo yum --enablerepo=elrepo-kernel install kernel-lt
查看系统启动grub2中配置的内核
sudo awk -F\' '$1=="menuentry " {print i++ " : " $2}' /etc/grub2.cfg
0 : CentOS Linux (4.4.189-1.el7.elrepo.x86_64) 7 (Core)
1 : CentOS Linux (3.10.0-957.12.1.el7.x86_64) 7 (Core)
2 : CentOS Linux (3.10.0-693.2.2.el7.x86_64) 7 (Core)
3 : CentOS Linux (3.10.0-693.el7.x86_64) 7 (Core)
4 : CentOS Linux (0-rescue-f0f31005fb5a436d88e3c6cbf54e25aa) 7 (Core)
选取要加载的内核(以上查询结果第一列序号)，此处先取0即代表CentOS Linux (4.4.189-1.el7.elrepo.x86_64) 7 (Core)
sudo grub2-set-default 0
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
重启使之生效
在查找问题的过程中，还发现PingCAP(我的偶像公司啊)一篇内核问题分析诊断修复 TiDB Operator 在 K8s 测试中遇到的 Linux 内核问题，由于各种限制与惰性，这个问题到现在也算是有了眉目，先观察几天看看，后面逐个升级worker节点内核。
Refer:
