Azure Kubernetes 服务是如何让开发者更有成效？

【编辑的话】微软发布了新的托管Kubernetes服务预览版“Azure容器服务（AKS）”，该产品独立于现有的ACS，后者支持Kubernetes、Mesos DC/OS和Docker Swarm等多种编排工具。AKS有如下特性：Azure托管的控制面板、自动升级、自我修复、用户可配置的扩展以及“面向开发人员和集群操作人员的简洁用户体验”。

容器简化了应用的部署，伸缩和运行。Kubernetes 是编排和管理容器的平台，它整合了虚拟环境中日益增加的应用所需要的组件。现代的 app 开发途径近乎贪婪的胃口，已经在构建容器和 Kubernetes 技术的开源社区建立了一个强制功能。

Kubernetes 生态系统仍然提供有关在生产中有效运行复杂的容器化应用程序的关键技术。但是对于现在将要使用容器的主流开发者而言，问题不是他们的 apps 要不要运行在Kubernetes，而是如何在 Kubernetes 上运行的更有效。

凭借强大的Kubernetes核心，现在是容器和Kubernetes发展的下一个阶段。而今，开发人员的体验将变得至关重要。这是 Azure Kubernetes Service (AKS)架构师的核心信仰。从构建和测试容器镜像到调试和部署至生产线，AKS 使开发人员体验更简单。

微软的新 AKS 开发者 工具 反应了这种对开发者体验的重视。基于 Visual Studio的开发工具，简化了 Kubernetes 的开发工作流程。此工具为运行在 Kubernetes 上，基于复杂的微服务的应用，设置一个更容易的开发环境，以及预生产测试，迭代开发和快速调试。

“在分布式系统时代，开发人员是不容易的。在让主流开发人员能够使用容器和容器编排以及构建分布式应用程序方面，我们还有很长的路要走。” Gabe Monroy，微软 Azure 容器团队的项目经理说道。“ 业界一直以来专注于API和有原则的分层架构 - 这很好，我们需要这些 - 但是对于应用程序开发人员的体验并没有那么多关注。我们如何使在这个新世界中开发软件的过程感觉像以前一样？

Kubernetes 使开发者面临从构建到部署的一系列挑战

不熟悉Kubernetes的开发人员面临着很高的进入门槛。想要利用好容器就可能意味着需要数小时的研究。他们首先学习如何编写Dockerfile，清单和Helm图表，以及使用 Draft 进行本地开发。然后他们逐步研究如何进行代码测试，内置到映像中，链接到Brigade的持续集成工作流，并安全地部署到集群上，这需要创建审计日志而没有任何偶然的部署。

但是开发人员还需要设置他们的开发环境来处理容器，使其看上去，感觉上和表现地和生产环境一样。它还必须和为了应用程序提供支持的所有其他微服务，容器和外部依赖项集成，这意味着在本地存根或模拟服务以匹配该服务。在一个大型项目中，每个开发人员都必须花时间来做这件事，即使他们可能只处理其中的一小部分。

此外，他们想在他们的环境中使用熟悉的，丰富的开发者工具，使用日志，以便他们可以针对实时服务进行调试，以及直接从IDE进行断点和快速部署，以便他们可以测试更改代码。

“你肯定已经听说过这样一个业界的梗，Kubernetes 对于开发人员来说还是太难了。” Monroy 说道。“我们同意这是下一代基础设施 - 没有人可以使用它，它很棒！” 这是一个有点严肃的笑话。

微软的 Kubernetes 开发者工具

一次又一次，微软已经改变了不同领域的开发者的体验，从 Excel 和 Access 到 Logic Apps，现在是新的 Azure Dev Spaces 服务，用于针对AKS的快速开发。

微软的目标是支持那些现在开始使用容器的主流开发者。为此，公司正在从其在开发者工具方面的历史，以及从创建Helm，Brigade和Draft等开源工具中学到的知识。微软也是 Kubernetes 上游项目的主要贡献者——Kubernetes 联合创始人 Brendan Burns 领导了微软容器小组——微软是 Cloud Native Computing Foundation (CNCF) 的成员。

“微软作为一家面向开发者的公司的基因已经被激活，您将看到微软开发部门的全部力量将在CNCF世界中释放出来，” Monroy 说道。

AKS Dev Spaces 中调试微服务只需5分钟

在 Kubernetes 集群中，Dev Spaces 为每个开发者在项目中建立一个独立的，沙盒空间。他们可以从熟悉的 IDEs 直接使用这个空间，如，Visual Studio 和 Visual Studio Code （Windows，Mac or Linux），或者是命令行。他们运行在在线的云端 Kubernetes 集群，使开发环境就像生产环境一样，拥有 app 所需的所有的依赖库和微服务以及交互的服务。那些没有权限或技能去设置这些服务的开发者仍然能够测试这些运行在云端的服务。但是他们直接进入到代码所在的容器，并且独立的调试和迭代他们；不会影响其团队中的开发者。

使用名称空间隔离和多租户控制为Kubernetes集群设置隔离通常非常复杂； 而这仅是 Dev Spaces 中 Azure access 模块所附带的功能。但是因为 AKS 是完整的 Kubernetes，Dev Spaces 是使用原生 Kubernetes 概念实现的现有 AKS 集群的附加组件，你可以使用其他Azure服务或第三方工具。如果你想使用 Azure Key Vault 或 Hashicorp Vault 来注入秘密，那么不用将它们存储在代码中，就能生效。

但与 Visual Studio 集成的优点在于，除了容器和云服务的所有功能外，开发者还可以获得熟悉的工具和工作流程的生产力。他们可以从创建一个新项目到设置断点，然后点击F5来调试他们的代码，就像他们在自己的系统上运行代码一样。就像编写任何其他类型的应用程序时一样，他们获得 IntelliSense 和新的 IntelliCode AI 支持，用于编写代码甚至是 Visual Studio Live Share 的协作编辑。但是因为运行在 AKS 上，他们也能看到容器运行的健康状态和搜索生产日志以确定哪里出了问题。一旦发现了 Bug，他们就能修复并且按 F5 直接发送这些更改到 AKS 并且运行他们。

“随着世界已经接受了这些复杂的微服务环境，现在开发人员走向环境并提高工作效率变得非常困难。” Monroy 指出。

当一个应用程序可以包含数百个微服务，每个微服务都有自己的数据存储排列，修复一个服务中的错误就像在大海捞针一样。在笔记本电脑上设置一百个服务或模拟它们以及所有后备存储对于开发人员而言非常耗时。只需设置他们的环境，以便他们可以找到并修复过去需要一天的整体应用程序。现在，准备好处理复杂的分布式应用程序可能需要数周时间，如果开发人员甚至可以正确设置它。

“Dev Spaces提供了使用Azure帐户进行操作的功能，您可以在五分钟内修复错误，” Monroy 说道。

在幕后，Dev Spaces将开发人员在本地工作的代码中的更改直接同步到容器中。对于大多数更改，更新时不需要重建和重新部署容器映像。意味着开发人员在等待查看更改是否修复了错误时不会丢失编码流程。对于Node.js开发人员来说，每次检测到文件更改时，nodemon都会自动为他们重新启动节点服务，并且只需要刷新浏览器以查看他们的新代码，这将感觉熟悉且高效。

Dev Spaces使用服务网格路由来允许开发人员调试非常复杂的分布式应用程序，Monroy解释说。“通过在URL中附加前缀，您可以指示服务网格将流量路由到正在进行开发的容器中。”

“现有的开源生态系统中没有任何东西可以进行智能代码同步或流量路由，” Monroy 指出。“如果您在GKE上有一个应用程序并且您在GKE上使用Draft，那么您可以将相同的应用程序带到Azure，并通过更快的迭代循环，集成空间和流量路由获得Dev Spaces的更好体验。”

Visual Studio，Dev Spaces和AKS之间的紧密集成意味着在Azure上使用Kubernetes的开发人员在开始使用云原生工具时不会失去他们用于本地开发的生产力。

原文链接： How the Azure Kubernetes Service Makes Developers More Productive （翻译：Sam）