儒道哲學的浪漫人生

　　過去在VM 虛擬機的時代，我的服務單位花費很大的心力在AWS上建構了第二個備用服務中心，目標是實現應用服務的異地備援機制，以便當目前在美國的應用服務中心出問題時，可以緊急切換到另一個在歐洲地區的備用應用服務中心。

　　現在我們剛剛完成了應用服務的容器化，利用AWS的EKS服務建構了我們的服務，而今天我們也剛好做了一套新的EKS把舊的EKS服務切轉到新的EKS上面，準備淘汰舊的EKS。

　　這不禁讓我想到即使是在K8S容器雲的世界裡，我們也一樣要有一套異地備援機制，因為我們的應用服務是建立在K8S的Cluster之上的(在AWS則是EKS的Cluster)，可是Cluster一樣是會有故障的可能的(例如K8S/EKS的網路基礎架構故障導致Cluster運作失效)，而通常Cluster內會佈滿我們的服務在多個節點(Node)上，這個時候我們稱之為容災故障。

　　發生容災故障時我們一樣要有一個備用的Cluster可以立刻切換且喚醒裡中佈好的服務，接手故障的Cluster繼續運作我們的服務。

　　是的，以我們team的狀況來說，我們目前只有一個運作中的cluster，但一旦這個cluster發生任何意外，那我們將面臨即刻的服務停擺，這時候k8S會自動重啟容器(Pod)的機制可一點也不管用，因為壞掉的是能讓容器運作的Cluster。

　　所以我們服務目前只有一套Cluster可用實在是太危險了，服務相當脆弱，加上容器雲有太多未知的穩定性議題(最近有聽說網路很多人在談論使用容器運作服務的可靠性問題)，建立容災備援的Cluster以及切轉流程無論怎麼看都會是必要的，在容器雲的實作上，異地備援機制依然是不能被遺忘的一環！