使用 FluxCD 實(shí)現(xiàn) Kubernetes GitOps

作者：陽明 2023-10-07 07:51:55

Flux 項目由命令行工具（FLux CLI）和一系列 Kubernetes 控制器組成。要安裝 Flux，首先需要下載 Flux CLI，然后使用 CLI，可以在集群上部署 Flux 控制器并配置 GitOps 交付流水線。

Flux 是一套針對 Kubernetes 的持續(xù)交付和漸進(jìn)式交付的解決方案，可以讓我們以 GitOps 的方式輕松地交付應(yīng)用。和另一個同類的 CNCF 孵化項目 Argo CD 不同，F(xiàn)lux CD 是許多工具集的集合，天然松耦合并且有良好的擴(kuò)展性，用戶可按需取用。最新版本的 Flux 引入了許多新功能，使其更加靈活多樣。Flux 已經(jīng)是 CNCF 畢業(yè)項目。

組件

Flux 是使用 GitOps Toolkit 組件構(gòu)建的，它是一組：

專用工具和 Flux 控制器。
可組合的 API。
在 fluxcd GitHub 組織下，為構(gòu)建基于 Kubernetes 的持續(xù)交付提供可重用的 Go 依賴包。

用于在 Kubernetes 之上構(gòu)建持續(xù)交付。

GitOps Toolkit

這些 API 包括 Kubernetes 自定義資源，可以由集群用戶或其他自動化工具進(jìn)行創(chuàng)建和更新。我們可以使用這個工具包擴(kuò)展 Flux，并構(gòu)建自己的持續(xù)交付系統(tǒng)。

Flux 的核心工具包包括以下 5 個：

Source Controller
Kustomize Controller
Helm Controller
Notification Controller
Image automation controllers

每個工具包都是一個控制器，都有自己的自定義資源定義 (CRD)，用于定義其行為。

安裝

Flux CLI 是一個二進(jìn)制可執(zhí)行文件，可以從 GitHub 發(fā)布頁面下載直接下載即可。

對于 Mac 用戶可以直接使用 homebrew 進(jìn)行一鍵安裝：

$ brew install fluxcd/tap/flux

如果是 Linux 用戶也可以使用下面的命令進(jìn)行安裝：

$ curl -s https://fluxcd.io/install.sh | sudo bash

安裝完成后，可以使用 flux 命令來驗(yàn)證是否安裝成功：

$ flux --version
flux version 2.1.1

接下來我們就可以使用 Flux CLI 來安裝 Flux 控制器了。

Flux CLI 提供了一個 bootstrap 命令在 Kubernetes 集群上部署 Flux 控制器，并配置控制器以從 Git 存儲庫同步集群狀態(tài)。除了安裝控制器之外，bootstrap 命令還將 Flux 清單推送到 Git 存儲庫，并將 Flux 配置為從 Git 進(jìn)行自我更新。

flux

如果集群上存在 Flux 控制器，則 bootstrap 命令將在需要時執(zhí)行升級。Bootstrap 是冪等的，可以安全地運(yùn)行該命令任意多次。

Flux 與主流的 Git 提供商進(jìn)行集成，以簡化部署密鑰和其他身份驗(yàn)證機(jī)制的初始設(shè)置。比如我們這里選擇和 GitLab 進(jìn)行集成。那么我們可以使用 bootstrap gitlab 命令在 Kubernetes 集群上部署 Flux 控制器，并配置控制器從 GitLab 項目同步集群狀態(tài)。除了安裝控制器之外，bootstrap 命令還將 Flux 清單推送到 GitLab 項目，并將 Flux 配置為從 Git 進(jìn)行自我更新。運(yùn)行 bootstrap 命令后，對集群的任何操作都可以通過 Git 推送完成，無需連接到 Kubernetes 集群。

要啟動 Flux，運(yùn)行命令的人員必須擁有目標(biāo) Kubernetes 集群的集群管理員權(quán)限，還要求運(yùn)行該命令的人是 GitLab 項目的所有者，或者具有 GitLab 組的管理員權(quán)限。

為了訪問 GitLab API，boostrap 命令需要具有對 GitLab API 的完整讀/寫訪問權(quán)限的 GitLab 個人訪問令牌 (PAT)。GitLab PAT 可以導(dǎo)出為環(huán)境變量：

export GITLAB_TOKEN=<gh-token>

如果未設(shè)置 GITLAB_TOKEN 環(huán)境變量，boostrap 命令將提示你輸入 token，當(dāng)然可以使用管道提供，例如：echo "<gl-token>" | flux bootstrap gitlab。

比如我們這里可以前往 GitLab 個人訪問令牌頁面頁面創(chuàng)建一個 PAT：

Create PAT

然后我們可以使用下面的命令來安裝 Flux：

export GITLAB_TOKEN=glpat-RzooW-ViSatx6zgzmb6d
flux bootstrap gitlab \
  --deploy-token-auth \
  --hostname=gitlab.k8s.local \
  --owner=cnych \
  --repository=flux \
  --branch=main \
  --path=clusters/my-cluster \
  --personal

如果指定的項目不存在，F(xiàn)lux 將為你創(chuàng)建一個私有項目，如果希望創(chuàng)建公共項目，需要設(shè)置 --private=false 參數(shù)。使用 --deploy-token-auth 時，CLI 會生成一個 GitLab 項目部署令牌，并將其作為 Kubernetes Secret 存儲在集群中 flux-system 命名空間內(nèi)。

對多環(huán)境集群的支持并沒有采用多倉庫/多分支的策略，而是用的使用不同路徑來管理不同的集群，這也是 Flux 推薦的策略，可以減少代碼維護(hù)和合并的難度。

上面的命令執(zhí)行后會出現(xiàn)如下所示的錯誤信息：

? connecting to https://gitlab.k8s.local
? failed to get Git repository "https://gitlab.k8s.local/cnych/flux": provider error: Get "https://gitlab.k8s.local/api/v4/projects/cnych%2Fflux": tls: failed to verify certificate: x509: certificate is valid for ingress.local, not gitlab.k8s.local

這是因?yàn)槲覀冞@里安裝的 GitLab 使用的是 http 的方式，而且該命令下面并沒有跳過對 https 證書校驗(yàn)的參數(shù)，所以這里我們需要換另外一種方式來安裝，使用通用的 git 方式來安裝，命令如下所示：

flux bootstrap git \
  --url=http://gitlab.k8s.local/cnych/flux \
  --username=cnych \
  --password=<gh-token> \
  --token-auth=true \
  --path=clusters/my-cluster
  --allow-insecure-http=true  # 運(yùn)行不安全的 http 方式

上面的命令會在 flux-system 命名空間中部署一系列 Kubernetes 控制器及其 CRD、RBAC 和網(wǎng)絡(luò)策略，默認(rèn)的組件包括：source-controller、kustomize-controller、helm-controller、notification-controller，可以通過 --components 參數(shù)來指定要安裝的組件，但是需要注意最小安裝需要 source-controller 和 kustomize-controller 兩個組件。

上面的命令執(zhí)行后會正常情況下會出現(xiàn)如下所示的輸出信息：

? cloning branch "main" from Git repository "http://gitlab.k8s.local/cnych/flux"
? cloned repository
? generating component manifests
? generated component manifests
? component manifests are up to date
? reconciled components
? determining if source secret "flux-system/flux-system" exists
? generating source secret
? applying source secret "flux-system/flux-system"
? reconciled source secret
? generating sync manifests
? generated sync manifests
? sync manifests are up to date
? applying sync manifests
? reconciled sync configuration
◎ waiting for Kustomization "flux-system/flux-system" to be reconciled
? Kustomization reconciled successfully
? confirming components are healthy
? helm-controller: deployment ready
? kustomize-controller: deployment ready
? notification-controller: deployment ready
? source-controller: deployment ready
? all components are healthy

在 flux-system 命名空間中可以查看到部署的 Flux 控制器：

$ kubectl get pods -n flux-system
NAME                                      READY   STATUS    RESTARTS   AGE
helm-controller-7c8b698656-gftdr          1/1     Running   0          65m
kustomize-controller-858996fc8d-k2dlx     1/1     Running   0          65m
notification-controller-ddf44665d-49vtp   1/1     Running   0          65m
source-controller-594c848975-sq2pp        1/1     Running   0          29m

此時在對于的 GitLab 代碼倉庫 http://gitlab.k8s.local/cnych/flux 中可以看到 Flux 為我們創(chuàng)建了一個 clusters/my-cluster/flux-system 的目錄，里面包含了一些 Flux 的配置文件。

flux git

到這里我們就完成了 Flux 的安裝。

示例

這里我們還是以前面 Jenkins Pipeline 章節(jié)中的示例來進(jìn)行說明，如何通過 Flux 來實(shí)現(xiàn) GitOps 的持續(xù)交付。

示例中要用到的 Git 資源清單倉庫為 http://gitlab.k8s.local/cnych/k8s-demo-config，該項目中包含一個 helm 目錄，目錄下面就是一個 helm chart 包：

demo config

當(dāng)然在繼續(xù)之前，為避免產(chǎn)生影響，我們可以將前面通過 Argo CD 部署的應(yīng)用刪除掉。

接下來我們就可以通過 Flux 來部署應(yīng)用了，首先需要為 FluxCD 創(chuàng)建一個倉庫連接信息，這就需要用到一個名為 GitRepository 的 CRD 對象，該對象可以定義一個 Source 代碼源來為 Git 存儲庫的一個版本生成一個制品，如下所示：

# k8s-demo-git-repo.yaml
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: k8s-demo
spec:
  url: http://gitlab.k8s.local/cnych/k8s-demo-config
  timeout: 60s
  interval: 30s
  ref:
    branch: main
  secretRef:
    name: k8s-demo
---
apiVersion: v1
stringData:
  password: <gl-token>
  username: cnych
kind: Secret
metadata:
  name: k8s-demo
type: Opaque

這里我們創(chuàng)建了一個名為 k8s-demo 的 GitRepository 對象，其中 spec 字段定義了如何從 Git 存儲庫提取數(shù)據(jù)，url 字段指定了 Git 存儲庫的 URL，ref 字段指定了要提取的代碼分支，interval 字段指定了從 Git 存儲庫提取數(shù)據(jù)的頻率，secretRef 字段指定了包含 GitRepository 身份驗(yàn)證憑據(jù)的 Secret。

對于 HTTPS 倉庫，Secret 必須包含基本認(rèn)證的 username 和 password 字段，或者令牌認(rèn)證的 bearerToken 字段。對于 SSH 倉庫，Secret 必須包含 identity 和 known_hosts 字段。

直接應(yīng)用該資源對象即可：

$ kubectl apply -f k8s-demo-git-repo.yaml
gitrepository.source.toolkit.fluxcd.io/k8s-demo created
secret/k8s-demo created
$ kubectl get gitrepositories
NAME       URL                                             AGE   READY   STATUS
k8s-demo   http://gitlab.k8s.local/cnych/k8s-demo-config   53s   True    stored artifact for revision 'main@sha1:cbb0226130da3ff5e1d4ccad9407e210ab65e551'

創(chuàng)建后我們可以通過 kubectl describe gitrepository k8s-demo 命令來查看 GitRepository 的各種狀態(tài)：

$ kubectl describe gitrepositories k8s-demo
Name:         k8s-demo
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  source.toolkit.fluxcd.io/v1
Kind:         GitRepository
Metadata:
  Creation Timestamp:  2023-09-23T09:29:35Z
  Finalizers:
    finalizers.fluxcd.io
  Generation:        1
  Resource Version:  485193
  UID:               fef6070d-56bf-452b-8aeb-c821a76ab8f2
Spec:
  Interval:  30s
  Ref:
    Branch:  main
  Secret Ref:
    Name:   k8s-demo
  Timeout:  60s
  URL:      http://gitlab.k8s.local/cnych/k8s-demo-config
Status:
  Artifact:
    Digest:            sha256:b1944afa22fe6b0ce816100b7ac307fc142506287af9d8ac2cc693f7af73364b
    Last Update Time:  2023-09-23T09:29:36Z
    Path:              gitrepository/default/k8s-demo/cbb0226130da3ff5e1d4ccad9407e210ab65e551.tar.gz
    Revision:          main@sha1:cbb0226130da3ff5e1d4ccad9407e210ab65e551
    Size:              7240
    URL:               http://source-controller.flux-system.svc.cluster.local./gitrepository/default/k8s-demo/cbb0226130da3ff5e1d4ccad9407e210ab65e551.tar.gz
  Conditions:
    Last Transition Time:  2023-09-23T09:29:36Z
    Message:               stored artifact for revision 'main@sha1:cbb0226130da3ff5e1d4ccad9407e210ab65e551'
    Observed Generation:   1
    Reason:                Succeeded
    Status:                True
    Type:                  Ready
    Last Transition Time:  2023-09-23T09:29:36Z
    Message:               stored artifact for revision 'main@sha1:cbb0226130da3ff5e1d4ccad9407e210ab65e551'
    Observed Generation:   1
    Reason:                Succeeded
    Status:                True
    Type:                  ArtifactInStorage
  Observed Generation:     1
Events:
  Type    Reason                 Age                From               Message
  ----    ------                 ----               ----               -------
  Normal  NewArtifact            103s               source-controller  stored artifact for commit 'build: automatic update of devops-demo2'
  Normal  GitOperationSucceeded  14s (x3 over 72s)  source-controller  no changes since last reconcilation: observed revision 'main@sha1:cbb0226130da3ff5e1d4ccad9407e210ab65e551'

通過 .status.artifact.revision 字段可以查看到當(dāng)前的 Git 版本，新的制品在 .status.artifact 字段中可以查看到。

接下來我們只需要為該應(yīng)用創(chuàng)建一個部署策略即可，由于我們這里要發(fā)布的是 Helm Chart，所以我們需要創(chuàng)建一個 HelmRelease 對象，該對象可以定義一個包含 Chart 的源（可以是 HelmRepository、GitRepository 或 Bucket）告知 source-controller，以便 HelmRelease 能夠引用它，很明顯我們這里的源就是上面定義的 GitRepository 對象。

我們這里創(chuàng)建的 HelmRelease 對象如下所示：

# k8s-demo-helm-release.yaml
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: k8s-demo
  namespace: default
spec:
  interval: 30s
  chart:
    spec:
      chart: helm # Chart 是 Helm chart 在 SourceRef 中可用的名稱或路徑
      sourceRef:
        kind: GitRepository
        name: k8s-demo
        namespace: default
      valuesFiles:
        - helm/values.yaml
        - helm/my-values.yaml
      interval: 30s
  values:
    replicaCount: 2

上面我們定義了一個 HelmRelease 對象，其中 chart 字段指定了 Helm Chart 的源，因?yàn)槲覀冞@里的 Helm Chart 是存儲在 Git 代碼倉庫中的，所以我們通過 sourceRef 字段來指定 GitRepository 對象，interval 字段指定了從 Git 存儲庫提取數(shù)據(jù)的頻率，values 字段指定了 Chart 的 values 值。

其中的 valuesFiles 字段是一個備選的值文件列表，用作 Chart 的 Values 值（默認(rèn)情況下不包括 values.yaml），是相對于 SourceRef 的路徑，Values 文件按照此列表的順序合并，最后一個文件將覆蓋第一個文件。

同樣直接應(yīng)用該資源對象即可：

$ kubectl apply -f k8s-demo-helm-release.yaml
helmrelease.helm.toolkit.fluxcd.io/k8s-demo created
$ kubectl get helmrelease
NAME       AGE     READY   STATUS
k8s-demo   5m56s   True    Release reconciliation succeeded

我們可以看到已經(jīng)成功部署了應(yīng)用，如果出現(xiàn)了任何問題，可以通過 kubectl describe helmrelease k8s-demo 命令來查看 HelmRelease 的各種狀態(tài)：

$ kubectl describe helmrelease k8s-demo
Name:         k8s-demo
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  helm.toolkit.fluxcd.io/v2beta1
Kind:         HelmRelease
Metadata:
  Creation Timestamp:  2023-09-23T09:53:49Z
  Finalizers:
    finalizers.fluxcd.io
  Generation:        2
  Resource Version:  491438
  UID:               7dc72409-57ee-4e4a-8950-ea5d09e43bc1
Spec:
  Chart:
    Spec:
      Chart:               helm
      Interval:            30s
      Reconcile Strategy:  ChartVersion
      Source Ref:
        Kind:       GitRepository
        Name:       k8s-demo
        Namespace:  default
      Values Files:
        helm/values.yaml
        helm/my-values.yaml
      Version:  *
  Interval:     30s
  Values:
    Replica Count:  2
Status:
  Conditions:
    Last Transition Time:          2023-09-23T09:59:44Z
    Message:                       Release reconciliation succeeded
    Reason:                        ReconciliationSucceeded
    Status:                        True
    Type:                          Ready
    Last Transition Time:          2023-09-23T09:59:44Z
    Message:                       Helm install succeeded
    Reason:                        InstallSucceeded
    Status:                        True
    Type:                          Released
  Helm Chart:                      default/default-k8s-demo
  Last Applied Revision:           0.1.0+2
  Last Attempted Revision:         0.1.0+2
  Last Attempted Values Checksum:  1dd4966b30314fd329b48c5892b6a85412fd0236
  Last Release Revision:           1
  Observed Generation:             2
Events:
  Type    Reason  Age                   From             Message
  ----    ------  ----                  ----             -------
  Normal  info    41s (x13 over 6m31s)  helm-controller  HelmChart 'default/default-k8s-demo' is not ready
  Normal  info    41s                   helm-controller  Helm install has started
  Normal  info    36s                   helm-controller  Helm install succeeded

事實(shí)上我們雖然是在 HelmRelease 中去為 chart 源關(guān)聯(lián)的 GitRepository 對象，但是實(shí)際上 HelmRelease 會自動創(chuàng)建一個 HelmChart 對象，該對象可以定義一個包含 Chart 的源，以便 HelmRelease 能夠引用它，如下所示：

$ kubectl get helmchart default-k8s-demo
NAME               CHART   VERSION   SOURCE KIND     SOURCE NAME   AGE     READY   STATUS
default-k8s-demo   helm    *         GitRepository   k8s-demo      7m35s   True    packaged 'devops-demo' chart with version '0.1.0+2' and merged values files [helm/values.yaml helm/my-values.yaml]
$ kubectl get helmchart default-k8s-demo -o yaml
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmChart
metadata:
  name: default-k8s-demo
  namespace: default
spec:
  chart: helm
  interval: 30s
  reconcileStrategy: ChartVersion
  sourceRef:
    kind: GitRepository
    name: k8s-demo
  valuesFiles:
  - helm/values.yaml
  - helm/my-values.yaml
  version: '*'
# ......

最后我們也可以通過 helm 命令來驗(yàn)證我們的應(yīng)用是否已經(jīng)部署成功：

$ helm ls
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                 APP VERSION
k8s-demo        default         1               2023-09-23 09:59:39.906949292 +0000 UTC deployed        devops-demo-0.1.0+2   1.0

這樣接下來我們只需要在 CI 流水線中去將鏡像構(gòu)建完成后，將鏡像推送到鏡像倉庫，然后更新 Git 代碼倉庫中的 Values 文件的鏡像版本即可，F(xiàn)lux 會自動檢測到 Chart 版本的變化，然后自動更新應(yīng)用。

但是這樣的話，我們每次都需要在 CI 流水線去手動更新 Git 代碼倉庫中的 Values 文件的鏡像版本，這樣就會比較麻煩，和 Argo CD 類似，F(xiàn)lux 也提供了一個 Image Automation 控制器的功能。

責(zé)任編輯：姜華來源： k8s技術(shù)圈