监控服务DripStat指微软AKS服务不稳且无法有效解决，决定搬至GCP,,云端基础架构监控服务

原标题：监控服务DripStat指微软AKS服务不稳且无法有效解决，决定搬至GCP

云端服务的安全性是企业采用的重要考量之一，而可靠度也是需要仔细评估的要素。云端基础架构监控服务DripStat创办人Prashant△Deva在博客上抱怨，他们所使用的Azure△Kubernetes服务（AKS），虽然近期已经进入一般可...

云端服务的安全性是企业采用的重要考量之一，而可靠度也是需要仔细评估的要素。云端基础架构监控服务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的问题，他们应该确保容器不会崩溃。

This△is△what△its△like△to△use△#Azure Kubernetes△in△production. Every△day△since△the△last△week△pic.twitter.com/BLxn5EwkW4

— Prashant△Deva△(#pdeva) 2018年7月13日

?

而最糟糕的情况发生了，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，内核只会关闭应用程序而非关键系统程序。

橙山网（Csnd.net）简评：云端基础架构监控服务DripStat创办人Prashant△Deva在博客上抱怨，他们所使用的Azure△Kubernetes服务（AKS），虽然近期已经进入一般可...云端服务的安全性是企业采用的重