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

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

概述

本文中的注意事项分为以下四个类别：

体系结构和网络注意事项

• 操作系统 【OS】 支持
• 网络地址空间
• 流量流分析
• 子网规划
• 可用的入口 IP 地址
• 用户定义的路由（UDR）和 NAT 网关支持
• 专用网络集成
• 协议覆盖范围
• 负载均衡
• 服务发现
• 自定义域和托管传输层安全性 （TLS）
• 相互 TLS （mTLS）
• 适用于 Azure Kubernetes 服务的高级容器网络（AKS）
• 特定 Azure 服务的网络概念

安全注意事项

• 群集内流量安全性的网络策略
• 网络安全组（NSG）
• Azure 密钥保管库集成
• 托管标识支持
• 使用 Microsoft Defender for Containers 进行威胁防护和漏洞评估
• 安全基线
• 适用于安全性的 Azure 精心设计框架

操作考虑

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

可靠性注意事项

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

本文重点介绍一部分 Azure 容器服务，这些服务为 Web 应用程序和 API、网络、可观测性、开发人员工具和作提供成熟的功能集。 这些服务包括 AKS、AKS 自动、Azure 容器应用和用于容器的 Web 应用。 有关 Azure 容器服务的完整列表，请参阅 容器服务。

体系结构注意事项

本部分涵盖那些在不进行重大停机或重新部署的情况下难以逆转或更正的体系结构决策。 在完成基本组件之前，仔细评估基本组件（如网络和安全）尤其重要。

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

OS 支持

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

*需要适用于 Windows 和 Linux 的单独 Azure 应用服务计划

网络注意事项

在规划过程中，由于安全性和合规性限制以及强制实施的指导方针，了解网络设计至关重要。 通常，本指南中涵盖的 Azure 服务之间的主要差异取决于偏好。 请考虑以下服务：

• 容器应用 是一种平台即服务（PaaS），提供 Azure 托管的网络功能，如服务发现、内部托管域和虚拟网络控制。

• AKS 是三个服务中最可配置的，它提供对网络流的最大控制。 例如，AKS 通过 Kubernetes 网络策略提供自定义入口控制器和控制群集内流量。 工作负荷团队可以利用各种 Azure 管理的网络插件，并安装并运作来自 Kubernetes 生态系统的任何插件。

• 用于容器的 Web 应用 是 应用服务的功能。 其网络模型，特别是专用网络集成，紧跟应用服务的体系结构。 使用应用服务的工作负荷团队熟悉此体系结构。 对于以前没有应用服务体验且更倾向于更传统的 Azure 虚拟网络集成的团队，我们建议使用容器应用。

网络是一个基础基础结构层。 通常很难在设计中进行更改，而无需重新部署工作负荷，这可能会导致停机。 如果工作负荷具有特定的网络要求，请在缩小 Azure 容器服务选择范围之前仔细查看本部分。

网络地址空间

将应用程序集成到虚拟网络中时，需要规划 IP 地址，以确保容器实例足够。 在此过程中，分配额外的 IP 地址以适应更新、蓝绿部署和类似的方案。 这些事件可能会临时部署使用比平常更多的地址的额外实例。

AKS 要求取决于所选的网络插件。 AKS 的某些网络插件需要更广泛的 IP 地址预留。 这些信息超出了本文的范围。 有关详细信息，请参阅 AKS 的网络概念。

了解流量流

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

以下部分介绍各种网络约束。 这些约束会影响是否需要部署额外的子网，具体取决于以下配置的要求：

• 多个并置工作负载

• 专用入口、公共入口或两者

• 在容器应用和 AKS 的群集内，或在所有 Azure 容器服务的虚拟网络中，实现东西向流量的访问控制流

子网规划

子网必须足够大才能包含应用程序实例，但容量并不是确定部署这些工作负荷的网络占用空间的唯一因素。

*最佳做法，而不是技术限制

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

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

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

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

入口 IP 地址可用性

下表包含上一个子网规划部分，用于定义可公开的 IP 地址数。 它适用于单个 Azure 容器服务部署中托管的任意数量的应用程序。

容器应用支持每个环境（公共或专用）的一个 IP 地址。 AKS 支持任意数量的公共或专用 IP 地址。 用于容器的 Web 应用当在非应用服务环境中使用时，每个应用服务计划允许使用一个公共 IP 地址，并通过 Azure 专用终结点提供多个不同的专用 IP 地址。

请记住，集成到应用服务环境中的 Web 应用仅通过与应用服务环境关联的单个入口 IP 地址（无论是公共的还是专用的）接收流量。

UDR 和 NAT 网关支持

如果工作负荷需要 UDR 和 NAT 网关功能才能进行精细网络控制，容器应用需要使用 工作负荷配置文件。 UDR 和 NAT 网关兼容性在容器应用的按需计费方案中不可用。

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

专用网络集成

对于需要对入口和出口进行严格第 4 层专用网络的工作负载，您应该考虑使用容器应用、AKS 和单租户应用服务环境 SKU，这些工作负载会被部署到自维护虚拟网络中。 此部署提供常规细粒度专用网络控制。

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

Web App for Containers 提供了一些不同于本文介绍的其他 Azure 服务的额外网络功能。 若要实施严格的专用网络要求，工作负荷团队应熟悉这些网络概念。 仔细查看以下网络功能：

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

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

协议覆盖范围

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

*在容器应用环境中， HTTP 或 HTTPS 可以在任何端口上公开 ，以便进行群集内部通信。 在这种情况下，内置容器应用 HTTP 功能（如跨域资源共享和会话相关性）不适用。

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

负载均衡

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

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

AKS 的高级容器网络服务

高级容器网络服务（ACNS）为 AKS 提供高级网络功能，这些功能超出了容器应用或用于容器的 Web 应用的可用功能。 这些功能为动态容器化环境提供强大的可观测性和增强的安全性。

• 容器网络可观测性：

  ACNS 使用 Hubble 的控制平面来直观深入地深入了解网络行为。 借助易于使用的节点级和 Pod 级指标和全面的流日志，可以快速查明问题并优化性能。 这种内置的可观测性减少了外部监视设置的需求，并降低了通常与 Kubernetes 网络诊断关联的学习曲线。

• 容器网络安全：

  对于使用由 Cilium 提供支持的 Azure 容器网络接口的群集，ACNS 提供完全限定的域名（FQDN）筛选。 可以基于域名定义策略，而不是管理基于 IP 地址的静态安全策略。 这种动态方法简化了策略管理，并与新式零信任安全模型保持一致。 通过此方法，可以更轻松地强制实施可靠的安全性，而无需不断进行手动更新。

有关详细信息，请参阅以下资源：

• 什么是容器网络可观测性？
• 什么是容器网络安全？

服务发现

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

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

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

Kubernetes 部署本质上无法从群集内部或外部发现。 若要以可寻址方式向网络公开应用程序，必须定义和创建 Kubernetes API 指定的 Kubernetes 服务。

自定义域和托管 TLS

容器应用和用于容器的 Web 应用都为自定义域和证书管理提供内置解决方案。

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

mTLS

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

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

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

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

特定于服务的网络概念

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

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

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

安全注意事项

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

安全比较概述

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

在本指南中的服务中，AKS 提供最强的可配置性和可扩展性，其中的一部分原因是它能够揭示底层组件，这些组件通常可以通过配置选项加以保护。 例如，可以使用配置选项来禁用 Kubernetes API 服务器的本地帐户，或启用对基础节点的自动更新。

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

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

Kubernetes 控制平面安全性

AKS 提供了本文中考虑的三个选项的最大灵活性。 它提供对 Kubernetes API 的完全访问权限，以便自定义容器业务流程。 但是，对 Kubernetes API 的访问也表示需要保护的重大攻击面。

基于身份的安全性

你负责保护对 API 的基于标识的访问。 Kubernetes 提供自己的身份验证和授权管理系统。 此系统需要使用访问控制进行保护。

若要利用单平面玻璃进行 Azure 上的标识和访问管理，最佳做法是禁用特定于 Kubernetes 的本地帐户，而是实现 AKS 托管的 Microsoft Entra 集成以及适用于 Kubernetes 的 Azure 基于角色的访问控制（Azure RBAC）。 如果实施此最佳做法，管理员无需在多个平台上执行身份和访问管理。

如果使用容器应用，则无法访问 Kubernetes API。 Microsoft 可确保此 API 安全。

基于网络的安全性

如果要限制对 Kubernetes 控制平面的网络访问权限，则需要使用 AKS，它提供两个选项。 第一个选项是使用 专用 AKS 群集，该群集在 API 服务器的专用网络与 AKS 群集的专用网络之间使用 Azure 专用链接。 第二个选项是 API 服务器虚拟网络集成 ，其中 API 服务器集成到委托的子网中。

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

ACNS 增强了 AKS 中的数据平面安全性。 对于使用由 Cilium 提供支持的 Azure 容器网络接口的群集，ACNS 通过 FQDN 筛选引入容器网络安全。 可以基于 FQDN 定义动态策略，而不是管理基于 IP 地址的静态安全策略。 此方法简化了策略管理，减少了管理开销，并通过确保只允许流量流向受信任的域，从而支持零信任模型。

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

数据平面网络安全

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

群集内流量安全性的网络策略

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

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

NSG

在所有方案中，都可以使用网络安全组在整个虚拟网络中管理网络通信。 使用此方法，可以使用第 4 层流量规则来调节虚拟网络级别的入口和出口。

入口的内置 IP 地址限制

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

应用程序级安全性

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

密钥保管库集成

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

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

有关详细信息，请参阅以下资源：

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

托管标识支持

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

有关详细信息，请参阅以下资源：

• 在 AKS 中使用托管标识
• AKS 工作负载 ID
• 容器应用中的托管标识
• 应用服务的托管标识

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

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

当 AKS 公开原生 Kubernetes API 时，可以使用 Kubernetes 生态系统中的 Kubernetes 专用安全工具评估群集安全性。

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

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

安全基线

大多数 Azure 容器服务通常集成 Azure 安全产品/服务。 请记住，安全功能集只是实现云安全性的一小部分。 有关如何实现容器服务安全性的详细信息，请参阅以下特定于服务的安全基线：

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

Well-Architected 框架的安全性

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

有关 AKS 的更完整安全指南，请参阅 AKS 最佳做法。

运行考虑事项

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

更新和修补程序

必须更新并定期修补应用程序的基础 OS。 但是，每个更新都会带来失败风险。 本部分和下一部分介绍有关客户与平台之间共同责任的三个容器服务的关键注意事项。

作为托管的 Kubernetes 服务，AKS 提供节点操作系统和控制平面组件的更新映像。 但是，工作负荷团队需负责对其群集应用更新。 可以手动触发更新或使用 集群自动升级通道 功能来确保集群保持最新。 有关 AKS 第 2 天作指南的详细信息，请参阅 修补和升级 AKS 群集。

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

容器映像更新

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

伸缩性

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

纵向基础结构可伸缩性

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

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

以下文章提供有关容器应用和应用服务的 SKU 产品/服务的详细信息：

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

横向基础结构可伸缩性

水平缩放 是指通过添加或删除基础结构组件（如 VM 节点）来增加或减少容量的能力。 在缩放增加或减少期间，容器应用消耗层级抽象化底层虚拟机。 对于剩余的 Azure 容器服务，可以使用标准资源管理器 API 管理水平缩放策略。

横向扩展和缩减包括重新均衡实例，因此会导致停机的风险。 该风险低于纵向缩放对应的风险。 不管怎样，你都负责确保应用程序能够处理故障。 你还负责实现应用程序的正常启动和关闭，以避免停机。

应用程序可伸缩性

基础结构和应用程序的缩放通常由资源消耗（如 CPU 和内存）触发。 某些容器解决方案还可以根据特定于应用程序的指标（例如 HTTP 请求）缩放容器实例的数量。 例如，AKS 和容器应用程序可以通过 Kubernetes 事件驱动的自动缩放（KEDA），以及通过其缩放程序根据消息队列和许多其他指标来缩放容器实例。 为应用程序选择可伸缩性策略时，这些功能提供灵活性。 用于容器的 Web 应用依赖于 Azure 提供的可伸缩性选项。 容器 Web 应用不支持像 KEDA 这样的自定义缩放器配置。

默认情况下，AKS 自动启用水平 Pod 自动缩放程序、KEDA 和垂直 Pod 自动缩放程序。

可观察性

工作负载检测

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

• 自动检测： 无需更改代码

• 手动检测： 集成和配置 SDK 和客户端所需的最少代码更改

  仪器方法	容器应用	AKS	用于容器的 Web 应用
  通过平台自动化监测	❌	❌	部分支持*
  通过代理自动检测	❌	部分支持*	不可用
  手动仪器	通过 SDK 或 OpenTelemetry	通过 SDK 或 OpenTelemetry	通过 SDK 或 OpenTelemetry

*适用于容器的 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

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

Azure 为特定服务提供了许多 SLA。 没有这样的服务可用性，因为软件、硬件甚至自然事件（如风暴和地震）中可能发生故障。 SLA 不是保证，而是对定义的可用性级别的财务支持承诺。

有关 SLA 和详细信息，请下载 Microsoft 联机服务的 SLA 最新文档。

免费层与付费层

通常，Azure 服务的免费层不提供 SLA，这使得它们成为非生产环境经济高效的选择。 但是，对于生产环境，最好选择具有 SLA 的付费层。

AKS 的额外因素

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

• 控制平面： Kubernetes API 服务器具有单独的 SLA。

• 数据平面： 节点池使用 VM SKU 的基础 SLA。

• 可用性区域： 这两个平面有不同的 SLA，具体取决于 AKS 群集是否启用了可用性区域 ，以及 多个实例是否跨可用性区域运行。

使用多个 Azure 服务时， 复合服务级别目标 可能与单个 SLA 不同且低于单个 SLA。

可用性区域冗余

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

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

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

运行状况检查和自我修复

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

若要更好地了解 Kubernetes 运行状况探测的类型，请考虑以下 内置选项：

• 启动： 检查应用程序是否已成功启动

• 准备： 检查应用程序是否准备好处理传入请求

• 活性： 检查应用程序是否正在运行并响应

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

大多数应用程序都支持通过 HTTP 或 HTTPS 协议进行运行状况检查。 但是，某些应用程序可能需要其他协议（如 TCP 或 gRPC）来执行这些检查。 在设计您的健康检查系统时，请记住这一点。

在用户容器的 Web 应用中，运行状况检查是最容易实现的。 请考虑下列因素：

• 其启动探测是内置的，无法更改。 它将 HTTP 请求发送到容器的起始端口。 来自应用程序的任何响应都视为成功启动。

• 它不支持就绪情况探测。 如果启动探测成功，容器实例将添加到正常实例池中。

• 它会以 1 分钟间隔发送运行状况检查。 该间隔无法更改。

• 为运行不正常实例从内部负载均衡机制中移除的频率设置的最小阈值为 2 分钟。 运行不正常实例在未通过运行状况检查后的至少两分钟内还会获取流量。 此设置的默认值为 10 分钟。

或者，容器应用和 AKS 更灵活，并提供类似的选项。 就具体差异而言，AKS 提供了以下用于执行运行状况检查的选项，而这些选项在容器应用中不可用：

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

自动自愈

标识故障的容器实例并停止其流量仅仅是开始。 下一步是实现自动修复。 自动修复 是重启应用程序以尝试从不正常状态恢复的过程。 请考虑以下容器服务之间的比较方式：

• 在用于容器的 Web 应用中，在 运行状况检查失败后，无法立即重启容器实例。 如果实例继续失败一小时，则新实例将替换它。 自动修复 监控并重启实例。 它与健康检查不直接相关。 自动修复使用各种应用程序指标，例如内存限制、HTTP 请求持续时间和状态代码。

• 如果运行情况探测达到定义的故障阈值，容器应用和 AKS 会自动尝试重启容器实例。

零停机时间应用程序部署

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

应用程序体系结构还必须支持零停机部署。

资源限制

可靠共享环境的另一个重要组成部分是控制容器的资源使用情况，例如 CPU 或内存。 需要避免单个应用程序使用所有资源并使其他应用程序处于错误状态的情况。

• 用于容器的 Web 应用： 可以在单个应用服务计划中托管多个应用程序（容器）。 例如，可以分配一个具有两个 CPU 核心和 4 gibibyte（GiB）RAM 的计划，可以在其中在容器中运行多个 Web 应用。 但是，不能将其中一个应用限制为特定数量的 CPU 或内存。 它们都争用相同的应用服务计划资源。 若要隔离应用程序资源，需要创建额外的应用服务计划。

• 容器应用： 可以为环境中的每个应用程序设置 CPU 和内存限制。 但是，只能使用一组 允许的 CPU 和内存组合。 例如，不能配置一个 vCPU 和 1 GiB 内存，但可以配置一个 vCPU 和 2 GiB 内存。 容器应用环境与 Kubernetes 命名空间类似。

• AKS： 只要节点具有硬件来支持它，就可以选择 vCPU 和内存 的任意组合。 如果要按这种方式对群集进行分段，还可以限制 命名空间级别的 资源。

Well-Architected 架构框架的可靠性

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

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

结束语

精心构建的解决方案为成功的工作负载奠定了基础。 随着工作负载的增长和团队在云旅程中的发展，体系结构决策可能会演变。 某些选择（尤其是与网络相关的选择）很难逆转，而不会造成重大停机或重新部署。

比较 Azure 容器服务时，会出现一个明确的主题。 AKS 公开了最底层的基础结构，可提供最大控制和配置性。 AKS 自动化通过执行许多操作任务，平衡了控制与简便性。

AKS 工作负荷的运营开销和复杂性各不相同。 某些团队通过使用Microsoft托管的加载项、扩展和自动升级功能大幅降低开销。 其他团队更喜欢完全群集控制，以利用 Kubernetes 的完整扩展性和NCF 生态系统。 例如，虽然 Microsoft 提供 Flux 作为管理 GitOps 扩展，但许多团队选择自行设置和操作 ArgoCD。

不需要 CNCF 应用程序的工作负载团队、运营经验较少、或者更倾向于专注于应用程序功能，可能更倾向于选择 PaaS 解决方案。 我们建议这些团队首选考虑容器应用。

容器应用和用于容器的 Web 应用都是 PaaS 产品/服务，提供类似的Microsoft托管基础结构级别。 但是，容器应用更接近 Kubernetes，并为服务发现、事件驱动的自动缩放和 Dapr 集成提供额外的云原生功能。 不需要这些功能且熟悉应用服务网络和部署模型的 Teams 可能更喜欢用于容器的 Web 应用。

通用化有助于缩小 Azure 容器服务列表的范围以供考虑。 但是，还应通过详细查看各个要求并将其与特定于服务的功能进行匹配来验证自己的选择。

贡献者

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

主要作者：

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

其他参与者：

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

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

后续步骤

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

相关资源

• 使用容器应用部署微服务
• 规划设计和运作