非構造化リポジトリの使用

非構造化リポジトリを使用すると、自分が一番使いやすい方法でリポジトリを整理できます。この柔軟性により、既存の Kubernetes 構成を Config Sync リポジトリと同期させることができます。たとえば、Helm チャートをクラスタに同期する場合は、helm template を実行して、レンダリングされたマニフェストをリポジトリに commit できます。詳細については、Config Sync と Helm の使用のチュートリアルをご覧ください。

ほとんどのユーザーには、非構造化形式の使用をおすすめします。ただし、階層リポジトリを作成して、構成ファイルをカテゴリに分類することもできます。階層リポジトリのルールに従わずに階層型ポリシーを作成する場合は、Hierarchy Controller の使用を検討してください。

制限事項

非構造化リポジトリには、以下の制限があります。

  • 非構造化リポジトリでは Repo または HierarchyConfig Kubernetes オブジェクトを使用できません。

  • 抽象 Namespaceは、非構造化リポジトリではサポートされていません。

  • nomos vet コマンドを使用する場合は、--source-format=unstructured フラグを追加します。次に例を示します。

    nomos vet --source-format=unstructured
    

Namespace スコープ オブジェクト

非構造化リポジトリで NamespaceSelector を宣言できます。NamespaceSelector を宣言するには、metadata.namespace アノテーションまたは NamespaceSelector アノテーションのどちらかを追加します。両方のアノテーションを宣言することはできません。Namespace スコープのリソースで metadata.namespaceNamespaceSelector アノテーションが宣言されていない場合、Config Sync はクラスタの「default」Namespace を使用します。

階層リポジトリでの場合とは異なり、非構造化リポジトリでは、リポジトリ内にある Namespace スコープ オブジェクトのすべての Namespace を宣言する必要はありません。オブジェクトは、非構造化リポジトリ内に一致する Namespace オブジェクトがなくても metadata.namespace を定義できます。Namespace がすでにクラスタに存在する場合、Config Sync はその Namespace 内にオブジェクトを作成します。Namespace がまだクラスタに存在しない場合、Config Sync は Namespace を暗黙的に作成します。

非構造化リポジトリでは、NamespaceSelector アノテーションを宣言するオブジェクトは、NamespaceSelector's 条件を満たす Namespace のすべてに適用されます。以前に階層リポジトリで使用されていたオブジェクトを使用して非構造化リポジトリを作成する前に、NamespaceSelectors は追加リソースに適用されないことを確認してください。

非構造化リポジトリから Namespace スコープ オブジェクトを削除すると、Config Sync によってオブジェクトが削除されますが、その削除されたオブジェクトに対して暗黙的に作成された Namespace は削除されません。これは、Config Sync が暗黙的に作成された Namespace を安全に削除できるタイミングを推測できないためです。このため、暗黙的に作成された Namespace は必ずクラスタに残ります。

クラスタ スコープ オブジェクト

非構造化リポジトリでは、ClusterSelectors は通常と同じように機能します。

非構造化リポジトリの構成

非構造化リポジトリを構成するには、RootSync オブジェクトまたは ConfigManagement オブジェクトの spec.sourceFormat の値を unstructured に設定します。

RootSync

次の RootSync オブジェクトでは、非構造化リポジトリから同期するように Anthos Config Management を構成します。

# root-sync.yaml
# If you are using a Config Sync version earlier than 1.7,
# use: apiVersion: configsync.gke.io/v1alpha1
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: init
    dir: quickstart/multirepo/root
    auth: ssh
    secretRef:
      name: SECRET_NAME

SECRET_NAME は、Secret の名前に置き換えます。

ConfigManagement

次の ConfigManagement オブジェクトでは、継続的インテグレーション パイプラインを設定し、同期先のリポジトリが構造化されていないことを指定します。

# config-management.yaml

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  # clusterName is required and must be unique among all managed clusters
  clusterName: CLUSTER_NAME
  sourceFormat: unstructured
  git:
    syncRepo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    syncBranch: init
    secretType: ssh
    policyDir: ci-pipeline-unstructured

spec フィールドに追加できるフィールドの全一覧については、ConfigManagement フィールドをご覧ください。

階層リポジトリを非構造化リポジトリに変換する

階層リポジトリを使用していて、それを非構造化リポジトリに変換する場合は、リポジトリで次のコマンドを実行します。

nomos hydrate [/path/to/directory]

これにより、現在の作業ディレクトリに compiled/ ディレクトリが作成されます。このディレクトリで、登録済みのクラスタごとに完全に解決された構成ファイルを使用してサブディレクトリが作成され、各サブディレクトリを非構造化リポジトリで使用できます。

詳しくは、nomos コマンドをご覧ください。

手動で変換する場合は、次の手順に従って変換します。

  1. Git リポジトリから system/ ディレクトリの Repo 構成ファイルを削除します。非構造化リポジトリに Repo リソースは必要ありません。

  2. 非構造化リポジトリでは、抽象名前空間ディレクトリはサポートされていません。したがって、元のすべてのディレクトリの名前空間は namespaces/ ディレクトリとそのサブディレクトリで宣言する必要があります。

  3. Namespace の継承は非構造化リポジトリでサポートされていません。したがって、元々は子 descend 名前空間に継承されているすべてのリソース、つまり namespaces/ ディレクトリの下に元々置かれたリソースを宣言する必要があります。

次のステップ