GitOps 是一套操作和管理软件系统的原则。 本文介绍使用 GitOps 原则操作和管理 Azure Kubernetes 服务 (AKS) 群集的方法。
Flux、Argo CD、OPA Gatekeeper、Kubernetes 和 git 徽标是其各自公司的商标。 使用这些标志并不意味着认可。
体系结构
可与 AKS 配合使用的两个 GitOps operator 是 Flux 和 Argo CD。 它们都来自云原生计算基金会 (CNCF) 项目，并且得到广泛采用。 以下方案演示了其用法。
方案 1：将 GitOps 与 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 存储库。
此方案的数据流为：
- 开发人员将配置更改提交到 GitHub 存储库。
- Flux 检测 Git 存储库中的配置偏差，并拉取配置更改。
- Flux 协调 Kubernetes 群集中的状态。
方案 1 的替代方案
- 可以将 Flux 与其他 Git 存储库（例如 Azure DevOps、GitLab 和 BitBucket）配合使用。
- 与 Git 存储库不同，Flux Bucket API 定义一个源来为存储解决方案（例如 Amazon S3 和 Google Cloud Storage 存储桶）中的对象生成项目。 你也可以使用具有 S3 兼容 API 的解决方案。 两个例子是 Minio 和阿里云 OSS，但不限于此。
- 你还可以针对 Azure Blob 存储容器将 Flux 配置为用于生成项目的源。 有关详细信息，请参阅 AKS 和已启用 Azure Arc 的 Kubernetes 的 GitOps Flux v2 配置。
方案 2：将 GitOps 与 Flux、GitHub 和 AKS 配合使用以实现 CI/CD
下载此体系结构的 Visio 文件。
方案 2 的数据流
此方案是适用于典型 Web 应用程序的基于拉取的 DevOps 管道。 该管道使用 GitHub Actions 进行生成。 对于部署，它使用 Flux 作为 GitOps operator 来拉取和同步应用。 数据流经方案的情形如下所示：
- 应用代码是使用 Visual Studio Code 等 IDE 开发的。
- 应用代码提交到 GitHub 存储库。
- GitHub Actions 从应用代码生成容器映像，并将容器映像推送到 Azure 容器注册表。
- GitHub Actions 根据 Azure 容器注册表中容器映像的版本号来使用当前映像版本更新 Kubernetes 清单部署文件。
- Flux operator 检测 Git 存储库中的配置偏差，并拉取配置更改。
- Flux 使用清单文件将应用部署到 AKS 群集。
方案 3：将 GitOps 与 Argo CD、GitHub 存储库和 AKS 配合使用
下载此体系结构的 Visio 文件。
方案 3 的数据流
在此方案中，Kubernetes 管理员可以更改 Kubernetes 配置对象（例如机密和 ConfigMap），并将更改直接提交到 GitHub 存储库。
此方案的数据流为：
- Kubernetes 管理员在 YAML 文件中进行配置更改，并将更改提交到 GitHub 存储库。
- Argo CD 从 Git 存储库拉取更改。
- 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
下载此体系结构的 Visio 文件。
方案 4 的数据流
此方案是适用于典型 Web 应用程序的基于拉取的 DevOps 管道。 该管道使用 GitHub Actions 进行生成。 对于部署，它使用 Argo CD 作为 GitOps operator 来拉取和同步应用。 数据流经方案的情形如下所示：
- 应用代码是使用 Visual Studio Code 等 IDE 开发的。
- 应用代码提交到 GitHub 存储库。
- GitHub Actions 从应用代码生成容器映像，并将容器映像推送到 Azure 容器注册表。
- GitHub Actions 根据 Azure 容器注册表中容器映像的版本号来使用当前映像版本更新 Kubernetes 清单部署文件。
- Argo CD 从 Git 存储库拉取数据。
- Argo CD 将应用部署到 AKS 群集。
方案 4 的替代方案
与 Git 兼容的任何存储库（包括 Azure DevOps）都可以充当配置源存储库。
方案详细信息
GitOps 是一套操作和管理软件系统的原则。
- 它使用源代码管理作为系统的单一事实源。
- 它将版本控制、协作、合规性和持续集成/持续部署 (CI/CD) 等开发做法应用于基础结构自动化。
- 你可以将其应用于任何软件系统。
GitOps 通常用于 Kubernetes 群集管理和应用程序交付。 本文介绍了一些用于将 GitOps 与 AKS 群集结合使用的常用选项。
根据 GitOps 原则，GitOps 管理的系统的所需状态必须是：
- 声明性：必须以声明方式表达 GitOps 管理的系统的所需状态。 声明通常存储在 Git 存储库中。
- 版本受控且不可变：所需状态的存储方式强制实施不可变性和版本控制，并保留完整的版本历史记录。
- 自动拉取：软件代理自动从源拉取所需状态声明。
- 持续协调：软件代理持续观察实际系统状态并尝试应用所需状态。
在 GitOps 中，基础结构即代码 (IaC) 使用代码声明基础结构组件（例如虚拟机 (VM)、网络和防火墙）的所需状态。 此代码受版本控制，且可进行审核。
Kubernetes 使用清单以声明方式描述从群集状态到应用程序部署的所有内容。 GitOps for Kubernetes 将群集基础结构所需状态置于版本控制之下。 群集中有一个组件（通常称为 operator）持续同步声明性状态。 使用这种方法可以审查和审核影响群集的代码更改。 它通过支持最低特权原则增强了安全性。
GitOps 代理持续地使系统状态与存储在代码存储库中的所需状态相协调。 某些 GitOps 代理可以还原在群集外部执行的操作，例如手动创建 Kubernetes 对象。 例如，许可控制器在执行创建、更新和删除操作期间对对象强制实施策略。 你可以使用许可控制器来确保仅当源存储库中的部署代码发生更改时才更改部署。
可以将策略管理和强制工具与 GitOps 结合使用来强制实施策略，并为建议的策略更改提供反馈。 可为各个团队配置通知，以便为他们提供最新的 GitOps 状态。 例如，可以发送部署成功和协调失败的通知。
GitOps 用作单一事实源
GitOps 提供群集状态的一致性和标准化，有助于增强安全性。 你还可以使用 GitOps 来确保多个群集之间的状态一致。 例如，GitOps 可以跨主群集和灾难恢复 (DR) 群集或者在整个群集场中应用同一配置。
如果你想强制要求仅限 GitOps 更改群集状态，可以限制对群集的直接访问。 可以通过多种方式做到这一点，包括 Azure 基于角色的访问控制 (RBAC)、许可控制器和其他工具。
使用 GitOps 启动初始配置
可能需要将 AKS 群集部署为基线配置的一部分。 例如，在部署工作负载之前，必须先部署一组共享服务或配置。 这些共享服务可以配置 AKS 加载项，例如：
- Microsoft Entra 工作负载 ID。
- 适用于 Secrets Store CSI 驱动程序的 Azure Key Vault 提供程序。
- 合作伙伴工具，例如：
- 开源工具，例如：
可以启用 Flux 作为创建 AKS 群集时应用的扩展。 然后，Flux 可将基线配置启动至群集。 AKS 群集的基线体系结构建议使用 GitOps 进行启动。 如果使用 Flux 扩展，在部署后很快就可以启动群集。
其他 GitOps 工具和加载项
可以将所述的方案扩展到其他 GitOps 工具。 Jenkins X 是另一个 GitOps 工具，它提供集成到 Azure 的指令。 可以使用 Flagger 等渐进式交付工具逐步转移通过 GitOps 部署的生产工作负载。
可能的用例
此解决方案可为任何想要享有部署应用程序和基础结构即代码的优点的组织提供好处，并包含每个更改的审核线索。
GitOps 消除了开发人员管理容器环境时所面临的复杂性。 开发人员可以继续使用他们熟悉的工具（例如 Git）来管理更新和新功能。 这样，GitOps 就可以提高开发人员的工作效率。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。
可靠性的重要支柱之一是复原能力。 复原能力的目标是在故障发生后将应用程序恢复到可完全正常运行的状态。 如果某个群集不可用，GitOps 可以快速创建一个新群集。 它使用 Git 存储库作为 Kubernetes 配置和应用程序逻辑的单一事实源。 它可以创建并应用群集配置和应用程序部署作为缩放单元，并可以建立部署缩放单元模式。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。
使用 GitOps 方法，单个开发人员或管理员不会直接访问 Kubernetes 群集来应用更改或更新。 用户将更改推送到 Git 存储库，而 GitOps operator（Flux 或 Argo CD）读取更改并将其应用于群集。 此方法通过不向 DevOps 团队提供对 Kubernetes API 的写入权限来遵循最小特权的最佳安全做法。 在诊断或故障排除方案中，你可以根据具体情况在有限时间内授予群集权限。
除了设置存储库权限的任务之外，请考虑在同步到 AKS 群集的 Git 存储库中实施以下安全措施：
- 分支保护：防止直接将更改推送到表示 Kubernetes 群集状态的分支。 使用 PR 进行更改，并由其他至少一个人员审查每个 PR。 另外，使用 PR 进行自动检查。
- PR 评审：要求 PR 至少具有一个审阅者，以强制执行四眼原则。 还可以使用 GitHub 代码所有者功能来定义负责查看存储库中特定文件的个人或团队。
- 不可变的历史记录：仅允许在现有更改之上进行新的提交。 不可变的历史记录对于审核目的尤其重要。
- 进一步的安全措施：需要 GitHub 用户激活双因素身份验证。 另外，只允许已签名的提交，以防止发生更改。
成本优化
成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。
- 在免费层，AKS 提供免费的群集管理。 成本仅限于由 AKS 用来托管节点的计算、存储和网络资源。
- GitHub 提供免费服务，但若要使用高级安全相关功能（如代码所有者或所需的审阅者），则需要团队计划。 有关详细信息，请参阅 GitHub 定价页。
- Azure DevOps 提供了一个可用于某些方案的免费层。
- 使用 Azure 定价计算器估算成本。
卓越运营
卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅卓越运营支柱概述。
GitOps 可以提高 DevOps 的工作效率。 最有用的功能之一是能够快速回滚由于执行 Git 操作而发生意外行为的更改。 提交图仍包含所有提交，因此它可以帮助进行总结分析。
GitOps 团队通常会为同一个应用程序管理多个环境。 典型的做法是，将应用程序的多个阶段部署到不同的 Kubernetes 群集或命名空间。 Git 存储库是单一可信源，它显示当前部署到群集的应用程序版本。
部署方案
以下列表提供了有关部署五个方案的参考信息：
- 方案 1：有关结合使用 GitOps 和 Flux v2 将应用程序部署到 AKS 的指导，请参阅教程：结合使用 GitOps 和 Flux v2 来部署应用程序。 有关如何使用 Flux 扩展启动 AKS 群集部署的示例，请参阅 AKS 基线的参考实现。
- 方案 2：有关在 AKS 上结合使用 GitOps 和 Flux v2 部署应用程序及实现 CI/CD 的指导，请参阅：教程：使用 GitOps (Flux v2) 实现 CI/CD。
- 方案 3 和 4：有关使用 Argo CD 和 AKS 部署示例工作负载的分步指导，请参阅 AKS 基线自动化中的基于拉取的 CI/CD 方案。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Francis Simy Nazareth | 首席云解决方案架构师
若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。