用户吐槽 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运行起来再顺畅不过了。”

我们应该都很幸运。