Azure容器服务并没有在编排的辩论中选择站队，也并没有添加对Kubernetes的支持，或者比公有云对手提供更多的不同功能。

　　在新兴的容器编排大战中，微软已经将自己定位为云提供商中的瑞士。

　　微软对其初步的Azure容器服务进行了多次升级，例如与Kubernetes和基于Apache Mesos的DC / OS进行更深入的集成，以及在Azure上托管容器图像的新的私有存储库。 根据开放性主题，Microsoft已经发布了Azure容器服务引擎的源代码。

　　Microsoft是Kubernetes的早期支持者，并支持它在Azure上的使用，但是使用Kubernetes 1.4，支持更深入，具有本机功能，因此用户可以创建Kubernetes集群以与其他Azure服务集成。

　　与此同时，DC / OS升级了，在其用户界面上添加了更多虚拟网络选项，以及作业调度和基于Marathon的编排。 新的Mesos和Kubernetes功能目前正在公开预览。 微软没有说它将什么时候全部支持这些容器。

　　微软不站队

　　微软在这个领域采取了与其最大竞争对手不同的做法——对最突出的编排工具提供了深入支持。 毫不奇怪，Google Container Engine非常依赖Kubernetes——它是Google内部调度技术的开源版本，而Docker正在Docker Swarm上构建其平台，Mesosphere也依赖于Mesos。

　　一些突出的平台即服务产品（例如Red Hat OpenShift）也依赖于Kubernetes，而亚马逊则首次使用其EC2容器服务进行市场营销，并且已经建立了自己的专有工具来管理Docker容器。

　　Gartner的研究副总裁Richard Watson说，每种技术都确信它的编排技术将取得成功。 微软已经提供了Swarm和Mesos的客户选择，所以它只有把Kubernetes添加到列表中，并修改主题，不强迫用户选择，才有意义，他补充说。

　　Watson说：“微软很明智地成为了容器编排市场中的瑞士，因为这一市场没有明确的赢家和输家。 客户正在尝试许多不同的事情，在用于某些用例中，有些编排工具将会比其更好 。”

　　当然，对于容器编排而言，成为中立平台是说比做容易。 随着其服务的进步，在围绕着如何深入地与各种工具集成，以及何时解决本地问题，微软必须做出选择，

　　这也可能表明微软想成为Kubernetes生态系统的重要贡献者，Watson 说。 用户应该期望Kubernetes在Windows上正常工作，并在未来集群功能中引入Windows ，这对混合环境 IT 市场很重要，他说。

　　微软 利用Azure容器服务引擎在Azure 服务上创建部署，并在GitHub上开源了基础代码。 相比于定制化部署，目前还不确定微软这一做法如何让使用户在短期内直接受益，但它的目标是在Azure上，最终在Azure Stack 上 ，开发和分享最佳实践。

　　在Docker发展初期 微软Azure 支持Linux 容器，并与Docker合作在它的技术之上构建Windows版本 ，且本地支持 在最新的Windows Server。 451 Research的首席分析师Jay Lyman表示，由于微软在开源和DevOps的游戏中迟到了，因此它要加大力度在容器市场。

　　Kubernetes很受开发人员欢迎，但对企业IT来说，它仍然是新的，Lyman说。 微软的这一举动可能反映了一种转变，因为公司不仅使用容器用于开发/测试和Web应用，而且还用于传统企业中的数据丰富的生产工作负载上。

　　Lyman说：“这种管理和编排工作变得越来越重要，容器应用向生产环境的转移，意味着人们希望供应商支持SLA且确保技术支持。

　　公有云容器服务在兴起

　　Watson听到的大量客户的心声，他们已经准备好将容器迁移到操作环境中，但是他们需要一个编排工具。 由于这些工具可能难以管理，他希望看到大量公有云提供商提供这类服务。

　　“人们会意识到，允许提供商运行这些东西，事情会变得更好，如果他们已经在这些提供商的云上构建和运行了应用的话，那么与这些新的容器化应用集成将会更加容易”，Watson 说。

　　新的Azure Container Registry 表与Docker Registry v2兼容，它提供了一个私有存储库来存储Docker格式的镜像。 该工具在11月14日的预览版本中提供，作为Visual Studio中的新的持续集成和开发功能，供多容器Linux应用使用。