【Azure容器】选择Azure容器服务

Azure提供了一系列容器托管服务，旨在适应各种工作负载、架构和业务需求。此容器服务选择指南可以帮助您了解哪种Azure容器服务最适合您的工作负载场景和要求。

注：

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

如何使用本指南

本指南包括两篇文章：这篇介绍文章和另一篇关于所有工作负载类型共享的考虑因素的文章。

注：

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

这篇介绍文章描述了本指南范围内的Azure容器服务，以及服务模型如何在可配置性和有主见的解决方案之间进行权衡比较，例如客户管理与微软管理的方法。根据您的服务模型首选项确定候选服务后，下一步是通过查看关于网络、安全性、操作和可靠性的共同考虑因素的文章，根据您的工作负载要求评估选项。

本指南根据技术要求、工作量的大小和复杂性以及工作量团队的专业知识，考虑了您可能需要做出的权衡。

本指南涵盖的Azure容器服务

本指南重点介绍Azure目前提供的容器服务的一个子集。此子集为web应用程序和API、网络、可观察性、开发人员工具和操作提供了一个成熟的功能集。对这些集装箱服务进行了比较：

Azure容器应用程序是一个完全托管的基于Kubernetes的应用程序平台，可帮助您从代码或容器部署HTTP和非HTTP应用程序，而无需编排基础设施。有关更多信息，请参阅Azure容器应用文档。

Azure Kubernetes Service（AKS）是用于运行容器化应用程序的托管Kubernetes服务。使用AKS，您可以利用托管插件和扩展来获得更多功能，同时保持最广泛的可配置性。有关更多信息，请参阅AKS文档。

Web App for Containers是Azure App Service的一项功能，Azure App Service是一种完全托管的服务，用于托管基于HTTP的Web应用程序，具有内置的基础设施维护、安全补丁、扩展和诊断工具。有关更多信息，请参阅应用服务文档。

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

服务模式考虑因素

该服务模型提供了对任何Azure容器服务提供的灵活性和控制水平的最广泛洞察，以换取其整体的简单性和易用性。

有关服务模型（包括基础设施即服务（IaaS）和平台即服务（PaaS））的术语和概念的一般介绍，请参阅云中的共享责任。

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

AKS

作为IaaS和PaaS的混合体，AKS将控制置于简单之上。尽管AKS简化了底层核心基础设施的管理，但这个基于VM的平台仍然暴露在您的应用程序中，需要适当的防护措施和流程，如补丁，以确保安全性和业务连续性。计算基础架构由直接托管在订阅中的其他Azure资源支持，如Azure负载平衡器。

AKS还提供对Kubernetes API服务器的访问，使您能够自定义容器编排，从而从云原生计算基金会（CNCF）部署项目。因此，对于刚接触Kubernetes的工作负载团队来说，学习曲线很长。如果你是容器化解决方案的新手，这种学习曲线可能会成为一种阻碍。以下PaaS解决方案提供了较低的进入门槛。当您的需求要求迁移时，您可以迁移到Kubernetes。

Azure容器应用

容器应用程序是一种PaaS产品，它平衡了控制和简单性。它提供了无服务器和专用计算选项，从而消除了相对于操作系统修补操作系统或围绕应用程序构建护栏的需要。容器应用程序还完全抽象了容器编排API，并通过您的团队可能已经熟悉的Azure API提供其关键功能的子集。此外，第7层入口、流量分流、A/B测试和应用程序生命周期管理都是现成的。

容器Web应用程序

容器Web App也是一种PaaS产品，但它比容器应用程序更简单，控制更少。它抽象了容器编排，但仍然提供了适当的扩展、应用程序生命周期管理、流量拆分、网络集成和可观察性。

托管模式考虑因素

您可以使用Azure资源（如AKS集群）来承载多个工作负载。这样做可以帮助您简化操作，从而降低整体成本。如果你选择这条路，以下是一些重要的考虑因素：

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

如果您需要Kubernetes API提供的附加功能，并且您的工作负载团队有足够的经验来操作Kubernete集群，那么您也可以在单工作负载场景中使用AKS。Kubernetes经验较少的团队仍然可以通过利用Azure管理的插件和功能（如集群自动升级）来减少运营开销，从而成功运营自己的集群。

• Container Apps 。容器应用程序应用于承载具有共享安全边界的单个工作负载。容器应用程序有一个单一的顶级逻辑边界，称为容器应用程序环境，它也可以作为增强的安全边界。没有额外的细粒度访问控制机制。例如，环境内通信不受限制，所有应用程序共享一个日志分析工作区。

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

• 容器Web App。容器Web App是App Service的一个功能。App Service将应用程序分组到称为App Service计划的计费边界中。因为您可以在应用程序级别定义基于角色的访问控制（RBAC），所以在单个计划中托管多个工作负载可能很有诱惑力。但是，我们建议您为每个计划托管一个工作负载，以避免噪音邻居问题。单个应用服务计划中的所有应用共享相同的分配计算、内存和存储。

当你考虑硬件隔离时，你需要意识到应用服务计划通常在与其他Azure客户共享的基础设施上运行。您可以为专用虚拟机选择专用层，或为专用虚拟网络中的专用VM选择隔离层。

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

如果您需要在一台主机上托管不同的、可能不相关的应用程序组件或工作负载，请考虑AKS。

控制和易用性之间的权衡

AKS提供了最多的可配置性，但与其他服务相比，这种可配置性以增加运营开销为代价。尽管Container Apps和Web App for Containers都是PaaS服务，具有类似级别的微软管理功能，但Web App for Container强调简单性，以迎合其目标受众：现有的Azure PaaS客户，他们对界面很熟悉。

经验法则

一般来说，提供更简单的服务往往适合那些更喜欢关注功能开发而较少关注基础设施的客户。提供更多控制的服务往往适合那些需要更多可配置性并拥有管理自己的基础设施所需的技能、资源和业务理由的客户。

所有工作负载的共同考虑因素

尽管工作负载团队可能更喜欢特定的服务模型，但该模型可能无法满足整个组织的要求。例如，开发人员可能更喜欢较少的操作开销，但安全团队可能会认为这种开销是满足合规要求所必需的。团队需要合作做出适当的权衡。

请注意，共同的考虑是广泛的。只有一个子集可能与您相关，这不仅取决于工作负载类型，还取决于您在组织中的角色。

下表提供了考虑因素的高级概述，包括服务功能比较。审查每个类别中的考虑因素，并将其与工作负载的要求进行比较。

在回顾了上述考虑因素后，您可能仍然没有找到完美的契合点。这完全正常。

评估权衡

选择云服务并非易事。考虑到云计算的复杂性、许多团队之间的协作以及涉及人员、预算和时间的资源限制，每个解决方案都有权衡。

请注意，对于任何给定的工作负载，某些要求可能比其他要求更重要。例如，一个应用程序团队可能更喜欢像Container Apps这样的PaaS解决方案，但选择了AKS，因为他们的安全团队要求默认情况下拒绝托管工作负载组件之间的网络控制，这是一个仅使用Kubernetes网络策略的AKS功能。

最后，请注意，前面的共同考虑因素包括最常见的要求，但并不全面。在确认决定之前，工作负载团队有责任根据首选服务的功能集调查每个需求。

结论

本指南描述了您在选择Azure容器服务时面临的最常见考虑因素。它旨在指导工作量团队做出明智的决策。该过程从选择云服务模型开始，这涉及确定所需的控制级别。控制是以牺牲简单性为代价的。换句话说，这是一个在自我管理的基础架构和微软管理的基础设施之间找到适当平衡的过程。

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

除了纳入尽职调查外，所有工作量团队还应使用本指南，以避免难以逆转的决策。然而，请注意，在开发人员尝试该服务并根据经验而非理论做出决定之前，该决定不会得到确认。