FluxCD を使用した Kubernetes GitOps の実装

Flux は、Kubernetes 向けの継続的デリバリーおよびプログレッシブデリバリーのソリューションであり、GitOps 方式でアプリケーションを簡単に配信できます。同様の CNCF インキュベーション プロジェクトである Argo CD とは異なり、Flux CD は多くのツール セットのコレクションであり、自然に疎結合でスケーラビリティに優れており、ユーザーは必要に応じて使用できます。 Flux の最新バージョンでは、柔軟性と汎用性を高める多くの新機能が導入されています。 Flux はすでに CNCF 卒業プロジェクトです。

コンポーネント

Flux は、次のセットである GitOps Toolkit コンポーネントを使用して構築されます。

• 専用ツールと Flux コントローラー。
• 構成可能な API。
• fluxcd GitHub 組織では、Kubernetes に基づく継続的デリバリーを構築するための再利用可能な Go 依存パッケージが提供されています。

Kubernetes 上で継続的デリバリーを構築します。

GitOps ツールキット

これらの API には、クラスター ユーザーまたはその他の自動化ツールによって作成および更新できる Kubernetes カスタム リソースが含まれます。このツールキットを使用して Flux を拡張し、独自の継続的デリバリー システムを構築できます。

Flux のコア ツールキットには、次の 5 つが含まれます。

• ソースコントローラ
• Kustomize コントローラー
• ヘルムコントローラー
• 通知コントローラ
• 画像自動化コントローラ

各ツールキットはコントローラーであり、その動作を定義する独自のカスタム リソース定義 (CRD) を持ちます。

インストール

Flux プロジェクトは、コマンドライン ツール (FLux CLI) と一連の Kubernetes コントローラーで構成されています。 Flux をインストールするには、まず Flux CLI をダウンロードする必要があります。次に、CLI を使用して、クラスターに Flux コントローラーをデプロイし、GitOps 配信パイプラインを構成できます。

Flux CLI は、GitHub リリース ページから直接ダウンロードできるバイナリ実行可能ファイルです。

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 は、Kubernetes クラスターに Flux コントローラーをデプロイし、コントローラーが Git リポジトリからクラスターの状態を同期するように構成するためのブートストラップ コマンドを提供します。コントローラーのインストールに加えて、bootstrap コマンドは Flux マニフェストを Git リポジトリにプッシュし、Git から Flux 自体を更新するように構成します。

フラックスは巨大です。

クラスターに Flux コントローラーが存在する場合、ブートストラップ コマンドは必要に応じてアップグレードを実行します。 Bootstrap はべき等性があり、コマンドを何度でも安全に実行できます。

Flux は一般的な Git プロバイダーと統合され、デプロイ キーやその他の認証メカニズムの初期設定を簡素化します。たとえば、ここでは GitLab との統合を選択します。次に、bootstrap gitlab コマンドを使用して、Kubernetes クラスターに Flux コントローラーをデプロイし、コントローラーが GitLab プロジェクトからクラスターのステータスを同期するように構成します。コントローラーのインストールに加えて、bootstrap コマンドは Flux マニフェストを GitLab プロジェクトにプッシュし、Git から Flux 自体を更新するように構成します。ブートストラップ コマンドを実行した後は、Kubernetes クラスターに接続しなくても、Git プッシュを通じてクラスター上のあらゆる操作を実行できます。

Flux を起動するには、コマンドを実行するユーザーが、対象の Kubernetes クラスターに対するクラスター管理者権限を持っている必要があります。また、コマンドを実行するユーザーは GitLab プロジェクトの所有者であるか、GitLab グループの管理者権限を持っている必要があります。

GitLab API にアクセスするには、boostrap コマンドに、GitLab API への完全な読み取り/書き込みアクセス権を持つ GitLab 個人アクセス トークン (PAT) が必要です。 GitLab PAT は環境変数としてエクスポートできます。

 export GITLAB_TOKEN=<gh-token>

GITLAB_TOKEN 環境変数が設定されていない場合、boostrap コマンドはトークンの入力を要求します。トークンはパイプを使用して指定できます。例: echo "<gl-token>" |フラックスブートストラップgitlab。

たとえば、GitLab の Personal Access Token ページにアクセスして PAT を作成できます。

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

指定されたプロジェクトが存在しない場合は、Flux によってプライベート プロジェクトが作成されます。パブリック プロジェクトを作成する場合は、--private=false パラメータを設定する必要があります。 --deploy-token-auth を使用すると、CLI は GitLab プロジェクトのデプロイ トークンを生成し、それをクラスターの flux-system 名前空間に Kubernetes Secret として保存します。

マルチ環境クラスターのサポートでは、マルチリポジトリ/マルチブランチ戦略は採用されませんが、異なるパスを使用して異なるクラスターを管理します。これは Flux が推奨する戦略でもあり、コードのメンテナンスとマージの難しさを軽減できます。

上記のコマンドを実行すると、次のエラー メッセージが表示されます。

 ► 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 証明書を検証するためのパラメータをスキップしないため、一般的な 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 方式

上記のコマンドは、一連の Kubernetes コントローラーとその CRD、RBAC、およびネットワーク ポリシーを flux-system 名前空間にデプロイします。デフォルトのコンポーネントには、source-controller、kustomize-controller、helm-controller、notification-controller が含まれます。 --components パラメータを使用してインストールするコンポーネントを指定できますが、最小インストールでは source-controller と kustomize-controller の 2 つのコンポーネントが必要であることに注意してください。

上記のコマンドを実行すると、通常、次の出力情報が表示されます。

 ► 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 コントローラーは、 flux-system 名前空間で表示できます。

 $ 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 によって clusters/my-cluster/flux-system ディレクトリが作成されており、その中に Flux 構成ファイルがいくつか含まれていることがわかります。

フラックスgit

これで Flux のインストールが完了しました。

例

ここでは、前の Jenkins パイプラインの章の例を引き続き使用して、Flux を通じて GitOps 継続的デリバリーを実装する方法を説明します。

例で使用される Git リソース リスト リポジトリは http://gitlab.k8s.local/cnych/k8s-demo-config です。プロジェクトには helm ディレクトリが含まれており、そのディレクトリの下に helm チャート パッケージがあります。

デモ設定

もちろん、続行する前に、影響を避けるために、以前に Argo CD を通じてデプロイされたアプリケーションを削除することもできます。

次に、Flux を通じてアプリケーションをデプロイできます。まず、FluxCDのウェアハウス接続情報を作成する必要があります。これには、リポジトリ接続が必要です。   GitRepository  以下に示すように、Git リポジトリのバージョンの成果物を生成するためのソース コード ソースを定義できる CRD オブジェクト。

 # 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

ここでは、k8s-demo という名前の GitRepository オブジェクトを作成します。spec フィールドは Git リポジトリからデータを抽出する方法を定義し、url フィールドは Git リポジトリの URL を指定し、ref フィールドは抽出するコード ブランチを指定し、interval フィールドは Git リポジトリからデータを抽出する頻度を指定し、secretRef フィールドは GitRepository 認証資格情報を含む Secret を指定します。

HTTPS リポジトリの場合、Secret には基本認証用のユーザー名とパスワードのフィールド、またはトークン認証用の 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'

作成後、kubectl describe gitrepository k8s-demo コマンドを使用して GitRepository のさまざまな状態を表示できます。

 $ 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'

現在の Git バージョンは .status.artifact.revision フィールドで表示でき、新しいアーティファクトは .status.artifact フィールドで表示できます。

次に、アプリケーションのデプロイメント戦略を作成する必要があります。ここでは Helm Chart を公開するため、HelmRelease オブジェクトを作成する必要があります。このオブジェクトは、Chart を含むソース (HelmRepository、GitRepository、または Bucket) を定義して、ソース コントローラーに通知し、HelmRelease がそれを参照できるようにします。明らかに、ここでのソースは上記で定義した GitRepository オブジェクトです。

ここで作成する 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 リポジトリからデータを抽出する頻度を指定し、values フィールドで Chart の値を指定します。

valuesFiles フィールドは、チャートの値として使用される代替値ファイルのリストです (デフォルトでは values.yaml は除きます)。これは SourceRef に対する相対パスです。値ファイルはこのリストの順序でマージされ、最後のファイルが最初のファイルを上書きします。

リソース オブジェクトを直接適用することもできます。

 $ 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

アプリケーションが正常にデプロイされたことがわかります。何か問題があれば、   kubectl describe helmrelease k8s-demo   HelmRelease のさまざまなステータスを表示するコマンド:

 $ 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 では GitRepository オブジェクトをチャート ソースに関連付けていますが、実際には HelmRelease によって HelmChart オブジェクトが自動的に作成され、チャートを含むソースを定義できるため、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 コマンドを使用して、アプリケーションが正常にデプロイされたかどうかを確認することもできます。

 $ 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 ファイルのイメージ バージョンを更新するだけで済みます。 Flux は Chart バージョンの変更を自動的に検出し、アプリケーションを自動的に更新します。

しかし、この場合、CI パイプライン内の Git コード リポジトリ内の Values ファイルのイメージ バージョンを毎回手動で更新する必要があり、面倒です。 Argo CD と同様に、Flux もイメージ自動化コントローラー機能を提供します。