非常抱歉，今天下午16:30-17:30左右，我们用阿里云ECS自己搭建的 k8s 集群，由于2台高配的抢占式实例被同时释放，造成全站故障，由此给您带来很大的麻烦，请您谅解。
16:33 左右，接到阿里云的短信通知，k8s集群中两台32核64G的节点服务器（抢占式实例）被释放。
【阿里云】尊敬的用户，您好！您的抢占式实例: i-bp1habzb9w4vokdzwhwt(kube-temp10-32c64g) 因库存变化, 即将进入释放状态
【阿里云】尊敬的用户，您好！您的抢占式实例: i-bp1e81o773w3yewsjtzh(kube-temp11-32c64g) 因库存变化, 即将进入释放状态
2台高配节点被同时释放，我们知道坏事了，因为高配节点上部署了很多 pod，突然释放根本来不及重新调度部署。
收到这个短信通知，预示着这两台服务器将在5分钟内被释放。
我们一边赶紧 drain 即将被释放的节点以触发这个节点上的 pod 被调度部署到其他节点部署，一边赶紧加服务器。
shell
kubectl drain kube-temp10-32c64g --ignore-daemonsets --delete-emptydir-data 但是由于节点上部署的 pod 太多，根本来不及，当2台32核64G节点服务器被释放并且新服务器已经加入集群后，依然有大量 pod 没有成功部署到新的节点。
于是我们赶紧去恢复这些没能成功部署的 pod，在处理中我们犯了一个错误，没有优先恢复 dapr 的 pod，很多应用 pod 无法启动是因为 dapr 不能正常工作造成 pod 中的 dapr sidecar 容器无法启动。
在发现这个错误后，我们才去优先恢复 dapr 的 pod。
dapr 的 pod 中，有些没能正常启动，是因为个别节点的镜像加速有问题，有些是因为 pod 处于 Terminating 状态，但没有被调度重新部署。
我们一边解决镜像加速问题，一边强制结束这些处于 Terminating 状态的 pod，等 dapr pod 都恢复正常后，其他应用 pod 随后也很快恢复了正常。
到这时，园子才从故障中恢复正常，而时间已经到了17:30左右，故障已经1小时左右。
非常抱歉，这次故障给大家带来了很大的麻烦，我们会调整 k8s 集群的节点部署。