关于git:GitOps-应用实践系列-Flux-CD-及其核心组件

大家好，我是张晋涛。

通过后面三篇文章，不仅为大家介绍了什么是 GitOps 也介绍了如何利用 Argo CD 来施行 GitOps。本篇我来为你介绍另一个可用于施行 GitOps 的工具：Flux CD。

Flux CD

Flux 是一组可反对实现 GitOps 的工具，用于使 Kubernetes 集群与配置源（如 Git 仓库）放弃同步，并在有代码更新后主动同步配置，面向 Kubernetes 的 继续渐进式交付解决方案。

Flux CD 的倒退历史

• 2016 年 10 月 28 日，Flux single-user service 版本公布。

它奠定了 flux 的两个基调：

• • 集中式运行的服务
  • 以守护过程的形式，在主动模式下运行在 k8s 集群中

• 2016 年 12 月 15 日，公布《应用 Weave Flux 继续交付》，构建了将 CI 与继续部署 (CD) 分割起来的 Flux。

​

• 2017 年 8 月 22 日，v1.0.0 版本正式公布。

自 v1.0.0 开始，Flux 致力于将集群与存储在 Git 中的配置同步，并在新版本筹备好部署时主动降级镜像。（提出了：Configuration as code）

​

• 2018 年 5 月 1 日，公布的 alpha 版本中，集成了 Helm Operator。这是 Flux Helm Operator 的第一个 alpha 标签的版本。
• 2019 年 8 月 15 日，Flux 发表退出 CNCF Sandbox。随着各开发者及企业开始落地 GitOps，Flux 的用户数量一直增长。彼时已超过 2500 个 GitHub star，也在一直地集成：Helm Operator、Kustomize、Weave Flagger、OpenFaaS、Fluxcloud、Flux Web UI 等。
• 2019 年 10 月 2 日公布的版本，正式反对 kustomize。
• 2019 年 11 月 14 日，《Argo Flux 简介 – Weaveworks-Intuit-AWS 合作》中，Weaveworks 发表与 Intuit 单干创立了 Argo Flux。该我的项目被称为 GitOps-Engine，当初位于 Argo 我的项目组织中，由 Intuit、Red Hat 和 GitLab 驱动。（具体可参考：https://www.weave.works/blog/…）
• 2020 年 10 月 5 日，Flux v1（和 Helm Operator v1）发表处于保护模式（仅提供 6 个月反对），并发表将致力于 Flux v2 的开发。

• • Flux v1 is in maintenance mode #3320 https://github.com/fluxcd/flu…
  • Helm Operator (v1) is in maintenance mode #546 https://github.com/fluxcd/hel…
• • V1 in maintenance #25 https://github.com/fluxcd/web…

• 2021 年 2 月 17 日新版本公布，正式将 issue、PR 指向 v2。
• 2021 年 3 月 11 日，CNCF 技术监督委员会（TOC）投票将 Flux 从 Sandbox 晋升为孵化我的项目（Incubation）。自退出 CNCF Sandbox 以来，Flux 的最终用户群减少了 2.75 倍，并将其社区扩充了 2 至 4 倍，包含 Slack 用户、邮件列表订阅者和贡献者。80 多个组织在生产中应用它，包含 Babylon Health、Fidelity Investments、MyFitnessPal、Starbucks 等等。CNCF End User Community 将 Flux 纳入继续交付的 Technology Radar。

​

• 2021 年 8 月 13 日，正式公布了《Flux v2 助力 GitOps 变得更好》，宣告了从 Flux 到 Flux v2 的交替。Flux v2 在 Flux 已有性能的根底上，更适于 Kubernetes 的操作和 可观测性，并且性能更弱小。Flux v2 的根底是 GitOps Toolkit，这是一组用于构建基于 GitOps 的交付和自动化组件。（也实现了重要组件的解耦，具体可参考：https://www.weave.works/blog/…）

​

​ 注：Flux 团队决定在不应用 GitOps Engine 的状况下继续前进，并构建了 GitOps Toolkit。Flux v2 参考了 GitOps Engine，但它不应用 GitOps Engine。

• 自 2018 年 10 月开始的 Flagger 我的项目也于 2021 年集成入 Flux v2。

​

​

Flux CD v2 和 GitOps Toolkit

GitOps Toolkit

GitOps Toolkit 是形成 Flux 运行时的一组 APIs 和 controllers。能够通过 GitOps Toolkit 来扩大 Flux，并构建所需 CD 零碎。

Source Controller

Source Controller 次要作用是为工件获取提供通用接口。Source API 定义了一组 Kubernetes 对象，cluster admin 和各种自动化 operator 能够与之交互，以将 Source（如 Git 和 Helm repo）注册、身份验证、验证和资源获取卸载到专用的 controller。

每个 Flux 和 Helm 的 operator 都以雷同的形式应用 Git repositories 中的代码（镜像），然而其余组件可能须要拜访到不同的镜像。Flux 和 Helm operator 就能够应用规范的 Kubernetes 机制来构建 Source（通常是 Git repo，但也有 Helm chart 等）作为 Kubernetes 资源，独立于应用它们的组件进行治理。

Git Repository

它为来自 Git 的 artifact 定义了一个源，将来自 Git 的最新状态作为 artifact 公开为 gzip 压缩的 TAR 文件 (<commit hash>.tar.gz)。

默认状况会排除，Git 文件 (.git/ ,.gitignore, .gitmodules, .gitattributes)；文件扩展名 (.jpg, .jpeg, .gif, .png, .wmv, .flv, .tar.gz, .zip)；CI 配置 (.github/, .circleci/, .travis.yml, .gitlab-ci.yml, appveyor.yml, .drone.yml, cloudbuild.yaml, codeship-services.yml, codeship-steps.yml)；CLI 配置 (.goreleaser.yml, .sops.yaml)；Flux v1 配置 (.flux.yaml)。

如果想要自定义排除能够思考以下两种方法：

• 通过 .sourceignore 在 repository 的根目录中增加文件。（遵循 .gitignore 格局，详见 https://git-scm.com/docs/giti…）
• 应用 spec.ignore 字段。

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
  name: podinfo
  namespace: default
spec:
  interval: 5m
  url: https://github.com/stefanprodan/podinfo
  ignore: |
    ## exclude all
    /*
    ## include deploy dir
    !/deploy
    ## exclude file extensions from deploy dir
    /deploy/**/*.md
    /deploy/**/*.txt  

Helm Charts

它为来自 Helm 源 的 Helm chart artifacts 定义了一个源，将作为 artifact 的最新拉取或打包的 chart 公开。

Helm Repositories

它为 Helm repositories 定义了一个源，将作为 artifact 的最新同步的 repository 索引公开。

Object storage buckets

它为来自 S3 兼容的存储（Minio, Amazon S3, Google Cloud Storage, Alibaba Cloud OSS 等等）定义了一个源，将来自 S3 的最新同步状态作为 artifact 公开为 gzip 压缩的 TAR 文件 (<bucket checksum>.tar.gz)。

默认及自定义排除文件，可参考 Git Repositories 中的排除文件相干内容。

Kustomize Controller

kustomize-controller 是一个专门用于运行通过应用 Kustomize 组装 Kubernetes 清单和工作负载定义的继续交付 pipeline 的 Kubernetes operator。它提供一个自动化的 operator，能够疏导并继续协调来自多个 sources（例如基础设施和应用程序 repositories）的集群状态。

配置新集群时，能够依照特定程序装置工作负载。当多个团队同时操作集群时，集群管理员能够为每个团队调配角色和服务帐户。团队领有的 manifests 将应用团队帐户利用于集群，从而确保团队之间的隔离。

处理事件时，能够抉择不进行协调器影响整个集群，采纳暂停某些工作负载的协调并将其余工作负载的协调固定到指定的 Git 版本的形式进行。

操作集群时，不同的团队能够收到与之相干的 CD pipeline 状态告诉。

Kustomization API 定义了一个能够获取，解密，构建，验证和利用 Kubernetes manifests 的 pipeline。

spec.sourceRef 是对 Source Controller 治理的对象的援用。当 Source（反对类型：GitRepository、Bucket）版本变更时，它会生成一个 Kubernetes 事件，触发 kustomize 的构建和利用。

如果 repository 蕴含原始的 Kubernetes manifest，会为 spec.path 和子目录中的所有 Kubernetes manifest 主动生成 kustomization.yaml。（倡议 kustomization.yaml 自行生成并存储在 Git 仓库中）

spec.interval 通知 Controller 在哪个工夫距离为 Source 获取 Kubernetes manifest，构建 Kustomization 并将其利用于集群。间隔时间单位是 s（最小值应超过 60 秒，interval: 60s）。

spec.healthChecks、spec.wait 和 spec.timeout 能够设置一系列运行状况查看。

• Kubernetes 内置（Deployment、DaemonSet、StatefulSet、PersistentVolumeClaim、Pod、PodDisruptionBudget、Job、CronJob、Service、Secret、ConfigMap、CustomResourceDefinition）
• Toolkit（HelmRelease、HelmRepository、GitRepository 等）
• 与 kstatus 兼容的自定义资源（https://github.com/kubernetes…）

spec.dependsOn 能够自定义依赖。多个 Kustomizations 的状况下，能够指定先后顺序及依赖。这就引入了两个必须留神的中央：

• 防止循环。
• 与健康检查联合应用时，将在其所有依赖项健康检查通过后运行 Kustomization。

Kustomization 在笼罩自定义配置、变量替换、加解密等也有这很多灵便的设置，感兴趣的小伙伴能够自行浏览官网文档理解。

Helm Controller

Helm Controller 是一个 Kubernetes operator，容许应用 Kubernetes manifests 以申明形式治理 Helm chart Release。它提供一个自动化的 operator，能够执行 Helm 操作（例如装置、降级、卸载、回滚、测试）并继续协调 Helm Release 的状态。

配置新集群时，能够指定程序装置 Helm Release。处理事件时，能够不用进行协调器影响整个集群，采纳暂停一些 Helm Release 的协调即可。操作集群时，不同的团队能够收到与其无关的 Helm Release 状态的告诉。

HelmRelease 对象定义了一个控制器资源通过 Helm 操作（例如装置、降级、测试、卸载和回滚）驱动的 Helm Release 协调。包含公布地位（namespace/name）、公布内容（chart/values overrides）、操作触发器配置、个别操作配置和状态。

能够别离通过 spec.targetNamespace、spec.storageNamespace 和 spec.releaseName 笼罩默认部署和存储 Helm Release 的 namespace/name。

spec.chart.spec 是创立具备指定 spec 的新 HelmChart 资源的模板。spec.chart.spec.sourceRef 是对 Source Controller 治理的对象的援用。当 source（反对类型：HelmRepository、GitRepository、Bucket）版本变更时，会生成触发新版本的 Kubernetes 事件。

如果没有找到具备匹配 namespace/name 的 Helm Release，将装置配置中的 Helm Release。

当呈现以下状态更新时，Helm Release 将降级：

• spec（以及 metadata.generation）
• 最新的 HelmChart 修订版可用
• ConfigMap 和 Secret 值笼罩（为了防止在更新多个资源时产生大量降级，不会立刻进行，会在 spec.interval 距离后进行）

Helm 反对装置 CRD，因为存在数据失落的危险，目前暂不反对应用 Helm 降级或删除 CRD。

更多 Helm Controller 的具体内容欢送参考官网文档。

Notification Controller

Notification Controller 是一个 Kubernetes operator，专门解决出入口事件。

它提供一个告诉服务，能够通过 HTTP 接管事件并依据事件严重性和波及的对象将它们分派到内部零碎（Slack、Microsoft Teams、Discord、Rocker）。

GitOps Controller 实质上是基于拉取的，为了告诉 Controllers 无关 Git 或 Helm 库中的变更，能够反对设置 webhooks 在每次源更改时触发集群协调。

Image reflector and automation controllers

image-reflector-controller 和 image-automation-controller 协同工作，在新的容器镜像可用时更新 Git repository。

• image-reflector-controller 扫描镜像仓库，并与 K8S 资源中的元数据进行比照。
• image-automation-controller 依据扫描到的最新镜像，更新 YAML 文件 并且提交变更到指定的 Git repository。

Flux CD 应用要求

Kubernetes 版本

应用 Flux CD，最好 Kubernetes 集群版本在 v1.19 或更高版本。旧版本也反对，但官网不倡议在生产中运行 EOL Kubernetes 版本。

注：如果你正在应用 APIService（例如 metrics-server），Kubernetes 集群版本至多须要 v1.18.18，v1.19.10，v1.20.6 或 v1.21.0。

Git Repo 权限

通过设置 SSH 部署密钥或应用基于令牌的身份验证，将指标集群配置为与 Git 库进行同步。

• GitLab 应用示例

// 将 GitLab personal access token 导出为环境变量：export GITLAB_TOKEN=<your-token>
// 在 GitLab 账号上运行 git 库的疏导程序：flux bootstrap gitlab \
  --owner=my-gitlab-username \
  --repository=my-repository \
  --branch=master \
  --path=clusters/my-cluster \
  --token-auth \
  --personal
// 应用部署密钥进行身份验证运行 git 库的疏导程序，必须指定 SSH hostname：flux bootstrap gitlab \
  --ssh-hostname=gitlab.com \
  --owner=my-gitlab-username \
  --repository=my-repository \
  --branch=master \
  --path=clusters/my-cluster
// 为 GitLab 团队的 git 库运行疏导程序：flux bootstrap gitlab \
  --owner=my-gitlab-group/my-gitlab-subgroup \
  --repository=my-repository \
  --branch=master \
  --path=clusters/my-cluster
// 为托管在本地或企业 GitLab 上的 git 库运行疏导程序，必须指定 GitLab hostname：flux bootstrap gitlab \
  --hostname=my-gitlab.com \
  --token-auth \
  --owner=my-gitlab-group \
  --repository=my-repository \
  --branch=master \
  --path=clusters/my-cluster

• GitHub 应用示例

// 将 GitHub personal access token 导出为环境变量：export GITHUB_TOKEN=<your-token>
//flux bootstrap 命令会创立一个 SSH 密钥，并存储在 Kubernetes 集群中。// 该密钥还用于在 GitHub 库中创立部署密钥。// 在 GitHub 账号上运行 git 库的疏导程序：flux bootstrap github \
  --owner=my-github-username \
  --repository=my-repository \
  --path=clusters/my-cluster \
  --personal
// 当指定团队列表时，这些团队将被授予对 git 库的维护者拜访权限。// 为 GitHub 中团队领有的 git 库运行疏导程序：flux bootstrap github \
  --owner=my-github-organization \
  --repository=my-repository \
  --team=team1-slug \
  --team=team2-slug \
  --path=clusters/my-cluster

总结

本篇次要介绍了 Flux CD 的倒退历史和其外围组件及其性能，后续文章中将陆续介绍如何应用 Flux CD 来实际 GitOps，敬请期待。