记一次K8s系统生产事故（集群节点证书到期）

这个月9号，距离公司k8s生产集群部署刚好一整年，k8s 默认的证书到期失效，致使生产系统多个节点不可用。

排查问题，看到了报错 certificate has expired or is not yet valid。本来是一个非常简单的问题，但当时头脑严重迷糊，竟然重新生成证书，将NotReady的节点进行重新部署。结果反复试验，重启，导致整个集群所有节点都不可用。

这不是最遭的，更糟的是加班到深夜3点多，头脑迷糊的我将整个集群重新进行了部署，虽然还有仅剩的理智，想着只要不破坏 etcd的数据，集群是能重新恢复的。

事与愿违，集群起来了，但所有的 pod 无法启动，因为不知什么原因k8s的集群服务网段发生了变化，导致新的网段证书无法授权。修改网段，pod终于起来了。但令我万分沮丧的是，虽然 所有的 pvc 都没有变化，还是之前etcd数据中的pvc，但 。。。

数据库尽然是空的，是空的，是空的。。。

虽然系统正式启动也就一个多月的时间，但这两个月也有了很多生产数据，最关键的是，本来就对我有所不满的主管，终于有理由对我之前提的所有的技术方案说不了。

k8s，干掉，MongoDB，干掉，go语言，干掉，我就乖乖的弄前端那一亩三分地吧。所有的服务器，干掉Linux，上Windows，后端的服务器，竟然上了个win10，只是因为docker在win10下才有可视化的维护界面。

公司最大的业务系统MES，几乎都是我一个人写的，终于在10月底上线。老板很高兴，还请我们团队吃了饭。但这些天年底绩效评估，没有功劳，只有过错。绩效几乎不合格，来年的涨薪不要再想。终于我彻底地心灰意冷了。

现在还不知道为什么我的服务都起来了，用的也是之前etcd的数据，之前的pod和pvc配置都在，存储用的是 ceph，为什么数据就全丢了。还是怪自己学艺不精，遇事头脑不清晰，最重要的是，没有和主管处好关系。之前测试集群就已经挂掉，我猜想是同样的原因，但因为重启系统没有成功，无法再连接。之前的运维被挤走，新来的运维服务器这块还没有交接。因为和主管不和，我竟然就不想和他说话，让他在运维端把机器重启一下，失去了最开始发现和解决问题的最佳时机。在此吸取教训，以后不管怎么样，要和上级处好关系。

在此把解决方法贴说一下，希望遇到此问题的其他小伙伴，以后能够顺利解决。

其实很简单啊。

1. 删除过期的节点
   kubectl delete node [node-name]
2. 进入被删除的节点，重启 kubelet
   systemctl restart kubelet

过一段时间之后，查看节点
kubectl get nodes
会发现之前删除的节点重新出现，但节点 AGE 是最新的时间