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

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

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

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

このページでは、リポジトリに構成ファイルを追加する方法について説明します。構成を作成する方法については、構成を作成するをご覧ください。

構成を整理する方法を選択してください

Config Sync は、Git リポジトリを使用して構成を保存し、バージョンを制御します。リポジトリには、非構造化階層の 2 つの形式を選択できます。

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

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

ほとんどのユーザーには、非構造化形式の使用をおすすめします。また、名前空間リポジトリには非構造化形式を使用する必要があります。

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

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

機能 非構造化形式(推奨) 階層形式
ルート リポジトリの形式として使用 サポート対象 サポート対象
Namespace リポジトリの形式として使用 サポート対象 非対応
Hierarchy Controller と一緒に使用 サポート対象 非推奨
クラスタ セレクタ サポート対象 サポート対象
Namespace セレクタ サポート対象 サポート対象
nomos hydrate コマンド --source-format=unstructured フラグでサポート サポート対象
nomos init コマンド 非対応 サポート対象
nomos vet コマンド --source-format=unstructured フラグでサポート サポート対象
その他のすべての nomos コマンド サポート対象 サポート対象
抽象 Namespace 非対応 サポート対象
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 が返されます。

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

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

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

背後にクラスタが存在するオブジェクトの状態を Config Sync が維持しないようにするには、Config Sync がミューテーションを無視するように client.lifecycle.config.k8s.io/mutation: ignore アノテーションをオブジェクトに追加します。アノテーションを使用するには、複数のリポジトリからの同期を有効にして、1.7.0 以降のバージョンを使用する必要があります。Google Cloud Console または Google Cloud CLI を使用してバージョン 1.7.0 以降の Config Sync をインストールする場合、複数のリポジトリからの同期はデフォルトで有効になっています。kubectl を使用して Config Sync をインストールする場合は、ConfigManagement オブジェクトで spec.enableMultiRepotrue に設定します。

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

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

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

次のステップ