起因及分析

前几天发现某系统的微信推送功能突然没有了。由于都没有改过任何代码，所以估计问题出在K8S或者网络方面。
由于之前做过一次灾备演练，所以先从灾备演练的过程着手回溯。当时演练的时候，强行关闭了A节点，造成之前在A节点上的服务会自动漂移到B节点。
结果发现B节点是之前做过测试的节点，上面有很多之前旧版本的镜像。由于之前的镜像是用版本号区分的，现在已经改为按照日期+时间的方式打tag区分，造成漂移过去的服务自动加载了这些旧的镜像。
由此问题的原因找到！
涉及到公司信息，就不截图给大家了

解决

如何解决呢？
思路是这样的，找出错误加载的镜像，然后找到对应的服务，利用K8S的特点，将对应的容器实例设置为0，再删除错误的镜像，然后再将对应的容器实例设置为1，服务即会自动加载正确的镜像重启，恢复系统。

步骤

经过统计，共发现有20个旧的镜像。一个一个的排除，效率太低。

1. 为此，利用K8S的容错机制，即一旦镜像被加载，就无法删除，就执行了这20个镜像的删除操作，一下子过滤出来8个镜像。
2. 经过与正确的镜像的MD5值做对比，排除了2个正确的镜像，剩下6个镜像需要删除。
3. 在删除的过程，发现只要把B节点设置为脏节点，如下代码：

kubectl taint node node1 key1=value1:NoSchedule

则此节点上被中止的容器会被强制漂移到其他节点。另外还有两个命令，这里用不到:

kubectl taint node node1 key1=value1:NoExecute
kubectl taint node node1 key2=value2:PreferNoSchedule

4. 按照6个服务从次到主的顺序，依次逐个处理，由于K8S的特性，很快就恢复了正常的服务。

反思

经过这次故障，更加要注重镜像的管理和版本控制，在任何节点上，都不要保留旧的版本，以免产生上述问题。