KubernetesクラスターでのGitOpsの利用

  • GitLab 13.7 で導入されました。
  • GitLab 14.0 で導入され、resource_inclusions とresource_exclusions 属性が削除され、reconcile_timeout,dry_run_strategy,prune,prune_timeout,prune_propagation_policy,inventory_policy 属性が追加されました。
  • 15.3でGitLab PremiumからGitLab Freeに移動しました。
  • GitLab 15.7 でid 属性をオプションに変更しました。
  • GitLab 15.7で導入されたKubernetesマニフェストファイルをフェッチするためにブランチ、タグ、またはコミットリファレンスを指定。
  • GitLab 16.1でGitOpsのFluxを優先するように変更。

GitLabはFluxfor GitOpsをインテグレーションしています。Fluxを使い始めるには、Flux for GitOpsチュートリアルをご覧ください。

GitOpsを使えば、コンテナ化されたクラスターやアプリケーションをGitリポジトリから管理することができます：

  • システムの単一の真実のソースです。
  • システムをオペレーションする 唯一の場所です

GitLab、Kubernetes、GitOpsを組み合わせることで

  • GitLabをGitOpsのオペレーションに。
  • 自動化と収束システムとしてのKubernetes。
  • GitLab CI/CD 継続的インテグレーション。
  • 継続的デプロイとクラスター観測のためのエージェントです。
  • 自動ドリフト修正機能
  • サーバーサイドによるリソース管理は、透過的なマルチアクターフィールド管理に適用されます。

デプロイ順序

この図は、GitOpsのデプロイにおけるリポジトリと主なアクターを示しています：

sequenceDiagram participant D as Developer participant A as Application code repository participant M as Deployment repository participant R as OCI registry participant C as Agent configuration repository participant K as GitLab agent participant F as Flux loop Regularly K-->>C: Grab the configuration end D->>+A: Pushing code changes A->>M: Updating manifest M->>R: Build an OCI artifact M->>K: Notify K->>F: Notify and watch sync R-->>F: Pulling and applying changes K->>M: Notify after sync

Fluxとagentk GitOpsデ agentkプロイの両方を使うべきです。agentk Fluxはクラスタの状態をソースと同期させたまま、 agentkFluxのセットアップを簡素化し、クラスタからGitLabへのアクセス管理を提供し、GitLab UIでクラスタの状態を可視化します。

ソース管理のためのOCI

Fluxのソースコントローラーとして、GitリポジトリではなくOCIイメージを使うべきです。GitLabコンテナレジストリはOCIイメージをサポートしています。

OCI レジストリGitリポジトリ
コンテナイメージを大規模に提供するように設計されています。ソースコードのバージョン管理と保存
不変で、セキュリティスキャンをサポートします。不変。
デフォルトの Git ブランチは、同期をトリガーせずにクラスターの状態を保存することができます。デフォルトの Git ブランチは、クラスターの状態を保存するときに同期をトリガーします。

リポジトリ構造

設定を簡素化するため、チームごとに 1 つの配信リポジトリを使用します。アプリケーションごとに、配信リポジトリを複数の OCI イメージにパッケージ化できます。

その他の推奨リポジトリ構造については、Fluxのドキュメントを参照してください。

Git リポジトリの即時照合

通常、Fluxソースコントローラーは設定された間隔でGitリポジトリの照合を行います。このため、git push 、クラスターの状態を照合するまでに遅延が発生し、GitLabから不必要なプルが発生する可能性があります。

Kubernetes 用エージェントは、エージェントが接続しているインスタンスで GitLab プロジェクトを参照する FluxGitRepository オブジェクトを自動的に検出し、インスタンス用にReceiver を設定します。Kubernetes 用エージェントがgit pushを検出すると、Receiver がトリガーされ、Flux はクラスターとリポジトリへの変更を照合します。

Gitリポジトリの即時リコンシリエーションを使用するには、Kubernetesクラスターが稼働している必要があります：

  • Kubernetes用のエージェント。
  • Fluxsource-controller とnotification-controller 。

Git リポジトリの即時リコンシリエーションは、プッシュからリコンシリエーションまでの時間を短縮できますが、すべてのgit push イベントを受け取ることを保証するものではありません。それでも、GitRepository.spec.interval を許容できる時間に設定する必要があります。

カスタム Webhook エンドポイント

Kubernetes 用エージェントがReceiver Webhook を呼び出すとき、エージェントのデフォルトはhttp://webhook-receiver.flux-system.svc.cluster.local で、これは Flux ブートストラップのインストールによって設定されるデフォルトの URL でもあります。カスタムエンドポイントを設定するには、flux.webhook_receiver_url をエージェントが解決できるURLに設定します。例えば

flux:
  webhook_receiver_url: http://webhook-receiver.another-flux-namespace.svc.cluster.local

このフォーマットで設定されたサービス・プロキシURLには、特別なハンドリングがあります:/api/v1/namespaces/[^/]+/services/[^/]+/proxy 。例えば

flux:
  webhook_receiver_url: /api/v1/namespaces/flux-system/services/http:webhook-receiver:80/proxy

このような場合、Kubernetes用エージェントは利用可能なKubernetes設定とコンテキストを使用してAPIエンドポイントに接続します。エージェントをクラスター内部で実行し、Flux通知コントローラのIngress を設定していない場合に使用できます。

caution
信頼できるサービスプロキシURLのみを設定する必要があります。サービスプロキシURLを提供すると、Kubernetes用エージェントは、APIサービスとの認証に必要な認証情報を含む典型的なKubernetes APIリクエストを送信します。

トークンの管理

Fluxの特定の機能を利用するには、複数のアクセストークンが必要になる場合があります。さらに、同じ結果を得るために複数のトークンタイプを使うこともできます。

このセクションでは、必要となる可能性のあるトークンのガイドラインと、可能な限り推奨されるトークンの種類を示します。

FluxによるGitLabアクセス

コンテナレジストリやGitリポジトリであるGitLabにアクセスするには、Fluxを使います：

  • プロジェクトやグループのデプロイトークン。
  • プロジェクトまたはグループのデプロイキー。
  • プロジェクトまたはグループのアクセストークン。
  • 個人アクセストークン。

トークンに書き込みアクセス権は必要ありません。

http アクセスが可能な場合は、プロジェクトデプロイトークンを使用する必要があります。git+ssh アクセスが必要な場合は、デプロイキーを使用する必要があります。デプロイキーとデプロイトークンの比較については、デプロイキーを参照してください。

デプロイトークンの作成、ローテーション、レポートの自動化のサポートは、イシュー389393で提案されています。

Flux から GitLab への通知

Gitソースから同期するようにFluxを設定すると、FluxはGitLabパイプラインに外部ジョブのステータスを登録することができます。

Fluxから外部のジョブステータスを取得するには、次のようにします：

  • プロジェクトやグループのデプロイトークン。
  • プロジェクトまたはグループのアクセストークン。
  • 個人アクセストークン。

トークンにはapi スコープが必要です。漏洩したトークンの攻撃範囲を最小にするために、プロジェクトアクセストークンを使うべきです。

GitLab パイプラインに Flux をジョブとしてインテグレーションすることは、イシュー405007 で提案されています。