通过

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

选择 Azure 容器服务

Azure 提供了一系列容器托管服务，旨在满足各种工作负荷、体系结构和业务需求。 此容器服务选择指南可帮助工作负荷团队了解最适合工作负荷方案和要求的 Azure 容器服务。

注意

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

概述

本指南包含此简介文章和另一篇文章，介绍在所有工作负荷类型 之间共享的注意事项 。

注意

如果您没有采用容器化，请选择其他计算选项来托管您的工作负荷。

本介绍性文章概述了本指南中介绍的 Azure 容器服务，并基于可配置性和预定义解决方案（例如客户管理的与Microsoft托管方法）比较其服务模型。 在根据服务模型首选项确定候选服务后，下一步是通过查看有关网络、安全、操作和可靠性方面的共享注意事项的文章，来评估这些选项是否符合您的工作负载要求。

本指南可帮助你根据工作负荷的技术要求、大小和复杂性评估权衡。 它还考虑团队的专业知识，以确保明智的决策。

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

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

Azure 容器应用徽标

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

AKS 徽标

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

应用程序服务徽标

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

有关 Azure 容器服务的完整列表，请参阅 Azure 上的容器。

服务模式注意事项

服务模型可帮助你了解每个 Azure 容器服务提供的灵活性和控制程度。 复杂的服务提供更多的控制，而更简单的服务使管理更容易，但限制自定义。

有关服务模型术语和概念的详细信息，包括基础结构即服务（IaaS）和平台即服务（PaaS），请参阅 云中的共同责任。

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

Azure Kubernetes 服务 （AKS）

AKS 是 IaaS 和 PaaS 的组合，侧重于控制而不是简单性。 它使用 Kubernetes，这是用于协调容器的标准系统。 AKS 简化了底层核心基础结构的管理。 但是，此基于虚拟机（VM）的平台会向应用程序公开，需要适当的防护措施和流程（例如修补），以确保安全性和业务连续性。 在订阅中直接托管的额外 Azure 资源支持计算基础设施，例如 Azure 负载均衡器、容器注册表或应用程序网关。

AKS 提供对 Kubernetes API 服务器的访问，使你可以自定义容器业务流程并从 Cloud Native Computing Foundation 部署辅助应用程序。 因此，不熟悉 Kubernetes 的工作负荷团队面临着巨大的学习曲线。 如果不熟悉容器化解决方案，则必须考虑此学习曲线。 以下 PaaS 解决方案提供了较低的进入屏障。 当需求要求时，可以过渡到 Kubernetes。

AKS 自动版

借助 AKS 自动 ，可以通过自动执行复杂的群集管理任务，更轻松地采用 Kubernetes。 这种自动化减少了对高级 Kubernetes 专业知识的需求。 它提供更简化的 PaaS 式体验，同时保持 Kubernetes 的灵活性和可扩展性。 Azure 默认管理群集设置、节点预配、缩放、安全修补，并应用最佳做法配置。 此自动化可减少作工作量，但会限制可用的拓扑选项。

注意

本指南区分 AKS 标准版和 AKS 自动（如果适用）。 否则，可以假定所描述的功能在两种产品/服务中都是一致的。

容器应用

容器应用是 Kubernetes 之上的抽象层，它允许应用运行和缩放，而无需直接管理底层基础结构。 容器应用提供无服务器和专用计算选项。 这些选项可让你完全控制应用程序可用的计算资源的类型和数量。 容器应用抽象化容器业务流程 API，同时仍提供对第 7 层入口、流量拆分、A/B 测试和应用程序生命周期管理等关键功能的内置访问。

用于容器的 Web 应用

用于容器的 Web 应用是一种 PaaS 产品/服务，优先考虑简单性而非控制，与容器应用相比更注重简化。 它抽象化容器业务流程，同时仍支持缩放、应用程序生命周期管理、流量拆分、网络集成和可观测性。

托管模式注意事项

可以使用 AKS 群集等 Azure 资源托管多个工作负载。 此方法可帮助你简化作，从而降低总体成本。 如果选择此选项，请考虑以下功能：

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

    如果需要 Kubernetes API 提供的额外功能，并且工作负荷团队具有足够的运营 Kubernetes 群集的经验，还可以在单工作负荷方案中使用 AKS。 具有较少 Kubernetes 体验的团队仍可使用 Azure 托管 的加载项 和功能（如 群集自动升级 ）有效地管理自己的群集，以减少运营工作量。

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

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

  • 用于容器的 Web 应用是应用程序服务的功能。 应用服务将应用程序分组到名为 应用服务计划的逻辑计算边界中。 由于可以在应用程序级别限定基于角色的访问控制范围，因此可能需要在单个计划中托管多个工作负荷。 但是，最好为每个方案托管单个工作负荷，以避免邻居噪声问题。 单一应用服务计划中的所有应用共享相同的分配计算、内存和存储。

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

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

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

控制与易用性之间的权衡

AKS 提供最可配置性，但与其他服务相比，这种配置能力需要更多的作工作量。 容器应用和用于容器的 Web 应用程序都是具有 Microsoft 托管的类似功能级别的 PaaS 服务。 用于容器的 Web 应用侧重于为目标受众提供服务的简单性，即熟悉界面的现有应用服务客户。

最佳做法

提供更简单的服务通常适合专注于功能开发而不是基础结构管理的客户。 提供更多控制的服务通常适合需要可配置性且具有管理自身基础结构的技能、资源和业务理由的客户。

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

工作负荷团队可能更喜欢特定的服务模型，但该模型可能不符合组织的总体要求。 例如，开发人员可能需要更少的工作量，但安全团队可能会认为此开销对于合规性是必要的。 团队需要进行协作才能做出正确的权衡。

共享的考虑因素涵盖广泛的范围。 根据工作负荷类型，只有一部分注意事项才适用于你。 在组织中的角色也会影响哪些注意事项是相关的。

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

类别 概述
网络注意事项 Azure 容器服务中的网络取决于你喜欢的简单性或可配置性。 AKS 对网络流量提供全面控制，但需要更多的运营工作。 容器应用具有 Azure 托管的网络功能，位于用于容器的 AKS 和 Web 应用之间，后者为已使用应用服务的客户提供服务。

网络设计决策具有长期后果，因为更改它们通常需要重新部署工作负荷。 多个因素（例如 IP 地址规划、负载均衡、服务发现和专用网络）在这些服务之间有所不同。 应仔细查看每个服务如何满足特定的网络要求。
安全注意事项 用于容器的容器应用、AKS 和 Web 应用与关键的 Azure 安全产品/服务（例如 Azure Key Vault 和托管标识）集成。 AKS 提供额外的功能，如运行时威胁防护和网络策略。 容器应用等 PaaS 服务似乎具有较少的安全功能，但部分原因是 Azure 管理了更多底层基础结构组件。 由于这些组件不会向客户公开，因此风险较低。
运行考虑事项 AKS 提供了最多的自定义项，但需要更多的操作投入。

PaaS 解决方案（如容器应用和用于容器的 Web 应用）允许 Azure 处理 OS 更新等任务。 可伸缩性和硬件 SKU 灵活性非常重要。 AKS 提供灵活的硬件选项，但容器应用和用于容器的 Web 应用的选择较少。 在 AKS 中，应用程序可伸缩性是你的责任，因此你可以应用任何与 Kubernetes 兼容的解决方案。 AKS 自动、容器应用和用于容器的 Web 应用侧重于更简单的方法。
可靠性注意事项 与 AKS 相比，容器 Web 应用程序和容器应用程序的健康探测配置有限。 但是，设置起来更简单，因为它们使用熟悉的 Azure 资源管理器 API。

AKS 需要 Kubernetes API，还需要管理 Kubernetes 节点池的可伸缩性和可用性，以便正确计划应用程序实例。 这些要求增加了 AKS 的作工作量。 容器应用和用于容器的 Web 应用的服务级别协议（SLA）比 AKS SLA 更容易计算。 AKS 控制平面和节点池各有自己的 SLA，必须将它们合并考虑。 所有服务在支持区域冗余的数据中心提供该功能。

查看上述注意事项后，您可能仍未找到合适的选择，这是很常见的。

评估权衡

云计算很复杂。 它涉及跨多个团队的协作，必须考虑到人员、预算和时间方面的限制。 这些因素使得云服务的选择变得困难，并且充满了权衡。

对于任何工作负荷，某些要求可能比其他要求更重要。 例如，应用程序团队可能更喜欢 PaaS 解决方案（如 Container Apps），但选择了 AKS，因为他们的安全团队要求在并置的工作负载组件之间实施默认拒绝的网络控制策略。 此功能仅面向 AKS，并使用 Kubernetes 网络策略。

上述共享注意事项涵盖最常见的要求，但并不全面。 在做出决策之前，必须根据首选服务的功能集评估每个要求。

结束语

本指南介绍选择 Azure 容器服务时最常见的注意事项。 它旨在帮助工作负荷团队做出明智的决策。 该过程从选择云服务模型开始，这涉及到确定所需的控制级别。 控制增加是以牺牲简洁性为代价的。 换句话说，目标是在自管理基础结构与Microsoft托管基础结构之间找到正确的平衡。

许多工作负荷团队仅根据他们更喜欢 PaaS 还是 IaaS 来选择 Azure 容器服务。 其他团队需要进一步调查，才能确定特定于服务的功能如何满足工作负载或组织要求。

使用本指南仔细评估选项，避免做出难以逆转的决策。 但是，在开发人员尝试该服务并根据实际体验而不是理论对其进行评估之前，没有最终决定权。

贡献者

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

其他参与者：

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。