信頼できる情報源について

このドキュメントでは、Config Sync が同期できるさまざまな種類の信頼できる情報源について説明します。

GitOps ワークフローの重要なコンセプトは、構成ファイルが保存される中央リポジトリである信頼できる情報源です。構成ファイルは通常、Kubernetes リソースを定義する YAML ファイルまたは JSON ファイルです。通常、kubectl コマンドライン ツールを使用して Kubernetes オブジェクトを手動で適用しますが、Config Sync では、Git リポジトリなどの単一の信頼できる情報源からこれらのリソースを自動的に適用できます。その後、Config Sync は指定された信頼できる情報源をモニタリングし、クラスタに変更を自動的に適用します。

Config Sync は、Git リポジトリ、Open Container Initiative（OCI）イメージ、Helm チャートの 3 種類のソースから構成ファイルを同期できます。このドキュメントでは、これらの各ソースタイプと、Config Sync がそれらとどのように連携するかについて説明します。このドキュメントを読むと、ワークフローと環境に最適なソース オプションを選択するのに役立ちます。

Git リポジトリ

Git は、バージョン管理とコラボレーションに広く採用されているテクノロジーです。Git を使用すると、ニーズに合わせてリポジトリを整理し、必要に応じてバージョン管理とブランチのメリットを得ることができます。Git は成熟した広く採用されているテクノロジーであるため、プロバイダとツールにはさまざまなオプションがあります。

Git リポジトリを信頼できる情報源として Config Sync を構成すると、Config Sync は reconciler Pod 内の git-sync コンテナを使用して Git リポジトリから構成を pull します。リポジトリ URL、ブランチ、リビジョン（commit またはタグ）を構成して、Git リポジトリ内の構成をプルする場所をより詳細に制御できます。

RootSync 構成の例

次の例は、Git リポジトリから同期する RootSync マニフェストを示しています。

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/example/my-configs.git
    revision: main
    dir: cluster-configs
    auth: none # replace with your authentication method such as ssh or token
    period: 60s

この構成では、Git リポジトリからマニフェストを同期するように Config Sync を設定します。Config Sync は、https://github.com/example/my-configs.git リポジトリの main ブランチにある cluster-configs ディレクトリを監視し、認証なしで 60 秒ごとに更新を確認します。

ユースケースの例: 一元管理

たとえば、プラットフォーム管理者が Git リポジトリを使用して、フリート内のすべてのクラスタにベースライン ポリシーを適用するとします。このシナリオでは、標準の NetworkPolicies、RoleBindings、ResourceQuotas を standard-configs という名前の中央 Git リポジトリに保存します。新しいクラスタがプロビジョニングされると、Config Sync は standard-configs リポジトリから同期するように構成され、すべてのクラスタが最初から組織の標準を満たすようにします。

OCI イメージ

OCI イメージは、アプリケーションとその依存関係をパッケージ化するための標準形式です。このアプローチでは、コンテナ イメージと同様に、構成をアーティファクトとして扱います。このアプローチには、不変性や大規模なパフォーマンスの高速化などのメリットがあります。OCI を使用すると、Artifact Registry などのコンテナ イメージ インフラストラクチャとツールを使用してイメージを管理し、Workload Identity Federation for GKE を使用して認証を簡素化できます。

通常、OCI を構成ソースとして使用するには、構成ファイルを OCI イメージにビルドしてから、Artifact Registry などのレジストリ プラットフォームに push するための個別のプロセスが必要です。この方法は、Git リポジトリのファイルとして保存された構成よりも、人間が直接読み取りにくい場合があります。

信頼できる情報源として OCI イメージを使用して Config Sync を構成すると、Config Sync は Reconciler Pod 内の oci-sync コンテナを使用して、構成を含む OCI イメージをレジストリから pull します。

RootSync 構成の例

次の例は、Artifact Registry に保存されている OCI イメージから同期する RootSync マニフェストを示しています。

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0
    dir: .
    auth: k8sserviceaccount

この構成では、OCI イメージから同期するように Config Sync を設定します。Config Sync は、認証に Kubernetes サービス アカウントを使用して、Artifact Registry から us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 イメージを pull します。

ユースケースの例: CI/CD パイプラインの統合

OCI イメージの作成を組織の CI/CD パイプラインに統合するとします。構成ファイルへの変更がマージされたら、検証テスト（nomos vet コマンドなど）を実行し、YAML ファイルを OCI イメージにビルドして、Artifact Registry にイメージを push するようにパイプラインを設定できます。Config Sync は、新しいバージョンのイメージを自動的に検出してクラスタに適用し、すべての構成変更の検証済みバージョン管理されたロールアウトを保証します。

Helm チャート

Helm は Kubernetes でよく使用されるパッケージ マネージャーで、Chart と呼ばれるパッケージ形式を使用します。Config Sync は、Helm チャートで定義されたリソースの取得、レンダリング、同期を行うことができます。

Helm は、Kubernetes アプリケーションをパッケージ化して再利用する一貫した方法を提供します。テンプレートまたは事前構築済みの Helm チャートを使用して、一貫性のある再利用可能な構成を作成できます。

Helm に慣れていない場合、テンプレートとリリース プロセスによって構成管理パイプラインが複雑になる可能性があります。

信頼できる情報源として Helm チャートを使用して Config Sync を構成すると、Config Sync は Reconciler Pod 内の helm-sync コンテナを使用して、Helm リポジトリ（Artifact Registry など）または Git リポジトリからチャートを pull し、チャートをレンダリングして Kubernetes マニフェストを生成します。または、Kustomize で Config Sync を使用して Helm チャートをレンダリングすることもできます。このアプローチの詳細については、Kustomize と Helm で Config Sync を使用するをご覧ください。

RootSync 構成の例

次の例は、Artifact Registry に保存されている Helm チャートから同期する RootSync マニフェストを示しています。

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: helm
  helm:
    repo: oci://us-central1-docker.pkg.dev/my-project/my-helm-repo
    chart: my-chart
    version: 1.2.0
    auth: gcpserviceaccount
    gcpServiceAccountEmail: my-service-account@my-project.iam.gserviceaccount.com
    releaseName: my-chart-release
    namespace: my-app-namespace # Namespace where the chart resources will be deployed

この構成では、OCI リポジトリから Helm チャートを同期するように Config Sync を設定します。Config Sync は、oci://us-central1-docker.pkg.dev/my-project/my-helm-repo リポジトリから my-chart チャートのバージョン 1.2.0 を取得し、my-service-account@my-project.iam.gserviceaccount.com サービス アカウントで認証します。チャートのリソースを、リリース名 my-chart-release の my-app-namespace Namespace にデプロイします。

ユースケースの例: サードパーティ アプリケーションのデプロイ

Prometheus をクラスタにデプロイするアプリケーション チームの一員であるとします。Prometheus をデプロイするビルド済みの Helm チャートから pull するように Config Sync を構成できます。Helm コマンドを手動で実行する代わりに、Config Sync の RootSync オブジェクトまたは RepoSync オブジェクト内で、チャートのソース、バージョン、カスタム values を定義します。Config Sync は、指定されたグラフ バージョンと構成でデプロイの同期を維持します。

ソースタイプの選択

最適なソースタイプは、チームの既存のツール、ワークフロー、設定によって異なります。この表を使用して、各ソースタイプの主な特徴を把握し、十分な情報に基づいて意思決定を行うことができます。

機能 Git リポジトリ OCI イメージ Helm チャート
最適な用途 汎用構成管理、柔軟性、人間が読める形式 不変のバージョン管理された構成。コンテナ インフラストラクチャを活用 複雑なアプリケーションのパッケージングと配信
可変性 変更可 変更不可 変更可能（チャートのバージョンは変更不可ですが、値は変更できます）
ロールバック コミットを元に戻す、ブランチを変更する 以前のイメージタグをデプロイする 以前のバージョンのグラフにロールバックする
ツール 標準の Git クライアント、CI/CD パイプライン Docker または Podman、コンテナ レジストリ Helm CLI、Helm リポジトリ
パフォーマンス 大規模なリポジトリでは速度が低下する可能性がある 特に大規模な場合に高速 チャート リポジトリからフェッチするときに高速
認証 柔軟性がある（SSH、トークン）。設定が複雑になる可能性がある Workload Identity Federation for GKE で簡素化（Artifact Registry など） Workload Identity Federation for GKE で簡素化（Artifact Registry など）

同じクラスタで、異なる目的で異なるソースタイプを使用することもできます。たとえば、クラスタには次のものがあります。

  • プラットフォーム チームが管理するベース クラスタ全体のリソースとポリシーを含む Git リポジトリから同期する RootSync。
  • 特定の名前空間の RepoSync が Helm チャートから同期して、アプリケーション チームが管理する Redis インスタンスをデプロイする。
  • 別の Namespace の別の RepoSync が、別の CI/CD プロセスで構築されたアプリケーション固有の構成のセットを含む OCI イメージから同期します。

次のステップ