通过

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

选择 Azure 容器服务

  • 项目

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

注意

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

如何使用本指南

本指南包括两篇文章：这篇介绍文章和另一篇文章介绍了所有工作负荷类型共同的 注意事项。

注意

如果您尚未投入使用容器化，请参阅 选择 Azure 计算服务，了解可用于托管工作负荷的其他计算选项的信息。

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

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

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

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

Azure 容器应用徽标

Azure 容器应用是完全托管的平台，使用它可以运行容器化应用程序，而无需担心业务流程或基础结构。 有关详细信息，请参阅 Azure 容器应用文档。

AKS 徽标

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

应用程序服务徽标

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

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

服务模式注意事项

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

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

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

AKS

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

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

AKS 自动版

AKS Automatic 通过自动化复杂的群集管理任务来简化 Kubernetes 的采用，从而减少了对深厚 Kubernetes 专业知识的需求。 它提供更简化的 PaaS 式体验，同时保持 Kubernetes 的灵活性和可扩展性。 Azure 会处理群集设置、节点预配、缩放、安全修补，并默认应用一些最佳做法配置。 这减少了作工作量，但附带了一组受限的可用拓扑选项。

注意

本指南将区分 AKS 标准版和 AKS 自动（如果适用）。 否则，可以假定所描述的功能在标准版和自动版之间具有相同性。

Azure Container Apps

Azure 容器应用是 Kubernetes 之上的抽象层，它允许应用运行和缩放，而无需直接管理底层基础结构。 容器应用提供无服务器和专用计算选项，可完全控制应用程序可用的计算资源类型和数量。 容器应用在抽象化容器编排 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 中的应用程序可伸缩性由客户负责，这意味着可以应用任何与 Kubernetes 兼容的解决方案。 AKS 自动、容器应用和用于容器的 Web 应用侧重于更简单的方法。
可靠性注意事项 与 AKS 相比，用于容器和容器应用的 Web 应用运行状况探测配置受到限制，但设置更简单，因为它们使用熟悉的 Azure 资源管理器 API。 AKS 需要使用 Kubernetes API。 它还要求你承担管理 Kubernetes 节点池可伸缩性和可用性的额外责任，以正确安排应用程序实例。 这些要求会导致 AKS 的额外的操作工作。

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

查看上述注意事项后，您可能仍未找到理想的选择。 这很正常。

权衡利弊

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

请注意，对于任何给定工作负载，某些要求可能比其他要求更重要。 例如，应用程序团队可能更喜欢 PaaS 解决方案（如容器应用服务），但因其安全团队要求在共同部署的工作负载组件之间进行默认拒绝的网络控制，而选择了 AKS。这是一项使用 Kubernetes 网络策略的功能，仅在 AKS 中可用。

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

结束语

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

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

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

贡献者

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

主要作者：

其他参与者：

下一步

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

共享体系结构注意事项