雲端服務的安全性是企業採用的重要考量之一,而可靠度也是需要仔細評估的要素。雲端基礎架構監控服務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,內核只會關閉應用程式而非關鍵系統程序。


Advertisement

更多 iThome相關內容