使用 FluxCD 實現(xiàn) Kubernetes GitOps
Flux 是一套針對 Kubernetes 的持續(xù)交付和漸進式交付的解決方案，可以讓我們以 GitOps 的方式輕松地交付應用。和另一個同類的 CNCF 孵化項目 Argo CD 不同，F(xiàn)lux CD 是許多工具集的集合，天然松耦合并且有良好的擴展性，用戶可按需取用。最新版本的 Flux 引入了許多新功能，使其更加靈活多樣。Flux 已經(jīng)是 CNCF 畢業(yè)項目。
組件
Flux 是使用 GitOps Toolkit 組件構建的，它是一組：
- 專用工具和 Flux 控制器。
- 可組合的 API。
- 在 fluxcd GitHub 組織下，為構建基于 Kubernetes 的持續(xù)交付提供可重用的 Go 依賴包。
用于在 Kubernetes 之上構建持續(xù)交付。
GitOps Toolkit
這些 API 包括 Kubernetes 自定義資源，可以由集群用戶或其他自動化工具進行創(chuàng)建和更新。我們可以使用這個工具包擴展 Flux，并構建自己的持續(xù)交付系統(tǒng)。
Flux 的核心工具包包括以下 5 個：
- Source Controller
- Kustomize Controller
- Helm Controller
- Notification Controller
- Image automation controllers
每個工具包都是一個控制器，都有自己的自定義資源定義 (CRD)，用于定義其行為。
安裝
Flux 項目由命令行工具（FLux CLI）和一系列 Kubernetes 控制器組成。要安裝 Flux，首先需要下載 Flux CLI，然后使用 CLI，可以在集群上部署 Flux 控制器并配置 GitOps 交付流水線。
Flux CLI 是一個二進制可執(zhí)行文件，可以從 GitHub 發(fā)布頁面下載直接下載即可。
對于 Mac 用戶可以直接使用 homebrew 進行一鍵安裝：
$ brew install fluxcd/tap/flux如果是 Linux 用戶也可以使用下面的命令進行安裝：
$ curl -s https://fluxcd.io/install.sh | sudo bash安裝完成后，可以使用 flux 命令來驗證是否安裝成功：
$ flux --version
flux version 2.1.1接下來我們就可以使用 Flux CLI 來安裝 Flux 控制器了。
Flux CLI 提供了一個 bootstrap 命令在 Kubernetes 集群上部署 Flux 控制器，并配置控制器以從 Git 存儲庫同步集群狀態(tài)。除了安裝控制器之外，bootstrap 命令還將 Flux 清單推送到 Git 存儲庫，并將 Flux 配置為從 Git 進行自我更新。
flux
如果集群上存在 Flux 控制器，則 bootstrap 命令將在需要時執(zhí)行升級。Bootstrap 是冪等的，可以安全地運行該命令任意多次。
Flux 與主流的 Git 提供商進行集成，以簡化部署密鑰和其他身份驗證機制的初始設置。比如我們這里選擇和 GitLab 進行集成。那么我們可以使用 bootstrap gitlab 命令在 Kubernetes 集群上部署 Flux 控制器，并配置控制器從 GitLab 項目同步集群狀態(tài)。除了安裝控制器之外，bootstrap 命令還將 Flux 清單推送到 GitLab 項目，并將 Flux 配置為從 Git 進行自我更新。運行 bootstrap 命令后，對集群的任何操作都可以通過 Git 推送完成，無需連接到 Kubernetes 集群。
要啟動 Flux，運行命令的人員必須擁有目標 Kubernetes 集群的集群管理員權限，還要求運行該命令的人是 GitLab 項目的所有者，或者具有 GitLab 組的管理員權限。
為了訪問 GitLab API，boostrap 命令需要具有對 GitLab API 的完整讀/寫訪問權限的 GitLab 個人訪問令牌 (PAT)。GitLab PAT 可以導出為環(huán)境變量：
export GITLAB_TOKEN=<gh-token>如果未設置 GITLAB_TOKEN 環(huán)境變量，boostrap 命令將提示你輸入 token，當然可以使用管道提供，例如：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)建公共項目，需要設置 --private=false 參數(shù)。使用 --deploy-token-auth 時，CLI 會生成一個 GitLab 項目部署令牌，并將其作為 Kubernetes Secret 存儲在集群中 flux-system 命名空間內(nèi)。
對多環(huán)境集群的支持并沒有采用多倉庫/多分支的策略，而是用的使用不同路徑來管理不同的集群，這也是 Flux 推薦的策略，可以減少代碼維護和合并的難度。
上面的命令執(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這是因為我們這里安裝的 GitLab 使用的是 http 的方式，而且該命令下面并沒有跳過對 https 證書校驗的參數(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 # 運行不安全的 http 方式上面的命令會在 flux-system 命名空間中部署一系列 Kubernetes 控制器及其 CRD、RBAC 和網(wǎng)絡策略，默認的組件包括：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é)中的示例來進行說明，如何通過 Flux 來實現(xiàn) GitOps 的持續(xù)交付。
示例中要用到的 Git 資源清單倉庫為 http://gitlab.k8s.local/cnych/k8s-demo-config，該項目中包含一個 helm 目錄，目錄下面就是一個 helm chart 包：
demo config
當然在繼續(xù)之前，為避免產(chǎn)生影響，我們可以將前面通過 Argo CD 部署的應用刪除掉。
接下來我們就可以通過 Flux 來部署應用了，首先需要為 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 身份驗證憑據(jù)的 Secret。
對于 HTTPS 倉庫，Secret 必須包含基本認證的 username 和 password 字段，或者令牌認證的 bearerToken 字段。對于 SSH 倉庫，Secret 必須包含 identity 和 known_hosts 字段。
直接應用該資源對象即可：
$ 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 字段可以查看到當前的 Git 版本，新的制品在 .status.artifact 字段中可以查看到。
接下來我們只需要為該應用創(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 的源，因為我們這里的 Helm Chart 是存儲在 Git 代碼倉庫中的，所以我們通過 sourceRef 字段來指定 GitRepository 對象，interval 字段指定了從 Git 存儲庫提取數(shù)據(jù)的頻率，values 字段指定了 Chart 的 values 值。
其中的 valuesFiles 字段是一個備選的值文件列表，用作 Chart 的 Values 值（默認情況下不包括 values.yaml），是相對于 SourceRef 的路徑，Values 文件按照此列表的順序合并，最后一個文件將覆蓋第一個文件。
同樣直接應用該資源對象即可：
$ 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)成功部署了應用，如果出現(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事實上我們雖然是在 HelmRelease 中去為 chart 源關聯(lián)的 GitRepository 對象，但是實際上 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 命令來驗證我們的應用是否已經(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 流水線中去將鏡像構建完成后，將鏡像推送到鏡像倉庫，然后更新 Git 代碼倉庫中的 Values 文件的鏡像版本即可，F(xiàn)lux 會自動檢測到 Chart 版本的變化，然后自動更新應用。
但是這樣的話，我們每次都需要在 CI 流水線去手動更新 Git 代碼倉庫中的 Values 文件的鏡像版本，這樣就會比較麻煩，和 Argo CD 類似，F(xiàn)lux 也提供了一個 Image Automation 控制器的功能。
