采访微软项目经理 Gabe Monroy，探讨 Build 2018 大会上发布的 Azure Kubernetes Service

在近期于西雅图举办的微软 //build 大会上，有多场与容器和 Kubernetes 相关的技术演讲。InfoQ 与 Azure 的容器服务的项目经理主管 Gabe Monroy 进行了一次访谈，主题是 Azure Kubernetes Service（AKS）服务。InfoQ 在近期的报导中已提过， AKS 最近刚刚进入正式可用状态。

Monroy 在访谈中介绍了 Azure 云与 Kubernetes 服务的集成，以及微软对 Deis 的收购为 Kubernetes 服务的推出所带来的促进作用。他同时提到，微软在与社区展开合作的同时，也致力于让 AKS 带来与众不同的功能，例如与 Azure Active Directory（AAD）的集成。

InfoQ：让我们直奔主题吧。在各个云平台纷纷推出 Kubernetes 服务的当下，AKS 的竞争力体现在哪里，如何吸引开发人员与架构师的目光？

Gabe Monroy：在选择 Kubernetes 服务的时候要牢记一点 —— 并不是所有的一切都运行在 Kubernetes 中。你的业务还需要依赖数据库、队列、函数以及其他服务，其中有许多功能是不会运行在 Kubernetes 之上的。因此，我认为 Kubernetes 服务的竞争力主要体现在它的底层云平台。在 Azure 上，你可以享受到其他服务带来的便利，例如 Azure Active Directory、Azure Traffic Manager、Azure Monitor，当然，还有我们无与伦比的开发工具套件。

具体说到 AKS 服务本身，它的独特功能包括：

• Kubernetes RBAC 集成了 Azure Active Directory
• 在 AKS 门户上直接集成监控与日志记录功能
• 实现 HTTP 应用路由功能，并内建了 Ingress 与 DNS 区域文件的管理功能
• 提供 GPU 功能节点，适用于处理计算与图形密集型的工作
• 为私有网络环境提供自定义虚拟网络的功能
• 通过 Azure Files 与 Azure Disks 实现持久化卷
• 遵循 SOC、ISO、HIPPA、HITRUST 等合规性规范

InfoQ：您本人也是来自已由微软收购的 Deis 这家公司。可否介绍一下，你们是如何将在 Deis 的工作成果集成至（或是正在集成） Azure Kubernetes 平台上的？

Monroy：Deis 在以下两个领域得到了业界的广泛赞誉：

1. 为 Kubernetes 打造开发工具 —— 我们开发了一套类 Heroku 风格的 PaaS 解决方案，名为 Deis Workflow，并得到了非常广泛的应用。这也是第一套能够运行在任意 Kubernetes 环境上的 PaaS 解决方案。此外，我们还创建了 Helm，它已经逐步成为 Kubernetes 生态圈中包管理方案的事实标准。近期，Helm 刚刚被选为 CNCF 的顶级项目之一。我们还将继续 Helm 以及其他开源开发工具，例如 Draft 和 Brigade 的开发。
2. 帮助大客户在生产环境中成功地实施 Kubernetes，我们拥有一支广受赞誉的专业服务团队，已帮助 Mozilla、Hearst Corporation 和 OpenAI 等客户成功地实施了大规模的 Kubernetes 应用。由于这项工作在 Kubernetes 的早期阶段就已经启动，我们也因此获得了操作大规模 Kubernetes 的丰富经验。这些宝贵的经验也为我们开发 AKS 带来了巨大的价值。

InfoQ： Azure Container Instances 近期刚刚正式发布。你能否为开发者与架构师提供一些建议：何时应使用 AKS，何时应使用 Azure Container Instances？

Monroy：从上周起，Azure Container Instances 与 Azure Kubernetes Service 都已经正式可用，这是个令人振奋的消息。

• 何时选用 ACI? - 如果你希望使用容器技术，又不打算操作复杂的容器编排。那么可以考虑使用 ACL，它适用于仅仅运行少量容器的场景，包括会终止的服务（例如某个完成任务后即终结的作业），以及需要不间断运行的服务（例如某个简单的 web 应用）。ACI 的特点是易于使用、计时收费，并且无需管理虚拟机。ACI 的 API 与 Virtual Machine API 非常相似，可通过 API 对实例进行增删查改以及查看列表操作。只是操作的对象由 VM 变成了容器。
• 何时选用 AKS? - 如果你希望将服务运行在容器上，并且需要用到容器编排功能，例如无停机更新、维护多个分发节点、通过服务发现方式实现容器间的通信、批处理工作流等特性，则可以选择 AKS。如果你希望享受到 Kubernetes 生态环境所带来的便利，包括跨环境的可移植性，以及使用由 CNCF 托管的各种工具与服务，那么 AKS 同样也是一个良好的选择。

在《Azure 计算服务的决策树》这篇文章中提供了更多的细节，以帮助用户选择最合适的服务，并且除了 AKS 与 ACI 之外还提供了更多的选择。

InfoQ：Kubernetes 生态系统的发展非常迅猛，这对于开发者来说也是个挑战。比方说，企业应用的开发者希望使用他们最熟悉的监控工具，例如 Nagios、Ganglia 等等，所面临的困难在于 1) 如何监控整个 Kubernetes 集群，2) 如何运用当前已经过时间检验的工具。对于在 Kubernetes 生态系统仍在持续发展的特性，尤其是监控方面的特性来说，AKS 提供了哪些常规的方案呢？

Monroy：AKS 旨在提供开箱即用的监控与日志聚合体验。事实上，今年在西雅图举办的 //build 大会上，我们已经展示了 Azure 门户中的 Container Health 监控工具，通过它所提供的仪表盘，用户可以查看容器和相应的监控指标，甚至直接查看容器的日志。所有这一切都可以在 Azure 门户中完成，并且默认就是开启的。作为一名开发者，这正是我想要的体验。

对于想要自行选择监控方案的客户来说，AKS 也提供了 Kubernetes DaemonSets 特性，它能够在 Kubernetes 集群中的所有虚拟机上安装代理。对于常规的方案而言，可以通过 Helm 简便地安装现成的监控应用包。不过，如果你选择实施自己的监控方案，那么比起我们在产品中提供的整合方案来说就意味着需要更多的工作。当然，最终还是由用户来决定。

InfoQ：有一种说法认为，容器与 Kubernetes 的出现带来了额外的安全隐患。AKS 是如何消除这些隐患的？

Monroy：不能说 Kubernetes 和容器本身是不安全的，而是在于他们从根本上改变了安全模型。防火墙规则通常会针对 IP 地址构建访问控制清单。而在容器的世界里，由于 IP 地址变化如此之快，已不适用于防火墙的规则了。因此，安全团队需要转而使用基于标签的防火墙规则（例如：role=frontend 标签对应的资源可访问 role=backend 的资源）。类似的变化也适用于运行时的安全管理，进程能力的限制与系统调用的筛选变得重要起来。

一般来说，我认为一个运行良好的容器基础设施比起遗留的 VM 基础设施来说具备更强的安全性。举例来说，在这次 AKS 的正式发布版本中，提供了对 Azure Active Directory 的支持，以实现身份与分组管理的功能。这种方式为集中式的用户账号与分组管理提供了一个安全性良好的解决方案，而 Kubernetes 能够获取这些账号信息。Azure AD 中的用户身份信息也构成了 Kubernetes RBAC 的基础。Active Directory 是 Azure 的一个独立功能，我很高兴看到它与 AKS 产品实现了深度的集成。

InfoQ：能否请你介绍一下 AKS 的产品发展路线，以及与 Kubernetes 社区下一步的合作计划？

Monroy：我们很快会支持多节点池、集成集群的自动扩展，以及更丰富的安全特性。我们还会在更多的区域推出 AKS，并让 AKS 更好地与整个 Azure 平台相结合。此外，打造更好的开发者工具与用户体验也始终是我们的工作重心。

这次发布有一点特别令我感觉兴奋，那就是我们在 Kubernetes 社区中参与的 Virtual Kublet 工作的内容。用户非常欢迎 “无服务器 Kubernetes” 体验的这一想法。通过这种方式，用户可以按需调用 Kubernetes API，同样计时收费，并且无需使用虚拟机。敬请期待无服务器 Kubernetes 在近期的更多更新。

在 build 2018 大会的官网上可观看主题演讲与其他演讲内容的录制视频，包括本次演讲的视频。

查看英文原文： Q&A with Gabe Monroy of Microsoft on Azure Kubernetes Service from Build 2018