信頼できる情報源に構成ファイルを追加する

このページでは、信頼できる情報源に構成を追加し、保存されている構成を整理する方法について説明します。

構成ファイルについて

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

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

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

制限事項

  • 一部の Kubernetes リソースには、Deployment オブジェクトの Pod セレクタなど、変更不可能なフィールドが含まれています。信頼できる情報源の値を変更しても、構成ファイル内の変更不可フィールドを変更することはできません。このような変更を試みると、KNV2009 エラーが発生します。変更不可フィールドを変更する必要がある場合は、信頼できる情報源からオブジェクトを削除し、Config Sync がクラスタからオブジェクトを削除するのを待ってから、更新したオブジェクトを信頼できる情報源に再作成します。

  • Git サブモジュールを使用する場合は、サブモジュールを含むすべてのリポジトリに Config Sync のアクセス権を付与する必要があります。

  • Config Sync を使用して、組み込みの Kubernetes ClusterRole を直接管理することはできません。GKE には、cluster-admin、admin、edit、view などの組み込みのユーザー向けロールが用意されています。これらの ClusterRole を Config Sync で直接管理することはできません。Config Sync が GKE と競合するためです。組み込みの ClusterRole に権限を追加するには、ロールの集約を使用して間接的に変更します。ロールを変更するには、適切なアノテーションを使用して、信頼できる情報源に一意の名前の ClusterRole を作成します。

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

Config Sync では、構成の保存とバージョンの管理に信頼できる情報源を使用します。信頼できる情報源として、非構造化と階層型の 2 つの形式を選択できます。

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

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

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

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

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

機能 非構造化形式（推奨） 階層型形式
RootSync オブジェクトまたは一元的な信頼できる情報源の形式として使用 サポート対象 サポート対象
RepoSync オブジェクトの形式として使用 サポート対象 サポート対象外
ClusterSelector サポート対象 サポート対象
NamespaceSelector サポート対象 サポート対象
nomos hydrate コマンド --source-format=unstructured フラグでサポート サポート対象
nomos init コマンド 非対応 サポート対象
nomos vet コマンド --source-format=unstructured フラグでサポート サポート対象
その他のすべての nomos コマンド サポート対象 サポート対象
抽象 Namespace 非対応 サポート対象
Repo 個のオブジェクト 非対応 サポート対象
HierarchyConfig オブジェクト 非対応 サポート対象

情報源に構成ファイルを追加するタイミング

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

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

信頼できる情報源を作成して構成ファイルを追加したら、nomos vet コマンドを使用して信頼できる情報源の構造を検証し、構文と構成の有効性を確認します。

信頼できる情報源から読み取るように Config Sync を構成する

信頼できる情報源を作成して構成ファイルを保存したら、その情報源から読み取るように Config Sync を構成できます。この手順が完了すると、Config Sync は信頼できる情報源の構成ファイルをクラスタと同期します。

信頼できる情報源の場所は、Config Sync をインストールするときに構成できます・Config Sync の構成は後で編集できます。信頼できる情報源の場所に加えて、情報源に構成ファイル以外のコンテンツがある場合は、監視するブランチやサブディレクトリを指定できます。

階層型形式を使用していて、kubectl で Config Sync を手動でインストールする場合は、Operator の構成ファイルを system/ ディレクトリや cluster/、namespaces/ などの他の予約済みディレクトリに配置しないでください。この構成ファイルを予約済みディレクトリのいずれかに置くと、nomos vet が失敗し、KNV1033: IllegalSystemResourcePlacementError、KNV1038: 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

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

次のステップ