コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Git リポジトリに構成ファイルを追加する

Config Sync は、多数のクラスタを管理するクラスタ オペレータ向けに設計されています。Config Sync にすべてのクラスタの Namespace、Role、RoleBinding、ResourceQuota、その他の重要な Kubernetes オブジェクトの管理を任せることで、運用するクラスタがビジネスやコンプライアンスの基準を確実に遵守するようにできます。

Config Sync はこれらのリソースを管理する際に、構成ファイルを使用して、登録されたクラスタを同期させます。構成ファイルは、Git リポジトリに保存されている YAML ファイルまたは JSON ファイルです。構成ファイルには、kubectl apply コマンドを使用して手動でクラスタに適用できるものと同じタイプの構成情報が含まれています。クラスタ内に存在可能な Kubernetes オブジェクトの構成ファイルを作成できます。ただし、Secret などの一部の Kubernetes オブジェクトには機密情報が含まれており、Git リポジトリに保存するのは適切でない場合があります。これらのタイプのオブジェクトを Config Sync で管理するかどうかは、ご自身で判断してください。

Config Sync と Config Connector を使用して、Google Cloud リソースの構成ファイルを同期することもできます。Config Connector の使い方については、Config Connector を使用した Google Cloud リソースの管理をご覧ください。Config Controller を設定すると、Config Sync と Config Connector のインストールを簡素化できます。

このページでは、リポジトリに構成ファイルを追加する方法について説明します。構成ファイルを作成する方法については、構成ファイルを作成するをご覧ください。OCI イメージを公開する方法については、Artifact Registry から OCI アーティファクトを同期するをご覧ください。Helm リポジトリから同期する方法については、Artifact Registry から Helm チャートを同期するをご覧ください。

構成ファイルを整理する方法を選択する

Config Sync は、構成の保存とバージョン管理に Git リポジトリを使用します。リポジトリには、非構造化階層型の 2 つの形式があります。

非構造化ソース形式を使用すると、リポジトリ内の構成ファイルを最適な方法で整理できます。この形式は、KustomizekptHelm などのツールで構成ファイルを整理または生成する場合に特に便利です。構成ファイルの整理方法の例については、非構造化リポジトリの形式の例をご覧ください。

階層型または構造化されたソース形式では、構成ファイルをカテゴリに分類して整理できます。カテゴリとしては、システム構成、クラスタ メタデータ、クラスタレベルの構成、名前空間構成があります。階層型リポジトリ構造の詳細については、階層型リポジトリの構造をご覧ください。

ほとんどのユーザーには、非構造化形式の使用をおすすめします。また、RepoSync オブジェクトを作成して構成する Namespace リポジトリでは、非構造化形式を使用する必要があります。

非構造化リポジトリと階層型リポジトリでサポートされている機能

次の表は、非構造化形式と階層型形式の違いを示したものです。

機能 非構造化形式(推奨) 階層型形式
ルート リポジトリの形式として使用 サポート対象 サポート対象
名前空間リポジトリの形式として使用 サポート対象 非対応
Hierarchy Controller と一緒に使用 サポート対象 非推奨
ClusterSelector サポート対象 サポート対象
NamespaceSelector サポート対象 サポート対象
nomos hydrate コマンド --source-format=unstructured フラグでサポート サポート対象
nomos init コマンド 非対応 サポート対象
nomos vet コマンド --source-format=unstructured フラグでサポート サポート対象
その他のすべての nomos コマンド サポート対象 サポート対象
抽象名前空間 非対応 サポート対象
Repo オブジェクト 非対応 サポート対象
HierarchyConfig オブジェクト 非対応 サポート対象
Hierarchy Controller の階層型 Namespace サポート対象 非対応

リポジトリに構成ファイルを追加する

非構造化リポジトリを作成する場合は、作成後すぐに構成ファイルの追加を開始できます。階層型リポジトリを作成する場合は、nomos init コマンドを使用してリポジトリを初期化するか、ディレクトリ構造を手動で作成します。

空のディレクトリは Git リポジトリに commit できないため、Config Sync を構成する前に構成ファイルを作成してリポジトリに追加します。

リポジトリを作成してその構成ファイルを追加したら、nomos vet コマンドを使用してリポジトリの構造を確認し、構成ファイルの構文と有効性を確認します。

リポジトリから読み取るように Config Sync を構成する

リポジトリを作成して構成ファイルを配置したら、そのリポジトリから読み取るように Config Sync を構成できます。この手順が完了すると、Config Sync はリポジトリからクラスタに構成ファイルを同期します。

リポジトリの場所は、Config Sync のインストール時に構成します。また、Config Sync の構成は後で編集できます。Git リポジトリに構成以外のコンテンツがある場合は、リポジトリの場所に加えて、監視する Git ブランチとサブディレクトリを指定できます。

階層型リポジトリを使用していて、kubectl で Config Sync を手動でインストールする場合は、Operator の構成ファイルを system/ ディレクトリや cluster/namespaces/ などの他の予約済みディレクトリに配置しないでください。この構成ファイルを予約済みディレクトリのいずれかに置くと、nomos vet が失敗し、KNV1033: IllegalSystemResourcePlacementErrorKNV1038: IllegalKindInNamespacesError または KNV1039: IllegalKindInClusterError が返されます。

特定のプロダクト チームのデプロイ リポジトリへのアクセス権を付与できます。ただし、デプロイ リポジトリへのアクセス権をユーザーに付与すると、そのユーザーには、そのリポジトリで実行されている Reconciler と同じ RBAC も付与されます。

Config Sync とリポジトリ間の認証と認可を構成する方法については、git-creds Secret の構成に関するインストール手順をご覧ください。

オブジェクトのミューテーションを無視する

背後にクラスタが存在するオブジェクトの状態を Config Sync が維持しないようにするには、Config Sync がミューテーションを無視するように client.lifecycle.config.k8s.io/mutation: ignore アノテーションをオブジェクトに追加します。

アノテーションを使用するには、RootSync API と RepoSync API を有効にする必要があります。

そのアノテーションをオブジェクトに追加する方法を、次の例に示します。

metadata:
  annotations:
    client.lifecycle.config.k8s.io/mutation: ignore 

クラスタのマネージド オブジェクトでは、このアノテーションは手動で変更できません。

次のステップ