关于k8s日常问题处理（持续更新）

博客前面讲了k8s的安装，在安装之后就是投入实际的应用，在使用过程中难免会出现何种各样的问题，下面是我分享的个人遇见的问题以及处理方式
问题记录一：
在日常检查集群的时候发现很多pod处于Evicted状态，但是也能看到每一个Pod下面都会有很多个Evicted的pod,但是也会有一个running状态的pod,这个说明服务还是正常运行的，但是Evicted状态的pod还是需要处理的，因为这样会很占资源的。

处理方式

#执行该命令删除Evicted状态的Pod就可以了，这条命令中的Evicted可以替换（根据你想删除的相应的pod的状态），在命令的前面和最后-n的后面跟上你所需要删除的空间下的pod
kubectl get pods -n yingxiao | grep Evicted | awk '{print $1}' | xargs kubectl delete pod -n yingxiao

问题记录二：
在准备搭建新环境，对就环境一些项目迁移时发现其中一个节点无法加入集群，加入集群时失败，然后根据报错发现是docker的问题（k8s版本是1.20.0），然后随手输入了一下docker然后报错没有命令，瞬间明了，docker脚本从master传过来之后还没有执行（自己太马虎>_<），于是重置k8s，安装docker，重新加入成功。


问题记录三：
刚刚做了NFS然后验证的时候发现，报错网络不通，重启服务之后还是不通，于是检查了一下NFS服务，本机检查NFS没有问题，思索了一下，那肯定就是防火墙在搞鬼了，然后尝试关闭防火墙，果然防火墙没有关闭，然后再次验证，果然是防火墙的问题（论细节的重要性T灬T）




问题记录四：
系统在运行一段时间之后，在使用系统的过程中开始报错，内存溢出,然后开发如约而至，让检查服务器问题，于是开始 去排查问题，在kubesphere的页面看到，内存使用并不高，但是却报错，心里很纳闷，于是先重启服务，恢复系统使用，在接下来的时间里重复出现这个问题，但是每次报错时，使用的内存并不是很高，最高的时候67%,感觉事情不简单，于是迁移项目，把这个项目单独迁移到一个新集群看看效果，可是在迁移之后还是出现内存溢出的问题，于是确定这个和我们的集群没有什么关系，可能是服务的问题，但是一时间无法排查出具体是哪个服务，结果惊喜在后面，CPU把服务器吃爆了，这下彻底凉了，只有关闭该集群的节点，CPU一下就恢复正常。于是开始把该项目分成两个部分迁移到两个新集群，系统和基础服务分开部署，这部署之后CPU恢复正常了，但是还是会报错内存溢出的问题，但是只是基础服务没有出问题，于是问题定位再次缩小，那就是服务的代码有问题了，然后开始跟踪服务，功夫不负有心人，最终还是逮住了罪魁祸首。
从这次的问题涨了经验，以后开发部署的服务必须限制资源使用，否则可能会出现服务器崩溃的现象，到时候损失会更多。
问题记录五：
刚刚安装的集群，查看pod时，状态都是为running，但是数量为0
于是describe一下这个pod查看一下具体什么原因，可以到报错显示找不到BIRD，这是说找不到网卡，也就是你的虚拟机的ens*找不到，所以需要在calico.yaml文件里面添加，然后重新执行一下这个文件即可，


问题记录六：
趁机趁我不注意的时候，就开始报错了，执行命令6443端口被拒绝，查看kubelet的状态也是找不到自己

使用docker查看，发现etcd在一直重启，于是查看日志发现，证书失效了

找到问题，就好解决了，证书失效，重新生成就好了，然后启动之后注意删除以前的apiserver的pod，如果你的apiserver启动失败的话

###########证书已经过期更新证书

##修改系统时间到证书有效期时间内
date -s "2021-07-11 22:30:00"        ##根据情况自己设定时间
ntpdate ntp1.aliyun.com              ##证书重新生成回复之后注意恢复你修改的时间
##备份配置文件
kubeadm config view > /root/kubeadm.yaml

##生成新的证书文件
kubeadm alpha certs renew all

##将新生成的文件拷贝到 ${HOME}/.kube 目录下并重命名为 config
mv ~/.kube ~/.kube.bak
mkdir ~/.kube
cp /etc/kubernetes/admin.conf ~/.kube/config

##重启 apiserver、kube-controller、kube-scheduler、etcd 容器
docker ps | grep -v pause | grep -E "etcd|scheduler|controller|apiserver" | awk '{print $1}' | awk '{print "docker","restart",$1}' | bash

##重启kubelet
systemctl restart kubelet

#################证书未过期更新


##备份配置文件
kubeadm config view > /root/kubeadm.yaml

##生成新的证书文件
kubeadm alpha certs renew all

##将新生成的文件拷贝到 ${HOME}/.kube 目录下并重命名为 config
mv ~/.kube ~/.kube.bak
mkdir ~/.kube
cp /etc/kubernetes/admin.conf ~/.kube/config

##重启kubelet
systemctl restart kubelet

问题记录七：
问题现象：基于k8s我们使用了kubesphere，问题现象是kubepshere无法登录，F12打开请求正常，但是没有跳转。
问题分析：由于我们的k8s集群是高可用集群，所以再kubesphere-system下有三个ks-api的pod，而我们的三个ks-api的pod只有一个是正常状态，所以能访问到kubesphere的页面，由于ks-api请求是走的redis，看了redis三个都是处于不正常状态，于是查看redis的日志，午饭创建redis.cof文件，在部署kubesphere时需要设置一个默认存储，我们这里使用的是nfs，于是去检查nfs服务，登录nfs验证了服务正常，继续检查redis的挂载文件，redis.conf文件是存在的。根据redis-ha的logs显示是无法创建，于是手动创建测试文件，报错文件系统是只读，于是退出nfs目录，去跟根创建能正常创建，于是重启了nfs的服务器之后，恢复正常。
问题原因：是因为意外关闭了存储服务器（nfs所在的虚拟机的数据盘是选择的存储服务器），导致虚拟机为了保护数据触发了只读机制。