【51CTO.com快译】谷歌的Kubernetes容器管理系统目前已经开始在微软的Azure Container Service(简称ACS)中正式向用户开放。
ACS支持能力正是微软为其Azure容器管理选项提供的重大调整之一，旨在借此提供该服务的开放性与竞争力。在一篇博文中，微软公司宣称Azure是“惟一一套提供容器服务并允许用户从三种主流开源编辑方案中任意选择的公有云平台。”
将Kubernetes的力量引入各个角落
微软公司在最初发布Azure Container Service时即强调“选择”优势。尽管在初期并不支持Kubernetes，但Azure一直能够支持Mesosphere DC/OS以及Docker Swarm，这主要是考虑到微软客户多数使用这两类方案，且企业认为这样的支持范围已经相当完备。
自那时开始，Kubernetes快速崛起并成为容器编排解决方案领域中的统治者。被用于多种深度学习框架、作为开源无服务器/“Lambda”应用框架的基础并可以内部托管服务的形式起效。
Azure上的Kubernetes自然也以在Azure环境中的Kubernetes运行为首要议题，而不在其它环境中提供即服务方案。不过通用版本中包含更多附加功能，旨在吸引Linux与Windows Server等广泛受众的关注，具体包括支持***版本的DC/OS(1.8.8)。
让Kubernetes在Azure环境上顺利运行并不困难，但根据微软合伙架构师Brendan Burns的说法，其中仍有大量功能缺失问题需要解决。以高可用性集群为例，“在审查中，大家只能在一套集群中设置一个主节点，”Burns解释称。“虽然其中可包含多台工作节点，但集群只能拥有一台主脑; 如果该设备发生故障，将产生致命的影响。”用户现在能够选择将多个节点设置为主节点，从而应用潜在的故障问题。
扩展能力则是微软需要实现的另一大需求。“大家可以选定一套现有集群，并对其进行规模扩展以获取更高容量，”Burns表示，“或者在不再需要时实现规模收缩。”
微软公司认为这些能力对于此项服务极为必要，但同时亦在其它层面发现了更多“改进空间”——例如开发一款更出色的命令行工具。微软还发现了几项影响到集群内容器中磁盘挂载与卸载的bug，并将其提交给上游厂商——不过相关解决方案将主要针对Azure自身的存储系统，而非实现一般性解决效果。
另一项重要补充是对Kubernetes与Windows Server Containers的配合效果进行审查。同样的，微软所关注的更多是理念层面而非技术层面的问题。微软的思路非常明确，如果Kubernetes未来成为***容器系统，那么其绝不想在这方面落后于他人。
对开发者更为友好的DIY途径
微软需要跟上容器技术发展趋势，这主要是由于容器已经能够“充当其自己的应用交付平台”，Burns解释称。根据目前Kubernetes与Azure的对接情况来看，这些平台“将成为内部平台，但亦将作为构建组件立足容器编排层进行开发，”他指出。
这一容器编排层将逐渐成为新时代下的虚拟机方案，也标志着容器即服务将快速成为实现平台即服务功能的***选项。传统的PaaS则将转向裸机或者虚拟机平台。不过就目前来看，“我认为我们还将见到更多作为新型基础设施的容器编排方案，且将主要作为以开发者为核心的平台选项存在，”Burns解释称。
“容器镜像已经成为新的软件交付方式，而这类镜像具备语言中立性以及一定程度的平台中立性，”他补充称。编排层负责运行容器化应用、保证正常运行并实现负载均衡。
基于容器技术的新型PaaS不再需要专注于分布式系统构建的精细化方向，可将这些工作交由Kubernetes解决，转而专心提供“更为丰富的开发者使用体验——帮助顺利完成由源代码编写到应用程序部署的整个流程，”Burns总结道。
原文标题：Kubernetes rounds out Azure options, paves way for Windows Server Containers，原文作者：Serdar Yegulalp
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
