ConfigManagement オブジェクトを移行する

このページでは、ConfigManagement オブジェクトを RootSync オブジェクトに移行する方法について説明します。ConfigManagement オブジェクトから RootSync オブジェクトに移行すると、RootSync API と RepoSync API が有効になります。これらの API を使用すると、追加機能を使用できます。たとえば、Kustomize の構成と Helm チャートをレンダリングし、リソース上限の変更取得する Git commit 数の更新を行うことができます。ルート リポジトリのみを使用し、名前空間リポジトリを使用しない場合は、これらの API を有効にできます。

ConfigManagement の設定を移行する

nomos migrate を使用する

バージョン 1.10.0 以降では、nomosnomos migrate コマンドを使用すると、RootSync API と RepoSync API を有効にできます。nomos を 1.10.0 以降に更新する必要があります。

コマンドを実行する詳しい方法については、ConfigManagement オブジェクトから RootSync オブジェクトに移行するをご覧ください。

手動移行

nomos バージョンが 1.10.0 より前の場合、設定を手動で移行できます。ConfigManagement オブジェクトで spec.enableMultiRepotrue に設定して、ルート リポジトリをクラスタに同期する RootSync オブジェクトを作成する必要があります。ルート リポジトリは、クラスタごとに 1 つだけ作成できます。また、ルート リポジトリは、非構造化リポジトリか、階層リポジトリのいずれかになります。

構成を移行してルート リポジトリを構成するには、次の操作を行います。

  1. ConfigManagement オブジェクトを開きます。
  2. spec.git フィールドの値をコピーします。これらの値は、RootSync オブジェクトを作成するときに使用します。
  3. ConfigManagement オブジェクトから spec.git フィールド(git: を含む)をすべて削除します。
  4. ConfigManagement オブジェクトの spec.enableMultiRepo フィールドを true に設定します。

    # config-management.yaml
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      enableMultiRepo: true
    
  5. 変更を適用します。

    kubectl apply -f config-management.yaml
    
  6. RootSync CRD が作成されるまで待ちます。

    kubectl wait --for=condition=established crd rootsyncs.configsync.gke.io
    
  7. ConfigManagement オブジェクトからコピーした値を使用して、RootSync オブジェクトを作成します。次に例を示します。

    # root-sync.yaml
    # If you are using a Config Sync version earlier than 1.7.0,
    # use: apiVersion: configsync.gke.io/v1alpha1
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: root-sync
      namespace: config-management-system
    spec:
      sourceFormat: ROOT_FORMAT
      git:
        repo: ROOT_REPOSITORY
        revision: ROOT_REVISION
        branch: ROOT_BRANCH
        dir: "ROOT_DIRECTORY"
        auth: ROOT_AUTH_TYPE
        gcpServiceAccountEmail: ROOT_EMAIL
        # secretRef should be omitted if the auth type is none, gcenode, or gcpserviceaccount.
        secretRef:
          name: git-creds
    

    次のように置き換えます。

    • ROOT_FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では自分にとって最も便利な方法で構成ファイルを整理できます。
    • ROOT_REPOSITORY: ルート リポジトリとして使用する Git リポジトリの URL を記述します。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。プロトコルを入力しない場合、URL は HTTPS URL として扱われます。このフィールドは必須です。
    • ROOT_REVISION: チェックアウトする Git リビジョン(タグまたはハッシュ)を記述します。このフィールドは省略可能で、デフォルト値は HEAD です。
    • ROOT_BRANCH: 同期元となるリポジトリのブランチを記述します。このフィールドは省略可能で、デフォルト値は master です。
    • ROOT_DIRECTORY: 同期先への構成を含むルート ディレクトリへの Git リポジトリのパスを記述します。このフィールドは省略可能で、デフォルトはリポジトリのルート ディレクトリ(/)です。
    • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

      • none: 認証なし
      • ssh: SSH 認証鍵ペアを使用
      • cookiefile: cookiefile を使用
      • token: トークンを使用
      • gcpserviceaccount: Google サービス アカウントを使用して Cloud Source Repositories 内のリポジトリにアクセス。
      • gcenode: Google サービス アカウントを使用して Cloud Source Repositories 内のリポジトリにアクセス。このオプションは、Workload Identity がクラスタで有効になっていない場合にのみ、選択してください。

        この認証の種類の詳細については、Config Sync に Git の読み取り専用アクセス権を付与するをご覧ください。

      このフィールドは必須です。

    • ROOT_EMAIL: AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

  8. 変更を適用します。

    kubectl apply -f root-sync.yaml
    

ConfigManagement と RootSync の比較表

次の表に、ConfigMangent オブジェクトのフィールドと RootSync オブジェクトのフィールドの対応を示します。

ConfigManagement のフィールド RootSync のフィールド
spec.git.gcpServiceAccountEmail spec.git.gcpServiceAccountEmail
spec.git.syncRepo spec.git.repo
spec.git.syncBranch spec.git.branch
spec.git.policyDir spec.git.dir
spec.git.syncWait spec.git.period
spec.git.syncRev spec.git.revision
spec.git.secretType spec.git.auth
git-creds(これは ConfigManagement オブジェクトの固定値です) spec.git.secretRef.name
spec.sourceFormat spec.sourceFormat
spec.git.proxy.httpProxy または spec.git.proxy.httpsProxy spec.git.proxy

次のステップ