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

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

概述

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

体系结构和网络注意事项

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

安全注意事项

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

操作考虑

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

可靠性注意事项

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

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

体系结构注意事项

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

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

操作系统支持

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

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

网络注意事项

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

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

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

网络地址空间

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

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

了解流量流

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

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

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

子网规划

确保子网足够大以容纳工作负载的应用程序实例并不是决定这些应用程序部署时网络足迹的唯一因素。

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

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

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

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

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

可用入口 IP 数

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

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

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

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

如果工作负荷需要用户定义的路由（UDR）和 NAT 网关功能来实现精细网络控制，容器应用需要使用 工作负荷配置文件。 ACA 的消费型计划不支持 UDR 和 NAT 网关的兼容性。

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

专用网络集成

对于需要对入站和出站进行严格的第 4 层网络专用连接的工作负载，您应该考虑容器应用、AKS 和单租户应用服务环境 SKU，其中工作负载部署到自行管理的虚拟网络中，提供惯常的细粒度专用网络控制。

用于容器的 Web 应用专用网络

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

• 专用终结点
• 虚拟网络集成

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

协议覆盖范围

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

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

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

负载均衡

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

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

服务发现

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

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

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

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

自定义域和托管 TLS

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

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 中，可以通过 基于 Istio 的服务网格作为托管加载项实现双向 TLS，其中包含用于入站客户端连接和服务之间的群集内通信的 mTLS 功能。 工作负荷团队还可以选择从 Kubernetes 生态系统中安装和管理另一个服务网格。 这些选项可使 Kubernetes 中的 mTLS 实现最为灵活。

特定于服务的网络概念

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

• 容器应用中的网络
• AKS 的网络概念
• 应用服务网络功能

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

安全注意事项

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

安全比较概述

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

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

AKS 自动群集附带强化的默认配置，默认启用许多群集、应用程序和网络安全设置。 这些初始配置不仅减少了部署时间，还为用户提供了预先验证的标准化配置，从而为用户提供了第 2 天运营责任的坚实基础。 此基础有助于缩短对技术不熟悉的团队的长期群集管理的学习曲线。

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

Kubernetes 控制平面安全性

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

基于身份的安全性

客户负责确保对 API 的基于身份的访问权限安全。 开箱即用的 Kubernetes 提供了其自身的身份验证和授权管理系统，同时也需要通过访问控制来确保安全。

要利用 Azure 上标识和访问管理的统一界面，最佳做法是禁用特定于 Kubernetes 的本地帐户，并改为结合实现 AKS 托管的 Microsoft Entra 集成与 Azure RBAC for Kubernetes。 如果实施此最佳做法，管理员无需在多个平台上执行身份和访问管理。

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

基于网络的安全性

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

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

这些注意事项不适用于容器应用。 因为它是 PaaS，因此 Microsoft 屏蔽了底层基础设施。

数据平面网络安全

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

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

某些安全状况需要在环境中进行网络流量隔离，例如，使用多租户环境托管多个或多层应用程序时。 在这些方案中，应选择 AKS 并实施 网络策略，这是一种云原生技术，用于在 Kubernetes 群集中精细配置第 4 层网络。

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

网络安全组

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

内置入口 IP 限制

容器应用和用于容器的 Web 应用为单个应用程序的入口流量提供内置源 IP 限制。 AKS 可以实现相同的功能，但需要 Kubernetes 本机功能，通过 Kubernetes 服务 API 资源 ，可以在其中为 loadBalancerSourceRanges 设置值。

应用程序级安全性

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

密钥保管库集成

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

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

有关详细信息，请参阅：

• 管理 Azure 容器应用中的机密
• 将 Key Vault 与 AKS 集成
• 在 Azure 应用服务中将 Key Vault 引用用作应用设置

托管标识支持

应用程序可以使用托管标识对 Microsoft Entra ID 保护的服务进行身份验证，而无需使用密钥或机密。 容器应用和用于容器的 Web 应用提供内置的 Azure 原生支持，用于应用程序级托管身份。 AKS 的应用程序级托管标识支持是通过 Entra Workload ID 完成的。 AKS 还需要与基础结构相关的托管标识，以支持 Kubelet、控制平面和各种 AKS 加载项的群集操作。

有关详细信息，请参阅：

• 在 AKS 中使用托管标识
• 使用 AKS 的 Microsoft Entra Workload ID
• Azure 容器应用中的托管标识
• 如何使用应用服务的托管标识

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

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

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

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

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

安全基线

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

• 容器应用的 Azure 安全基线
• Azure Kubernetes 服务的 Azure 安全基线
• 应用服务的 Azure 安全基线

Well-Architected 安全框架

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

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

运行考虑事项

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

更新和修补程序

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

作为托管的 Kubernetes 服务，AKS 将为节点操作系统和控制平面组件提供更新的镜像。 但是，工作负荷团队需负责对其群集应用更新。 可以手动触发更新或利用 群集自动升级通道 功能来确保群集是最新的。 请参阅 AKS 日常运维指南，了解如何对 AKS 集群进行修补和升级。

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

容器映像更新

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

伸缩性

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

纵向基础结构可伸缩性

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

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

以下文章提供有关另外两项服务的 SKU 产品的详细信息：

• 容器应用中的工作负荷特性
• 应用服务定价

横向基础结构可伸缩性

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

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

应用程序可伸缩性

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

默认情况下，AKS 自动启用水平 Pod 自动缩放程序、Kubernetes 事件驱动自动缩放（KEDA）和垂直 Pod 自动缩放程序（VPA）。

可观察性

工作负载检测

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

• 自动化仪表。 无需更改代码。
• 手动检测。 集成和配置 SDK 和/或客户端所需的最少代码更改。

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

• 自动检测支持的环境、语言和资源提供程序
• Kubernetes 的零检测应用程序监视

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

• Application Insights SDK
• OpenTelemetry 分发版

日志和指标

所有 Azure 容器服务都提供应用程序和平台日志和指标功能。 应用程序日志是由工作负荷生成的控制台日志。 平台日志捕获在应用程序范围之外的平台级别发生的事件，例如缩放和部署。 指标是数值，用于描述某个时间点系统的某些方面，使你能够监视和警报系统性能和运行状况。

Azure Monitor 是 Azure 中与这些服务集成的主要日志记录和指标服务。 Azure Monitor 使用 资源日志 将不同源的日志分为类别，并收集指标，以便深入了解资源性能。 确定每个 Azure 服务提供哪些日志和指标的一种方法是查看每个服务的资源日志类别和可用指标。

容器应用 将所有内部 Kubernetes 日志抽象化为两类：控制台日志（包含工作负荷容器日志）和包含所有平台相关日志的系统日志。 对于指标，容器应用与 Azure Monitor 集成以收集标准指标，并支持通过 Dapr 集成实现高级方案的自定义指标。

AKS 提供与 Kubernetes 相关的日志，并精细控制所记录的内容。 AKS 保留了与 Kubernetes 日志流式处理客户端工具（如 kubectl）的完全兼容性。 对于指标，AKS 与 Azure Monitor 集成以收集群集和节点指标。 可以使用 Prometheus 进行自定义指标的收集，并使用 Grafana 进行可视化，但这需要手动设置和配置。

AKS 自动 预配置了特定的监视工具。 它使用 Managed Prometheus 进行指标收集，使用 Managed Grafana 进行可视化。 会自动收集群集和应用程序指标，并可以可视化。 AKS Automatic 还与 Azure Monitor 集成，用于日志和指标收集。

用于容器的 Web 应用 提供多个类别的资源日志，因为其平台（应用服务）并非专用于容器工作负载。 对于管理其内部 Docker 平台的容器特定操作，它提供 AppServicePlatformLogs 日志类别。 另一个重要类别是 AppServiceEnvironmentPlatformLogs，用于记录缩放和配置更改等事件。 指标是通过 Azure Monitor 收集的，使你能够监视应用程序性能和资源利用率。

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

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

• AKS
• 用于容器的 Web 应用

可靠性

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

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

服务级别协议

可靠性通常由 业务驱动的指标 （如 SLA）或恢复指标（如恢复时间目标）来衡量。

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

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

免费层与付费层

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

针对 AKS 的其他因素

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

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

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

可用性区域冗余

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

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

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

运行状况检查和自我修复

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

请查看 Kubernetes 提供的内置健康探测器类型，以便更好地区分这些探测器的类型。

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

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

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

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

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

另一方面，容器应用和 AKS 更灵活，并提供类似的选项。 就具体差异而言，AKS 提供了以下用于执行健康检查的选项，而这些选项在容器应用中不可用：

• gRPC 支持
• 命名端口
• Exec 命令

自动修复

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

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

零停机时间应用程序部署

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

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

资源限制

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

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

Well-Architected 可靠性框架

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

• AKS 的架构良好框架评审
• 容器应用中的可靠性
• Azure 应用服务和可靠性

结束语

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

一般情况下，比较 Azure 容器服务时，会出现一个主题：AKS 暴露最多的底层基础设施，从而提供最大的控制和可配置性，而 AKS 自动化通过自动化许多操作任务，在控制和简易性之间提供平衡。

对于 AKS 工作负荷，操作开销和复杂性会有很大变化。 某些团队可以使用 Microsoft 托管的加载项和扩展以及自动升级功能来大幅降低运营开销。 其他客户可能更喜欢完全控制群集，以便利用 Kubernetes 和 NCF 生态系统的完全扩展性。 例如，尽管 Microsoft 以托管 GitOps 扩展的形式提供 Flux，但许多团队会选择自行设置和运行 ArgoCD。

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

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

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

贡献者

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

主要作者：

• 安德烈·杜威斯 |高级客户工程师
• 刘旭红 |高级服务工程师
• 马科斯·马丁内斯 |高级服务工程师
• Julie Ng |高级工程师

其他参与者：

• 米克·阿尔伯特 |技术编写器
• 马丁·格约舍夫斯基 |高级客户工程师
• Don High |首席客户工程师
• Nelly Kiboi |服务工程师
• 费萨尔·穆斯塔法 |高级客户工程师
• 沃尔特·迈尔斯 |首席客户工程经理
• 索纳利卡·罗伊 |高级客户工程师
• Paolo Salvatori |首席客户工程师
• 维克多·桑塔纳 |首席客户工程师

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

后续步骤

• AKS 文档
• 容器应用文档
• 应用服务文档

相关资源

• AKS - 规划设计和操作
• 使用 Azure 容器应用部署微服务