非常抱歉，今天下午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 被排程部署到其他節點部署，一邊趕緊加伺服器。
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 叢集的節點部署。