你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

选择 Azure 容器服务

  • 项目

Azure 提供了一系列容器托管服务，旨在满足各种工作负载、体系结构和业务需求。 本容器服务选择指南有助于了解最适合工作负载应用场景和要求的 Azure 容器服务。

注意

在本指南中，“工作负载”一词指支持业务目标或业务流程执行的应用程序资源集合。 工作负载使用 API 和数据存储等多个服务协同工作，以提供特定的端到端功能。

如何使用本指南

本指南包含两篇文章：本简介文章以及另一篇关于所有工作负载类型共享的注意事项的文章。

注意

如果尚未致力于适用容器化，请参阅选择 Azure 计算服务，了解有关可用于托管工作负载的其他计算选项的信息。

本简介文章介绍了本指南目标范围内的 Azure 容器服务，以及在可配置性与固执的解决方案（例如客户托管方法与 Microsoft 托管方法）之间的权衡方面对这些服务模型的比较。 根据服务模型偏好设置确定候选服务后，下一步是查看有关网络、安全、操作和可靠性的共享注意事项的文章，根据工作负载要求评测这些选项。

本指南根据工作负载的技术要求、规模和复杂性以及工作负载团队的专长，将你可能需要做出的权衡考虑在内。

本指南范围内的 Azure 容器服务

本指南重点介绍 Azure 当前提供的一部分容器服务。 这部分服务为 Web 应用程序和 API、网络、可观测性、开发人员工具和操作提供了成熟的功能集。 这些容器服务的比较情况如下：

容器应用徽标

Azure 容器应用是一个完全托管且基于 Kubernetes 的应用程序平台，它可帮助你从代码或容器来部署 HTTP 和非 HTTP 应用，而无需协调基础结构。 有关详细信息，请参阅 Azure 容器应用文档。

AKS 徽标

Azure Kubernetes 服务 (AKS) 是一种托管 Kubernetes 服务，用于运行容器化应用程序。 借助 AKS，可利用托管加载项和扩展来实现其他功能，同时保留最广泛的可配置性。 有关详细信息，请参阅 AKS 文档。

应用服务徽标

用于容器的 Web 应用是 Azure 应用服务功能，它是一项完全托管的服务，用于托管内置基础结构维护、安全修补、缩放和诊断工具且基于 HTTP 的 Web 应用。 有关详细信息，请查看应用服务文档。

有关所有 Azure 容器服务的完整列表，请参阅容器服务产品类别页面。

服务模式注意事项

服务模式可提供最广泛的见解，了解任何 Azure 容器服务提供的灵活性和控制级别，以获取有关其整体简单性和易用性的信息。

有关基础结构即服务 (IaaS) 和平台即服务 (PaaS) 等服务模式的术语和概念的一般介绍，请参阅云中责任分担。

比较 Azure 容器解决方案的服务模式

AKS

AKS 混合了 IaaS 和 PaaS，它更看重控制级别而不是简单性。 尽管 AKS 简化了底层核心基础结构的管理，但此基于虚拟机的平台仍向应用程序公开，并且需要适当的防护措施以及修补等流程，来确保安全性和业务连续性。 计算基础结构由直接在订阅中托管的其他 Azure 资源支持，例如 Azure 负载均衡器。

还可通过 AKS 访问 Kubernetes API 服务器，以自定义容器业务流程协调，从而从云原生计算基金会 (CNCF) 部署项目。 因此，对于不熟悉 Kubernetes 的工作负载团队来说，学习曲线较长。 如果你不熟悉容器化解决方案，则此学习曲线可能成为阻碍。 以下 PaaS 解决方案降低了入门门槛。 可在要求规定移动到 Kubernetes 时进行该移动。

Azure Container Apps

容器应用（PaaS 产品/服务）通过简单性平衡控制级别。 它提供无服务器和专用计算选项，从而无需修补操作系统或围绕应用程序构建防护措施（相对于操作系统）。 容器应用还完全抽象化容器业务流程协调 API，并通过团队可能已熟悉的 Azure API 提供一部分关键功能。 此外，第 7 层入口、流量拆分、A/B 测试和应用程序生命周期管理全部都是现成的。

用于容器的 Web 应用

用于容器的 Web 应用也是 PaaS 产品/服务，但与容器应用相比，它更简单，但控制级别更低。 它抽象化容器业务流程协调，但仍提供适当的缩放、应用程序生命周期管理、流量拆分、网络集成和可观测性。

托管模式注意事项

可以使用 AKS 群集等 Azure 资源托管多个工作负载。 这样做有助于简化操作，从而降低整体成本。 如果选择此路径，下面是一些重要注意事项：

  • AKS 通常用于托管多个工作负载或不同的工作负载组件。 可以使用命名空间、访问控制和网络控制等 Kubernetes 本机功能来隔离这些工作负载和组件，以满足安全要求。

    如果需要 Kubernetes API 提供的其他功能，并且工作负载团队有足够的经验来运行 Kubernetes 群集，还可以在单一工作负载应用场景中使用 AKS。 Kubernetes 经验较少的团队仍可以通过利用 Azure 托管的加载项和群集自动升级等功能成功操作自己的群集，以减少运营开销。

  • 应使用“容器应用”托管具有共享安全边界的单一工作负载。 容器应用具有称为“容器应用环境”的单一顶级逻辑边界，该边界同时充当增强的安全边界。 没有用于其他精细访问控制的机制。 例如，环境内部通信不受限制，所有应用程序共享单一 Log Analytics 工作区。

    如果工作负载具有多个组件和多个安全边界，部署多个容器应用环境，或考虑改用 AKS。

  • “用于容器的 Web 应用”是应用服务的功能。 应用服务将应用程序分组到称为“应用服务计划”的计费边界中。 由于可以在应用程序级别下限定基于角色的访问控制 (RBAC)，因此在单一计划中托管多个工作负载可能很诱人。 但是，我们建议每个计划托管一个工作负载，以免出现近邻干扰问题。 单一应用服务计划中的所有应用共享相同的分配计算、内存和存储。

    考虑硬件隔离时，需要注意，应用服务计划通常在与其他 Azure 客户共享的基础结构上运行。 可以为专用虚拟机选择专用层，也可以为专用虚拟网络中的专用虚拟机选择独立层。

通常，所有 Azure 容器服务都可以托管多个具有多个组件的应用程序。 但是，容器应用和用于容器的 Web 应用更适合单一工作负载组件或多个高度相关的工作负载组件，这些组件共享单个团队拥有并运行应用程序的类似生命周期。

如果需要在一台主机上托管可能无关的独立应用程序组件或工作负荷，请考虑使用 AKS。

权衡控制与易用性

AKS 的可配置性最高，但与其他服务相比，这种可配置性会增加操作开销。 尽管容器应用和用于容器的 Web 应用是 Microsoft 托管功能级别类似的 PaaS 服务，但用于容器的 Web 应用侧重简单性，以满足其目标受众：即觉得界面很熟悉的现有 Azure PaaS 客户。

经验法则

通常，可提高简单性的服务往往适合倾向于增加对功能开发的关注、减少对基础结构的关注的客户。 可提供更多控制的服务往往适合需要提高可配置性且拥有管理自己的基础结构所需的技能、资源和业务理由的客户。

所有工作负载共享的注意事项

尽管工作负载团队可能更喜欢特定的服务模式，但该模式可能不符合整个组织的要求。 例如，开发人员可能更希望减少操作开销，但安全团队可能会将此类开销视为满足合规性要求的必需开销。 团队需要协作才能做出适当的权衡。

注意，共享注意事项很广泛。 可能只有一部分事项与你相关，具体取决于工作负载类型以及你在组织内的角色。

下表简要概述了注意事项，包括服务功能比较。 查看每个类别中的注意事项，并将其与工作负载要求进行比较。

类别 概述
网络注意事项 Azure 容器服务中的网络取决于你对简单性和可配置性的偏好。 AKS 高度可配置，可实现对网络流的广泛控制，但需要更多操作工作量。 容器应用提供 Azure 托管网络功能。 这是 AKS 和用于容器的 Web 应用的折衷方案，它专为熟悉应用服务的客户定制。

关键是，网络设计决策可能会产生长期后果，因为面临在不重新部署工作负载的情况下对其进行更改这一挑战。 在这些服务之间，多个因素有所不同，例如 IP 地址规划、负载均衡职责、服务发现方法和专用网络功能。 应仔细查看服务如何满足特定的网络要求。
安全注意事项 容器应用、AKS 和用于容器的 Web 应用均提供与 Azure Key Vault 和托管标识等关键 Azure 安全产品/服务的集成。 AKS 提供运行时威胁防护和网络策略等其他功能。 尽管容器应用等 PaaS 服务提供的安全功能较少，但部分原因是更多的底层基础结构组件由 Azure 托管，不会向客户公开，从而降低风险。
运行考虑事项 尽管 AKS 可实现的自定义级别最高，但它需要的操作输入更高。 相比之下，容器应用和用于容器的 Web 应用等 PaaS 解决方案允许 Azure 处理操作系统更新等任务。 可伸缩性和硬件 SKU 灵活性至关重要。 AKS 提供灵活的硬件选项，而容器应用和用于容器的 Web 应用提供集合配置。 客户仅负责 AKS 中的应用程序可伸缩性。 容器应用和用于容器的 Web 应用提供了更简化的方法。
可靠性注意事项 用于容器的 Web 应用和容器应用运行状况探测配置比 AKS 配置更精简，因为它们使用熟悉的 Azure Resource Manager API。 AKS 需要使用 Kubernetes API。 它还要求你承担管理 Kubernetes 节点池可伸缩性和可用性的额外责任，以正确安排应用程序实例。 这些要求会导致 AKS 产生额外开销。

此外，与 AKS 相比，容器应用和用于容器的 Web 应用的 SLA 更为简单，因为 AKS 的控制平面和节点池都具有自己的 SLA，需要相应地进行复合。 所有服务在其所在的数据中心中提供区域冗余。

查看上述注意事项后，可能仍未找到最适合的产品。 这很正常。

权衡利弊

选择云服务并不是一个简单的练习。 鉴于云计算的复杂性，许多团队之间的协作以及涉及人员、预算和时间的资源约束，所有解决方案都有利弊。

请注意，对于任何给定工作负载，某些要求可能比其他要求更重要。 例如，应用程序团队可能更喜欢容器应用等 PaaS 解决方案，但之所以选择 AKS 是因为其安全团队要求在并置工作负载组件之间使用“默认拒绝”网络控制，这是使用 Kubernetes 网络策略的仅 AKS 功能。

最后，请注意，前面的共享注意事项包含最常见的要求，但并不全面。 工作负载团队负责在确认决策之前调查针对首选服务功能集的所有要求。

结束语

本指南介绍了选择 Azure 容器服务时面临的最常见注意事项。 该指南旨在指导工作负载团队做出合理的决定。 按照流程，首先选择云服务模式，这涉及到确定所需的控制级别。 提高控制级别就会降低易用性。 换句话说，这是查找自托管基础结构与 Microsoft 托管基础结构之间的适当折衷方案的过程。

许多工作负载团队只能根据首选服务模式选择 Azure 容器服务：PaaS 与 IaaS。 其他团队需要进一步调查，才能确定特定于服务的功能如何满足工作负载或组织要求。

所有工作负载团队都应使用本指南，同时纳入尽职调查以避免难以扭转的决策。 但是，请注意，在开发人员尝试服务并根据经验而不是理论做出决定之前，不会确认该决定。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

其他参与者：

下一步

详细了解本文中提及的服务的共享体系结构注意事项。

共享体系结构注意事项