非常非常抱歉，新年上班第一天， 在今天阿里雲上氣候突變情況下，由於我們開船技術差，在今天 10:15~12:00 左右的訪問高峰，我們竟然把船給開翻了，造成近2個小時整個博客站點無法訪問，由此給您帶來很大很大的麻煩，懇請您的諒解。
翻船經過如下。
翻船前的船只情況
博客站點正在使用的 k8s 集群一共用了 9 台 worker 節點服務器，在訪問低峰時用 5 台，另外 4 台處於關機狀態，在進入訪問高峰前啟動。所以我們用 cron 定時任務在工作日每天早上啟動 4 台服務器，每天晚上關閉 4 台服務器。為了節約成本，這 4 台服務器用的是阿里雲搶占式實例，由此帶來的風險是如果啟動時當前可用區對應的實例庫存不足，就會啟動失敗。
還有一個正在搭建中的高可用 k8s 集群，運行着 1 台 master 與 1 台 worker 節點，另外 2 台 master 與 1 台 worker 處於關機狀態。
在 k8s 集群之前使用的 docker swarm 集群處於待棄用狀態，運行着 1 台 manager 與 1 台 worker 節點，其他節點都處於關機狀態，用的也是阿里雲搶占式實例。
風雲突變，船只顛簸
今天新年上班第一天，阿里雲上生意非常火爆，我們的服務器所在可用區的所有4核8G的搶占式實例全部售罄，造成定時啟動 k8s 集群節點服務器的任務全部失敗，僅有的 5 台服務器在訪問高峰不堪重負，開始出現 502 ，當我們發現后，嘗試通過阿里雲 ecs 控制台啟動這些服務器，但依然因庫存不足而無法啟動。
操作有錯誤發生： i-bp10c3nww9y26s9yppcq : 庫存不足，請您嘗試其它類型的實例規格 或者 其它可用區/地域的實例。您可以選擇變配到其他規格，然后啟動。更改實例規格 RequestId: 86752D85-39F0-4FEC-875B-80A3269D0B23
緊急自救，卻遭意外雷擊而翻船
手動啟動服務器失敗后，我們趕緊新購服務器添加到集群，本以為等服務器加好就能恢復，哪知卻遭遇新的意外情況，新加服務器上所有博客站點的 pod 都啟動失敗。
NAME READY STATUS RESTARTS AGE blog-web-bw87z 0/1 CrashLoopBackOff 4 4m36s
Pod 啟動失敗是因為其中的博客站點容器 dns 解析失敗，無法解析所依賴的服務的地址。
接着情況變得越來越嚴重，不僅新加服務器因 dns 解析問題無法啟動 pod ，而且集群中已有服務器也因為這個問題無法啟動 pod 。本來已有 5 台還能支撐部分請求，但由於這個意外的 dns 解析問題，集群中除了1-2台博客應用的 pod 還在運行，其他全掛了，這時整個博客站點全是 502 錯誤，k8s 巨輪就這么翻了。
救援行動，舊漁船挺身而出
巨輪翻了后，我們開始救援行動，首當其沖就是另外一艘建造中的更高級的巨輪 —— k8s 高可用集群，新購服務器加到這個集群，准備用這個集群處理負載，哪知這個集群也出現了異常情況，pod 也是無法啟動，一直處於 ContainerCreating 狀態。
NAME READY STATUS RESTARTS AGE blog-web-b2ggt 0/1 ContainerCreating 0 4m48s Error from server: Get https://10.0.2.82:10250/containerLogs/production/blog-web-b2ggt/blog-web: dial tcp 10.0.2.82:10250: connect: connection refused
這時唯一的救命稻草就是那艘准備棄用的舊漁船 —— docker swarm 集群，這個集群中處於關機狀態的節點服務器也因為庫存不足而無法啟動，只能新加服務器，趕緊把 k8s 集群中的那些服務器拿過來用鏡像更換系統后加入 docker swarm 集群。
sudo rm -rf /var/lib/docker/swarm && \ service docker restart && \ docker swarm join --token xxx 10.0.151.251:2377
當 docker swarm 集群投入使用並加到一定量的服務器后，博客站點才恢復正常。
開船的迷茫
恢復正常后，我們立即去排查出現 dns 解析問題的 k8s 集群，發現所有 worker 節點都出現了 dns 解析問題， 上次我們也被 dns 解析問題坑過（詳見 k8s 開船記：升級為豪華郵輪（高可用集群）與遇到奇怪故障（dns解析異常）），只是上次只有部分節點出現這個問題，這次是所有 worker 節點，上次是通過重啟服務器解決的，難道這次也要重啟才能解決？
於是將 worker 節點全部重啟，重啟后所有 pod 都正常運行了，這時我們恍然大悟，后悔莫及，當時營救翻船最簡單快速的方法就是重啟所有 worker 節點服務器。
開着舊漁船，回想着靠岸待修理的巨輪，望着茫茫大“雲”，我們更加迷茫了。使用 docker swarm 時多次遭遇奇怪的網絡問題，通過重啟節點服務器解決，開始我們懷疑水（雲），后來我們懷疑船（docker swarm），於是下定決心換掉漁船，換上巨輪（k8s），結果又遇到到了奇怪的網絡問題（dns 解析問題是網絡問題引起的），現在我們該懷疑誰呢？.
對於這次大翻船，最重要的原因是我們過多地使用了搶占式實例，是我們的過錯，我們會吸取教訓，調整服務器的部署。
這次大故障給您帶來麻煩了，再次懇請您的諒解。