高可用性 Kubernetes 群集模式

本文介绍如何使用 Azure Stack Hub 上的 Azure Kubernetes 服务 （AKS） 引擎构建和运行基于 Kubernetes 的高可用性基础结构。 对于高度受限且受监管的环境中具有关键工作负荷的组织来说，这种情况很常见。 金融、国防和政府等领域的组织。

上下文和问题

许多组织正在开发使用最先进的服务和技术（如 Kubernetes）的云原生解决方案。 尽管 Azure 在全球大多数区域提供数据中心，但有时存在边缘用例和应用场景，其中业务关键型应用程序必须在特定位置运行。 注意事项包括：

• 位置敏感度
• 应用程序和本地系统之间的延迟
• 带宽保护
• 连接
• 法规或法定要求

Azure 与 Azure Stack Hub 结合使用，解决了其中大多数问题。 下面介绍了成功实现 Azure Stack Hub 上运行的 Kubernetes 的一组广泛的选项、决策和注意事项。

解决方案

此模式假定我们必须处理一组严格的约束。 应用程序必须在本地运行，并且所有个人数据不得访问公有云服务。 监视和其他非 PII 数据可以发送到 Azure 并在那里进行处理。 可以访问公共容器注册表等外部服务，但可以通过防火墙或代理服务器进行筛选。

此处显示的示例应用程序旨在尽可能使用 Kubernetes 原生解决方案。 此设计可避免供应商锁定，而不是使用平台原生服务。 例如，应用程序使用自承载 MongoDB 数据库后端，而不是 PaaS 服务或外部数据库服务。 有关详细信息，请参阅 Azure 学习路径上的 Kubernetes 简介。

上图说明了在 Azure Stack Hub 上的 Kubernetes 上运行的示例应用程序的应用程序体系结构。 该应用由多个组件组成，包括：

1. Azure Stack Hub 上基于 AKS 引擎的 Kubernetes 群集。
2. 证书管理器，它为 Kubernetes 中的证书管理提供了一套工具，用于自动从 Let's Encrypt 请求证书。
3. 一个 Kubernetes 命名空间，其中包含前端（ratings-web）、API（ratings-api）和数据库（ratings-mongodb）的应用程序组件。
4. 入口控制器，它将 HTTP/HTTPS 流量路由到 Kubernetes 群集中的终结点。

示例应用程序用于说明应用程序体系结构。 所有组件都是示例。 该体系结构仅包含单个应用程序部署。 为了实现高可用性（HA），我们在两个不同的 Azure Stack Hub 实例上运行部署至少两次 - 它们可以在同一位置或两个（或更多）不同的站点中运行：

Azure 容器注册表、Azure Monitor 等服务托管在 Azure 或本地的 Azure Stack Hub 外部。 此混合设计可保护解决方案免受单个 Azure Stack Hub 实例中断的影响。

组件

整体体系结构由以下组件组成：

Azure Stack Hub 是 Azure 的扩展，可以通过在数据中心提供 Azure 服务来在本地环境中运行工作负荷。 若要了解详细信息，请转到 Azure Stack Hub 概述。

Azure Kubernetes 服务引擎（AKS 引擎） 是目前在 Azure 中提供的托管 Kubernetes 服务产品/服务（AKS）背后的引擎。 对于 Azure Stack Hub，AKS 引擎允许我们使用 Azure Stack Hub 的 IaaS 功能部署、缩放和升级功能齐全的自托管 Kubernetes 群集。 转到 AKS 引擎概述 了解详细信息。

若要详细了解 Azure 上的 AKS 引擎与 Azure Stack Hub 上的 AKS 引擎之间的差异，请转到 已知问题和限制。

Azure 虚拟网络（VNet） 用于为托管 Kubernetes 群集基础结构的虚拟机（VM）提供每个 Azure Stack Hub 上的网络基础结构。

Azure 负载均衡器 用于 Kubernetes API 终结点和 Nginx 入口控制器。 负载均衡器将外部（例如 Internet）流量路由到提供特定服务的节点和 VM。

Azure 容器注册表（ACR） 用于存储部署到群集的专用 Docker 映像和 Helm 图表。 AKS 引擎可以使用 Microsoft Entra ID 通过容器注册表进行身份验证。 Kubernetes 不需要 ACR。 可以使用其他容器注册表，例如 Docker 中心。

Azure Repos 是一组可用于管理代码的版本控制工具。 还可以使用 GitHub 或其他基于 git 的存储库。 若要了解详细信息，请转到 Azure Repos 概述。

Azure Pipelines 是 Azure DevOps Services 的一部分，并运行自动生成、测试和部署。 还可以使用第三方 CI/CD 解决方案，例如 Jenkins。 若要了解详细信息，请转到 Azure Pipeline 概述。

Azure Monitor 收集和存储指标和日志，包括解决方案和应用程序遥测中 Azure 服务的平台指标。 使用此数据监视应用程序、设置警报和仪表板，并执行故障的根本原因分析。 Azure Monitor 与 Kubernetes 集成，从控制器、节点和容器以及容器日志和主节点日志收集指标。 转到 Azure Monitor 概述，以了解更多信息。

Azure 流量管理器 是一种基于 DNS 的流量负载均衡器，可用于将流量以最佳方式分配到不同 Azure 区域或 Azure Stack Hub 部署的服务。 流量管理器还提供高可用性和响应能力。 应用程序终结点必须可从外部访问。 还有其他可用的本地解决方案。

Kubernetes 入口控制器 向 Kubernetes 群集中的服务公开 HTTP（S） 路由。 Nginx 或任何合适的入口控制器都可用于此目的。

Helm 是 Kubernetes 部署的包管理器，提供了将部署、服务、机密等不同 Kubernetes 对象捆绑到单个“图表”中的方法。 可以发布、部署、控制版本管理和更新图表对象。 Azure 容器注册表可用作存储库来存储打包的 Helm 图表。

设计注意事项

此模式遵循本文后续部分更详细地介绍的一些高级注意事项：

• 应用程序使用 Kubernetes 原生解决方案来避免供应商锁定。
• 应用程序使用微服务体系结构。
• Azure Stack Hub 不需要入站，但允许出站 Internet 连接。

这些建议的做法也适用于实际工作负荷和方案。

可伸缩性注意事项

可伸缩性对于为用户提供对应用程序的一致、可靠且性能良好的访问非常重要。

示例方案涵盖应用程序堆栈多层的可伸缩性。 下面是不同层的高级概述：

体系结构级别	影响	如何？
应用程序	应用程序	基于 Pod/副本/容器实例数量的横向缩放*
群集	Kubernetes 群集	节点数（介于 1 到 50 之间）、VM-SKU 大小和节点池（Azure Stack Hub 上的 AKS 引擎当前仅支持单个节点池）：使用 AKS 引擎的缩放命令 （手动）
基础设施	Azure Stack Hub	Azure Stack Hub 部署中的节点数、容量和缩放单元数

* 使用 Kubernetes 的水平 Pod 自动缩放程序 (HPA)；通过调整容器实例（cpu/内存）的大小，自动进行基于指标的缩放或垂直缩放。

Azure Stack Hub（基础结构级别）

Azure Stack Hub 基础结构是实现的基础，因为 Azure Stack Hub 在数据中心的物理硬件上运行。 选择中心硬件时，需要选择 CPU、内存密度、存储配置和服务器数。 若要详细了解 Azure Stack Hub 的可伸缩性，请查看以下资源：

• Azure Stack Hub 的容量计划概述
• 在 Azure Stack Hub 中添加其他缩放单元节点

Kubernetes 群集（群集级别）

Kubernetes 群集本身由 Azure IaaS 组件（包括计算、存储和网络资源）组成，并基于这些组件构建。 Kubernetes 解决方案涉及主节点和工作节点，这些节点在 Azure（和 Azure Stack Hub）中部署为 VM。

• 控制平面节点（master）提供核心 Kubernetes 服务并编排应用程序工作负载。
• 工作器节点（工作器）运行应用程序工作负荷。

在为初始部署选择虚拟机大小时，需要注意以下几点：

• 成本 - 规划工作器节点时，请记住每个 VM 产生的总体成本。 例如，如果应用程序工作负荷需要有限的资源，则应计划部署较小的 VM。 Azure Stack Hub（如 Azure）通常按消耗量计费，因此适当调整 Kubernetes 角色的 VM 大小对于优化消耗成本至关重要。

• 可伸缩性 - 群集的可伸缩性可以通过扩大和缩小主节点与工作节点的数量，或者添加额外的节点池（目前在 Azure Stack Hub 上不可用）来实现。 可以通过容器见解（Azure Monitor 和 Log Analytics）收集的性能数据来缩放群集。

  如果应用程序需要更多（或更少的）资源，则可以水平横向扩展（或缩小）当前节点（介于 1 到 50 个节点之间）。 如果需要 50 个以上的节点，可以在单独的订阅中创建其他群集。 在不重新部署群集的情况下，无法将实际 VM 纵向扩展到另一个 VM 大小。

  缩放是通过使用最初用于部署 Kubernetes 群集的 AKS 引擎辅助虚拟机手动完成的。 有关详细信息，请参阅 扩展 Kubernetes 群集

• 配额 - 在 Azure Stack Hub 上规划 AKS 部署时，请考虑您所配置的 配额。 请确保每个订阅都具有适当计划并配置了配额。 订阅需要适应群集横向扩展所需的计算、存储和其他服务量。

• 应用程序工作负荷 - 请参阅 Azure Kubernetes 服务文档的 Kubernetes 核心概念中的群集和工作负载概念。 本文可帮助你根据应用程序的计算和内存需求确定适当的 VM 大小。

应用程序（应用程序级别）

在应用程序层上，我们使用 Kubernetes 水平 Pod 自动缩放程序 (HPA)。 HPA 可以根据不同的指标（如 CPU 使用率）来增加或减少部署中的副本数（Pod/容器实例）。

另一个选项是垂直缩放容器实例。 这可以通过更改特定部署所请求和可用的 CPU 和内存量来实现。 有关详细信息，请参阅 kubernetes.io 上的管理容器资源。

网络和连接注意事项

网络和连接还影响 Azure Stack Hub 上的 Kubernetes 前面提到的三个层。 下表显示了层及其包含的服务：

层	影响	什么？
应用程序	应用程序	应用程序是如何访问的？ 它会向 Internet 公开吗？
群集	Kubernetes 群集	Kubernetes API、AKS 引擎 VM、拉取容器映像（流出量）、发送监视数据和遥测（流出量）
基础设施	Azure Stack Hub	Azure Stack Hub 管理终结点（例如门户和 Azure 资源管理器终结点）的可访问性。

应用程序

对于应用程序层，最重要的考虑因素是应用程序是否公开并从 Internet 访问。 从 Kubernetes 的角度来看，Internet 可访问性意味着使用 Kubernetes 服务或入口控制器公开部署或 Pod。

通过负载均衡器或入口控制器公开使用公共 IP 的应用程序并不意味着应用程序现在可通过 Internet 访问。 Azure Stack Hub 可以有一个仅在本地 Intranet 上可见的公共 IP 地址，并非所有公共 IP 都真正面向 Internet。

上一个块对应用程序的入口流量进行了考虑。 成功部署 Kubernetes 的另一个考虑因素是出站/出口流量。 下面是一些需要出口流量的用例：

• 拉取存储在 DockerHub 或 Azure 容器注册表上的容器映像
• 检索 Helm 图表
• 发出 Application Insights 数据（或其他监视数据）

某些企业环境可能需要使用 透明 或 非透明 代理服务器。 这些服务器需要在群集的各个组件上进行特定配置。 AKS 引擎文档包含有关如何容纳网络代理的各种详细信息。 有关详细信息，请参阅 AKS 引擎和代理服务器

最后，跨群集流量必须在 Azure Stack Hub 实例之间流动。 示例部署由在单个 Azure Stack Hub 实例上运行的单个 Kubernetes 群集组成。 它们之间的流量（例如两个数据库之间的复制流量）是“外部流量”。外部流量必须通过站点到站点 VPN 或 Azure Stack Hub 公共 IP 地址进行路由，才能在两个 Azure Stack Hub 实例上连接 Kubernetes：

群集之间 的流量

群集

Kubernetes 群集不一定需要通过 Internet 访问。 相关部分是用于运行群集的 Kubernetes API，例如，使用 kubectl。 运行群集或在其上部署应用程序和服务的每个人都必须能够访问 Kubernetes API 终结点。 在以下 部署（CI/CD）注意事项部分 中，从 DevOps 的角度更加详细地介绍了这一主题。

在群集级别，还有一些关于出口流量的注意事项：

• 节点更新（适用于 Ubuntu）
• 监视数据（发送到 Azure LogAnalytics）
• 需要出站流量的其他代理（特定于每个部署人员的环境）

在使用 AKS 引擎部署 Kubernetes 群集之前，请规划最终的网络设计。 将群集部署到现有网络可能更高效，而不是创建专用虚拟网络。 例如，可以使用已在 Azure Stack Hub 环境中配置的现有站点到站点 VPN 连接。

基础结构

基础设施是指访问 Azure Stack Hub 管理终结点。 终结点包括租户和管理门户，以及 Azure 资源管理器管理员和租户终结点。 需要这些终结点才能操作 Azure Stack Hub 及其核心服务。

数据和存储注意事项

将在两个 Azure Stack Hub 实例上的两个独立的 Kubernetes 集群中部署我们应用程序的两个实例。 此设计要求我们考虑如何在它们之间复制和同步数据。

借助 Azure，我们内置了跨云中的多个区域和区域复制存储的功能。 目前，Azure Stack Hub 没有本机方法可以跨两个不同的 Azure Stack Hub 实例复制存储——它们各自形成独立的云，没有统筹管理它们的方法。 规划跨 Azure Stack Hub 运行的应用程序的复原能力会强制你在应用程序设计和部署中考虑这种独立性。

在大多数情况下，在 AKS 上部署的可复原且高度可用的应用程序不需要存储复制。 但在应用程序设计中，应考虑每个 Azure Stack Hub 实例的独立存储。 如果此设计成为在 Azure Stack Hub 上部署解决方案的问题或障碍，则可以使用 Microsoft 合作伙伴的潜在解决方案来提供存储附件。 存储附加功能在多个 Azure Stack Hub 和 Azure 之间提供存储复制解决方案。 有关详细信息，请参阅 合作伙伴解决方案。

在我们的体系结构中，这些层被视为：

配置

配置包括 Azure Stack Hub、AKS 引擎和 Kubernetes 群集本身的配置。 配置应尽可能自动化，并将其存储为基于 Git 的版本控制系统（如 Azure DevOps 或 GitHub）中的基础结构即代码。 这些设置无法在多个部署之间轻松同步。 因此，我们建议从外部存储和应用配置，并使用 DevOps 管道。

应用程序

应用程序应存储在基于 Git 的存储库中。 每当有新的部署、应用程序更改或灾难恢复时，都可以使用 Azure Pipelines 轻松部署它。

数据

数据是大多数应用程序设计中最重要的考虑因素。 应用程序数据必须在应用程序的不同实例之间保持同步。 如果发生中断，数据还需要备份和灾难恢复策略。

实现此设计在很大程度上取决于技术选择。 下面是在 Azure Stack Hub 上以高可用性方式实现数据库的一些解决方案示例：

• 将 SQL Server 2016 可用性组部署到 Azure 和 Azure Stack Hub
• 将高度可用的 MongoDB 解决方案部署到 Azure 和 Azure Stack Hub

对于高可用性和可复原的解决方案来说，跨多个位置处理数据时的考虑因素是一个更复杂的考虑因素。 考虑：

• Azure Stack Hub 之间的延迟和网络连接。
• 服务和权限的标识可用性。 每个 Azure Stack Hub 实例都与外部目录集成。 在部署期间，你可以选择使用 Microsoft Entra ID 或 Microsoft Entra ID 联合。 因此，有可能使用单个标识来与多个独立的 Azure Stack Hub 实例进行交互。

业务连续性和灾难恢复

业务连续性和灾难恢复（BCDR）是 Azure Stack Hub 和 Azure 中的一个重要主题。 主要区别在于，在 Azure Stack Hub 中，作员必须管理整个 BCDR 过程。 在 Azure 中，BCDR 的某些部分由Microsoft自动管理。

BCDR 会影响上一部分中提到的相同区域 数据和存储注意事项：

• 基础结构/配置
• 应用程序可用性
• 应用程序数据

如前一部分所述，这些领域是 Azure Stack Hub作员的责任，组织之间可能有所不同。 根据可用的工具和进程规划 BCDR。

基础结构和配置

本部分介绍物理和逻辑基础结构以及 Azure Stack Hub 的配置。 其中包括管理员和租户空间中的操作。

Azure Stack Hub作员（或管理员）负责维护 Azure Stack Hub 实例。 包括本文范围之外的网络、存储、标识和其他主题等组件。 若要进一步了解 Azure Stack Hub 的运作详情，请参阅以下资源：

• 使用基础结构备份服务 恢复 Azure Stack Hub 中的数据
• 从管理员门户为 Azure Stack Hub 启用备份
• 从灾难性数据丢失中恢复
• 基础结构备份服务最佳做法

Azure Stack Hub 是将在其中部署 Kubernetes 应用程序的平台和构造。 Kubernetes 应用程序的所有者将是 Azure Stack Hub 的用户，并获得访问权限以部署解决方案所需的应用程序基础设施。 在这种情况下，应用程序基础结构是指使用 AKS 引擎部署的 Kubernetes 群集，以及周围的服务。 这些组件部署在 Azure Stack Hub 中，受 Azure Stack Hub 产品/服务的约束。 确保 Kubernetes 应用程序所有者接受的产品/服务有足够的容量（以 Azure Stack Hub 配额表示）来部署整个解决方案。 如上一部分所述，应用程序部署应使用基础结构即代码和部署管道（如 Azure DevOps Azure Pipelines）自动部署。

有关 Azure Stack Hub 套餐和配额的详细信息，请参阅 Azure Stack Hub 服务、计划、套餐和订阅概述

请务必安全地保存和存储 AKS 引擎配置，包括其输出。 这些文件包含用于访问 Kubernetes 群集的机密信息，因此必须保护它不被公开给非管理员。

应用程序可用性

应用程序不应依赖于已部署实例的备份。 作为标准做法，请完全按照基础结构即代码模式重新部署应用程序。 例如，使用 Azure DevOps Azure Pipelines 重新部署。 BCDR 过程应涉及将应用程序重新部署到相同或另一个 Kubernetes 群集。

应用程序数据

应用程序数据是最大程度减少数据丢失的关键部分。 在上一部分中，介绍了在应用程序的两个（或更多）实例之间复制和同步数据的技术。 根据用于存储数据的数据库基础结构（MySQL、MongoDB、MSSQL 或其他），将有不同的数据库可用性和备份技术可供选择。

实现完整性的建议方法是使用以下任一方法：

• 特定数据库的本机备份解决方案。
• 一种备份解决方案，它正式支持备份和恢复应用程序使用的数据库类型。

重要

不要将备份数据存储在应用程序数据所在的同一 Azure Stack Hub 实例上。 Azure Stack Hub 实例完全中断也会损害备份。

可用性注意事项

通过 AKS 引擎部署的 Azure Stack Hub 上的 Kubernetes 不是托管服务。 它是使用 Azure 基础结构即服务（IaaS）的 Kubernetes 群集的自动部署和配置。 因此，它提供与底层基础结构相同的可用性。

Azure Stack Hub 基础结构已经具备故障复原能力，并提供可用性集等功能，用于跨多个 故障域与更新域分发组件。 但是，如果发生硬件故障，基础技术（故障转移群集）仍会导致 VM 在受影响的物理服务器上发生一些停机。

最好将生产 Kubernetes 群集和工作负荷部署到两个（或更多）群集。 这些群集应托管在不同的位置或数据中心，并使用 Azure 流量管理器等技术基于群集响应时间或地理位置路由用户。

拥有单个 Kubernetes 群集的客户通常连接到给定应用程序的服务 IP 或 DNS 名称。 在多群集部署中，客户应连接到流量管理器 DNS 名称，该名称指向每个 Kubernetes 群集上的服务/入口。

备注

此模式也是 Azure 中（托管）AKS 群集的最佳做法。

通过 AKS 引擎部署的 Kubernetes 群集本身应包含至少三个主节点和两个工作器节点。

标识和安全注意事项

标识和安全性是重要的主题。 尤其是在解决方案跨越独立的 Azure Stack Hub 实例时。 Kubernetes 和 Azure（包括 Azure Stack Hub）都具有不同的基于角色的访问控制机制（RBAC）：

• Azure RBAC 控制对 Azure（和 Azure Stack Hub）中的资源的访问，包括创建新 Azure 资源的功能。 可以将权限分配给用户、组或服务主体。 （服务主体是应用程序使用的安全标识。
• Kubernetes RBAC 控制对 Kubernetes API 的权限。 例如，创建 Pod 和列出 Pod 是可以通过 RBAC 向用户授权（或拒绝）的操作。 若要向用户分配 Kubernetes 权限，请创建角色和角色绑定。

Azure Stack Hub 标识和 RBAC

Azure Stack Hub 提供两个标识提供者选择。 使用的提供程序取决于所在环境以及运行状态（连接或断开）。

• Microsoft Entra ID - 只能在连接的环境中使用。
• Microsoft Entra ID 与传统 Active Directory 林的联合 - 可以在连接或断开连接的环境中使用。

标识提供者管理用户和组，包括用于访问资源的身份验证和授权。 可以向 Azure Stack Hub 资源（例如订阅、资源组和单个资源（例如 VM 或负载均衡器）授予访问权限。 若要具有一致的访问模型，应考虑对所有 Azure Stack Hub 使用相同的组（直接或嵌套）。 下面是配置示例：

使用 Azure Stack Hub 的嵌套Microsoft Entra ID 组的

该示例包含用于特定用途的专用组。 例如，若要为在特定 Azure Stack Hub 实例上包含我们 Kubernetes 群集基础结构的 Resource Group（此处为“Seattle K8s 群集贡献者”）提供贡献者权限。 然后，这些组嵌套到包含每个 Azure Stack Hub 的“子组”的总体组中。

我们的示例用户现在对包含整个 Kubernetes 基础结构资源的两个资源组具有“参与者”权限。 用户有权访问 Azure Stack Hub 实例上的资源，因为实例共享相同的标识提供者。

重要

这些权限仅影响 Azure Stack Hub 及其上部署的某些资源。 具有此级别访问权限的用户可能会造成很大损害，但需要额外权限才能访问 Kubernetes 部署中的 IaaS VM 和 Kubernetes API。

Kubernetes 标识和 RBAC

默认情况下，Kubernetes 群集不使用与底层 Azure Stack Hub 相同的标识提供者。 托管 Kubernetes 群集、主节点和辅助角色节点的 VM 使用群集部署期间指定的 SSH 密钥。 使用此 SSH 密钥才能使用 SSH 连接到这些节点。

Kubernetes API（例如使用 kubectl 进行访问）还受到服务帐户（包括默认的“群集管理员”服务帐户）的保护。 此服务帐户的凭据最初存储在 Kubernetes 主节点上的 .kube/config 文件中。

机密管理和应用程序凭据

若要存储连接字符串或数据库凭据等机密，有多种选择，包括：

• Azure Key Vault
• Kubernetes 机密
• 第三方解决方案（如 HashiCorp Vault）（在 Kubernetes 上运行）

不要在配置文件、应用程序代码或脚本中以纯文本形式存储机密或凭据。 不要将它们存储在版本控制系统中。 相反，部署自动化应根据需要检索机密。

修补和更新

Azure Kubernetes 服务中的 修补和更新（PNU） 过程是部分自动化的。 Kubernetes 版本升级需要手动触发，而安全更新则是自动应用的。 这些更新可能包括 OS 安全修补程序或内核更新。 AKS 不会自动重新启动这些 Linux 节点以完成更新过程。

使用 Azure Stack Hub 上的 AKS 引擎部署的 Kubernetes 群集的 PNU 过程不受管理，并且由群集作员负责。

AKS 引擎可帮助完成两项最重要的任务：

• 升级到较新的 Kubernetes 和基础 OS 映像版本
• 仅升级基础 OS 映像

较新的基础 OS 映像包含最新的 OS 安全修补程序和内核更新。

无人参与升级机制会自动安装在 Azure Stack Hub 市场提供新基础 OS 映像版本之前发布的安全更新。 默认情况下启用无人参与升级并自动安装安全更新，但不重新启动 Kubernetes 群集节点。 可以使用开源 Kubernetes 重启守护程序 (kured)) 自动执行节点重启。 Kured 监视需要重新启动的 Linux 节点，然后自动处理正在运行的 Pod 和节点重启过程的重新安排。

部署 (CI/CD) 注意事项

Azure 和 Azure Stack Hub 公开相同的 Azure 资源管理器 REST API。 这些 API 的寻址方式与任何其他 Azure 云（Azure、Azure 中国世纪互联、Azure 政府）一样。 云之间的 API 版本可能存在差异，Azure Stack Hub 仅提供一部分服务。 管理终结点 URI 对于每个云以及 Azure Stack Hub 的每个实例也有所不同。

除了提到的细微差异之外，Azure 资源管理器 REST API 还提供与 Azure 和 Azure Stack Hub 交互的一致方式。 此处可以使用同一组工具，就像用于任何其他 Azure 云一样。 可以使用 Jenkins 或 PowerShell 等 Azure DevOps 工具将服务部署到 Azure Stack Hub 并安排服务。

注意事项

在 Azure Stack Hub 部署方面，主要区别之一是 Internet 可访问性问题。 Internet 可访问性决定是否为 CI/CD 作业选择 Microsoft 托管的生成代理或自托管生成代理。

自托管代理可以在 Azure Stack Hub 上（作为 IaaS 虚拟机）运行，或在能够访问 Azure Stack Hub 的网络子网上运行。 转到 Azure Pipelines 代理，了解有关差异的详细信息。

下图可帮助你确定是否需要自承载或Microsoft托管生成代理：

• Azure Stack Hub 管理终结点是否可通过 Internet 访问？
  • 是：可以将 Azure Pipelines 与 Microsoft 托管的代理配合使用，以连接到 Azure Stack Hub。
  • 否：我们需要能够连接到 Azure Stack Hub 管理终结点的自承载代理。
• Kubernetes 群集是否可通过 Internet 访问？
  • 是：可以将 Azure Pipelines 与 Microsoft 托管的代理配合使用，以便直接与 Kubernetes API 终结点交互。
  • 否：我们需要可连接到 Kubernetes 群集 API 终结点的自承载代理。

在可通过 Internet 访问 Azure Stack Hub 管理终结点和 Kubernetes API 的情况下，部署可以使用Microsoft托管的代理。 此部署会导致应用程序体系结构，如下所示：

如果无法通过 Internet 直接访问 Azure 资源管理器终结点、Kubernetes API 或两者，则可以使用自承载生成代理来运行管道步骤。 此设计需要更少的连接性，并且只能使用与 Azure 资源管理器终结点和 Kubernetes API 的本地网络连接进行部署：

备注

断开连接的场景怎么样？ 在 Azure Stack Hub 或 Kubernetes 或两者都没有面向 Internet 的管理终结点的情况下，仍可以使用 Azure DevOps 进行部署。 可以使用自托管代理池（即在本地或 Azure Stack Hub 上运行的 DevOps 代理）或完全自托管的本地 Azure DevOps Server。 自承载代理只需要出站 HTTPS (TCP/443) Internet 连接。

该模式可以在每个 Azure Stack Hub 实例上使用由 AKS 引擎部署和管理的 Kubernetes 集群。 它包括一个由前端、中间层、后端服务（例如 MongoDB）和基于 nginx 的入口控制器组成的应用程序。 可以使用“外部数据存储”，而不是使用 K8s 群集上托管的数据库。 数据库选项包括 MySQL、SQL Server 或 Azure Stack Hub 外部或 IaaS 中托管的任何类型的数据库。 此类配置不在此处的作用域内。

合作伙伴解决方案

有Microsoft合作伙伴解决方案可以扩展 Azure Stack Hub 的功能。 这些解决方案在部署 Kubernetes 群集上运行的应用程序时非常有用。

存储和数据解决方案

如 数据和存储注意事项中所述，Azure Stack Hub 目前没有原生解决方案来跨多个实例进行存储复制。 与 Azure 不同，跨多个区域复制存储的功能不存在。 在 Azure Stack Hub 中，每个实例都是其自己的不同云。 但是，解决方案可从Microsoft合作伙伴获取，这些合作伙伴支持跨 Azure Stack Hub 和 Azure 进行存储复制。

SCALITY

Scality 提供自 2009 年以来为数字企业提供支持的 Web 规模存储。 Scality RING 是我们软件定义的存储，可将商用 x86 服务器转变为无限制的存储池，用于存储 PB 级的任何类型的数据（文件和对象）。

CLOUDIAN

Cloudian 简化了企业存储，使用无限的可缩放存储将大型数据集合并到单个易于管理的环境。

后续步骤

若要详细了解本文中介绍的概念：

• Azure Stack Hub 中的跨云缩放 和 异地分布式应用模式。
• Azure Kubernetes 服务（AKS）上的微服务体系结构。

准备好测试解决方案示例时，请继续阅读 高可用性 Kubernetes 群集部署指南。 部署指南提供了部署和测试其组件的分步说明。