使用适用于 AKS 和已启用 Azure Arc 的 Kubernetes 的 GitOps (Flux v2) 进行应用程序部署

Azure 使用适用于 Azure Kubernetes 服务 (AKS) 和已启用 Azure Arc 的 Kubernetes 群集的 GitOps 提供自动化应用程序部署功能。 采用 GitOps 将应用程序部署到 Kubernetes 群集提供的主要优势包括:

  • 持续了解群集上运行的应用程序的状态。
  • 在应用程序开发团队和基础结构团队之间分离关注点。 应用程序团队无需具备 Kubernetes 部署的经验。 平台工程团队通常为应用程序团队创建自助服务模型,使他们能够更自信地运行部署。
  • 能够在崩溃或横向扩展时重新创建具有相同所需状态的群集。

通过 GitOps,可以在 Git 存储库中的文件中声明 Kubernetes 群集的所需状态。 Git 存储库可能包含以下文件:

  • YAML 格式的清单,用于描述 Kubernetes 资源(如命名空间、机密、部署和其他)
  • 用于部署应用程序的 Helm 图表
  • 用于描述环境特定更改的 Kustomize 文件

由于这些文件存储在 Git 存储库中,因此会对其进行版本控制,并可以轻松地跟踪版本之间的更改。 Kubernetes 控制器在群集中运行,并不断地使群集状态与 Git 存储库中声明的所需状态保持一致。 这些运算符从 Git 存储库中提取文件,并将所需状态应用到群集。 操作员还会持续确保群集保持在所需状态。

启用了 Azure Arc 的 Kubernetes 或 Azure Kubernetes 服务上的 GitOps 使用 Flux,它是一种常用的开源工具集。 Flux 支持常见文件源(Git 和 Helm 存储库、Bucket、Azure Blob 存储)和模板类型(YAML、Helm 和 Kustomizze)。 Flux 还支持多租户和部署依赖关系管理,以及其他功能

Flux 直接部署在群集上,并且每个群集的控制平面在逻辑上是分开的。 这使得它可以很好地扩展到数十万个群集。 Flux 支持基于纯拉取的 GitOps 应用程序部署。 源存储库或任何其他群集不需要访问群集。

Flux 群集扩展

在启用了 Azure Arc 的 Kubernetes 或 AKS 群集中启用 GitOps 作为 Microsoft.KubernetesConfiguration/extensions/microsoft.flux 群集扩展资源。 必须先在群集中安装 microsoft.flux 扩展,然后才能创建一个或多个 fluxConfigurations。 在群集中创建第一个 Microsoft.KubernetesConfiguration/fluxConfigurations 时,将自动安装该扩展,你也可以使用门户、Azure CLI (az k8s-extension create --extensionType=microsoft.flux)、ARM 模板或 REST API 手动安装该扩展。

Controllers

默认情况下,microsoft.flux 扩展安装 Flux 控制器(源、Kustomize、Helm、通知)以及 FluxConfig 自定义资源定义 (CRD)、fluxconfig-agentfluxconfig-controller。 另外,你还可以安装 Flux image-automationimage-reflector 控制器,这些控制器提供用于更新和检索 Docker 映像的功能。

  • Flux 源控制器:监视 source.toolkit.fluxcd.io 自定义资源。 处理 Git 存储库、Helm 存储库、Bucket 和 Azure Blob 存储之间的同步。 使用专用 Git、Helm 存储库和 Azure Blob 存储帐户的源来处理授权。 通过 tar 存档文件显示对源的最新更改。

  • Flux Kustomize 控制器:监视 kustomization.toolkit.fluxcd.io 自定义资源。 将源中的 Kustomize 或原始 YAML 文件应用到群集。

  • Flux Helm 控制器:监视 helm.toolkit.fluxcd.io 自定义资源。 从源控制器呈现的 Helm 存储库源检索关联图表。 创建 HelmChart 自定义资源,并将具有给定版本、名称和客户定义值的 HelmRelease 应用到群集。

  • Flux 通知控制器:监视 notification.toolkit.fluxcd.io 自定义资源。 接收来自所有 Flux 控制器的通知。 将通知推送到用户定义的 webhook 终结点。

  • Flux 自定义资源定义:

    • kustomizations.kustomize.toolkit.fluxcd.io
    • imagepolicies.image.toolkit.fluxcd.io
    • imagerepositories.image.toolkit.fluxcd.io
    • imageupdateautomations.image.toolkit.fluxcd.io
    • alerts.notification.toolkit.fluxcd.io
    • providers.notification.toolkit.fluxcd.io
    • receivers.notification.toolkit.fluxcd.io
    • buckets.source.toolkit.fluxcd.io
    • gitrepositories.source.toolkit.fluxcd.io
    • helmcharts.source.toolkit.fluxcd.io
    • helmrepositories.source.toolkit.fluxcd.io
    • helmreleases.helm.toolkit.fluxcd.io
    • fluxconfigs.clusterconfig.azure.com
  • FluxConfig CRD:定义 FluxConfig Kubernetes 对象的 fluxconfigs.clusterconfig.azure.com 自定义资源的自定义资源定义。

  • fluxconfig-agent:负责监视 Azure 中新的或更新的 fluxConfigurations 资源,以及启动群集中关联的 Flux 配置。 此外,还要负责将群集中的 Flux 状态更改推送回每个 fluxConfigurations 资源的 Azure。

  • fluxconfig-controller:监视 fluxconfigs.clusterconfig.azure.com 自定义资源,并使用群集中 GitOps 机制的新配置或更新的配置响应更改。

注意

microsoft.flux 扩展已安装在 flux-system 命名空间中,并且具有群集范围。 无法在命名空间作用域内安装此扩展。

Flux 配置

显示在已启用 Azure Arc 的 Kubernetes 或 AKS 群集中安装 Flux 配置的示意图。

创建 Flux 配置资源 (Microsoft.KubernetesConfiguration/fluxConfigurations),以从 Git 存储库、Bucket 源或 Azure Blob 存储启用群集的 GitOps 管理。 创建 fluxConfigurations 资源时,你为参数提供的值(例如目标 Git 存储库)用于创建和配置在该群集中启用 GitOps 进程的 Kubernetes 对象。 为确保数据安全,群集配置服务会将 fluxConfigurations 资源数据以静态加密方式存储在 Azure Cosmos DB 数据库中。

microsoft.flux 扩展一起安装的 fluxconfig-agentfluxconfig-controller 代理管理 GitOps 配置过程。

fluxconfig-agent 负责以下任务:

  • 为新资源或更新的 fluxConfigurations 资源轮询 Kubernetes 配置数据平面服务。
  • 使用配置信息在群集中创建或更新 FluxConfig 自定义资源。
  • 监视 FluxConfig 自定义资源,并将状态更改推送回关联的 Azure fluxConfiguration 资源。

fluxconfig-controller 负责以下任务:

  • 监视由托管 fluxConfigurations 创建的 Flux 自定义资源的状态更新。
  • 创建在 fluxConfigurations 生存期内存在的私钥/公钥对。 如果 URL 基于 SSH,并且用户在创建配置过程中未提供自己的私钥,则此密钥用于身份验证。
  • 基于用户提供的私钥/http 基本身份验证/已知主机/非身份验证数据创建自定义身份验证机密。
  • 设置基于角色的访问控制(预配的服务帐户、创建/分配的角色绑定、创建/分配的角色)。
  • 基于 FluxConfig 自定义资源中的信息创建 GitRepositoryBucket 自定义资源和 Kustomization 自定义资源。

Azure 中的每个 fluxConfigurations 资源都与 Kubernetes 群集中的一个 Flux GitRepositoryBucket 自定义资源以及一个或多个 Kustomization 自定义资源相关联。 创建 fluxConfigurations 资源时,我们将指定源(Git 存储库、Bucket 或 Azure Blob 存储)的 URL,以及每个 Kustomization 的源中的同步目标。 你可以配置 Kustomization 自定义资源之间的依赖关系,以控制部署顺序。 你还可以为不同的应用程序和应用团队在同一群集上创建多个命名空间范围的 fluxConfigurations 资源。

注意

fluxconfig-agent 监视 Azure 中的新的或更新的 fluxConfiguration 资源。 代理需要连接到 Azure,才能将 fluxConfiguration 的所需状态应用到群集。 如果代理无法连接到 Azure,则群集中的更改将一直等待,直至代理可以连接。 如果群集从 Azure 断开连接超过 48 小时,则对群集发出的请求将超时,并且需要在 Azure 中重新应用所做的更改。

敏感的客户输入内容(例如私钥和令牌/密码)在 Kubernetes 配置服务中的存储时间少于 48 小时。 如果在 Azure 中更新任意这些值,请确保群集在 48 小时内与 Azure 建立连接。

可以在 Azure 门户中监视 Flux 配置状态和合规性,或者使用仪表板监视状态、合规性、资源消耗和对帐活动。 有关详细信息,请参阅监视 GitOps (Flux v2) 状态与活动

版本支持

支持 Flux v2 扩展的最新版本 (microsoft.flux) 和前两个版本 (N-2)。 我们通常建议使用最新版本的扩展。 从 microsoft.flux 版本 1.7.0 开始,支持基于 ARM64 的群集。

注意

如果一直使用 Flux v1,建议尽快迁移到 Flux v2

2025 年 5 月 24 日起,将不再支持 2024 年 1 月 1 日之前创建的基于 Flux v1 的群集配置资源。 从 2024 年 1 月 1 日开始,你将无法创建新的基于 Flux v1 的群集配置资源。

如果添加了对已启用 Azure Arc 的 Kubernetes 群集的专用链接的支持,则 microsoft.flux 扩展可以立即与 Azure 通信。 若要连接到 Git 存储库、Helm 存储库或部署 Kubernetes 清单所需的任何其他终结点,必须在防火墙后面预配这些终结点,或者在防火墙上列出它们,以便 Flux 源控制器能够成功访问它们。

数据驻留

Azure GitOps 服务 (Azure Kubernetes 配置管理)存储/处理客户数据。 客户数据默认复制到配对区域。

大规模应用 Flux 配置

由于 Azure 资源管理器会管理你的配置,因此你可以在订阅或资源组范围内,使用 Azure Policy 在所有 Azure Kubernetes 服务和已启用 Azure Arc 的 Kubernetes 资源中自动创建相同的配置。 这种大规模强制确保跨整个群集组一致地应用特定配置。

参数

若要查看 Azure 中的 Flux v2 支持的所有参数,请参阅 az k8s-configuration 文档。 Azure 实施目前并不支持 Flux 支持的所有参数。

有关可用参数及其用法的信息,请参阅 GitOps (Flux v2) 支持的参数

多租户

版本 0.26 开始,Flux v2 支持多租户。 此功能已集成到 Azure 中的 Flux v2。

注意

对于多租户功能,需要知道清单是否包含 HelmRelease、Kustomization、ImagePolicy 或其他对象的任何跨命名空间 sourceRef,或者使用的 Kubernetes 版本是否低于 1.20.6。 准备工作:

  • 升级到 Kubernetes 版本 1.20.6 或更高版本。
  • 在 Kubernetes 清单中,确保所有 sourceRef 都指向与 GitOps 配置位于相同命名空间中的对象。
    • 如果需要时间来更新清单,可以选择退出多租户。 但仍需升级 Kubernetes 版本。

为多租户更新清单

假设你使用群集作用域将 fluxConfiguration 部署到 cluster-config 命名空间中的一个 Kubernetes 群集。 将源配置为同步 https://github.com/fluxcd/flux2-kustomize-helm-example 存储库。 这与使用 GitOps 和 Flux v2 部署应用程序教程中使用的示例 Git 存储库相同。

Flux 同步存储库后,它会部署清单中所述的资源(YAML 文件)。 两个清单描述了 HelmReleaseHelmRepository 对象。

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx
  namespace: nginx
spec:
  releaseName: nginx-ingress-controller
  chart:
    spec:
      chart: nginx-ingress-controller
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: flux-system
      version: "5.6.14"
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  # Default values
  # https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
  values:
    service:
      type: NodePort
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: flux-system
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami

默认情况下,Flux 扩展通过模拟仅部署在 cluster-config 命名空间中的 flux-applier 服务帐户来部署 fluxConfigurations。 使用上述清单,启用多租户后,HelmRelease 将被阻止。 这是因为 HelmRelease 位于 nginx 命名空间中,但它引用 flux-system 命名空间中的 HelmRepository。 此外,Flux helm-controller 无法应用 HelmRelease,因为 nginx 命名空间中没有 flux-applier 服务帐户。

若要使用多租户,正确的方法是将所有 Flux 对象部署到与 fluxConfigurations 相同的命名空间中。 此方法可以避免出现跨命名空间引用问题,并允许 Flux 控制器获取应用对象的权限。 因此,对于在 cluster-config 命名空间中创建的 GitOps 配置,这些示例清单将如下更改:

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx
  namespace: cluster-config 
spec:
  releaseName: nginx-ingress-controller
  targetNamespace: nginx
  chart:
    spec:
      chart: nginx-ingress-controller
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: cluster-config
      version: "5.6.14"
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  # Default values
  # https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
  values:
    service:
      type: NodePort
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: cluster-config
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami

选择退出多租户

安装 microsoft.flux 扩展时,将默认启用多租户。 如果你需要禁用多租户,可以通过使用 --configuration-settings multiTenancy.enforce=false 在群集中创建或更新 microsoft.flux 扩展来选择退出,如以下示例命令中所示:

az k8s-extension create --extension-type microsoft.flux --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>
az k8s-extension update --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>

从 Flux v1 迁移

如果你仍在使用 Flux v1,我们建议尽快迁移到 Flux v2。

若要在使用 Flux v1 的同一群集中迁移到使用 Flux v2,必须先从群集中删除所有 Flux v1 sourceControlConfigurations。 由于 Flux v2 具有完全不同的体系结构,因此如果群集中有 Flux v1 sourceControlConfigurations 资源,则不会安装 microsoft.flux 群集扩展。 删除 Flux v1 配置和部署 Flux v2 配置的过程不应超过 30 分钟。

删除 Flux v1 sourceControlConfigurations 不会停止群集上运行的任何应用程序。 但是,在删除 Flux v1 配置且 Flux v2 扩展尚未完全部署期间:

  • 如果存储在 Git 存储库中的应用程序清单中有新更改,则迁移期间不会拉取这些更改,并且部署在群集上的应用程序版本将过时。
  • 如果群集状态发生意外更改,并且它偏离了源 Git 存储库中指定的所需状态,则群集将无法自我修复。

建议在迁移生产环境之前在开发环境中测试迁移方案。

查看和删除 Flux v1 配置

使用以下 Azure CLI 命令查找并删除群集中的现有 sourceControlConfigurations

az k8s-configuration flux list --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>
az k8s-configuration flux delete --name <configuration name> --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>

还可以在 Azure 门户中查找和删除群集的现有 GitOps 配置。 若要执行此操作,请导航到在其中创建配置的群集,然后在左窗格中选择“GitOps”。 选择配置,然后选择“删除”。

部署 Flux v2 配置

使用 Azure 门户或 Azure CLI 将 Flux v2 配置应用于群集。

Flux v1 停用信息

Flux v1 的开放源代码项目已存档,功能开发已无限期停止

Flux v2 作为 Flux 的升级开放源代码项目启动。 它具有新的体系结构,并支持更多 GitOps 用例。 Azure 于 2022 年 5 月推出了使用 Flux v2 的扩展版本。 此后,建议客户在三年内迁移到 Flux v2,因为对 Flux v1 的支持计划于 2025 年 5 月结束。

Flux v2 的 GitOps 扩展中引入的关键新功能:

  • Flux v1 是一个整体的全能运算符。 Flux v2 将功能分为专用控制器(源控制器、Kustomize 控制器、Helm 控制器和通知控制器)。
  • 支持与多个源存储库同步。
  • 支持多租户,例如使用自己的权限集应用每个源存储库。
  • 通过运行状况检查、事件和警报提供操作见解。
  • 支持 Git 分支,固定提交和标记并遵循 SemVer 标记范围。
  • 每个 GitRepository 资源的凭据配置:SSH 私钥、HTTP/S 用户名/密码/令牌和 OpenPGP 公钥。

后续步骤