本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

为 Azure Container Service 带来 Kubernetes 支持

在我家乡西雅图举办的 KubeCon 大会上,有上千人参加,距离我协助启动 Kubernetes 项目仅仅三年。看到一小群人和一个激进的想法,经过一个庞大且不断壮大的社区三年来的辛勤工作,发展到如今的规模,真是令人惊叹和感慨。2014 年 7 月,也就是 Kubernetes 公开可用仅一个月后,微软宣布了对 Azure 的初步支持。Kubernetes 1.4 的发布带来了对原生微软网络、负载均衡器磁盘集成的支持。

今天,微软宣布了 Kubernetes 在 Azure 上的下一步:将 Kubernetes 作为受支持的编排器引入 Azure 容器服务 (ACS)。加入 ACS 团队并协助构建这一新功能令我非常兴奋。将 Kubernetes 集成到 ACS 意味着您只需在 Azure 门户中点击几下,或者在新版基于 Python 的 Azure 命令行工具中运行单个命令,即可创建功能齐全的 Kubernetes 集群,并与您的其他 Azure 资源集成。

Kubernetes 已在 Azure 容器服务中公开预览。社区参与一直是 Kubernetes 体验的重要组成部分。在接下来的几个月里,我希望大家能加入我们,在我们将它推向正式可用版时,提供您对体验的反馈。

本着社区精神,我们也很高兴地宣布一个全新的开源项目:ACS Engine。ACS Engine 的目标是提供一个开放的、社区驱动的平台,用于开发和分享在 Azure 上编排容器的最佳实践。我们在 Azure 上运行容器的所有知识都已保存在该存储库中,我们期待在未来与社区一起改进和扩展它。未来,ACS Engine 中的模板将成为通过 ACS API 部署集群的基础,因此社区驱动的改进、功能等将自然地融入 Azure 容器服务。我们很高兴邀请您加入我们,共同改进 ACS。在创建 ACS Engine 之前,具有 ACS API 不支持的独特需求的客户需要维护我们模板的变体。虽然这些差异最初很小,但随着主线模板的改进和用户对模板的迭代,它们会随着时间的推移而变大。这些差异和漂移严重影响了用户协作的能力,因为他们的模板都不同。如果没有分享和协作的能力,就很难形成社区,因为每个用户都被孤立在自己的变体中。

为了解决这个问题,ACS Engine 的核心是一个用 Go 编写的模板处理器,它使您能够动态地将不同的配置片段组合在一起,形成一个可用于构建集群的最终模板。因此,每个用户都可以混合搭配这些片段来构建符合其最终需求的容器集群。同时,每个片段都可以由社区协作构建和维护。我们一直在与一些客户进行这种方法的测试,到目前为止,我们收到的反馈非常积极。

除了帮助您在 Azure 上运行容器的服务外,我认为改进开发和部署容器化应用程序到 Kubernetes 的体验也至关重要。为此,我最近一直在努力为出色的开源 Visual Studio Code 构建 Kubernetes 扩展。Kubernetes 扩展使您能够快速将正在编辑的 JSON 或 YAML 文件部署到 Kubernetes 集群。此外,它还允许您将现有的 Kubernetes 对象导入到 Code 中,以便于编辑。最后,它使您的运行中的容器与正在开发的源代码之间实现同步,以便轻松调试您在生产环境中遇到的问题。

但是,俗话说“一图胜千言”,所以请观看此视频

当然,和 Kubernetes 的其他一切一样,它也是开源的,我期待与社区进一步合作。再次感谢大家,我期待今天在 OpenShift Gathering 以及明天和周三在 KubeCon 微软 Azure 展位与大家见面。欢迎来到西雅图!