Azure Kubernetes 服务的 GitOps

Azure Kubernetes 服务 (AKS)

GitHub

GitOps 是一套操作和管理软件系统的原则。 本文介绍使用 GitOps 原则操作和管理 Azure Kubernetes 服务 (AKS) 群集的方法。

Flux、Argo CD、OPA Gatekeeper、Kubernetes 和 Git 徽标是各自公司的商标。 使用这些标志并不意味着认可。

体系结构

可与 AKS 配合使用的两个 GitOps operator 是 Flux 和 Argo CD。 它们都来自云原生计算基金会 (CNCF) 项目，并且得到广泛采用。 以下方案演示了其用法。

方案 1：将 GitOps 与 Flux 和 AKS 配合使用

演示 Flux v2、GitHub 和 AKS 的 GitOps 工作流示意图。 在左侧，开发人员将配置更改提交到 GitHub 存储库。 在中心，AKS 群集中的 Flux 运算符监视存储库中的更改。 当 Flux 检测到配置偏移时，它会从 GitHub 拉取最新配置。 右侧，Flux 将存储库中所需的状态与 AKS 群集中的实际状态进行协调，并根据需要应用更新。 该图显示了从开发人员到 GitHub、Flux 以及最后到 AKS 群集的配置更改流，并强调基于拉取的连续对帐过程。

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

方案 1 的数据流

Flux 是与 AKS 原生集成的 集群扩展。 群集扩展提供了一个平台，用于在 AKS 群集上安装和管理解决方案。 你可以使用 Azure 门户、Azure CLI 或基础结构即代码 (IaC) 脚本（例如 Terraform 或 Bicep 脚本）来启用 Flux 作为 AKS 的扩展。 你还可以使用 Azure Policy 在 AKS 群集上大规模应用 Flux v2 配置。 有关详细信息，请参阅 使用 Flux v2 配置和 Azure Policy 大规模部署应用程序。

Flux 可以将 Kubernetes 清单、Helm 图表和 Kustomization 文件部署到 AKS。 Flux 是基于轮询的过程，因此它可以检测、拉取和协调配置更改，而无需将群集终结点公开给生成代理。

在此方案中，Kubernetes 管理员可以更改 Kubernetes 配置对象（例如机密和 ConfigMap），并将更改直接提交到 GitHub 存储库。

以下数据流对应于上图：

1. 开发人员将配置更改提交到 GitHub 存储库。

2. Flux 检测 Git 存储库中的配置偏移并拉取配置更改。

3. Flux 协调 Kubernetes 群集中的状态。

方案 1 的替代方案

• 可以将 Flux 与其他 Git 存储库（例如 Azure DevOps、GitLab 和 Bitbucket）配合使用。

• 而不是使用 Git 存储库，Flux Bucket API 定义了一个源，用于从存储解决方案（如 Amazon S3 和 Google Cloud Storage 的 Bucket）生成对象的制品。 你也可以使用具有 S3 兼容 API 的解决方案。 两个示例包括 MinIO 和 Alibaba Cloud Object Storage Service （OSS），但还有其他解决方案。

• 你还可以针对 Azure Blob 存储容器将 Flux 配置为用于生成项目的源。 有关详细信息，请参阅 AKS 和已启用 Azure Arc 的 Kubernetes 的 GitOps Flux v2 配置。

• Flux v2 支持多租户架构，从而允许不同的团队将工作负载部署到同一个共享的 Kubernetes 群集。 可以将代表不同租户的多个 Git 存储库同步到群集。 为了确保团队之间的工作负荷隔离，每个团队可能在 AKS 群集中有自己的命名空间或命名空间，这些命名空间或命名空间通过 Kubernetes 基于角色的访问控制 （RBAC） 策略进行限制。

• Flux 可以使用一个群集来管理同一群集或其他群集中的应用。 具有 Flux 控制器的中心 AKS 群集负责通过 GitOps 将应用程序和基础设施工作负载持续交付到多个辐射 AKS 群集。

方案 2：将 GitOps 与 Flux、GitHub 和 AKS 配合使用以实现 CI/CD

显示包含 GitOps、Flux、GitHub 和 AKS 的 CI/CD 工作流的关系图。 在左侧，开发人员在集成开发环境（IDE）中编写应用程序代码并将其提交到 GitHub 存储库。 GitHub Actions 从代码生成容器映像，并将其推送到 Azure 容器注册表。 GitHub Actions 使用新的映像版本更新存储库中的 Kubernetes 清单文件。 在中心，AKS 群集中的 Flux 运算符监视存储库中的更改。 当 Flux 检测到更新的清单时，它会拉取配置并将新应用程序版本部署到 AKS 群集。 该图显示了代码和配置从开发人员到 GitHub 的流动，通过 CI/CD 自动化，到 Flux，最后流向 AKS 集群，并强调基于拉取的自动化部署过程。

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

方案 2 的数据流

此方案是适用于典型 Web 应用程序的基于拉取的 DevOps 管道。 该管道使用 GitHub Actions 进行生成。 对于部署，它使用 Flux 作为 GitOps operator 来拉取和同步应用。

以下数据流对应于上图：

1. 应用代码是使用集成开发环境（IDE）（如 Visual Studio Code）开发的。

2. 应用代码提交到 GitHub 存储库。

3. GitHub Actions 从应用代码生成容器映像，并将容器映像推送到 Azure 容器注册表。

4. GitHub Actions 根据容器注册表中容器映像的版本号，使用当前映像版本来更新 Kubernetes 清单部署文件。

5. Flux operator 检测 Git 存储库中的配置偏差，并拉取配置更改。

6. Flux 使用清单文件将应用部署到 AKS 群集。

方案 3：使用 Argo CD、GitHub 存储库和 AKS 的 GitOps

显示包含 Argo CD、GitHub 和 AKS 的 GitOps 工作流的图表。 左侧是 Kubernetes 管理员编辑配置文件并将其提交到 GitHub 存储库。 在中心，AKS 群集中的 Argo CD 监视存储库中的更改。 当 Argo CD 检测到更新的配置时，它会拉取更改，并将所需状态与 AKS 群集中的实际状态协调。 该图突出显示了从管理员到 GitHub、Argo CD 以及最后到 AKS 群集的配置流，并强调基于拉取的、持续对帐过程以及 Argo CD 作为管理应用程序状态的控制器的角色。

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

方案 3 的数据流

可以在 AKS 中将 Argo CD 启用为群集扩展。 在此方案中，Kubernetes 管理员可以更改 Kubernetes 配置对象（例如机密和 ConfigMap），并将更改直接提交到 GitHub 存储库。

以下数据流对应于上图：

1. Kubernetes 管理员在 YAML 文件中进行配置更改，并将更改提交到 GitHub 存储库。

2. Argo CD 从 Git 存储库拉取更改。

3. Argo CD 协调 AKS 群集的配置更改。

Argo CD 不必自动将所需目标状态同步到 AKS 群集。 它实现为 Kubernetes 控制器，可持续监视正在运行的应用程序。 它将 AKS 群集的当前实时状态与 Git 存储库中指定的所需目标状态进行比较。 Argo CD 报告并直观显示差异，并提供工具自动或手动将实时状态同步回所需目标状态。

Argo CD 提供基于浏览器的用户界面。 可以使用该界面来添加应用程序配置，观察群集相关的同步状态，以及针对群集启动同步。 还可以使用 Argo CD 命令行执行这些任务。 用户界面和命令行接口都提供用于查看配置更改历史记录和回滚到先前版本的功能。

默认不会公开 Argo CD 用户界面和 API 服务器。 若要访问它们，我们建议创建一个具有内部 IP 地址的入口控制器。 或者，可以使用 内部负载均衡器 来公开它们。

方案 3 的替代方案

与 Git 兼容的任何存储库（包括 Azure DevOps）都可以充当配置源存储库。

方案 4：将 GitOps 与 Argo CD、GitHub Actions 和 AKS 配合使用来实现 CI/CD

将 GitOps 与 Argo CD、GitHub 和 AKS 配合使用的 CI/CD 工作流示意图。 在左侧，开发人员编写应用程序代码并将其提交到 GitHub 存储库。 GitHub Actions 生成容器映像，将其推送到容器注册表，并使用新的映像版本更新存储库中的 Kubernetes 清单文件。 在中心，AKS 群集中的 Argo CD 监视存储库中的更改、拉取更新的配置，并将新的应用程序版本部署到 AKS 群集。 该图显示了从开发人员到 GitHub 的代码和配置流，通过 CI/CD 自动化，到 Argo CD，最后流向 AKS 群集，重点介绍基于拉取的自动化部署过程。

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

方案 4 的数据流

此方案是适用于典型 Web 应用程序的基于拉取的 DevOps 管道。 该管道使用 GitHub Actions 进行生成。 对于部署，它使用 Argo CD 作为 GitOps operator 来拉取和同步应用。

以下数据流对应于上图：

1. 应用代码是使用 Visual Studio Code 等 IDE 开发的。

2. 应用代码提交到 GitHub 存储库。

3. GitHub Actions 从应用代码生成容器映像，并将容器映像推送到容器注册表。

4. GitHub Actions 根据容器注册表中容器映像的版本号，使用当前映像版本来更新 Kubernetes 清单部署文件。

5. Argo CD 从 Git 存储库拉取数据。

6. Argo CD 将应用部署到 AKS 群集。

方案 4 的替代方案

与 Git 兼容的任何存储库（包括 Azure DevOps）都可以充当配置源存储库。

方案详细信息

GitOps 是一套操作和管理软件系统的原则。

• 它使用源代码管理作为系统的单一事实源。

• 它将版本控制、协作、合规性、持续集成和持续部署（CI/CD）等开发做法应用于基础结构自动化。

• 你可以将其应用于任何软件系统。

GitOps 通常用于 Kubernetes 群集管理和应用程序交付。

根据 GitOps 原则，GitOps 托管系统的所需状态必须满足以下条件：

• 声明： GitOps 管理的系统必须以声明方式表达其所需状态。 声明通常存储在 Git 存储库中。

• 版本控制且不可变： 所需状态以强制实施不可变性和版本控制的方式存储，并保留完整的版本历史记录。

• 自动拉取： 软件代理会自动从源拉取所需状态声明。

• 持续协调： 软件代理会持续观察实际的系统状态，并尝试应用所需的状态。

在 GitOps 中， IaC 使用代码声明所需的基础结构组件状态，例如虚拟机（VM）、网络和防火墙。 此代码受版本控制，且可进行审核。

Kubernetes 使用清单以声明方式描述从群集状态到应用程序部署的所有内容。 GitOps for Kubernetes 将群集基础结构所需状态置于版本控制之下。 群集中的组件（通常称为 运算符）会持续同步声明性状态。 使用这种方法可以审查和审核影响群集的代码更改。 它通过支持最低特权原则（PoLP）来增强安全性。

GitOps 代理持续地使系统状态与存储在代码存储库中的所需状态相协调。 某些 GitOps 代理可以还原在群集外部执行的操作，例如手动创建 Kubernetes 对象。 例如， 允许控制器 在创建、更新和删除作期间对对象强制实施策略。 你可以使用许可控制器来确保仅当源存储库中的部署代码发生更改时才更改部署。

可以将策略管理和强制工具与 GitOps 结合使用来强制实施策略，并为建议的策略更改提供反馈。 可以为各个团队配置通知，让他们了解当前的 GitOps 状态。 例如，可以发送部署成功和协调失败的通知。

GitOps 用作单一事实源

GitOps 提供群集状态的一致性和标准化，有助于增强安全性。 你还可以使用 GitOps 来确保多个群集之间的状态一致。 例如，GitOps 可以跨主要群集和灾难恢复（DR）群集或群集场应用相同的配置。

若要强制 GitOps 作为更改群集状态的唯一方法，请限制对群集的直接访问。 若要设置此配置，请使用 Azure 基于角色的访问控制（Azure RBAC）、允许控制器或其他工具。

使用 GitOps 启动初始配置

有时需要 AKS 群集部署作为基线配置的一部分。 例如，在部署应用程序工作负荷之前，可能需要部署共享服务或系统级配置。 这些共享服务可以配置以下加载项和工具：

• AKS 加载项，例如 Microsoft Entra 工作负荷 ID 和 用于机密存储 CSI 驱动程序的 Azure Key Vault 提供程序

• Prisma Cloud Defender 等合作伙伴工具

• 开源工具，例如 Kubernetes 事件驱动的自动缩放（KEDA）、 ExternalDNS 和 Cert-manager

可以启用 Flux 作为创建 AKS 群集时应用的扩展。 然后，Flux 可将基线配置启动至群集。 AKS 群集的基线体系结构建议使用 GitOps 进行引导。 如果使用 Flux 扩展，则可以在部署后不久启动群集。

其他 GitOps 工具和加载项

可以将所述的方案扩展到其他 GitOps 工具。 Jenkins X 是另一个 GitOps 工具，它提供集成到 Azure 的指令。 可以使用 Flagger 等渐进式交付工具逐步转移通过 GitOps 部署的生产工作负载。

可能的用例

此解决方案有利于希望部署应用程序和 IaC 的组织，并维护每项更改的审核线索。

GitOps 简化了开发人员的容器管理，从而提高了工作效率。 开发人员可以继续使用他们熟悉的工具（例如 Git）来管理更新和新功能。

注意事项

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

可靠性

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅可靠性设计评审核对清单。

如果群集不可用，GitOps 应用作创建新群集的一部分。 它使用 Git 存储库作为 Kubernetes 配置和应用程序逻辑的单一事实源。 它可以创建并应用群集配置和应用程序部署作为缩放单元，并且可以建立 部署标记 模式。

安全性

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

使用 GitOps 方法，单个开发人员或管理员不会直接访问 Kubernetes 群集来应用更改或更新。 相反，用户会将更改推送到 Git 存储库和 GitOps 操作员（如 Flux 或 Argo CD），读取更改并将其应用到群集。 此方法通过不向 DevOps 团队提供对 Kubernetes API 的写入权限来遵循最小特权的最佳安全做法。 在诊断或故障排除方案中，你可以根据具体情况在有限时间内授予群集权限。

除了配置存储库权限之外，请考虑在与 AKS 群集同步的 Git 存储库中实现以下安全措施：

• 分支保护：防止直接将更改推送到表示 Kubernetes 群集状态的分支。 使用拉取请求（PR）进行变更，并至少有一个人审查每个 PR。 此外，使用 PR 执行自动检查。

• PR 审阅： 要求 PR 至少有一位审阅者以强制执行双重审核原则。 还可以使用 GitHub 代码所有者功能来定义负责查看存储库中特定文件的个人或团队。

• 不可变的历史记录：仅允许在现有更改之上进行新的提交。 不可变的历史记录对于审核目的尤其重要。

• 进一步的安全措施：需要 GitHub 用户激活双因素身份验证。 仅允许已签名的提交来防止更改。

成本优化

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

• AKS 免费层提供免费的群集管理。 成本仅限于由 AKS 用来托管节点的计算、存储和网络资源。 AKS 免费层不包括服务级别协议（SLA），不建议用于生产工作负荷。

• GitHub 提供免费服务，但要使用高级安全相关功能（如代码所有者或所需审阅者）需要团队计划。 有关详细信息，请参阅 GitHub 定价。

• Azure DevOps 提供可用于某些方案的免费层。

• 使用 Azure 定价计算器估算成本。

卓越运营

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

GitOps 可以提高 DevOps 的工作效率。 最有用的功能之一是能够通过执行 Git 操作快速回滚那些表现出意外行为的更改。 提交图仍包含所有提交，因此有助于进行追溯分析。

GitOps 团队通常会为同一个应用程序管理多个环境。 典型的做法是，将应用程序的多个阶段部署到不同的 Kubernetes 群集或命名空间。 Git 存储库是单一可信源，它显示当前部署到群集的应用程序版本。

部署方案

有关部署五种方案的详细信息，请参阅以下资源：

• 方案 1： 有关如何将 GitOps 与 Flux v2 配合使用将应用程序部署到 AKS 的指南，请参阅 教程：将 GitOps 与 Flux v2 配合使用来部署应用程序。 有关如何使用 Flux 扩展启动 AKS 群集部署的示例，请参阅 AKS 基线的参考实现。

• 方案 2：有关如何将 GitOps 与 AKS 上的 Flux v2 配合使用以部署应用程序和实现 CI/CD 的指导，请参阅教程：通过 GitOps 实现 CI/CD（Flux v2）。

• 方案 3 和 4： 有关如何使用 Argo CD 和 AKS 部署示例工作负荷的分步指南，请参阅 AKS 基线自动化中的基于拉取的 CI/CD 方案。

作者

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

主要作者：

• Francis Simy Nazareth | 首席云解决方案架构师

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

后续步骤

• 将 GitOps 与 Flux v2 配合使用来部署应用程序
• 使用 GitOps 和 Argo CD 部署应用程序
• 使用 GitOps 实现 CI/CD （Flux v2）
• Argo CD 文档
• Flux CD 文档
• 将 GitOps 与 Jenkins X 配合使用
• 什么是 Azure RBAC？

相关资源

• AKS 群集的基线体系结构
• 多区域群集的 AKS 基线
• AKS 上的 DevSecOps
• 适用于 IaC 的 DevSecOps

GitOps 是一套操作和管理软件系统的原则。 本文介绍使用 GitOps 原则操作和管理 Azure Kubernetes 服务 (AKS) 群集的方法。

Flux、Argo CD、OPA Gatekeeper、Kubernetes 和 Git 徽标是各自公司的商标。 使用这些标志并不意味着认可。

体系结构

可与 AKS 配合使用的两个 GitOps operator 是 Flux 和 Argo CD。 它们都来自云原生计算基金会 (CNCF) 项目，并且得到广泛采用。 以下方案演示了其用法。

方案 1：将 GitOps 与 Flux 和 AKS 配合使用

演示 Flux v2、GitHub 和 AKS 的 GitOps 工作流示意图。 在左侧，开发人员将配置更改提交到 GitHub 存储库。 在中心，AKS 群集中的 Flux 运算符监视存储库中的更改。 当 Flux 检测到配置偏移时，它会从 GitHub 拉取最新配置。 右侧，Flux 将存储库中所需的状态与 AKS 群集中的实际状态进行协调，并根据需要应用更新。 该图显示了从开发人员到 GitHub、Flux 以及最后到 AKS 群集的配置更改流，并强调基于拉取的连续对帐过程。

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

方案 1 的数据流

Flux 是与 AKS 原生集成的 集群扩展。 群集扩展提供了一个平台，用于在 AKS 群集上安装和管理解决方案。 你可以使用 Azure 门户、Azure CLI 或基础结构即代码 (IaC) 脚本（例如 Terraform 或 Bicep 脚本）来启用 Flux 作为 AKS 的扩展。 你还可以使用 Azure Policy 在 AKS 群集上大规模应用 Flux v2 配置。 有关详细信息，请参阅 使用 Flux v2 配置和 Azure Policy 大规模部署应用程序。

Flux 可以将 Kubernetes 清单、Helm 图表和 Kustomization 文件部署到 AKS。 Flux 是基于轮询的过程，因此它可以检测、拉取和协调配置更改，而无需将群集终结点公开给生成代理。

在此方案中，Kubernetes 管理员可以更改 Kubernetes 配置对象（例如机密和 ConfigMap），并将更改直接提交到 GitHub 存储库。

以下数据流对应于上图：

1. 开发人员将配置更改提交到 GitHub 存储库。

2. Flux 检测 Git 存储库中的配置偏移并拉取配置更改。

3. Flux 协调 Kubernetes 群集中的状态。

方案 1 的替代方案

• 可以将 Flux 与其他 Git 存储库（例如 Azure DevOps、GitLab 和 Bitbucket）配合使用。

• 而不是使用 Git 存储库，Flux Bucket API 定义了一个源，用于从存储解决方案（如 Amazon S3 和 Google Cloud Storage 的 Bucket）生成对象的制品。 你也可以使用具有 S3 兼容 API 的解决方案。 两个示例包括 MinIO 和 Alibaba Cloud Object Storage Service （OSS），但还有其他解决方案。

• 你还可以针对 Azure Blob 存储容器将 Flux 配置为用于生成项目的源。 有关详细信息，请参阅 AKS 和已启用 Azure Arc 的 Kubernetes 的 GitOps Flux v2 配置。

• Flux v2 支持多租户架构，从而允许不同的团队将工作负载部署到同一个共享的 Kubernetes 群集。 可以将代表不同租户的多个 Git 存储库同步到群集。 为了确保团队之间的工作负荷隔离，每个团队可能在 AKS 群集中有自己的命名空间或命名空间，这些命名空间或命名空间通过 Kubernetes 基于角色的访问控制 （RBAC） 策略进行限制。

• Flux 可以使用一个群集来管理同一群集或其他群集中的应用。 具有 Flux 控制器的中心 AKS 群集负责通过 GitOps 将应用程序和基础设施工作负载持续交付到多个辐射 AKS 群集。

方案 2：将 GitOps 与 Flux、GitHub 和 AKS 配合使用以实现 CI/CD

显示包含 GitOps、Flux、GitHub 和 AKS 的 CI/CD 工作流的关系图。 在左侧，开发人员在集成开发环境（IDE）中编写应用程序代码并将其提交到 GitHub 存储库。 GitHub Actions 从代码生成容器映像，并将其推送到 Azure 容器注册表。 GitHub Actions 使用新的映像版本更新存储库中的 Kubernetes 清单文件。 在中心，AKS 群集中的 Flux 运算符监视存储库中的更改。 当 Flux 检测到更新的清单时，它会拉取配置并将新应用程序版本部署到 AKS 群集。 该图显示了代码和配置从开发人员到 GitHub 的流动，通过 CI/CD 自动化，到 Flux，最后流向 AKS 集群，并强调基于拉取的自动化部署过程。

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

方案 2 的数据流

此方案是适用于典型 Web 应用程序的基于拉取的 DevOps 管道。 该管道使用 GitHub Actions 进行生成。 对于部署，它使用 Flux 作为 GitOps operator 来拉取和同步应用。

以下数据流对应于上图：

1. 应用代码是使用集成开发环境（IDE）（如 Visual Studio Code）开发的。

2. 应用代码提交到 GitHub 存储库。

3. GitHub Actions 从应用代码生成容器映像，并将容器映像推送到 Azure 容器注册表。

4. GitHub Actions 根据容器注册表中容器映像的版本号，使用当前映像版本来更新 Kubernetes 清单部署文件。

5. Flux operator 检测 Git 存储库中的配置偏差，并拉取配置更改。

6. Flux 使用清单文件将应用部署到 AKS 群集。

方案 3：使用 Argo CD、GitHub 存储库和 AKS 的 GitOps

显示包含 Argo CD、GitHub 和 AKS 的 GitOps 工作流的图表。 左侧是 Kubernetes 管理员编辑配置文件并将其提交到 GitHub 存储库。 在中心，AKS 群集中的 Argo CD 监视存储库中的更改。 当 Argo CD 检测到更新的配置时，它会拉取更改，并将所需状态与 AKS 群集中的实际状态协调。 该图突出显示了从管理员到 GitHub、Argo CD 以及最后到 AKS 群集的配置流，并强调基于拉取的、持续对帐过程以及 Argo CD 作为管理应用程序状态的控制器的角色。

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

方案 3 的数据流

可以在 AKS 中将 Argo CD 启用为群集扩展。 在此方案中，Kubernetes 管理员可以更改 Kubernetes 配置对象（例如机密和 ConfigMap），并将更改直接提交到 GitHub 存储库。

以下数据流对应于上图：

1. Kubernetes 管理员在 YAML 文件中进行配置更改，并将更改提交到 GitHub 存储库。

2. Argo CD 从 Git 存储库拉取更改。

3. Argo CD 协调 AKS 群集的配置更改。

Argo CD 不必自动将所需目标状态同步到 AKS 群集。 它实现为 Kubernetes 控制器，可持续监视正在运行的应用程序。 它将 AKS 群集的当前实时状态与 Git 存储库中指定的所需目标状态进行比较。 Argo CD 报告并直观显示差异，并提供工具自动或手动将实时状态同步回所需目标状态。

Argo CD 提供基于浏览器的用户界面。 可以使用该界面来添加应用程序配置，观察群集相关的同步状态，以及针对群集启动同步。 还可以使用 Argo CD 命令行执行这些任务。 用户界面和命令行接口都提供用于查看配置更改历史记录和回滚到先前版本的功能。

默认不会公开 Argo CD 用户界面和 API 服务器。 若要访问它们，我们建议创建一个具有内部 IP 地址的入口控制器。 或者，可以使用 内部负载均衡器 来公开它们。

方案 3 的替代方案

与 Git 兼容的任何存储库（包括 Azure DevOps）都可以充当配置源存储库。

方案 4：将 GitOps 与 Argo CD、GitHub Actions 和 AKS 配合使用来实现 CI/CD

将 GitOps 与 Argo CD、GitHub 和 AKS 配合使用的 CI/CD 工作流示意图。 在左侧，开发人员编写应用程序代码并将其提交到 GitHub 存储库。 GitHub Actions 生成容器映像，将其推送到容器注册表，并使用新的映像版本更新存储库中的 Kubernetes 清单文件。 在中心，AKS 群集中的 Argo CD 监视存储库中的更改、拉取更新的配置，并将新的应用程序版本部署到 AKS 群集。 该图显示了从开发人员到 GitHub 的代码和配置流，通过 CI/CD 自动化，到 Argo CD，最后流向 AKS 群集，重点介绍基于拉取的自动化部署过程。

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

方案 4 的数据流

此方案是适用于典型 Web 应用程序的基于拉取的 DevOps 管道。 该管道使用 GitHub Actions 进行生成。 对于部署，它使用 Argo CD 作为 GitOps operator 来拉取和同步应用。

以下数据流对应于上图：

1. 应用代码是使用 Visual Studio Code 等 IDE 开发的。

2. 应用代码提交到 GitHub 存储库。

3. GitHub Actions 从应用代码生成容器映像，并将容器映像推送到容器注册表。

4. GitHub Actions 根据容器注册表中容器映像的版本号，使用当前映像版本来更新 Kubernetes 清单部署文件。

5. Argo CD 从 Git 存储库拉取数据。

6. Argo CD 将应用部署到 AKS 群集。

方案 4 的替代方案

与 Git 兼容的任何存储库（包括 Azure DevOps）都可以充当配置源存储库。

方案详细信息

GitOps 是一套操作和管理软件系统的原则。

• 它使用源代码管理作为系统的单一事实源。

• 它将版本控制、协作、合规性、持续集成和持续部署（CI/CD）等开发做法应用于基础结构自动化。

• 你可以将其应用于任何软件系统。

GitOps 通常用于 Kubernetes 群集管理和应用程序交付。

根据 GitOps 原则，GitOps 托管系统的所需状态必须满足以下条件：

• 声明： GitOps 管理的系统必须以声明方式表达其所需状态。 声明通常存储在 Git 存储库中。

• 版本控制且不可变： 所需状态以强制实施不可变性和版本控制的方式存储，并保留完整的版本历史记录。

• 自动拉取： 软件代理会自动从源拉取所需状态声明。

• 持续协调： 软件代理会持续观察实际的系统状态，并尝试应用所需的状态。

在 GitOps 中， IaC 使用代码声明所需的基础结构组件状态，例如虚拟机（VM）、网络和防火墙。 此代码受版本控制，且可进行审核。

Kubernetes 使用清单以声明方式描述从群集状态到应用程序部署的所有内容。 GitOps for Kubernetes 将群集基础结构所需状态置于版本控制之下。 群集中的组件（通常称为 运算符）会持续同步声明性状态。 使用这种方法可以审查和审核影响群集的代码更改。 它通过支持最低特权原则（PoLP）来增强安全性。

GitOps 代理持续地使系统状态与存储在代码存储库中的所需状态相协调。 某些 GitOps 代理可以还原在群集外部执行的操作，例如手动创建 Kubernetes 对象。 例如， 允许控制器 在创建、更新和删除作期间对对象强制实施策略。 你可以使用许可控制器来确保仅当源存储库中的部署代码发生更改时才更改部署。

可以将策略管理和强制工具与 GitOps 结合使用来强制实施策略，并为建议的策略更改提供反馈。 可以为各个团队配置通知，让他们了解当前的 GitOps 状态。 例如，可以发送部署成功和协调失败的通知。

GitOps 用作单一事实源

GitOps 提供群集状态的一致性和标准化，有助于增强安全性。 你还可以使用 GitOps 来确保多个群集之间的状态一致。 例如，GitOps 可以跨主要群集和灾难恢复（DR）群集或群集场应用相同的配置。

若要强制 GitOps 作为更改群集状态的唯一方法，请限制对群集的直接访问。 若要设置此配置，请使用 Azure 基于角色的访问控制（Azure RBAC）、允许控制器或其他工具。

使用 GitOps 启动初始配置

有时需要 AKS 群集部署作为基线配置的一部分。 例如，在部署应用程序工作负荷之前，可能需要部署共享服务或系统级配置。 这些共享服务可以配置以下加载项和工具：

• AKS 加载项，例如 Microsoft Entra 工作负荷 ID 和 用于机密存储 CSI 驱动程序的 Azure Key Vault 提供程序

• Prisma Cloud Defender 等合作伙伴工具

• 开源工具，例如 Kubernetes 事件驱动的自动缩放（KEDA）、 ExternalDNS 和 Cert-manager

可以启用 Flux 作为创建 AKS 群集时应用的扩展。 然后，Flux 可将基线配置启动至群集。 AKS 群集的基线体系结构建议使用 GitOps 进行引导。 如果使用 Flux 扩展，则可以在部署后不久启动群集。

其他 GitOps 工具和加载项

可以将所述的方案扩展到其他 GitOps 工具。 Jenkins X 是另一个 GitOps 工具，它提供集成到 Azure 的指令。 可以使用 Flagger 等渐进式交付工具逐步转移通过 GitOps 部署的生产工作负载。

可能的用例

此解决方案有利于希望部署应用程序和 IaC 的组织，并维护每项更改的审核线索。

GitOps 简化了开发人员的容器管理，从而提高了工作效率。 开发人员可以继续使用他们熟悉的工具（例如 Git）来管理更新和新功能。

注意事项

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

可靠性

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅可靠性设计评审核对清单。

如果群集不可用，GitOps 应用作创建新群集的一部分。 它使用 Git 存储库作为 Kubernetes 配置和应用程序逻辑的单一事实源。 它可以创建并应用群集配置和应用程序部署作为缩放单元，并且可以建立 部署标记 模式。

安全性

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

使用 GitOps 方法，单个开发人员或管理员不会直接访问 Kubernetes 群集来应用更改或更新。 相反，用户会将更改推送到 Git 存储库和 GitOps 操作员（如 Flux 或 Argo CD），读取更改并将其应用到群集。 此方法通过不向 DevOps 团队提供对 Kubernetes API 的写入权限来遵循最小特权的最佳安全做法。 在诊断或故障排除方案中，你可以根据具体情况在有限时间内授予群集权限。

除了配置存储库权限之外，请考虑在与 AKS 群集同步的 Git 存储库中实现以下安全措施：

• 分支保护：防止直接将更改推送到表示 Kubernetes 群集状态的分支。 使用拉取请求（PR）进行变更，并至少有一个人审查每个 PR。 此外，使用 PR 执行自动检查。

• PR 审阅： 要求 PR 至少有一位审阅者以强制执行双重审核原则。 还可以使用 GitHub 代码所有者功能来定义负责查看存储库中特定文件的个人或团队。

• 不可变的历史记录：仅允许在现有更改之上进行新的提交。 不可变的历史记录对于审核目的尤其重要。

• 进一步的安全措施：需要 GitHub 用户激活双因素身份验证。 仅允许已签名的提交来防止更改。

成本优化

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

• AKS 免费层提供免费的群集管理。 成本仅限于由 AKS 用来托管节点的计算、存储和网络资源。 AKS 免费层不包括服务级别协议（SLA），不建议用于生产工作负荷。

• GitHub 提供免费服务，但要使用高级安全相关功能（如代码所有者或所需审阅者）需要团队计划。 有关详细信息，请参阅 GitHub 定价。

• Azure DevOps 提供可用于某些方案的免费层。

• 使用 Azure 定价计算器估算成本。

卓越运营

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

GitOps 可以提高 DevOps 的工作效率。 最有用的功能之一是能够通过执行 Git 操作快速回滚那些表现出意外行为的更改。 提交图仍包含所有提交，因此有助于进行追溯分析。

GitOps 团队通常会为同一个应用程序管理多个环境。 典型的做法是，将应用程序的多个阶段部署到不同的 Kubernetes 群集或命名空间。 Git 存储库是单一可信源，它显示当前部署到群集的应用程序版本。

部署方案

有关部署五种方案的详细信息，请参阅以下资源：

• 方案 1： 有关如何将 GitOps 与 Flux v2 配合使用将应用程序部署到 AKS 的指南，请参阅 教程：将 GitOps 与 Flux v2 配合使用来部署应用程序。 有关如何使用 Flux 扩展启动 AKS 群集部署的示例，请参阅 AKS 基线的参考实现。

• 方案 2：有关如何将 GitOps 与 AKS 上的 Flux v2 配合使用以部署应用程序和实现 CI/CD 的指导，请参阅教程：通过 GitOps 实现 CI/CD（Flux v2）。

• 方案 3 和 4： 有关如何使用 Argo CD 和 AKS 部署示例工作负荷的分步指南，请参阅 AKS 基线自动化中的基于拉取的 CI/CD 方案。

作者

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

主要作者：

• Francis Simy Nazareth | 首席云解决方案架构师

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

后续步骤

• 将 GitOps 与 Flux v2 配合使用来部署应用程序
• 使用 GitOps 和 Argo CD 部署应用程序
• 使用 GitOps 实现 CI/CD （Flux v2）
• Argo CD 文档
• Flux CD 文档
• 将 GitOps 与 Jenkins X 配合使用
• 什么是 Azure RBAC？

相关资源

• AKS 群集的基线体系结构
• 多区域群集的 AKS 基线
• AKS 上的 DevSecOps
• 适用于 IaC 的 DevSecOps