監控服務DripStat指微軟AKS服務不穩且無法有效解決，決定搬至GCP

雲端服務的安全性是企業採用的重要考量之一，而可靠度也是需要仔細評估的要素。雲端基礎架構監控服務DripStat創辦人Prashant Deva在部落格上抱怨，他們所使用的Azure Kubernetes服務（AKS），雖然近期已經進入一般可用階段，但因為其服務仍然非常不穩甚至還違反SLA，因此最後決定把自家服務搬遷到Google雲端平臺上。

雲端服務事件頻傳，在上個月，GCP用戶才抱怨自家服務被無預警關閉，損失了一個小時的資料，而騰訊雲也傳出其號稱99.95％服務可用性與99.9999999％資料可靠性的雲端服務，卻讓一家中國新創公司的資料全數消失。而Prashant Deva則抱怨了自家DripStat服務建構在微軟AKS上遇到的挫折，讓他最後決定將服務搬移至擁有Kubernetes最佳實作的Google雲端上。

Prashant Deva一開始提到，使用AKS服務他們會隨機的遭遇DNS故障，無論是在Azure之外的網域或是Azure虛擬網路內的主機名稱都曾發生這樣的問題，雖然總是在多試幾次後就能解決這個問題，但反覆地發生總是非常困擾，但Azure支援服務團隊卻認為，解析指向Azure網域之外的DNS並不是他們的問題，他們僅能處理位在Azure內主機名稱的故障。

Azure支援服務團隊同時也表示，DNS故障是因為用戶在CPU與記憶體使用設定的問題，如果想要DNS可以穩定的工作，就不應該使用太多的CPU與記憶體。不過，當DripStat反應這問題通常出現在CPU與記憶體使用率最低的時候，Azure支援服務便不再回應該問題。

DripStat遭遇到的第二個問題，他們每天都必須要重新啟動Kubernetes API伺服器。由於有一天他們發現無法啟動Kubernetes儀表板，經過多位Azure支援服務人員的協助後，找出唯一有效的方法，就是重新啟動Kubernetes API伺服器。但由於API伺服器由Azure管理，因此需要開立維修票券，將服務升級為工程等級，才能由Azure進行重啟。

由於這個問題每天都會重現，因此DripStat每天都需要開立一張維修票券，他們必須要在電子郵件中，詳細的紀載整個過程，以避免重啟程序申請時，Azure支援人員不停地詢問每日重複的問題。

前兩個問題可能只是造成服務不穩或是手續麻煩，Prashant Deva提到，AKS上容器崩潰會造成整個節點崩潰。當Docker映像檔崩潰，則整個底層虛擬機器都會跟著崩潰，而恢復的唯一手段就是登入Azure入口網站，並且手動重啟虛擬機器。Azure服務團隊告知DripStat，這是DripStat的問題，他們應該確保容器不會崩潰。

而最糟糕的情況發生了，Prashant Deva有一天發現他們Kubernetes叢集中的每一個節點都被關閉，即使從Azure入口網站手動重啟虛擬機器也沒有用，Azure支援幫助他們重啟叢集，但是無論如何節點數量都會不停地往下降，經過8個小時的嘗試後，總算叢集被啟動了，但是DripStat卻無法在上面執行任何容器，並且錯誤碼指向一些Go語言程式碼的錯誤，Prashant Deva提到，他們的應用程式是用Java開發的，而且Azure最後還是回應這是DripStat的問題作結。

經歷了這些過程，Prashant Deva認為，即便AKS沒有SLA，單個虛擬機器節點仍然必須遵守Azure上99.9％的SLA，由於DripStat的虛擬機器下線了數小時，他們開了票券來申請SLA，但最後仍被Azure支援服務忽略，因此他指控微軟違反SLA。此外，他也提到，DripStat使用的P1票券應該在1個小時內收到Azure支援回覆，但總是超過24小時後才收到回應。

Prashant Deva表示，DripStat最後還是選擇了擁有Kubernetes最佳實作的Google雲端，作為棲身之地。這個事件在網路論壇引發討論，有不少網友表示認同Prashant Deva的說法，認為Azure上的服務不少為半生不熟（Half-baked）的Alpha階段，也有網友提到，AWS上的Kubernetes服務也有類似的情況。

這個討論也引來了自稱為AKS工程主管回應，他提到AKS工程團隊花了一天的時間測試結果發現，用戶讓他們的應用程式過度的使用記憶體，導致核心的Oom殺手（Out of Memory Killer）終止了Docker守護行程和Kubelet。他提到，作為部分調查後的改進，現在用戶超過節點資源限制，系統則會保留Docker和kubelet，內核只會關閉應用程式而非關鍵系統程序。