KubernetesクラスターでGitOpsを使用する

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

GitLab 15.3でGitLab PremiumからGitLab Freeに移行しました。
GitLab 15.7でid属性をオプションにするように変更されました。
Kubernetesのマニフェストファイルをフェッチするためのブランチ、タグ、またはコミット参照の指定は、GitLab 15.7で導入されました。
GitOpsのためにFluxを優先するようにGitLab 16.1で変更されました。

GitLabはGitOps用にFluxを統合します。Fluxの使用を開始するには、Flux for GitOpsチュートリアルを参照してください。

GitOpsを使用すると、次のGitリポジトリから、コンテナ化されたクラスターとアプリケーションを管理できます。

システムの信頼できる唯一の情報源です。
システムを操作する唯一の場所です。

GitLab、Kubernetes、およびGitOpsを組み合わせることで、以下を実現できます。

GitOpsオペレーターとしてのGitLab。
自動化およびコンバージェンスシステムとしてのKubernetes。
継続的デプロイのためのGitLab CI/CD。
継続的デプロイとクラスターの可観測性のためのエージェント。
組み込みの自動構成ドリフト修復。
透過的なマルチアクターフィールドトークン管理のためのサーバーサイド適用によるリソース管理。

デプロイシーケンス

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

%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
accTitle: Deployment sequence
accDescr: Shows the repositories and main actors in a GitOps deployment.

  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

GitOpsデプロイには、Fluxとagentkの両方を使用する必要があります。Fluxはクラスターの状態をソースと同期させ、agentkはFluxのセットアップを簡素化し、クラスターからGitLabへのアクセス管理を提供し、GitLab UIでクラスターの状態を視覚化します。

ソース管理のためのOCI

Gitリポジトリの代わりに、OCIイメージをFluxのソースコントローラーとして使用する必要があります。GitLabコンテナレジストリはOCIイメージをサポートしています。

OCIレジストリ	Gitリポジトリ
コンテナイメージをスケールでサポートするように設計されています。	ソース管理をバージョン管理して保存するように設計されています。
イミュータブルで、セキュリティスキャンをサポートします。	変更可能。
デフォルトのGitブランチは、同期をトリガーせずにクラスターの状態を保存できます。	デフォルトのGitブランチは、クラスターの状態を保存するために使用されると、同期をトリガーします。

リポジトリ構造

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

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

即時Gitリポジトリ調整

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

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

即時Gitリポジトリ調整を使用するには、次のものを実行するKubernetesクラスターが必要です。

Kubernetes用エージェント
Flux source-controllerおよびnotification-controller。

即時Gitリポジトリ調整は、プッシュと調整の間の時間を短縮できますが、すべてのgit pushイベントが受信されることを保証するものではありません。許容できる期間にGitRepository.spec.intervalを設定する必要があります。

エージェントは、エージェント設定プロジェクトとすべてのパブリックプロジェクトにのみアクセスできます。エージェントは、エージェント設定プロジェクトを除き、プライベートプロジェクトをすぐに調整することはできません。エージェントがプライベートプロジェクトにアクセスできるようにすることは、イシュー389393で提案されています。

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

Kubernetes用エージェントがReceiver Webhookを呼び出すと、エージェントはhttp://webhook-receiver.flux-system.svc.cluster.localにデフォルト設定されます。これは、Fluxブートストラップインストールによって設定されたデフォルトのURLでもあります。カスタムエンドポイントを設定するには、エージェントが解決できるURLにflux.webhook_receiver_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を設定していない場合は、これを使用できます。

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

トークン管理

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

このセクションでは、必要なトークンのガイドラインを提供し、可能な場合はトークンタイプの推奨事項を提供します。

FluxによるGitLabアクセス

GitLabコンテナレジストリまたはGitリポジトリにアクセスするために、Fluxは以下を使用できます。

プロジェクトアクセストークンまたはグループデプロイトークン。
プロジェクトアクセストークンまたはグループデプロイトークン。
プロジェクトまたはグループのグループアクセストークン。
パーソナルアクセストークン。

トークンは書き込みアクセスを必要としません。

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

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

GitLab通知へのFlux

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

Fluxから外部ジョブ状態を取得するには、以下を使用できます。

プロジェクトアクセストークンまたはグループデプロイトークン。
プロジェクトまたはグループのグループアクセストークン。
パーソナルアクセストークン。

トークンにはapiスコープが必要です。漏洩したトークンのアタックサーフェスを最小限に抑えるには、プロジェクトアクセストークンを使用する必要があります。

ジョブとしてのFluxのGitLabパイプラインへの統合は、イシュー405007で提案されています。

トレーニングとデモのためのGitOpsの動作例
自己ペースの教室ワークショップ（AWS EKSを使用していますが、他のKubernetesクラスターにも使用できます）
GitOpsワークフローでのKubernetesシークレットの管理
- SOPSを使用してFluxに組み込み
- Sealed Secretsを使用