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

已启用 Azure Arc 的 Kubernetes 的 CI/CD 和 GitOps 规则

作为一个云原生构造，Kubernetes 需要云原生方法来进行部署和操作。 通过 GitOps，你可以在存储于 Git 存储库的文件中声明基于应用程序的部署的所需状态。 应用程序具有需要运行的 Kubernetes 对象，其中可能包括部署、Horizontal-Pod-Autoscalers、服务和 ConfigMap。 Kubernetes 运算符在群集中运行，并不断地使每个群集的状态与 Git 存储库中声明的所需状态保持一致。 这些运算符从 Git 存储库中拉取文件，并将所需状态应用到群集。 运算符还会持续确保群集保持在所需状态。

实现 GitOps 可以：

• 提高 Kubernetes 群集状态和配置的总体可见性。
• 通过 Git 更改历史记录（显示谁进行了更改、何时进行了更改以及为什么进行更改）对群集的更改进行简单的审核和版本历史记录。
• 自动更正群集可能发生的偏移。
• 通过 Git 还原或 Git 回滚命令将 Kubernetes 配置回滚到以前的版本。 为灾难恢复场景重新创建群集部署也成了一个快速、直接的过程，因为 Kubernetes 所需的群集配置存储在 Git 中。
• 通过减少对群集具有部署权限所需的服务帐户数量来提高安全性。
• 实现用于将应用程序部署到群集的 CI/CD 管道。

已启用 Azure Arc 的 Kubernetes 上的 GitOps 使用可实现 Flux 的扩展，Flux 是一种常用的开源工具集。 Flux 是在群集中自动执行 GitOps 配置部署的运算符。 Flux 提供对常见文件源（Git 存储库、Helm 存储库、Bucket）和模板类型（YAML、Helm 和 Kustomize）的支持。 Flux 还支持多租户和部署依赖关系管理，以及其他功能。

体系结构

下图展示了一个概念参考体系结构，其中突出显示了群集中的 Flux 群集扩展安装预配、已启用 Azure Arc 的 Kubernetes 群集的 GitOps 配置过程和 GitOps 流。

Flux v2 群集扩展预配过程：

GitOps 配置过程：

显示应用程序更新的 GitOps 流：

设计注意事项

规划实现已启用 Azure Arc 的 Kubernetes 的 GitOps 时，请查看以下设计注意事项。

配置

考虑 Kubernetes 群集中的不同配置层以及预配这些层所涉及的职责。

配置层

• 将应用程序及其相关 Kubernetes 对象部署到群集所需的应用程序配置，例如部署、服务、HPA 和 ConfigMap 资源。 应用程序配置通常应用于命名空间级别的 GitOps 配置，只需在单个命名空间中配置应用程序组件。
• 用于创建 Kubernetes 对象的群集范围配置，例如命名空间、服务帐户、角色和角色绑定及其他群集范围的策略。
• 群集范围的组件（例如入口控制器、监视和安全堆栈），以及跨群集运行的各种代理。

职责

• 应用程序开发人员负责推送其源代码、触发生成和创建容器映像。
• 应用程序操作员负责维护应用程序存储库、配置、环境变量、特定于应用的 Helm 图表、Kustomization 等。
  • 使用 Azure CLI 应用 Flux 配置
  • Flux2 Helm 和 Kustomize 示例
• 群集操作员负责设置群集基线。 他们关心的通常是设置群集范围的组件和策略。 他们维护一个或多个 Git 存储库目录，其中包含常用的基础结构工具，例如命名空间、服务帐户、角色绑定、CRD、群集范围的策略、入口组件等。

存储库结构

在选择 Git 存储库结构时请考虑到各种利弊。 选择的结构将定义 Kubernetes 群集状态，这包括应用程序和群集范围的组件。 根据确定的职责和角色，必须考虑任何必要的协作或者不同存储库结构选项所需的团队独立性。

可以对代码存储库使用你偏好的任何分支策略，因为它仅供持续集成 (CI) 过程使用。

对于 GitOps 配置存储库，请根据组织的业务需求、规模和工具考虑以下策略：

• 单个存储库（为每个环境创建分支）：
  • 能够最灵活地控制代表环境的每个分支的 Git 策略和权限。
  • 缺点是不会在环境之间共享通用配置，因为 Kustomize 之类的工具不适用于 Git 分支。
• 单一存储库（为每个环境创建目录）：
  • 可以使用 Kustomize 之类的工具来实现此方法，这样就可以为 Kubernetes 对象定义一个基础配置，并为环境定义一组替代基础配置的项目（例如修补程序）。
  • 此方法可以减少每个环境的重复 YAML 文件，但也会降低环境之间的配置隔离性。 对存储库进行单一更改有可能同时影响所有环境，因此必须充分了解对基础目录进行更改所造成的影响，并保持谨慎。
• 多个存储库（每个存储库发挥特定的作用）：
  • 可以使用此方法来隔离每个应用程序、团队、层或租户的配置存储库。
  • 这使团队能够获得更高的独立控制权，但无法遵守以下原则：在单个存储库中定义系统状态以改进到群集的部署的集中配置、可见性和控制。
  • 应考虑设置多个存储库来满足多租户需求。 内置了基于角色的访问控制 (RBAC) 和安全性，以限制分配到特定存储库的团队/租户可以应用的配置，例如仅允许部署到特定的命名空间。

在 Flux 指南中查看更多存储库构建方法。

应用程序和平台配置

平台操作员和应用程序操作员拥有多个用于管理 Kubernetes 配置的选项：

• 代表 YAML 规范的原始 Kubernetes YAML 文件，使你要部署的每个 Kubernetes API 对象都适用于单一环境。 使用原始 YAML 文件的缺点是，当你开始合并多个环境时自定义将变得困难，因为你需要复制 YAML 文件，并且没有很好的重用方法。
• Helm 是 Kubernetes 对象的包管理工具。 它是一个有效选项，群集操作员可用于安装第三方现成应用程序。 请确保不要过度将模板用作内部应用程序的配置管理工具，因为随着模板的增长，管理可能会变得复杂。
  • 如果使用的是 Helm，Flux 包含一个 Helm 控制器，该控制器使你能够使用 Kubernetes 清单以声明方式管理 Helm 图表发布。 可以创建 HelmRelease 对象来管理该过程。
• Kustomize 是一种 Kubernetes 本机配置管理工具，它引入了一种无模板方式来自定义应用程序配置。
  • 如果使用的是 Kustomize，Flux 包含一个 Kustomize 控制器，该控制器专门运行使用 Kubernetes 清单定义并使用 Kustomize 组装的基础结构和工作负载的持续交付管道。 可以创建 Kustomization 对象来管理该过程。
• 借助已启用 Azure Arc 的 Kubernetes，无需自己管理组件的生命周期和支持，你可以改为使用 Microsoft 管理和支持的可用扩展列表进行。 这些扩展是通过 Azure 资源管理器管理的。 其中一些扩展（例如 Azure Key Vault 机密提供程序）具有开放源代码替代项。 在扩展过程之外管理组件可以更好地控制组件，但也需要更多支持和生命周期管理方面的开销。

持续集成和持续交付 (CI/CD) 流

以下部分提供了应用程序管道和组件更新过程的注意事项。

应用程序管道

• 请考虑需要包含在 CI 过程中的应用程序生成、测试和验证。 这些可能包括与安全性、集成和性能相关的 Lint 分析和测试，这是为环境部署创建候选发布 (RC) 所需要的。
• 通过直接从部署管道调用 Kubernetes API，你可以使用传统的推送部署方法来弥合 CI 管道中的生成容器映像与其在集群中的部署之间的差距。

为避免手动修改 GitOps 存储库的配置，你可以将 CD 管道作为服务帐户运行，该帐户有权打开拉取请求 (PR) 或将新的容器映像更改直接提交到配置存储库。 这些更改还可以预配应用程序所需的所有 YAML 对象。

以下流程图展示了与支持 GitOps 的更改合并的传统应用程序 CI 过程。

群集范围的组件更新过程

• 群集操作员需要管理群集范围的组件，因此这可能不会源自用于部署应用程序和服务的 CD 管道。 请考虑定义特定于群集操作员的提升过程，以确保更改能够顺利从一个环境过渡到另一个环境。
• 如果需要将相同的 GitOps 配置大规模应用于已启用 Azure Arc 的 Kubernetes 群集，请考虑应用 Azure Policy，通过它可以自动安装 Flux 扩展并将 GitOps 配置应用于现有的已启用 Azure Arc 的 Kubernetes 群集或新群集，因为它们已载入 Azure Arc。

更新配置时，你可能希望验证更改是否已成功应用于所需的环境。 可以在 Flux 中定义通知以与 CI/CD 工具、电子邮件或 ChatOps 工具集成，并自动发送有关成功更改和部署失败的警报。 还可以在 Azure 门户中以及通过 k8s-configuration CLI 和 ARM API 查找部署状态信息。

安全注意事项

规划实现已启用 Azure Arc 的 Kubernetes 的 GitOps 时，请查看以下安全注意事项。

存储库身份验证

• 可以将公共或专用 Git 存储库与 GitOps 配合使用，但由于 Kubernetes 配置的敏感性质，建议使用需要由 SSH 密钥或 API 密钥进行身份验证的专用存储库。 GitOps 还可使用只能在专用网络中进行访问的 Git 存储库，前提是 Kubernetes 群集可以访问它，但此设置限制了使用基于云的 Git 提供程序（例如 Azure Repos 或 GitHub）的能力。
• HTTPS 和 SSH 协议都提供可靠且安全的连接，你可以用于连接到源代码管理工具。 但是，HTTPS 通常更易于设置，并且使用一个很少要求在防火墙中打开更多端口的端口。

存储库和分支安全性

• 在配置存储库上设置分支权限和策略。 随着 Git 存储库成为 Kubernetes 部署的核心部分，设置权限来控制谁可以在分支中读取和更新代码，以及实现策略来强制执行团队的代码质量和更改管理就变得至关重要。 否则，你的 GitOps 工作流可能会交付不符合组织标准的代码。
• 拉取请求 (PR) 管道可以使用你的分支策略来根据需要验证 YAML 配置和/或部署测试环境。 入口有助于消除配置错误并提高部署安全性和置信度。
• 分配访问权限时，请考虑组织中的哪些用户应具有存储库读取访问权限、PR 创建访问权限和 PR 审批访问权限。

机密管理

• 避免在 Git 存储库中存储纯文本或 base64 编码的机密。 相反，请考虑使用外部机密提供程序，例如 Azure Key Vault。 通过适用于机密存储 CSI 驱动程序的 Azure Key Vault 提供程序，你可以使用 CSI 卷将 Azure 密钥保管库作为机密存储与 Azure Kubernetes 服务 (AKS) 群集集成。 此服务可通过已启用 Azure Arc 的 Kubernetes 扩展获得。 HashiCorp Vault 是第三方托管机密提供程序替代项。
• 管理机密的另一种方法是使用 Bitnami 的 Sealed Secrets，它是根据公钥和私钥的概念运作的。 这允许操作员使用 Git 中的公钥存储单向加密机密，该机密只能通过私钥（该私钥由你的群集中运行的 SealedSecrets 控制器使用）进行解密。

设计建议

规划实现已启用 Azure Arc 的 Kubernetes 的 GitOps 时，请查看以下设计建议。

下图包含参考体系结构，该体系结构展示了使用已启用 Azure Arc 的 Kubernetes Flux 扩展实现 GitOps 过程所需的职责、存储库和管道。

存储库

设计中包含三个 Git 存储库：

• 应用程序代码存储库
  • 此存储库存储应用程序代码以及任何管道定义和配置脚本。
  • 使用易于理解并限制不需要的长时间运行的分支数量的开发分支策略。
• 应用程序配置存储库
  • 此存储库存储应用程序配置，包括 Kubernetes 对象，例如 ConfigMap、部署、服务和 HPA 对象。 为每个应用程序构建具有不同目录的此存储库。 Flux 会将更改从此存储库和目标分支同步到你的群集。
  • 合并工具，使应用程序开发人员和操作员能够更轻松地为每个环境生成初始配置。 应用程序操作员应定义 Kubernetes 特定的应用程序配置，该配置使用 Helm 等包管理器或 Kustomize 等配置工具来简化配置。
  • 创建一个分支来表示每个环境类型。 这允许对每个特定环境（例如非生产环境和生产环境）的更改进行精细控制。
  • 将应用程序部署到具体命名空间时，请使用 GitOps 配置中的命名空间范围功能来仅对特定命名空间强制实施配置。
• 群集范围的配置存储库
  • 定义群集范围的组件（例如入口控制器、命名空间、RBAC、监视和安全堆栈），供群集操作员管理。 Flux 会将更改从此存储库和目标分支同步到你的群集。
  • 使用表示不同组件的不同目录来构造此存储库。
  • 创建一个分支来表示每个环境类型。 这允许对每个特定环境（例如非生产环境和生产环境）的更改进行精细控制。
  • 群集操作员应使用 Helm 等包管理器或 Kustomize 覆盖等配置工具来简化配置。

CI/CD 和配置更新过程

CI/CD 和容器映像更新

• CI 管道
  • 开发团队应通过过程来定义 CI 管道，包括生成、Lint 分析、测试以及将应用程序推送到容器注册表。
• CD 管道
  • 创建一个 CD 管道，该管道针对应用程序配置存储库运行面向更改的脚本。 此脚本会创建一个源自目标环境的临时分支，对映像标记版本进行更改、提交更改，并针对目标环境分支打开拉取请求。 此 CD 管道可以拥有具有相应环境变量的环境阶段，以面向正确的 GitOps 配置存储库和分支。
  • 为环境阶段定义手动审批步骤，从而限制针对所有环境的不需要的拉取请求。
• 在应用程序配置存储库上启用分支策略，以强制对环境进行同级评审或审批。 这可以使所需评审数量保持最少或针对较低环境进行自动审批。 还可以根据需要考虑第三方集成和审批，从而满足组织的标准。

群集范围和应用程序配置更新

• 群集操作员和应用程序操作员分别在各自的配置存储库中定义配置。 这些用户不需要管道工具来推送配置。 他们改用本机 Git 提交和 PR 过程来定义配置，并将更改推送到代表环境的分支。
• 对于新的配置定义，首先在较低的环境（例如 Dev）中定义配置，然后通过合并和拉取请求提升到更高的环境。 根据需要挑拣特定于某些环境的配置更新。

反馈和警报

• 配置 Flux 通知以在 GitOps 配置无法同步或引发错误时发出警报。 应用程序操作员应配置警报以确定应用程序部署何时成功且正常。 群集操作员应配置警报以确定群集范围的组件对帐何时失败以及 Git 存储库何时出现同步问题。
• 实现 GitOps 连接器以将来自 Flux 代理的反馈集成到你的 CI/CD 工具中。

安全建议

• 查看针对已启用 Azure Arc 的 Kubernetes 群集的治理和安全建议。
• 通过使用具有可用于定义任何配置存储库的身份验证和授权的专用 Git 存储库，避免对任何群集配置进行不必要的访问。
  • 通过 SSH 连接到 GitHub
  • 为 Azure DevOps 选择正确的身份验证机制
• 通过 SSH 协议和 SSH 密钥（如果你的 Git 提供程序支持它）访问 Git 存储库。 如果 SSH 由于出站连接限制而不稳定，或者如果你的 Git 提供程序不支持所需的 SSH 库，请使用专用服务帐户并将 API 密钥与该帐户相关联，供 Flux 使用。 如果在使用 GitHub 时需要 SSH 的替代项，可以创建个人访问令牌来用于身份验证。
• 配置与群集职责匹配的分支策略和权限。 设置最少数量的审阅者来审批更改。
• 配置 PR 管道以验证 YAML 配置和语法，并选择性地部署测试 Kubernetes 群集。 设置一个分支策略，该策略要求此管道在可以接受任何合并之前成功运行。
• 使用适用于机密存储 CSI 驱动程序的 Azure Key Vault 提供程序来实施机密，这允许通过 CSI 卷将 Azure Key Vault 作为机密存储与已启用 Azure Arc 的 Kubernetes 集群集成。
• Flux 扩展支持命名空间和群集范围的配置。 如果不希望你的配置具有超出单个命名空间的访问权限，请选择命名空间范围。

后续步骤

有关混合云和多云旅程的详细信息，请参阅以下文章。

• 查看已启用 Azure Arc 的 Kubernetes 的先决条件。
• 查看启用 Azure Arc 的 Kubernetes 的经过验证的 Kubernetes 发行版。
• 了解如何管理混合和多云环境。
• 若要详细了解已启用 Azure Arc 的 Kubernetes 的 GitOps，
  • 查看概念 GitOps with Flux v2。
  • 了解如何使用 GitOps with Flux v2。
  • 查看概念 GitOps Flux v2 CI/CD 过程。
  • 按照实现 Flux v2 CI/CD 的教程进行操作。
• 通过 Azure Arc Jumpstart 中提供的 GitOps 流来体验已启用 Azure Arc 的 Kubernetes。
• 通过 Azure Arc 学习路径了解 Azure Arc。
• 查看常见问题解答 - 已启用 Azure Arc，以获取最常见问题的解答。