用戶吐槽 Azure Kubernetes，因其搞砸了集群！

微軟在6月份剛向全世界發布了Azure Kubernetes服務（AKS）；卻不料，現在幾個滿腹牢騷的客戶稱，這個託管容器產品還沒有完全成熟。

在周一發布的一篇博文（https://movingfulcrum.com/horrors-of-using-azure-kubernetes-service-in-production/）中，應用程序和基礎設施監控服務DripStat的開發者普拉尚特?德瓦（Prashant Deva）炮轟了AKS，斥責它是「被微軟號稱是正式版（GA）的alpha測試版服務。」

他列舉了生產環境中使用AKS後出現的幾大問題：隨機性的DNS故障、每天必須重啟Kubernetes API伺服器、容器崩潰會導致整個節點停運、無法恢復的集群崩潰以及無視違犯SLA的現象。

現將我們與ASK團隊的對話內容記錄如下：

AKS目前遇到了一個已知的問題，導致Kubernetes儀錶板無法正常使用。

唯一的解決辦法就是，AKS團隊手動重啟與該集群有關的API伺服器。

這個問題再次出現的話，我們應該不用費老大的勁，就能聯繫AKS團隊、重啟API伺服器。

這就是在生產環境中使用Azure Kubernetes的樣子。自上周以來天天如此。

德瓦表示，上個月他將其公司的生產工作負載轉移到了AKS，此後卻一直備受Azure以外的域和Azure虛擬網路中的主機名稱出現隨機性DNS故障這個問題的困擾。

他描述微軟支持部門給出的回應（建議不要使用過多的內存和CPU資源）實在可笑，表示他告知微軟DNS問題主要出現在極少使用內存和CPU資源的應用程序啟動這個過程中，微軟隨後沒有作出響應。

出問題的還有AKS Kubernetes儀錶板，沒過幾天儀錶板崩潰了，需要重啟Kubernetes API伺服器來修復。德瓦說，讓人抓狂的是每天都要重啟該伺服器，這意味著不斷處理支持工單。

您有沒有試過關閉後啟動您的基礎設施？

據德瓦聲稱，Docker容器崩潰後，底層的虛擬機也隨之崩潰。需要從Azure門戶網站手動重啟虛擬機才能進行恢復。他這樣描述自己從Azure支持部門得到的回應：「是的，這是您的問題。務必要確保您的容器永遠不會崩潰。」

他詳細敘述了一次無法恢復的集群崩潰，聲稱微軟違反了服務級別協議（SLA），SLA 的適用對象是AKS底層的虛擬機，而不是AKS本身。

他說：「Azure支持部門提供的支持服務是我有生以來遇到過的最差勁的。」他特別指出，他後來改用了谷歌雲平台的Kubernetes服務。「......無視違反SLA的現象是徹頭徹尾的欺詐行為。」

IT外媒The Register通過Twitter的私信系統聯繫上了德瓦，他說這次遭遇僅限於AKS，並不針對其他的Azure服務。

他告訴The Register：「微軟處理這次事件很糟糕。最糟糕的地方是，他們試圖責怪問題出在用戶自己身上。」

微軟發言人在發給The Register的電子郵件中將問題歸咎於德瓦在沒有內存限制的情況下運行工作負載：

我們的技術部門作了一番深入認真的調查，事後查明該客戶的工作負載在其集群的節點上過度調度，擠掉了系統服務，導致異常行為。

我們就該客戶如何防止這種情況再次發生給出了建議，並對AKS進行了相應的改進，以確保客戶不會無意中再次遇到這種狀況。我們還在繼續致力於提供更好的診斷和監控工具，以便客戶和我們自己的支持工程師能夠更快地查明什麼原因導致客戶的環境出現問題。我們一直關注客戶有沒有遇到AKS方面的問題，我們會利用此反饋，繼續改進服務和我們的支持流程。

一個人以QiKe之名發帖子，聲稱自己是AKS方面的工程主管，他在Hacker News的帖子中給出了類似的解釋。

德瓦不是唯一反映異常問題的AKS客戶。Seismic Software的高級數據科學家科林?傑摩特（Colin Jemmott）發推文稱：「我使用Azure託管Kubernetes（AKS）的情況與這個差不多。」

6月底，深度學習和金融公司SMACC的高級軟體工程師沃吉西奇?巴克津斯基（Wojciech Barczyński）描述了使用AKS引發的諸多問題。然而，他沒有因此丟棄AKS，而是建議大家跳過「正式版問題頻出的頭幾個月」，等服務變得更穩定後再使用。

他說：「隨著時間的推移，客戶數量越來越多，AKS團隊的經驗會越來越豐富。因此，服務會迅速改進。」

與此同時，AKS也不乏粉絲。有個人在Hacker News上發表評論稱：「我遇到的情況卻大不一樣。我公司一點都不大，但是對我們來說，Azure運行起來再順暢不過了。」

我們應該都很幸運。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！