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

选择 Azure 容器服务时的常规体系结构注意事项

  • 项目

本文将指导你完成选择 Azure 容器服务过程。 它概述了某些工作负载的常见和关键功能级别注意事项。 它可以帮助你做出决策，确保工作负载满足可靠性、安全性、成本优化、卓越运营和性能效率的要求。

注意

本文是系列的第二部分，从选择 Azure 容器服务开始。 强烈建议先阅读该概述文章，以获取有关这些体系结构注意事项的上下文。

概述

本文中的注意事项分为四类：

体系结构和网络注意事项

  • 操作系统支持
  • 网络地址空间
  • 了解流量流
  • 规划子网
  • 可用入口 IP 数
  • 用户定义的路由和 NAT 网关支持
  • 专用网络集成
  • 协议覆盖范围
  • 负载均衡
  • 服务发现
  • 自定义域和托管 TLS
  • 相互 TLS
  • 特定 Azure 服务的网络概念

安全注意事项

  • 使用网络策略为群集内流量提供安全性
  • 网络安全组
  • Azure 密钥保管库集成
  • 托管标识支持
  • Defender for Containers 威胁防护和漏洞评估
  • 安全基线
  • 适用于安全性的 Azure 架构良好的框架

运行考虑事项

  • 更新和修补程序
  • 容器映像更新
  • 纵向基础结构可伸缩性
  • 横向基础结构可伸缩性
  • 应用程序可伸缩性
  • 可观察性
  • 适用于卓越运营的架构良好的框架

可靠性注意事项

  • 服务级别协议
  • 通过可用性区域实现的冗余
  • 运行状况检查和自我修复
  • 零停机时间应用程序部署
  • 资源限制
  • 适用于可靠性的架构良好的框架

请注意，本文重点介绍一部分 Azure 容器服务，这些服务为 Web 应用程序和 API、网络、可观测性、开发人员工具和操作提供成熟的功能集：Azure Kubernetes 服务 (AKS)、Azure 容器应用和用于容器的 Web 应用。 有关所有 Azure 容器服务的完整列表，请参阅容器服务产品类别页面。

注意

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

体系结构注意事项

本部分介绍在没有长时间停机或重新部署的情况下难以撤消或更正的体系结构决策。 对于网络和安全等基本组件，尤其需要主要这一事项。

这些注意事项并不特定于架构良好的框架支柱。 但是，在选择 Azure 容器服务时，需要根据业务要求对这些事项进行额外的审查和评估。

操作系统支持

大多数容器化应用程序在 Linux 容器中运行，所有 Azure 容器服务都支持这些容器化应用程序。 对于需要 Windows 容器的工作负载组件，可选择的选项更加有限。

容器应用 AKS 用于容器的 Web 应用
Linux 支持 ✅ ✅ ✅
Windows 支持 ❌ ✅ ✅
混合操作系统支持 ❌ ✅ ❌*

*对用于容器的 Web 应用的混合操作系统支持需要适用于 Windows 和 Linux 的单独 Azure 应用程序服务计划。

网络注意事项

受安全性和符合性约束和施加的准则限制，必须在计划过程早期了解网络设计。 一般而言，本指南所涵盖 Azure 服务之间的主要差异取决于个人偏好：

  • 容器应用是 PaaS 产品/服务，可提供许多 Azure 托管的网络功能，例如服务发现和内部托管域。 在考虑用于将网络选项最大化的替代方案之前，需要更多一些可配置性的工作负荷团队可以使用工作负荷/专用配置文件。
  • AKS 是三个服务中可配置性最高的服务，可实现对网络流的最大控制。 例如，它提供自定义入口控制器并通过 Kubernetes 网络策略控制群集内流量。 工作负荷团队可利用各种 Azure 托管网络加载项，并可安装和操作来自更广泛 Kubernetes 生态系统的任意加载项。
  • 用于容器的 Web 应用是应用程序服务的一项功能。 因此，这些网络概念（尤其是专用网络集成）高度特定于应用程序服务。 已使用应用程序服务的工作负载团队很熟悉该服务。 建议没有用过应用程序服务以及想要更熟悉的 Azure 虚拟网络集成的团队考虑使用容器应用。

切记，网络是基本的基础结构层。 通常在不重新部署工作负载的情况下很难对设计进行更改，重新部署可能会导致停机时间。 因此，如果工作负载具有特定的网络要求，请在缩小 Azure 容器服务选择范围之前仔细查看本部分。

网络地址空间

将应用程序集成到虚拟网络中时，需要执行一些 IP 地址规划，以确保有足够的 IP 地址可用于容器实例。 在此过程中，计划其他地址以用于更新、蓝/绿部署以及部署额外实例（这会消耗其他 IP 地址）的类似情况。

容器应用 AKS 用于容器的 Web 应用
专用子网 消耗计划：可选
专用计划：必需		 必须 可选
IP 地址要求 消耗计划：请参阅仅消耗环境。
专用计划：请参阅工作负载配置文件环境。		 请参阅适用于 AKS 的 Azure 虚拟网络。 请参阅应用程序服务子网要求。

请注意，AKS 要求取决于所选的网络插件。 适用于 AKS 的某些网络插件需要更广泛的 IP 保留。 本文在此不做详述。 有关详细信息，请参阅适用于 AKS 的网络概念。

了解流量流

解决方案所需的流量流类型可能会影响网络设计。

以下几部分提供有关不同网络约束的信息。 这些约束会影响部署其他子网的需求，具体取决于是否需要以下各项：

  • 多个并置工作负载。
  • 专用和/或公共入口。
  • 群集（适用于容器应用和 AKS）或虚拟网络（适用于所有 Azure 容器服务）中的东-西流量的访问控制流。

子网规划

确保你所具有的子网大小足以包含工作负载的应用程序实例，但这不是决定部署这些应用程序的网络占用情况的唯一因素。

容器应用 AKS 用于容器的 Web 应用
支持子网中的并置工作负载* ❌* ✅ N/A*

*这描述了最佳做法，而不是技术限制。

对于容器应用，子网集成仅适用于单一容器应用环境。 所有容器应用环境都限制为单一入口 IP（公共或专用）。

每个容器应用环境仅适用于并置相关应用程序的单一工作负载。 因此，如果需要公共入口和专用入口，则需要引入额外的 Azure 网络设备来实现入口负载均衡。 例如，Azure 应用程序网关和 Azure Front Door。 此外，如果有多个需要隔离的工作负载，则需要其他容器应用环境，因此必须为每个环境分配额外的子网。

AKS 以 Kubernetes 网络策略的形式在群集中实现精细的东-西网络流控制。 此流控制使你能够在同一集群内使用不同的网络安全边界对多个工作负荷进行分段。

对于用于容器的 Web 应用，只要子网足够大，就可以将所需数量的应用与单一子网相集成。 对于同一虚拟网络中的 Web 应用之间的访问控制，没有相应的最佳做法。 每个 Web 应用独立管理分别来自虚拟网络或互联网的东-西或北-南流量访问控制。

注意

无法调整在其中部署资源的子网的大小。 计划网络时请格外小心，以免需要重新部署整个工作负载组件，这可能会导致停机。

可用入口 IP 数

下表考虑了先前的子网规划部分，以定义可针对在 Azure 容器服务单一部署中托管的任意数量应用程序公开的 IP 数量。

容器应用 AKS 用于容器的 Web 应用
入口 IP 数 一个 很多 应用程序服务环境：一个
无应用程序服务环境：多个

容器应用允许每个环境一个 IP（公共或专用）。 AKS 允许任意数量的 IP（公共或专用）。 应用程序服务环境之外的用于容器的 Web 应用允许将一个公共 IP 用于应用程序服务计划内的所有应用使用，以及多个不同专用 IP 使用 Azure 专用终结点。

值得注意的是，集成到应用程序服务环境中的 Web 应用仅通过与应用程序服务环境相关的单一入口 IP（无论是公共还是专用 IP）接收流量。

用户定义的路由和 NAT 网关支持

如果工作负荷需要用户定义的路由 (UDR) 和 NAT 网关功能来进行精细的网络控制，则容器应用需要使用工作负荷配置文件。 UDR 和 NAT 网关兼容性在 ACA 的仅消耗计划中不可用。

AKS 和用于容器的 Web 应用分别通过标准虚拟网络功能或虚拟网络集成实现这两种网络功能。 具体而言，应用程序服务环境中的 AKS 节点池和用于容器的 Web 应用已经是直接虚拟网络资源。 不在应用程序服务环境中的用于容器的 Web 应用通过虚拟网络集成支持 UDR 和 NAT 网关。 通过虚拟网络集成，资源严格来说并不直接驻留在虚拟网络中，但其所有出站访问都流经虚拟网络，并且网络的相关规则会按预期影响流量。

容器应用 AKS 用于容器的 Web 应用
UDR 支持 仅消耗计划：❌
工作负荷配置文件计划：✅		 ✅ ✅
NAT 网关支持 仅消耗计划：❌
工作负荷配置文件计划：✅		 ✅ ✅

专用网络集成

对于需要严格第 4 层专用入口和出口网络的工作负载，应考虑容器应用、AKS 和单租户应用程序服务环境 SKU，其中工作负载部署到自托管虚拟网络中，从而提供自定义精细专用网络控制。

容器应用 AKS 用于容器的 Web 应用
虚拟网络的专用入口 ✅ ✅ 通过专用终结点
虚拟网络的专用出口 ✅ ✅ 通过虚拟网络集成
完全抑制的公共终结点 ✅ ✅ 仅应用程序服务环境
用于容器的 Web 应用专用网络

用于容器的 Web 应用提供的其他网络功能与本文所述的其他 Azure 服务的呈现方式不同。 要实施严格的专用网络要求，工作负载团队需要熟悉这些网络概念。 仔细查看以下网络功能：

如果想要 PaaS 解决方案并且首选跨多个 Azure 解决方案共享的网络概念，应考虑容器应用。

协议覆盖范围

对于托管平台，必须考虑传入应用程序请求（入口）支持的网络协议。 用于容器的 Web 应用是最严格的选项，仅支持 HTTP 和 HTTPS。 容器应用还允许传入的 TCP 连接。 AKS 的灵活性最高，支持在自选端口上不受约束地使用 TCP 和 UDP。

容器应用 AKS 用于容器的 Web 应用
协议和端口支持 HTTP（端口 80）*
HTTPS（端口 443）*
TCP（端口 1-65535，80 和 443 除外）		 TCP（任意端口）
UDP（任意端口）		 HTTP（端口 80）
HTTPS（端口 443）
WebSocket 支持 ✅ ✅ ✅
HTTP/2 支持 ✅ ✅ ✅

*在容器应用环境中，可以在任何端口上公开 HTTP/S，以进行群集内部通信。 在这种情况下，CORS 和会话亲和性等内置容器应用 HTTP 功能不适用。

容器应用和用于容器的 Web 应用均支持将 TLS 1.2 用于其内置 HTTPS 入口。

负载均衡

Azure 使用容器应用和用于容器的 Web 应用完全抽象化第 4 层和第 7 层负载均衡器。

相较之下，AKS 使用共担责任模型，其中 Azure 会通过连接 Kubernetes API 来管理工作负荷团队配置的底层 Azure 基础结构。 对于 AKS 中的第 7 层负载平衡，你可以选择 Azure 托管选项，例如 AKS 托管应用程序路由加载项或容器应用程序网关，或者部署和自行管理你选择的入口控制器。

容器应用 AKS 用于容器的 Web 应用
第 4 层负载均衡器 Azure 托管 共担责任 Azure 托管
第 7 层负载均衡器 Azure 托管 共享或自托管 Azure 托管

服务发现

在云体系结构中，可以随时移除并重新创建运行时以再平衡资源，因此实例 IP 地址会定期更改。 这些体系结构使用完全限定的域名 (FQDN) 进行可靠且一致的通信。

容器应用 AKS 用于容器的 Web 应用
服务发现 Azure 托管的 FQDN Kubernetes 可配置 Azure 托管的 FQDN

用于容器的 Web 应用提供现成的公共入口（北-南通信）FQDN。 无需额外配置 DNS。 但是，没有内置机制来辅助或限制其他应用之间的流量（东-西通信）。

容器应用还提供公共入口 FQDN。 但是，容器应用还会进一步允许公开应用 FQDN 并限制仅环境内流量。 借助此功能，可以更轻松地管理东-西通信并支持 Dapr 等组件。

最初无法在集群内部或外部发现 Kubernetes 部署。 你必须创建 Kubernetes API 定义的 Kubernetes 服务，然后，这些服务会以可寻址的方式将应用程序公开到网络。

重要

只有容器应用和 AKS 在其各自的环境中通过内部 DNS 方案提供服务发现。 此功能可以简化跨开发/测试和生产环境的 DNS 配置。 例如，可以使用只需在环境或群集中具唯一性的任意服务名称创建这些环境，以跨开发/测试和生产环境统一。 对于用于容器的 Web 应用，服务名称必须跨不同环境具唯一性，以免与 Azure DNS 冲突。

自定义域和托管 TLS

容器应用和用于容器的 Web 应用均提供现成的解决方案，用于进行自定义域和证书管理。

容器应用 AKS 用于容器的 Web 应用
配置自定义域 即开即用 BYO 即开即用
适用于 Azure FQDN 的托管 TLS 即开即用 空值 即开即用
适用于自定义域的托管 TLS 预览版 BYO 现成或 BYO

AKS 用户负责管理其自定义域的 DNS、群集配置和 TLS 证书。 虽然 AKS 不提供托管 TLS，但客户可利用来自 Kubernetes 生态系统的软件，例如使用常用的证书管理器来管理 TLS 证书。

相互 TLS

要限制传入流量，另一种替代方法是相互 TLS (mTLS)。 双向 TLS 是一种安全协议，它可确保通信中的客户端和服务器均会经过身份验证。 为了完成身份验证，双方会在传输任何数据之前交换和验证证书。

用于容器的 Web 应用内置对传入客户端连接的 mTLS 支持。 但是，应用程序需要通过访问应用程序服务平台转发的 X-ARR-ClientCert HTTP 头来验证证书。

容器应用同时内置对 mTLS 的支持。 它将客户端证书转发到 HTTP 头 X-Forwarded-Client-Cert 中的应用程序。还可以轻松针对单一环境中应用之间的内部通信启用自动 mTLS。

AKS 中的相互 TLS 可通过基于 Istio 的服务网格作为托管加载项来实现，其中包括用于传入客户端连接和服务之间群集内通信的 mTLS 功能。 工作负荷团队还可以选择从 Kubernetes 生态系统安装和管理另一个服务网格产品/服务。 这些选项可使 Kubernetes 中的 mTLS 实现最为灵活。

特定于服务的网络概念

前面几部分介绍了需要考虑的一些最常见注意事项。 有关更多详细信息，并详细了解特定于各个 Azure 容器服务的网络功能，请参阅以下文章：

前面几部分侧重于网络设计。 继续学习下一部分，详细了解网络安全和确保网络流量安全。

安全注意事项

未能解决安全风险可能会导致未经授权的访问、数据泄露或敏感信息泄露。 容器可为应用程序提供封装环境。 但是，托管系统和基础网络覆盖需要额外的防护措施。 所选的 Azure 容器服务需要支持对每个应用程序进行单独保护的特定要求，并提供适当的安全措施，以防未经授权的访问并降低攻击风险。

安全比较概述

包括容器应用、AKS 和用于容器的 Web 应用在内的大多数 Azure 均与 Key Vault 和托管标识等关键安全产品/服务相集成。

对于本指南中的服务，AKS 可通过显示基础组件（通常可通过配置选项进行保护）来提供最高的可配置性和可扩展性。 例如，客户可禁用 Kubernetes API 服务器的本地帐户，或时通过配置选项来启用对基础节点的自动更新。

有关详细比较，请仔细查看以下注意事项，以确保满足工作负载安全要求。

Kubernetes 控制平面安全性

AKS 是本文所述的三个选项中灵活性最高的选项，可提供对 Kubernetes API 的完全访问权限，以自定义容器业务流程协调。 但是，对 Kubernetes API 的此访问权限也是一个重要的攻击面，需要确保其安全。

重要

请注意，本部分与使用 Azure Resource Manager API 作为其控制平面的用于容器的 Web 应用无关。

基于身份的安全性

客户负责确保对 API 的基于身份的访问权限安全。 Kubernetes 提供现成的身份验证和授权管理系统，这也需要通过访问控制进行保护。

要利用统一的管理平台进行 Azure 上的身份和访问管理，最佳做法是禁用特定于 Kubernetes 的本地帐户，改为实施 AKS 托管的 Microsoft Entra 集成以及适用于 Kubernetes 的 Azure RBAC。 如果实施此最佳做法，管理员无需在多个平台上执行身份和访问管理。

容器应用 AKS
Kubernetes API 访问控制 无访问权限 完全访问权限

使用容器应用的客户无权访问 Kubernetes API。 Microsoft 可确保此 API 安全。

基于网络的安全性

如果要限制对 Kubernetes 控制平面的网络访问权限，则需要使用 AKS，它提供两个选项。 第一个选项是使用专用 AKS 群集，该群集在 API 服务器的专用网络与 AKS 群集的专用网络之间使用 Azure 专用链接。 第二个选项是 API 服务器 VNet 集成（预览版），其中 API 服务器集成到委派的子网中。 有关详细信息，请参阅相应的文档。

实施对 Kubernetes API 的网络受限访问会产生后果。 最值得注意的是，只能从专用网络内部执行管理。 通常，这意味着你需要为 Azure DevOps 或 GitHub Actions 部署自托管代理。 要了解其他限制，请参阅产品特定文档。

容器应用 AKS
Kubernetes API 网络安全 在 PaaS 中不可配置 可配置：公共 IP 或专用 IP

这些注意事项不适用于容器应用。 由于它是 PaaS，Microsoft 会抽象化底层基础结构。

数据平面网络安全

以下网络功能可用于控制对工作负载的访问权限、工作负载访问权限以及工作负载内部访问权限。

使用网络策略确保群集内流量安全

某些安全状况需要在环境内进行网络流量隔离，例如，使用多组织环境托管多个或多层应用程序时。 在这些应用场景中，应选择 AKS 并实施网络策略，即支持精细配置 Kubernetes 群集内的第 4 层网络的云原生技术。

容器应用 AKS 用于容器的 Web 应用
网络策略 消耗计划：❌
专用计划：❌		 ✅ ❌

在本文中所述的三个 Azure 服务中，只有 AKS 支持在群集中进一步隔离工作负载。 容器应用或用于容器的 Web 应用不支持网络策略。

网络安全组

在任何应用场景中，都可以使用网络安全组来调节更广泛虚拟网络中的网络通信，以使用第 4 层流量规则在虚拟网络级别下调节入口和出口。

容器应用 AKS 用于容器的 Web 应用
网络安全组 消耗计划：✅
专用计划：✅		 ✅ ✅ VNet 集成的应用：仅出口

针对入口的 IP 限制

通常，网络流量限制会通过上述第 4 层规则进行应用。 但是，在缺少虚拟网络集成的应用程序的 PaaS 场景中，对应用程序层上的流量进行限制则可能非常有用。

容器应用和用于容器的 Web 应用会为单个应用程序的入口流量提供内置源 IP 限制。

容器应用 AKS 用于容器的 Web 应用
应用程序层的入口 IP 限制 即开即用 自管理或通过托管加载项 即开即用
资源消耗 - 使用群集资源 -

对于 AKS 工作负荷，实现取决于所选入口控制器。 自管理与 Azure 托管的应用程序路由加载项均会使用群集资源。

应用程序级安全性

不仅需要在网络和基础结构级别下确保工作负载安全，还需要保护工作负载和应用程序级别下确保安全。 Azure 容器解决方案与 Azure 安全产品/服务相集成，有助于标准化应用程序的安全实施和控制。

密钥保管库集成

最佳做法是在密钥保管库等密钥管理解决方案中存储和管理机密、密钥和证书，以增强这些组件的安全性。 所有应用程序都应与密钥保管库相集成，而不是在代码或 Azure 计算服务中存储和配置机密。

应用程序开发人员可借助密钥保管库集成专注于开发自己的应用程序代码。 本文中所述的所有三个 Azure 容器服务都可以自动从密钥保管库服务同步机密并将其提供给应用程序，通常以环境变量或装载文件的形式。

容器应用 AKS 用于容器的 Web 应用
密钥保管库集成 ✅ ✅ ✅

有关详细信息，请参阅：

托管标识支持

具有已分配托管标识的应用程序无需密码即可访问 Azure 资源。 本指南中提及的所有容器服务均支持托管标识。

容器应用 AKS 用于容器的 Web 应用
托管标识支持 ✅ ✅ ✅

有关详细信息，请参阅：

Defender for Containers 威胁防护和漏洞评估

针对漏洞的威胁防护同样很重要。 最佳做法是使用 Defender for Containers。 Azure 容器注册表支持漏洞评估，因此，所有 Azure 容器服务都可以使用这些评估，而不仅仅是本文中所述的服务。 但是，Defender for Containers 运行时保护仅适用于 AKS。

当 AKS 公开本机 Kubernetes API 时，还可使用来自 Kubernetes 生态系统的特定于 Kubernetes 的安全工具来评估群集安全性。

容器应用 AKS 用于容器的 Web 应用
运行时威胁防护 ❌ ✅ ❌

有关详细信息，请参阅 Defender for Cloud 中的容器支持矩阵。

请注意，容器映像漏洞评估不是实时扫描。 会定期对 Azure 容器注册表进行扫描。

安全基线

通常，大多数 Azure 容器服务都集成了 Azure 安全产品/服务。 总而言之，切记，安全功能集只是实施云安全的一小部分。 有关实施容器服务安全性的详细信息，请参阅以下服务特定安全基线：

安全基线涵盖其他 Azure 集成，包括硬件加密和日志记录，本文不包含这些信息。

适用于安全性的架构良好的框架

本文重点介绍此处所述的容器服务功能之间的主要差异。

有关 AKS 的更完整安全指南，请参阅架构良好的框架评审 - AKS。

运行考虑事项

要成功运行生产工作负载，团队需要实施卓越运营做法，包括集中化日志记录、监视、可伸缩性、定期更新和修补以及映像管理。

更新和修补程序

必须更新并定期修补应用程序的基础 OS。 但是，切记，每次更新都有失败的风险。 本部分和下一部分介绍有关三个容器服务在客户与平台共担责任方面的主要注意事项。

作为托管 Kubernetes 服务，AKS 将为节点 OS 和控制平面组件提供更新的映像。 但是，工作负荷团队需负责对其群集应用更新。 可手动触发更新或利用群集自动升级通道功能来确保群集处于最新状态。 请参阅 AKS 第 2 天操作指南，了解如何修补和升级 AKS 群集。

容器应用和用于容器的 Web 应用是 PaaS 解决方案。 Azure 负责管理更新和修补程序，因此客户可以避免复杂的 AKS 升级管理。

容器应用 AKS 用于容器的 Web 应用
控制平面更新 平台 客户 平台
主机更新和修补程序 平台 客户 平台
容器映像更新和修补程序 客户 客户 客户

容器映像更新

无论 Azure 容器解决方案为何，始终由客户自行负责容器映像。 如果存在容器基础映像的安全修补程序，则由你负责重新生成映像。 要获取有关这些漏洞的警报，请对容器注册表中托管的容器使用 Defender for Containers。

伸缩性

缩放用于调整资源容量以满足需求，增加更多容量以确保性能，删除未使用的容量以节省资金。 选择容器解决方案时，需要考虑基础结构约束和缩放策略。

纵向基础结构可伸缩性

纵向缩放指增加或减少现有基础结构（即计算 CPU 和内存）的能力。 不同的工作负载需要不同的计算资源量。 选择 Azure 容器解决方案时，需要了解可用于特定 Azure 服务的硬件 SKU 产品/服务。 它们会有所不同，并且可能会施加其他约束。

对于 AKS，请查看 Azure 中虚拟机的大小文档以及每个区域的 AKS 限制。

以下文章详述了适用于其他两项服务的 SKU 产品/服务：

横向基础结构可伸缩性

横向缩放指通过新基础结构（如虚拟机节点）来增加或减少容量的能力。 在缩放增加或减少期间，容器应用消耗层会抽象化基础虚拟机。 对于剩余 Azure 容器服务，可以使用标准 Azure Resource Manager API 管理横向缩放策略。

请注意，横向扩展和缩减包括实例的重新均衡，因此也会造成停机的风险。 该风险低于纵向缩放对应的风险。 不过，工作负载团队始终负责确保其应用程序能够处理故障，以及实施应用程序的正常启动和关闭，以免停机。

容器应用 AKS 用于容器的 Web 应用
基础结构横向缩减和横向扩展 消耗计划：N/A
专用计划：可配置		 可配置 可配置性
灵活的硬件预配 消耗计划：N/A
专用计划：使用工作负载配置文件抽象化		 任何虚拟机 SKU 已抽象化。 请参阅应用程序服务计划。

重要

容器应用专用计划（工作负载配置文件）和用于容器的 Web 应用（应用程序服务计划）提供的硬件预配选项的灵活性不如 AKS。 你需要熟悉每个服务中的可用 SKU，以确保满足你的需求。

应用程序可伸缩性

触发基础结构和应用程序缩放的典型度量是资源消耗：CPU 和内存。 某些容器解决方案可以使用 HTTP 请求等应用程序特定上下文根据指标缩放容器实例计数。 例如，AKS 和容器应用可以根据消息队列（通过 KEDA）和许多其他指标（通过缩放器）缩放容器实例。 这些功能支持你灵活地为应用程序选择可伸缩性策略。 用于容器的 Web 应用依赖于 Azure 提供的可伸缩性选项。 （请参阅下表。）用于容器的 Web 应用不支持自定义缩放器配置，如 KEDA。

容器应用 AKS 用于容器的 Web 应用
容器横向扩展 HTTP、TCP 或基于指标（CPU、内存、事件驱动）。 基于指标（CPU、内存或自定义）。 手动、基于指标或自动（预览版）。
事件驱动可伸缩性 是的。 云原生。 是的。 云原生。 需要进行其他配置。 是的。 特定于 Azure 资源。

可观察性

工作负载检测

收集针对复杂或多层应用程序的指标可能很困难。 要获取指标，可通过两种方式将容器化工作负载与 Azure Monitor 集成：

  • 自动检测。 无需更改代码。
  • 手动检测。 集成和配置 SDK 和/或客户端所需的最少代码更改。
容器应用 AKS 用于容器的 Web 应用
通过平台自动检测 ❌ ❌ 部分支持*
通过代理自动检测 ❌ 部分支持* 空值
手动检测 通过 SDK 或 OpenTelemetry 通过 SDK 或 OpenTelemetry 通过 SDK 或 OpenTelemetry

*AKS 和用于容器的 Web 应用支持自动检测 Linux 和 Windows 工作负载的某些配置，具体取决于应用程序语言。 有关详细信息，请参阅以下文章：

应用程序代码中的检测由应用程序开发人员负责，因此独立于任何 Azure 容器解决方案。 工作负载可以使用诸多解决方案，如下所示：

日志

所有 Azure 容器服务都提供应用程序和平台日志功能。 应用程序日志是工作负载生成的控制台日志。 平台日志捕获在平台级别下应用程序范围之外发生的事件，例如缩放和部署。

容器服务的日志记录功能的主要区别与平台日志记录有关：记录的内容以及日志内部组织方式。 Azure Monitor 是 Azure 中与这些服务集成的主要日志记录服务。 监视器使用资源日志对来自不同源的日志进行分类。 要确定每个 Azure 服务提供的日志，一种方法是查看每个服务的可用资源日志类别。

容器应用 AKS 用于容器的 Web 应用
支持日志流式处理（实时流式处理） ✅ ✅ ✅
支持 Azure Monitor ✅ ✅ ✅
Azure Monitor 资源日志 控制台和系统 Kubernetes API 服务器、审核、计划程序、群集自动缩放程序等 ConsoleLogs、HTTPLogs、EnvironmentPlatformLogs 等

有关表中每个资源日志的详细说明，请选择表中的链接。

下面是容器服务的日志记录功能的简短摘要：

  • 容器应用将所有内部 Kubernetes 日志概括为两个简单的类别。 名为控制台日志的类别包含工作负载容器日志。 第二个系统类别包含所有与平台相关的日志。
  • AKS 提供与 Kubernetes 相关的所有日志，并对可记录内容进行精细控制。 它还与 Kubernetes 客户端工具保持完全兼容性，以进行日志流式处理，例如 kubectl。
  • 用于容器的 Web 应用提供了许多资源日志类别，因为其平台（应用程序服务）并非专用于容器工作负载。 对于管理其内部 Docker 平台的容器特定操作，它提供 AppServicePlatformLogs 日志类别。 另一个重要类别是 AppServiceEnvironmentPlatformLogs，用于记录缩放和配置更改等事件。

适用于卓越运营的架构良好的框架

本文重点介绍此处所述的容器服务功能之间的主要差异。 请参阅以下文章，查看以下服务的完整卓越运营指南：

可靠性

可靠性指系统从故障中恢复并继续正常运行的能力。 在应用程序软件级别下，工作负载应实施缓存、重试、断路器模式和运行状况检查等最佳做法。 在基础结构级别下，Azure 负责处理数据中心的物理故障，例如硬件故障和停电。 仍可能发生故障。 工作负载团队应选择适当的 Azure 服务层级，并应用实施可用性区域之间的自动故障转移所需的最低实例配置。

要选择适当的服务层级，需要了解服务级别协议 (SLA) 和可用性区域的工作原理。

服务级别协议

可靠性通常通过业务驱动指标（如 SLA）或恢复指标（如恢复时间目标 (RTO)）进行衡量。

Azure 具有许多适用于特定服务的 SLA。 不存在 100% 服务级别，因为软件和硬件始终有发生故障的可能，例如自然界的风暴和地震。 SLA 不是保证，而是服务可用性的财政支持协议。

有关最新 SLA 和详细信息，请从 Microsoft 许可网站下载 Microsoft Online Services 的最新 SLA 文档。

免费层与付费层

通常，Azure 服务的免费层不提供 SLA，对于非生产环境来说，是一个具有成本效益的选择。 但是，对于生产环境，建议选择具有 SLA 的付费层。

针对 AKS 的其他因素

对于不同的组件和配置，AKS 具有不同的 SLA：

  • 控制平面。 Kubernetes API 服务器具有单独的 SLA。
  • 数据平面。 节点池使用基础虚拟机 SKU SLA。
  • 可用性区域。 这两个平面的 SLA 不同，具体取决于 AKS 群集是否已启用可用性区域，并跨可用性区域运行多个实例。

请注意，使用多个 Azure 服务时，复合 SLA 可能不同于甚至低于单个服务 SLA。

可用性区域冗余

可用性区域是单个区域内具有独立电源、冷却装置等的不同数据中心。 生成的冗余会增加故障容忍度，无需实施多区域体系结构。

Azure 在 Azure 运营数据中心区域的每个国家/地区都具有可用性区域。 要允许多个容器实例跨可用性区域，请务必选择提供可用性区域支持的 SKU、服务层级和区域。

功能 容器应用 AKS 用于容器的 Web 应用
可用性区域支持 完全 完全 完全

例如，如果托管硬件的可用性区域中出现问题，配置为运行单一实例的应用程序或基础结构将变为不可用。 要完全使用可用性区域支持，应部署至少配置三个跨区域分布的容器实例的工作负载。

运行状况检查和自我修复

运行状况检查端点对于可靠的工作负载至关重要。 但是，构建这些端点只是解决方案的一部分。 另一部分是控制托管平台在发生故障时采取的操作和方式。

要更好地区分运行状况探测类型，请查看 Kubernetes 提供的内置探测类型：

  • 启动。 检查应用程序是否已成功启动。
  • 就绪情况。 检查应用程序是否准备好处理传入请求。
  • 运行情况。 检查应用程序是否仍在运行且有响应。

另一个重要考虑因素是，从应用程序请求这些运行状况检查的频率（内部粒度）。 如果这些请求的间隔较长，则可能会继续为流量提供服务，直到实例视为运行不正常。

大多数应用程序通过 HTTP(S) 协议支持运行状况检查。 但是，一些应用程序可能需要其他协议（如 TCP 或 gRPC）才能执行这些检查。 在设计运行状况检查系统时，请记住这一点。

容器应用 AKS 用于容器的 Web 应用
启动探测 ✅ ✅ 部分支持
就绪情况探测 ✅ ✅ ❌
运行情况探测 ✅ ✅ ✅
间隔粒度 秒 秒 1 分钟
协议支持 HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

运行状况检查最容易在用于容器的 Web 应用中实现。 下面是一些重要注意事项：

  • 其内置启动探测且无法更改。 它将 HTTP 请求发送到容器的起始端口。 来自应用程序的任何响应都视为成功启动。
  • 它不支持就绪情况探测。 如果启动探测成功，容器实例将添加到正常实例池中。
  • 它会以 1 分钟间隔发送运行状况检查。 该间隔无法更改。
  • 为运行不正常实例从内部负载均衡机制中移除的频率设置的最小阈值为 2 分钟。 运行不正常实例在未通过运行状况检查后的至少两分钟内还会获取流量。 此设置的默认值为 10 分钟。

另一方面，容器应用和 AKS 更灵活，并提供类似的选项。 就具体差异而言，AKS 提供以下选项来执行运行状况检查，而容器应用则不提供这些选项：

自动修复

首先是标识故障容器实例并停止向其发送流量。 下一步是实施自动修复。 自动修复指在尝试从运行不正常状态恢复时重启应用程序的过程。 下面是三个容器服务的比较情况：

  • 在用于容器的 Web 应用中，未通过运行状况检查后无法立即重启容器实例。 如果实例故障持续一小时，则系统会将其替换为新实例。 还有一项称为自动修复的功能，用于监视和重启实例。 该功能与运行状况检查不直接相关。 它会利用各种应用程序指标，例如内存限制、HTTP 请求持续时间和状态代码。
  • 如果运行情况探测达到定义的故障阈值，容器应用和 AKS 会自动尝试重启容器实例。

零停机时间应用程序部署

在部署和替换应用程序时不会导致用户停机的能力对于可靠的工作负载至关重要。 本文中所述的所有三个容器服务都支持零停机时间部署，但采用的方式不同。

容器应用 AKS 用于容器的 Web 应用
零停机时间策略 滚动更新 滚动更新以及所有其他 Kubernetes 策略 部署槽位

请注意，应用程序体系结构还须支持零停机部署。 有关指南，请参阅 Azure Well-Architected Framework。

资源限制

可靠共享环境的另一个重要组件是控制容器的资源使用情况（如 CPU 或内存）。 需要避免单一应用程序占用所有资源并使其他应用程序处于故障状态的情况。

容器应用 AKS 用于容器的 Web 应用
资源限制（CPU 或内存） 每个应用/容器 每个应用/容器
每个命名空间		 每个应用程序服务计划
  • 用于容器的 Web 应用：可以在单一应用程序服务计划中托管多个应用程序（容器）。 例如，可以分配具有两个 CPU 核心和 4 GiB RAM 的计划，可在其中运行容器中的多个 Web 应用。 但是，无法将其中一个应用限制为一定数量的 CPU 或内存。 它们都争用相同的应用程序服务计划资源。 如果要隔离应用程序资源，则需要创建其他应用程序服务计划。
  • 容器应用：可以在环境中为每个应用程序设置 CPU 和内存限制。 但是，只能设置一组允许的 CPU 和内存组合。 例如，不能配置一个 vCPU 和 1 GiB 内存，但可以配置一个 vCPU 和 2 GiB 内存。 容器应用环境类似于 Kubernetes 命名空间。
  • AKS：只要节点具有支持它的硬件，就可以选择 vCPU 和内存的任意组合。 如果要按这种方式对群集进行分段，还可以在命名空间级别下限制资源。

适用于可靠性的架构良好的框架

本文重点介绍 Azure 中容器服务功能之间的主要差异。 要查看特定服务的完整可靠性指南，请参阅以下文章：

结束语

架构良好的解决方案是工作负载成功的基础。 尽管随着工作负载增长和团队的云历程不断进步可以调整体系结构，但一些决策（尤其是关于网络的决策）在不长时间停机或重新部署的情况下很难扭转。

通常，比较 Azure 容器服务时，会出现一个主题：AKS 会呈现最底层的基础结构，从而提供最大的可配置性和可扩展性。 对于 AKS 工作负荷，操作开销和复杂性会有很大变化。 某些团队可以使用 Microsoft 托管的加载项和扩展以及自动升级功能来大幅降低运营开销。 其他客户可能更喜欢完全控制群集，以便利用 Kubernetes 和 NCF 生态系统的完全扩展性。 例如，尽管 Microsoft 以托管 GitOps 扩展的形式提供 Flux，但许多团队会选择自行设置和运行 ArgoCD。

例如，对于无需使用 CNCF 应用程序且拥有较少运营经验或更喜欢专注于应用程序功能的工作负载团队来说，PaaS 产品/服务可能是其首选。 我们建议这些团队首选考虑容器应用。

尽管容器应用和用于容器的 Web 应用都是提供类似级别 Microsoft 托管基础结构的 PaaS 产品/服务，但二者的关键区别在于容器应用更接近 Kubernetes，并为服务发现、事件驱动自动缩放、Dapr 集成等提供额外的云原生功能。 但是，对于不需要这些功能且熟悉应用程序服务网络和部署模式的团队来说，用于容器的 Web 应用可能是首选。

泛化有助于缩小要考虑的 Azure 容器服务列表范围。 但请记住，还需要通过详细检查对应要求并将其与服务特定功能集进行匹配来验证选择是否合适。

作者

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

主要作者：

其他参与者：

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

后续步骤