在 Azure Stack HCI 或 Windows Server 上使用 Arc 启用的 AKS 部署和操作应用

本文的信息提供有关在 Azure Arc 启用的 Azure Kubernetes 服务上为容器化应用生成应用部署管道的建议。这些应用可以在 Azure Stack HCI 或 Windows Server 上运行。 具体而言，本指导适用于使用 Azure Arc 和 GitOps 的部署。

体系结构

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

工作流

该体系结构说明了在运行在 Azure Stack HCI 或 Windows Server 上的 AKS 群集上部署容器化应用程序的实现。 它使用 GitOps 来管理基础结构即代码 (IaC)。

1. 运营商在 Azure Stack HCI 或能够托管 AKS 群集的 Windows Server 硬件上设置本地基础结构。
2. 在本地，管理员在 Azure Stack HCI 或 Windows Server 基础结构上部署 AKS 群集，并使用 Azure Arc 将群集连接到 Azure。为了启用 GitOps，管理员还会将 Flux 扩展及其配置部署到 AKS 群集。
3. GitOps 配置有助于 IaC。 这些 GitOps 配置表示 AKS 群集的所需状态，并使用本地管理提供的信息。 本地管理是指部署在 Azure Stack HCI 或 Windows Server 上的 AKS 群集提供的管理工具、接口和做法。
4. 管理员会将 GitOps 配置推送到 Git 存储库。 还可以使用 Helm 或 Kustomize 存储库。 AKS 群集中的 Flux 组件监视存储库中的更改，并根据需要检测和应用更新。
5. 当对存储库中的配置进行更改时，AKS 群集中的 Flux 扩展会收到来自 GitOps 流的通知。 它使用 Helm 图表或 Kustomize 自动触发所需配置的部署。
6. 以新的或更新的配置或代码形式对应用程序所做的更改将推送到指定的存储库，包括相应的容器映像更新。 这些容器映像更新将推送到专用或公共容器注册表。
7. AKS 群集中的 Flux 运算符检测存储库中的更改，并将其部署到群集。
8. 更改以滚动方式在群集上实现，以确保最短的故障时间并保留群集的所需状态。

组件

• Azure Stack HCI 是超融合基础结构 (HCI) 解决方案，可用于在本地运行虚拟化工作负载。 它结合使用软件定义的计算、存储和网络技术。 它基于 Windows Server 构建，并与 Azure 服务集成，以提供混合云体验。
• Azure Stack HCI 上的 AKS 可支持开发人员和管理员使用 AKS 在 Azure Stack HCI 上部署和管理容器化应用。
• Azure Arc 是一种混合云管理解决方案，可用于跨本地、多云和边缘环境管理服务器、Kubernetes 群集和应用程序。 它提供统一的管理体验，支持你使用 Azure 管理服务（例如 Azure Policy、Microsoft Defender for Cloud 和 Azure Monitor）跨不同环境治理资源。
• Git、Helm 和 Bitbucket 存储库（公共和专用）可以托管 GitOps 配置，包括 Azure DevOps 和 GitHub 存储库。
• 容器注册表（公共和专用）包括 Azure 容器注册表和 Docker Hub，可托管容器映像。
• Azure Pipelines 是一种持续集成 (CI) 和持续交付 (CD) 服务，可自动更新存储库和注册表。
• Flux 是已启用 Azure Arc 的 Kubernetes 群集可以使用的开放源代码 GitOps 部署工具。 可以使用 Azure Arc 连接实现群集组件，可用于跟踪对指定的 Git、Helm 或 Kustomize 存储库所做的更改并将其应用于本地群集。 Flux 运算符会定期（或基于触发器）检查现有群集配置，以确保它与 Git 存储库中的配置相匹配。 如果检测到差异，Flux 会通过应用或重新应用（如果出现配置偏移）所需的配置来修正差异。

方案详细信息

大规模运行容器需要使用业务流程协调程序来自动执行计划、部署、网络、缩放、运行状况监视和容器管理。 Kubernetes 是面向新容器化部署的常用业务流程协调程序。 随着 Kubernetes 群集和环境数量的增长，单独管理它们可能比较困难。 使用已启用 Azure Arc 的服务（如已启用 Azure Arc 的 Kubernetes、GitOps、Azure Monitor 和 Azure Policy）可减轻管理负担，并帮助解决此难题。

注意事项

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

架构良好的框架提供了有助于评估和优化基于云的解决方案优势的指导原则。 鉴于本地 AKS 部署与 Azure 技术的固有集成，最好将框架建议应用于 GitOps 的设计和实现。

可靠性

可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。

• 使用 Kubernetes 的高可用性功能来确保基于 GitOps 的解决方案的高可用性。
• 使用 Flux v2 可进一步提高跨多个位置或群集的部署中应用程序的可用性。
• 使用自动部署可减少人为错误的可能性。
• 将 CI/CD 管道集成到体系结构中，以提高自动测试的有效性。
• 跟踪所有代码更改，以便快速识别和解决问题。 要跟踪这些操作更改，请使用 GitHub 或 Azure DevOps 的内置功能。 可以使用这些工具实现策略和自动化，以确保更改可以跟踪、遵循适当的审批过程且可维护。

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。

• 了解体系结构的安全优势。 使用 Flux v2、Kustomize、GitOps 和 DevOps 管道，可通过自动化应用操作更改。 可以通过利用分支保护、拉取请求评审和不可变历史记录等机制来控制和审核实现这些操作做法的代码。 IaC 方法无需管理访问基础结构的权限，并支持最低特权原则。 对基于命名空间的配置范围界定的 Flux 支持有助于实施多租户方案。

• 了解加密。 为了帮助确保数据安全，群集配置服务可将 Flux 配置资源数据存储在 Azure Cosmos DB 数据库中，并对其进行静态加密。

• 考虑使用专用终结点。 GitOps 支持 Azure 专用链接，以实现到 Azure Arc 相关服务的连接。

使用 Azure 策略和 Azure Arc

Azure Arc 将资源管理的范围扩展到 Azure 之外。 扩展的范围提供了一系列适用于物理服务器和虚拟服务器的优势。 在 AKS 的上下文中，这些优势包括：

• 治理。 Azure Arc 可以使用适用于 Kubernetes 的 Azure Policy 和相应策略符合性的集中报告来强制实施可影响 AKS 群集及其 Pod 的运行时治理。 例如，可使用此功能来强制使用 HTTPS 来传递流向 Kubernetes 群集的入口流量，或者确保容器仅侦听指定的特定端口。
• 改进的操作。 Azure Arc 通过 GitOps 提供对自动化群集配置的增强支持。

Azure Policy 通过内置的将 GitOps 部署到 Kubernetes 群集策略定义来促进集中的 GitOps 管理。 分配此策略后，如果 Azure 资源管理器资源在分配范围内，则会自动将你选择的任何基于 GitOps 的配置应用到你指定的已启用 Azure Arc 的 Kubernetes 群集。

成本优化

成本优化就是减少不必要的费用和提高运营效率。 有关详细信息，请参阅成本优化支柱概述。

• 使用 GitOps 提供的自动化来最大程度地减少管理和维护开销。 简化的操作模型减少了维护工作量，并且降低了运营成本。

• 使用 Arc 启用的 AKS。AKS Arc 提供对自动缩放计算资源的内置支持，并增加了容器化所固有的工作负载密度。 自动缩放可以帮助你优化物理基础结构的大小，并加速执行数据中心合并计划，从而帮助你节省资金。

卓越运营

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅卓越运营支柱概述。

• 使用 GitOps 存储库可提供存储所有 AKS 应用程序和群集基础结构数据的单个事实来源。 这些存储库可用作将更改应用于群集的唯一组件。

• 利用 GitOps 与 DevOps 基础结构方法的集成，以缩短交付新软件版本所需的时间。 我们还建议使用 Azure 资源管理器和 Azure Arc 为基于云的和本地容器化工作负载构建一致的运营模型。 要控制不同级别的 GitOps 配置，请将 Azure Policy 与 Flux 运算符的功能结合使用。 通过这样做，可以在企业级别、单个 AKS 群集的级别，甚至群集中特定命名空间级别建立控制。

• 创建范围限定为群集的 GitOps 配置（或限定为多个群集），以实现容器化基础结构组件（如入口控制器、服务网格、安全产品和监视解决方案）的基线。 此操作有助于确保群集满足基线基础结构要求。

• 创建命名空间级别 GitOps 配置，以支持你在更精细的级别控制工作负载的资源（例如 pod、服务和入口路由），从而确保工作负载符合应用程序标准。 通过遵循这些准则，可以确保 AKS Arc 应用程序的部署和管理保持高效、有效且经济高效。

使用 GitOps

GitOps 非常适合 AKS 群集的管理。 Kubernetes 基于声明性模型。 代码中介绍了群集状态及其组件。 GitOps 将代码存储在 Git 存储库中，并使用它来定义目标环境的所需状态。

代码更改受版本控制、审核和可选评审和审批的约束。 可以使用评审和审批来自动触发 AKS 基础结构和容器化工作负载的更新。 GitOps 使用的是拉取模型，其中一组专用的群集组件会轮询存储库的状态。 当检测到更改时，AKS 托管的 GitOps 组件将检索并应用新配置。

GitOps 显著减少了对直接群集管理的需求，从而简化了操作模型并提高了安全性。 GitOps 支持最低特权原则。 例如，GitOps 无需通过 kubectl 手动修改群集，因此所需的权限更少。 GitOps 还提供了有关建议的策略更改的早期反馈。 早期反馈对开发人员特别有价值，因为它可以帮助他们降低与 bug 相关的风险和成本。

GitOps 简化了整个组织的群集配置的标准化工作，以满足合规性和治理要求。 可以定义要应用于每个群集及其组件的基线配置，例如，网络策略、角色绑定和 Pod 安全策略。 要在所有已启用 Azure Arc 的群集中实现该配置，可以面向资源组或订阅使用 Azure Policy。 这些策略会自动应用于现有资源，也会应用于在策略分配后创建的资源。

GitOps 可将群集与一个或多个 Git 存储库链接到一起。 可以使用每个存储库来描述群集配置的不同方面。 生成的声明性模型有助于通过清单文件自动预配和管理 Kubernetes 资源（如命名空间或部署）。 还可以使用 Helm 图表，这些图表与 Flux v2 和 Kustomize 一起使用，有助于自动部署容器化应用程序或描述特定于环境的更改的 Kustomize 文件。

使用 Flux

Flux 可实现为 Kubernetes 运算符。 它使用一组控制器和相应的声明性 API。 控制器可管理一组自定义资源，这些资源协同工作以提供预期功能。

GitOps 会在启用了 Azure Arc 的 Kubernetes 群集中启用为 Microsoft.KubernetesConfiguration/extensions/microsoft.flux 群集扩展。 安装 microsoft.flux 群集扩展后，可以创建一个或多个 fluxConfigurations 资源，以将配置源的内容同步到群集，并将群集调整到所需状态。

默认情况下，microsoft.flux 扩展会安装 Flux 控制器（源、Kustomize、Helm 和 通知），以及 FluxConfig 自定义资源定义 (CRD)、fluxconfig-agent和 fluxconfig-controller。 还可以选择要安装其中哪些控制器，并且可以选择性地安装 Flux image-automation 和 image-reflector 控制器，这有助于更新和检索 Docker 映像。

在创建 fluxConfigurations 资源时，为参数提供的值（例如目标 Git 存储库）可用于创建和配置在该群集中启用 GitOps 功能的 Kubernetes 对象。

在部署和配置 Flux v2 群集扩展时，它会提供以下组件和功能：

• source-controller。 监视自定义配置的源（如 Git 存储库、Helm 存储库和 S3 存储桶等云存储服务），并对这些源进行同步和授权。
• kustomize-controller。 监视基于 Kustomization CRD 的自定义资源，其中包含 Kubernetes 清单和原始 YAML 文件。 将清单和 YAML 文件应用于群集。
• helm-controller。 监视基于图表并存储在由 source-controller 显示的 Helm 存储库中的自定义资源。
• notification-controller。 管理源自 Git 存储库的入站事件和出站事件，例如面向 Microsoft Teams 或 Slack 的事件。
• FluxConfig CRD。 表示定义特定于 Flux 的 Kubernetes 对象的自定义资源。
• fluxconfig-agent。 检测新的和更新的 Flux 配置资源。 在群集上启动相应的配置更新。 将状态更改传达给 Azure。
• fluxconfig-controller。 监视 fluxconfigs 自定义资源。

Flux 版本 2 提供以下附加功能：

有关详细信息，请参阅 AKS 和已启用 Azure Arc 的 Kubernetes 的 GitOps Flux v2 配置。

性能效率

性能效率是指工作负荷能够以高效的方式扩展以满足用户对它的需求。 有关详细信息，请参阅性能效率要素概述。

群集工作负载受益于 Kubernetes 平台固有的可伸缩性和敏捷性。 Flux v2 提供了额外的敏捷性，从而减少了端到端软件交付所需的时间。

• 针对特定工作负载优化 Kubernetes 群集和基础结构设置。 建议与应用程序开发人员合作，以确定所需的设置。
• 使用 Kubernetes 中的自动缩放功能。 有关详细信息，请参阅 Azure Arc 启用的 AKS 中的群集自动缩放。
• 添加缓存以优化应用程序。
• 建立性能基线。 对体系结构进行基准测试，并使用指标和监视工具来识别影响性能的任何问题或瓶颈。

作者

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

主要作者：

• Sarah Cooley |首席项目经理
• Mike Kostersitz | 主要项目经理领导

其他参与者：

• Mick Alberts | 技术文档撰写人
• Nate Waters | 产品营销经理

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

后续步骤

• 快速入门：使用 Windows Admin Center 设置 AKS Arc
• 快速入门：使用 Windows Admin Center 在 AKS Arc 上创建本地 Kubernetes 群集
• 快速入门：使用 PowerShell 在 Azure Stack HCI 和 Windows Server 上设置 Azure Kubernetes 服务主机并部署工作负载群集
• 针对 AKS 和已启用 Azure Arc 的 Kubernetes 的 GitOps Flux v2 配置
• 教程：在已启用 Azure Arc 的 Kubernetes 或 AKS 群集中使用 GitOps with Flux v2
• 教程：通过 GitOps 实现 CI/CD (Flux v2)

相关资源

• Azure Stack HCI 上的 AKS 的基线体系结构
• Azure Stack HCI 上的 AKS 的网络体系结构
• 适用于 Kubernetes 群集的 Azure Arc 混合管理和部署