通过

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

Azure Kubernetes 服务上的微服务体系结构

Microsoft Entra ID
Azure 容器注册表
Azure Kubernetes 服务 (AKS)
Azure 负载均衡器
Azure Pipelines
Azure Monitor

此参考体系结构演示了部署到 Azure Kubernetes 服务 (AKS) 中的微服务应用程序。 它描述了一个基本 AKS 配置，你可以将其用作大多数部署的起点。 本文假定你已基本了解 Kubernetes。 本文主要介绍了如何在 AKS 上管理微服务的基础结构和 DevOps 方面。 有关如何设计微服务的详细信息，请参阅 微服务体系结构设计。

GitHub 徽标。 GitHub 上提供了此体系结构的参考实现。

体系结构

显示 AKS 参考体系结构上的微服务的关系图。

Helm 是云原生计算基金会（CNCF）的商标。 使用此标志并不意味着认可。

下载此体系结构的 Visio 文件。

若要查看基于 AKS 基线体系结构构建的更高级微服务的示例，请参阅 高级 AKS 微服务体系结构。

工作流

此请求流实现 发布者-订阅者、 竞争使用者和 网关路由 云设计模式。

以下数据流对应于上图：

  1. 客户端应用程序通过 HTTPS 将 JSON 有效负载发送到负载均衡器（托管入口控制器）的公共完全限定域名，以计划无人机取件。

    • 托管入口控制器将请求路由到引入微服务。

    • 引入微服务处理 Azure 服务总线队列中的请求和队列传递请求。

  2. 工作流微服务：

    • 使用来自服务总线消息队列的消息信息。

    • 向传递微服务发送 HTTPS 请求，该微服务将数据传递到 Azure Redis 缓存中的外部数据存储。

    • 向无人机计划程序微服务发送 HTTPS 请求。

    • 向包微服务发送 HTTPS 请求，该请求将数据传递到 MongoDB 中的外部数据存储。

  3. HTTPS GET 请求返回传递状态。 此请求通过托管入口控制器传递到传递微服务。 然后，传递微服务从 Azure Redis 缓存读取数据。

有关示例微服务应用程序的详细信息，请参阅 微服务参考实现示例。

组件

  • AKS 是托管的 Kubernetes 群集，托管在 Azure 云中。 AKS 通过将大部分责任卸载到 Azure 来降低管理 Kubernetes 的复杂性和运营开销。

  • 入口服务器 向群集内的服务公开 HTTP（S） 路由。 参考实现通过应用程序路由加载项使用 基于托管 NGINX 的入口控制器 。 入口控制器实现微服务的 API 网关 模式。

  • 无状态微服务使用外部数据存储（例如 Azure SQL 数据库或 Azure Cosmos DB）来写入其数据和其他状态信息。 参考实现使用 Azure Cosmos DB、 Azure Redis 缓存、 用于 MongoDB 的 Azure Cosmos DB和服务总线 作为数据存储或存储状态的位置。

  • AKS 群集需要Microsoft Entra ID。 它提供用于访问 Azure 容器注册表以及访问和预配 Azure 资源（例如负载均衡器和托管磁盘）的 托管标识 。 在 AKS 群集上部署的工作负荷还需要Microsoft Entra 中的标识来访问Microsoft受 Entra 保护的资源，例如 Azure Key Vault 和 Microsoft Graph。 在此参考体系结构中， Microsoft Entra 工作负荷 ID 与 Kubernetes 集成，并提供标识的工作负载。 还可以对每个工作负荷使用托管标识或应用程序凭据。

  • 容器注册表 可用于存储部署到群集的专用容器映像。 AKS 可以使用容器注册表Microsoft Entra 标识进行身份验证。 在参考实现中，微服务容器映像生成并推送到容器注册表。

  • Azure Pipelines 是 Azure DevOps 套件的一部分，运行自动生成、测试和部署。 微服务环境中强烈建议 采用持续集成和持续部署（CI/CD） 方法。 各种团队可以使用 Azure Pipelines 独立生成微服务并将其部署到 AKS。

  • Helm 是 Kubernetes 的包管理器，它提供一种机制，用于将 Kubernetes 对象捆绑和标准化为可以发布、部署、版本管理和更新的单个单元。

  • Azure Monitor 收集并存储 Azure 服务的指标和日志、应用程序遥测和平台指标。 Azure Monitor 与 AKS 相集成，可以从控制器、节点和容器收集指标。

  • Application Insights 监视微服务和容器。 它可用于提供微服务的可观测性，其中包括流量流、端到端延迟和错误百分比。 微服务的运行状况及其之间的关系可以在单个应用程序映射上显示。

替代方案

Azure 容器应用 提供托管的无服务器 Kubernetes 体验。 当你不需要直接访问 Kubernetes 或其 API，并且不需要控制群集基础结构时，它可用作托管微服务的更简单的替代方法。

可以使用容器、Istio 入口网关或非Microsoft解决方案等替代方法，而不是 AKS 中的托管入口网关。 有关详细信息，请参阅 AKS 中的入口。

可以将容器映像存储在非Microsoft容器注册表（如 Docker Hub）中。

对于需要维护状态信息的微服务， Dapr 提供了用于管理微服务状态的抽象层。

可以使用 GitHub Actions 生成和部署微服务，或选择非Microsoft CI/CD 解决方案（如 Jenkins）。

可以使用 Kiali 等替代工具实现微服务可观测性。

方案详细信息

示例 微服务参考实现 实现本文中所述的体系结构组件和做法。 在此示例中，一家名为 Fabrikam， Inc.的虚构公司管理无人机机群。 各商家注册该服务，用户可以请求无人机收取要交付的商品。 当客户安排取件时，后端系统会分配无人机，并通知用户估计的交付时间。 交付正在进行时，客户可以通过持续更新的估计交付时间跟踪无人机的位置。

此方案旨在演示 AKS 中的微服务体系结构和部署最佳做法。

可能的用例

采用方案中的以下最佳做法，在 AKS 中构建基于微服务的复杂应用程序：

  • 复杂的 Web 应用程序
  • 使用微服务设计原则开发的业务逻辑

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 azure Well-Architected FrameworkMicrosoft。

设计

此参考体系结构侧重于微服务，但许多建议的做法适用于在 AKS 上运行的其他工作负荷。

微服务

微服务是松散耦合的、可独立部署的代码单元。 微服务通常通过妥善定义的 API 进行通信，可以通过某种形式的服务发现来发现它们。 Kubernetes 服务对象是一种在 Kubernetes 中为微服务建模的典型方法。

数据存储

在微服务体系结构中，服务不应共享数据存储解决方案。 每个服务都应管理其自己的数据集，以避免服务之间的隐藏依赖关系。 数据分离有助于避免服务之间的意外耦合。 当服务共享相同的基础数据架构时，可能会发生此过程。 当服务管理自己的数据存储时，它们可以使用正确的数据存储来满足其特定要求。 有关详细信息，请参阅 微服务的数据注意事项。

避免将持久性数据存储在本地群集存储中，因为该方法将数据绑定到节点。 请改用 SQL 数据库或 Azure Cosmos DB 等外部服务。 另一个选项是使用 Azure 磁盘存储或 Azure 文件将永久性数据卷装载到解决方案。 有关详细信息，请参阅 AKS 中应用程序的存储选项。

API 网关

API 网关是一种通用的微服务设计模式。 API 网关位于外部客户端和微服务之间。 网关充当反向代理，并将请求从客户端路由到微服务。 API 网关还可以执行各种交叉任务，例如身份验证、安全套接字层（SSL）终止和速率限制。 有关详细信息，请参阅以下资源：

在 Kubernetes 中，入口控制器主要处理 API 网关的功能。 入口和入口控制器可以结合使用：

  • 将客户端请求路由到正确的后端微服务。 此路由为客户端提供单个终结点，有助于将客户端与服务分离。

  • 将多个请求聚合到单个请求中，以减少客户端和后端之间的聊天。

  • 从后端服务卸载功能，例如 SSL 终止、身份验证、IP 地址限制或客户端速率限制（称为 限制）。

有用于反向代理的入口控制器，其中包括 NGINX、HAProxy、Traefik 和 Azure 应用程序网关。 AKS 提供了多个托管入口选项。 可以通过应用程序路由加载项（用于容器的应用程序网关）从 基于托管的 NGINX 入口控制器 中进行选择。 或者，可以选择 Istio 入口网关作为入口控制器。 有关详细信息，请参阅 AKS 中的入口。

Kubernetes 对象的入口资源已替换为更高级的通用 Kubernetes 网关 API。 入口控制器和网关 API 都是用于流量管理路由和负载均衡的 Kubernetes 对象。 网关 API 设计为通用、表达性、可扩展和面向角色，是一组新式 API，用于在 Kubernetes 中定义 L4 和 L7 路由规则。

入口控制器充当边缘路由器或反向代理。 反向代理服务器是潜在的瓶颈或单一故障点，因此我们建议至少部署两个副本，以帮助确保高可用性。

何时选择入口控制器或网关 API

入口资源适用于以下用例：

  • 入口控制器易于设置，适用于优先于轻松配置的较小且不太复杂的 Kubernetes 部署。

  • 如果当前已在 Kubernetes 群集中配置入口控制器，并且它们符合你的要求，则可能不需要立即转换到 Kubernetes 网关 API。

应使用网关 API：

  • 处理复杂的路由配置、流量拆分和高级流量管理策略时。 Kubernetes 网关 API 的路由资源提供的灵活性至关重要。

  • 如果网络要求需要自定义解决方案或非Microsoft插件的集成。 Kubernetes 网关 API 基于自定义资源定义的方法可以提供增强的扩展性。

可靠性

可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性设计评审核对清单。

对微服务进行分区

使用命名空间来组织群集中的服务。 Kubernetes 群集中的每个对象属于某个命名空间。 最好使用命名空间来组织群集中的资源。

命名空间有助于防止命名冲突。 如果多个团队将微服务（也许有数百个）部署到同一群集，而这些微服务都属于同一命名空间，则管理就会变得艰难。 命名空间还允许：

  • 将资源约束应用于命名空间，以便分配给该命名空间的总 Pod 集不能超过命名空间的资源配额。

  • 在命名空间级别应用策略，包括基于角色的访问控制（RBAC）和安全策略。

当多个团队开发和部署微服务时，可以使用命名空间作为一种方便的机制来控制每个团队可以部署到的区域。 例如，开发团队 A 只能授予对命名空间 A 的访问权限，而开发团队 B 只能通过 Kubernetes RBAC 策略授予对命名空间 B 的访问权限。

对于微服务体系结构，请考虑将微服务组织到边界上下文中，并为每个边界上下文创建命名空间。 例如，与“订单履行”绑定上下文相关的所有微服务都可以进入同一命名空间。 或者，为每个开发团队创建一个命名空间。

将公用服务放入其自身的独立命名空间。 例如，可以将 Elasticsearch 和 Prometheus 等群集监视工具部署到监视命名空间。

运行状况探测

Kubernetes 定义了 Pod 可以公开的三种类型的运行状况探测：

  • 就绪情况探测： 告知 Kubernetes Pod 是否已准备好接受请求。

  • 生存度探测： 告知 Kubernetes 是否应删除 Pod 并启动一个新实例。

  • 启动探测： 告知 Kubernetes Pod 是否已启动。

考虑探测时，请务必记住服务在 Kubernetes 中的工作原理。 服务具有与一组零个或多个 Pod 匹配的标签选择器。 Kubernetes 对发往匹配该选择器的 pod 的流量进行负载均衡。 只有成功启动且正常接收流量的 Pod。 如果容器崩溃，Kubernetes 将终止 Pod 并计划更换。

有时，即使 Pod 已成功启动，也可能无法接收流量。 例如，可能正在进行初始化任务，例如，当容器中运行的应用程序将数据加载到内存中或读取配置文件时。 可以对这些慢速启动容器使用启动探测。 此方法有助于防止 Kubernetes 在有机会完全初始化之前终止它们。

运行情况探测用于检查 Pod 是否正在运行但无法正常工作，需要重启。 例如，如果容器正在处理 HTTP 请求，但突然停止响应而不崩溃，则实时性探测将检测此事件并触发 Pod 重启。 如果设置了实时性探测，它会注意到容器未响应时，并提示 Kubernetes 重启 Pod（如果容器重复失败探测）。

在为微服务设计探测时，请考虑以下几点。

  • 如果代码的启动时间很长，则启动完成之前，运行情况探测报告失败存在危险。 若要延迟运行情况探测的开始，请使用启动探测，或者将 initialDelaySeconds 设置与运行情况探测一起使用。

  • 仅当重启 Pod 可能会将其还原为正常状态时，实时情况探测才有帮助。 可以使用实时探测来缓解内存泄漏或意外死锁，但没有理由重启将立即再次失败的 Pod。

  • 有时，就绪情况探测可用于检查依赖服务。 例如，如果 Pod 依赖数据库，则探测可以检查数据库连接。 但是，此方法可能造成意外的问题。 外部服务可能暂时不可用。 这种不可用会导致服务中所有 Pod 的就绪情况探测失败，从而导致其从负载均衡中删除。 此删除作会在上游创建级联故障。

    更好的方法是在服务中实现重试处理，以便服务能够从暂时性故障中正确恢复。 作为替代方法， Istio 服务网格 可以实现重试处理、容错和断路器，以创建可处理微服务故障的弹性体系结构。

资源约束

资源争用可能影响服务的可用性。 定义 容器的资源约束 ，以便单个容器无法使群集资源（如内存和 CPU）不堪重负。 对于非容器资源（例如线程或网络连接），请考虑使用 Bulkhead 模式 来隔离资源。

使用 资源配额 限制命名空间允许的总资源。 此限制可确保前端无法为资源提供后端服务，反之亦然。 资源配额可帮助将同一群集中的资源分配给多个微服务开发团队。

安全性

安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息，请参阅 安全的设计评审清单。

TLS 和 SSL 加密

在许多实现中，入口控制器用于 SSL 终止。 部署入口控制器时，需要创建或导入传输层安全性（TLS）证书。 仅用于开发和测试目的的自签名证书。 有关详细信息，请参阅 使用应用程序路由加载项设置自定义域名和 SSL 证书。

对于生产工作负荷，请从受信任的证书颁发机构获取签名的证书。

可能还需要根据组织的策略轮换证书。 可以使用 Key Vault 轮换微服务使用的证书。 有关详细信息，请参阅 在 Key Vault 中配置证书自动轮换。

RBAC

当多个团队同时开发和部署微服务时，AKS RBAC 机制可以提供对用户作的精细控制和筛选。 可以使用 Kubernetes RBAC 或具有 Microsoft Entra ID 的 Azure RBAC 来控制对群集资源的访问。 有关详细信息，请参阅 AKS 的访问权限和标识选项。

身份验证和授权

微服务可能需要使用服务或用户使用证书、凭据和 RBAC 机制对微服务的访问权限进行身份验证和授权。 Microsoft Entra ID 可用于实现 OAuth 2.0 令牌以进行授权。 Istio 等服务网格还为微服务提供授权和身份验证机制，其中包括 OAuth 令牌验证和基于令牌的路由。 参考实现不包括微服务身份验证和授权方案。

机密管理和应用程序凭据

应用程序和服务通常需要使用凭据连接到 Azure 存储或 SQL 数据库等外部服务。 此处的难题在于如何保护这些凭据的安全，避免将其透露。

对于 Azure 资源，请尽可能使用托管标识。 托管标识类似于存储在 Microsoft Entra ID 中的应用程序或服务的唯一 ID。 它使用此标识向 Azure 服务进行身份验证。 应用程序或服务在 Microsoft Entra ID 中创建服务主体，并使用 OAuth 2.0 令牌进行身份验证。 进程内运行的代码可以透明地获取令牌。 此方法有助于确保不需要存储任何密码或连接字符串。 若要使用托管标识，可以使用 Microsoft Entra 工作负荷 ID 将 Microsoft Entra 标识分配给 AKS 中的单个 Pod。

即使使用托管标识，你仍可能需要存储某些凭据或其他应用程序机密。 不支持托管标识、非Microsoft服务或 API 密钥的 Azure 服务需要此存储。 可以使用以下选项来帮助更安全地存储机密：

使用 Key Vault 等解决方案可提供多种优势，包括：

  • 对机密进行集中控制。
  • 帮助确保所有机密都静态加密。
  • 集中式密钥管理。
  • 对机密进行访问控制。
  • 密钥生命周期管理。
  • 审计。

参考实现将 Azure Cosmos DB 连接字符串和其他机密存储在 Key Vault 中。 参考实现使用微服务的托管标识向 Key Vault 进行身份验证并访问机密。

容器和业务流程协调程序安全性

以下建议的做法可帮助保护 Pod 和容器。

  • 监视威胁。 使用 Microsoft Defender for Containers 或非Microsoft功能监视威胁。 如果在虚拟机（VM）上托管容器，请使用 Microsoft Defender for Servers 或非Microsoft功能。 此外，还可以将 Azure Monitor 中的容器监视解决方案中的 日志集成到 Microsoft Sentinel 或现有的安全信息和事件管理（SIEM）解决方案。

  • 监视漏洞。 使用 Microsoft Defender for Cloud 或非Microsoft解决方案持续监视映像和运行已知漏洞的容器。

  • 自动执行映像修补。 使用 Azure 容器注册表任务（容器注册表的一项功能）自动执行映像修补。 容器映像是在层中生成的。 基本层包括 OS 映像和应用程序框架映像，例如 ASP.NET Core 或 Node.js。 基础映像通常是从应用程序开发人员上游创建的，其他项目维护人员维护它们。 在上游修补这些映像时，必须更新、测试和重新部署自己的映像，这样就不会留下任何已知的安全漏洞。 Azure 容器注册表任务可帮助自动执行此过程。

  • 将映像存储在受信任的专用注册表中。 使用受信任的专用注册表（如容器注册表或 Docker 受信任的注册表）来存储映像。 使用 Kubernetes 中的验证允许 Webhook 来帮助确保 Pod 只能从受信任的注册表检索映像。

  • 应用最低权限原则。 不要以特权模式运行容器。 特权模式可让容器访问主机上的所有设备。 如果可能，请避免以 root 身份在容器中运行进程。 容器不会从安全角度提供完全隔离，因此最好以非特权用户身份运行容器进程。

部署 CI/CD 注意事项

请考虑微服务体系结构的可靠 CI/CD 流程的以下目标：

  • 每个团队可以独立生成并部署自有的服务，而不影响或干扰其他团队。

  • 在将新版本的服务部署到生产环境之前，它将部署到开发、测试和 Q&A 环境进行验证。 在每个阶段强制实施质量控制。

  • 新服务版本可以连同前一版本一起部署。

  • 实施足够的访问控制策略。

  • 对于容器化工作负载，可以信任部署到生产环境的容器映像。

若要了解有关挑战的详细信息，请参阅微服务体系结构的 CI/CD。

使用 Istio 等服务网格可以帮助处理 CI/CD 进程，例如 Canary 部署、微服务的 A/B 测试，以及使用基于百分比的流量拆分的分阶段推出。

有关特定建议和最佳做法的详细信息，请参阅 使用 Azure DevOps 和 Helm 在 Kubernetes 上为微服务生成 CI/CD 管道。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅 成本优化的设计评审清单。

使用 Azure 定价计算器估算成本。 Microsoft Azure Well-Architected Framework 的“成本”部分介绍了其他注意事项。

对于此体系结构中使用的某些服务，请考虑以下几点。

AKS

Azure 负载均衡器

你只需为配置的负载平衡和出站规则的数量付费。 入站网络地址转换规则是免费的。 如果未配置规则，则标准负载均衡器不按小时收费。 有关详细信息，请参阅 Azure 负载均衡器定价。

Azure Pipelines（Azure 管道服务）

此参考体系结构仅使用 Azure Pipelines。 Azure 以单个服务的形式提供管道。 对于 CI/CD，每个月可以有 1,800 分钟的免费Microsoft托管作业，每月有一个自承载作业，每个月有无限分钟。 额外的作业会产生更多成本。 有关详细信息，请参阅 Azure DevOps 服务定价。

Azure Monitor

对于 Azure Monitor Log Analytics，需要为数据引入和保留付费。 有关详细信息，请参阅 Azure Monitor 定价。

卓越运营

卓越运营涵盖部署应用程序并使其在生产环境中运行的运营流程。 有关详细信息，请参阅 卓越运营的设计评审清单。

此参考体系结构包括用于预配云资源及其依赖项的 Bicep 文件 。 可以使用 Azure Pipelines 部署这些 Bicep 文件并快速设置不同的环境，例如复制生产方案。 此方法仅在需要时预配负载测试环境，从而帮助你节省成本。

请考虑遵循工作负荷隔离条件来构建 Bicep 文件。 工作负荷通常定义为任意功能单元。 例如，可以为群集创建单独的 Bicep 文件，然后为依赖服务创建另一个文件。 可以使用 Azure DevOps 执行 CI/CD 与工作负荷隔离，因为每个工作负荷都由其自己的团队关联和管理。

部署此方案

要部署此体系结构的参考实现，请按照 GitHub 存储库中的步骤操作。 有关详细信息，请参阅 AKS 微服务参考实现。

供稿人

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

主要作者：

其他参与者：

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

后续步骤