kubectl を使用して Config Sync を手動でインストールする

このページでは、kubectl コマンドを使用して Config Sync をインストールする方法について説明します。Config Management Operator は、Kubernetes クラスタ内の Config Sync を管理するコントローラです。Config Sync を使用して管理する各クラスタで Operator をインストールして構成するには、次の手順を行います。

このページで説明する kubectl コマンドを使用して Config Sync を構成する場合は、後で Google Cloud Console または Google Cloud CLI を使用して構成を変更できます。ただし、Cloud Console または gcloud CLI を使用して構成を変更すると、kubectl コマンドを使用して構成を変更できなくなります。

始める前に

このセクションでは、kubectl を使用して Config Sync をインストールする場合の前提条件について説明します。

ローカルの環境を準備する

Operator をインストールする前に、次の作業を行い、ローカル環境を準備してください。

  • Config Sync の同期先となる構成ファイルを格納できる Git リポジトリを作成するか、対象リポジトリへのアクセス権を取得します。

  • この手順で使用する gcloudgsutilkubectlnomos コマンドを含む Google Cloud CLI をインストールして初期化します。Cloud Shell を使用する場合、Google Cloud CLI がプリインストールされています。

  • kubectl は、デフォルトでは Google Cloud CLI によってインストールされません。kubectl をインストールするには、次のコマンドを使用します。

    gcloud components install kubectl
    
  • Config Sync のコンポーネントをダウンロードできるように、gcloud auth login コマンドを使用して Google Cloud に対する認証を行います。

クラスタを準備する

Config Sync の要件を満たす GKE クラスタを作成するか、該当するクラスタへのアクセス権を取得します。

権限を準備する

Config Sync をインストールする Google Cloud ユーザーには、クラスタに新しいロールを作成するための IAM 権限が必要です。必要であれば、次のコマンドを使用して、これらのロールを付与してください。

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user USER_ACCOUNT

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

  • CLUSTER_NAME: クラスタ名
  • USER_ACCOUNT: Google Cloud アカウントのメールアドレス

ローカル システムでの Google Cloud CLI の構成方法によっては、--project フィールドと --zone フィールドを追加する必要があります。

クラスタを登録する

Config Sync でクラスタを登録するには、次の手順を行います。

  1. Operator をデプロイする
  2. Operator に Git への読み取り専用アクセス権を付与する
  3. Operator を構成する

Operator をデプロイする

すべての前提条件を満たしていることを確認したら、YAML マニフェストをダウンロードして適用し、Operator をデプロイします。

  1. 次のコマンドを使用して、Operator マニフェストの最新バージョンをダウンロードします。特定のバージョンをダウンロードするには、ダウンロードをご覧ください。

    gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml
    
  2. マニフェストを適用します。

    kubectl apply -f config-management-operator.yaml

このコマンドが失敗した場合は、トラブルシューティングをご覧ください。

Operator に Git への読み取り専用アクセス権を付与する

Config Sync には、Git リポジトリに対する読み取り専用権限が必要です。この権限により、Config Sync はリポジトリに commit された構成ファイルを読み取り、クラスタに適用できるようになります。

読み取り専用アクセスに対してリポジトリによる認証が不要な場合は、引き続き Config Sync を構成し、認証タイプとして none を使用できます。たとえば、ログインせずにウェブ インターフェースでリポジトリを参照できる場合は認証の必要はありません。また、認証情報を指定することや、保存済みの認証情報を使用することなく、git clone を使用してリポジトリのクローンをローカルに作成できる場合も認証は不要です。この場合は Secret を作成する必要もありません。

ただし、ほとんどのユーザーは、リポジトリへの読み取りアクセスが制限されているため、認証情報を作成する必要があります。認証情報が必要な場合は、登録された各クラスタの git-creds Secret に認証情報が保存されています(Google サービス アカウントを使用している場合を除く)。Secret は固定値であるため、git-creds という名前にする必要があります。

Config Sync は、次の認証メカニズムをサポートしています。

  • SSH 認証鍵ペア
  • cookiefile
  • トークン
  • Google サービス アカウント(Cloud Source Repositories のリポジトリのみ)

どちらの方法を選択するかは、リポジトリがサポートする対象によって異なります。通常は、SSH 認証鍵ペアを使用することをおすすめします。GitHub と Bitbucket はどちらも SSH 認証鍵ペアの使用をサポートしています。ただし、Cloud Source Repositories のリポジトリを使用している場合は、プロセスがよりシンプルであるため、Google サービス アカウントの使用をおすすめします。組織でリポジトリをホストしていて、どの認証方法がサポートされているかがわからない場合は、管理者にお問い合わせください。

SSH 認証鍵ペア

SSH 認証鍵ペアは、公開鍵と秘密鍵の 2 つのファイルから構成されています。通常、公開鍵の拡張子は .pub です。

SSH 認証鍵ペアを使用するには、次の手順を行います。

  1. SSH 認証鍵ペアを作成し、Config Sync が Git リポジトリに対して認証されるようにします。この手順は、リポジトリのクローンを作成するか、リポジトリの内容を読み取る際に認証が必要になる場合に必要になります。鍵ペアがセキュリティ管理者から提供される場合は、この手順を省略します。自社のセキュリティとコンプライアンスの要件に応じて、すべてのクラスタに対して単一の鍵ペアを使用するか、クラスタごとに 1 つの鍵ペアを使用するかを選びます。

    次のコマンドは 4,096 ビットの RSA 鍵を作成します。これよりビット数の少ない鍵はおすすめできません。

    ssh-keygen -t rsa -b 4096 \
    -C "GIT_REPOSITORY_USERNAME" \
    -N '' \
    -f /path/to/KEYPAIR_FILENAME
    

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

    • GIT_REPOSITORY_USERNAME: Config Sync がリポジトリへの認証で使用するユーザー名。
    • /path/to/KEYPAIR_FILENAME: 鍵ペアへのパス。

    GitHub などのサードパーティ Git リポジトリ ホストを使用している場合や、Cloud Source Repositories でサービス アカウントを使用する場合は、別のアカウントを使用することをおすすめします。

  2. 新しく作成した公開鍵を認識するようにリポジトリを構成します。ご使用の Git ホスティング プロバイダのドキュメントをご覧ください。よく使われる Git ホスティング プロバイダの手順へのリンクを以下に示します。

  3. 秘密鍵をクラスタ内の新しい Secret に追加します。

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
    

    /path/to/KEYPAIR_PRIVATE_KEY_FILENAME は、秘密鍵の名前に置き換えます(.pub 拡張子は付けません)。

  4. ローカル ディスクから秘密鍵を削除するか、秘密鍵を保護します。

  5. Config Sync を構成して Git リポジトリの URL を追加する場合は、SSH プロトコルを使用します。Cloud Source Repositories のリポジトリを使用している場合は、URL を入力する際に次の形式を使用する必要があります。

    ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME
    

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

    • EMAIL: Google Cloud ユーザー名
    • PROJECT_ID: リポジトリが配置されている Google Cloud プロジェクトの ID
    • REPO_NAME: リポジトリの名前

cookiefile

cookiefile を取得するプロセスは、リポジトリの構成によって異なります。サンプルについては、Cloud Source Repositories のドキュメントの静的認証情報を生成するをご覧ください。認証情報は通常、ユーザーのホーム ディレクトリにある .gitcookies ファイルに保存されますが、セキュリティ管理者から提供されることもあります。

cookiefile を作成するには、次の手順を行います。

  1. cookiefile を作成して取得したら、クラスタの新しい Secret に追加します。

    HTTPS プロキシを使用しない場合は、次のコマンドを使用して Secret を作成します。

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-file=cookie_file=/path/to/COOKIEFILE
    

    HTTPS プロキシを使用する必要がある場合は、次のコマンドを実行して、cookiefile と一緒に Secret に追加します。

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-file=cookie_file=/path/to/COOKIEFILE \
     --from-literal=https_proxy=HTTPS_PROXY_URL
    

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

    • /path/to/COOKIEFILE: 適切なパスとファイル名
    • HTTPS_PROXY_URL: Git リポジトリとの通信時に使用する HTTPS プロキシの URL
  2. 引き続きローカルで必要な場合は、cookiefile の内容を保護します。必要でなければ削除します。

トークン

組織で SSH 認証鍵の使用が許可されていない場合は、トークンを使用することをおすすめします。Config Sync では、トークンとして GitHub の個人アクセス トークン(PAT)、GiLab の PAT、デプロイキー、Bitbucket のアプリ パスワードを使用できます。

トークンを使用して Secret を作成するには、次の手順を行います。

  1. GitHub または Bitbucket を使用してトークンを作成します。

  2. トークンを作成して取得したら、それをクラスタの新しい Secret に追加します。

    HTTPS プロキシを使用しない場合は、次のコマンドを使用して Secret を作成します。

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
      --namespace="config-management-system" \
      --from-literal=username=USERNAME \
      --from-literal=token=TOKEN
    

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

    • USERNAME: 使用するユーザー名。
    • TOKEN: 前のステップで作成したトークン。

    HTTPS プロキシを使用する必要がある場合は、次のコマンドを実行して、username および token と一緒に Secret に追加します。

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=username=USERNAME \
      --from-literal=token=TOKEN \
     --from-literal=https_proxy=HTTPS_PROXY_URL
    

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

    • USERNAME: 使用するユーザー名。
    • TOKEN: 前のステップで作成したトークン。
    • HTTPS_PROXY_URL: Git リポジトリとの通信時に使用する HTTPS プロキシの URL。
  3. ローカルでのトークンが必要な場合は、トークンを保護します。必要でなければ削除します。

Google サービス アカウント

リポジトリが Cloud Source Repositories にある場合は、Google サービス アカウントを使用して、マネージド クラスタと同じプロジェクト内のリポジトリに対するアクセス権を Config Sync に付与できます。

Cloud Source Repositories のリポジトリを Config Sync リポジトリとして使用するには、次の手順を行います。

  1. Cloud Source Repositories の URL を取得します。

    1. リポジトリのリストを取得します。

      gcloud source repos list
      
    2. 使用するリポジトリの URL を出力からコピーします。例:

      REPO_NAME  PROJECT_ID  URL
      my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
      

      この URL は、次のセクションで Config Sync を構成するときに必要になります。Google Cloud Console を使用して Config Sync を構成する場合は、URL を [URL] フィールドに追加します。Google Cloud CLI を使用して Config Sync を構成する場合は、構成ファイルの syncRepo フィールドに URL を追加します。

  2. Config Sync を構成するときに、適切な認証タイプを選択します。選択する認証タイプは、所有しているクラスタの種類と Workload Identity が有効かどうかによって異なります。

    • Workload Identity が有効な場合: GKE Workload Identity を有効にしている場合、またはフリートの Workload Identity を使用している場合は、この方法を使用します。フリートの Workload Identity を使用している場合は、GKE クラスタと非 GKE クラスタの両方でこの認証方法を使用できます。

    • Workload Identity が有効になっていない場合: この方法は、GKE クラスタにのみ使用できます。

    Workload Identity が有効になっている

    1. 必要に応じて、サービス アカウントを作成します。サービス アカウントに source.reader ロールを付与して、Cloud Source Repositories に対する読み取りアクセス権があることを確認します。

    2. Google Cloud Console を使用して Config Sync を構成する場合は、[認証タイプ] で [Workload Identity] を選択し、サービス アカウントのメールアドレスを追加します。

      Google Cloud CLI を使用して Config Sync を構成する場合は、gcpserviceaccountsecretType として追加し、サービス アカウントのメールアドレスを gcpServiceAccountEmail に追加します。

    3. Config Sync の構成が完了したら、Kubernetes サービス アカウントと Google サービス アカウントの間に IAM ポリシー バインディングを作成します。Config Sync を構成するまで Kubernetes サービス アカウントは作成されません。

      フリートに登録されたクラスタを使用している場合は、フリートごとに 1 回だけポリシー バインディングを作成する必要があります。フリートに登録されたすべてのクラスタは、同じ Workload Identity プールを共有します。フリートのコンセプトである同一性により、1 つのクラスタの Kubernetes サービス アカウントに IAM ポリシーを追加すると、同じフリート内の他のクラスタでも同じ Namespace の Kubernetes サービス アカウントが同じ IAM ポリシーを取得します。

      このバインディングにより、Config Sync Kubernetes サービス アカウントが Google サービス アカウントとして機能できるようになります。

      gcloud iam service-accounts add-iam-policy-binding \
         --role roles/iam.workloadIdentityUser \
         --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
         GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
      

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

      • PROJECT_ID: GKE Workload Identity を使用している場合は、組織のプロジェクト ID を追加します。

        フリートの Workload Identity を使用している場合は、2 つの異なるプロジェクト ID を使用できます。serviceAccount:PROJECT_ID で、クラスタが登録されているフリートのプロジェクト ID を追加します。GSA_NAME@PROJECT_ID に、Cloud Source Repositories のリポジトリに対する読み取りアクセス権を持つプロジェクトのプロジェクト ID を追加します。

      • KSA_NAME: Reconciler の Kubernetes サービス アカウント。ルート リポジトリでは、RootSync の名前が root-sync の場合、KSA_NAMEroot-reconciler です。それ以外の場合は root-reconciler-ROOT_SYNC_NAME です。

        名前空間リポジトリでは、RepoSync の名前が repo-sync の場合、KSA_NAMEns-reconciler-NAMESPACE です。それ以外の場合は ns-reconciler-NAMESPACE-REPO_SYNC_NAME です。

      • GSA_NAME: Cloud Source Repositories への接続に使用するカスタム Google サービス アカウント。選択した Google サービス アカウントに source.reader ロールがあることを確認します。

    Workload Identity が有効になっていない

    Google Cloud Console を使用して Config Sync を構成する場合は、[認証タイプ] に [Google Cloud Repository] を選択します。

    Google Cloud CLI を使用して Config Sync を構成する場合は、gcenodesecretType として追加します。

    Google Cloud Repository または gcenode を選択すると、Compute Engine のデフォルトのサービス アカウントを使用できます。デフォルトでは、Compute Engine のデフォルトのサービス アカウント PROJECT_ID-compute@developer.gserviceaccount.com には、同じプロジェクトのリポジトリに対する source.reader アクセス権が付与されています。ただし、Cloud Source Repositories がクラスタのプロジェクトと異なるプロジェクトに存在する場合、クラスタのプロジェクトからデフォルトの Compute Engine サービス アカウントに Cloud Source Repositories のプロジェクトの source.reader を付与する必要があります。

    次のコマンドで source.reader ロールを追加できます。

    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role roles/source.reader
    

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

    • PROJECT_ID: 組織のプロジェクト ID
    • PROJECT_NUMBER: 組織のプロジェクト番号

    アクセス スコープは、ノードプールの作成後は変更できません。ただし、同じクラスタを使用しながら、適切なアクセス スコープを持つ新しいノードプールを作成できます。デフォルトの gke-default スコープに cloud-source-repos-ro は含まれません。

Operator を構成する

ルート リポジトリからの同期を構成するには、ConfigManagement オブジェクトでマルチリポジトリ モードを有効にして、ルート リポジトリをクラスタに同期する RootSync オブジェクトを作成する必要があります。ルート リポジトリは、クラスタごとに 1 つだけ作成できます。また、ルート リポジトリは、非構造化リポジトリか、階層リポジトリのいずれかになります。

  1. バージョン 1.7 を使用していて、限定公開クラスタに Config Sync をインストールする場合は、ファイアウォール ルールを追加してポート 8676 を許可します。Config Sync アドミッション Webhook では、ドリフト防止にポート 8676 を使用します。バージョン 1.8.0 以降、ポートは 10250 に切り替えられ、限定公開クラスタではデフォルトで開いています。バージョン 1.10.0 以降、Config Sync アドミッション Webhook はデフォルトで無効になっています。

  2. config-management.yaml という名前のファイルを作成して、次の YAML ファイルをコピーします。

    # config-management.yaml
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      # The `enableMultiRepo` field is set to true to enable RootSync and RepoSync APIs.
      enableMultiRepo: true
      # The `preventDrift` field is supported in Anthos Config Management version 1.10.0 and later.
      preventDrift: PREVENT_DRIFT
    

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

    • PREVENT_DRIFT: true に設定されている場合、Config Sync アドミッション Webhook を有効にして、競合変更がライブクラスタに push されないように拒否することにより、ブレを防止します。デフォルトの設定は false です。Config Sync は、このフィールドの値に関係なく、常にブレを修正します。
  3. 変更を適用します。

    kubectl apply -f config-management.yaml
    
  4. CRD の RootSyncRepoSync が使用可能になるまで待ちます。

    until kubectl get customresourcedefinitions rootsyncs.configsync.gke.io reposyncs.configsync.gke.io; do date; sleep 1; echo ""; done
    
  5. 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_NAME
      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:
          name: ROOT_SECRET_NAME
        # the `noSSLVerify` field is supported in Anthos Config Management version 1.8.2 and later.
        noSSLVerify: ROOT_NO_SSL_VERIFY
    

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

    • ROOT_SYNC_NAME: RootSync オブジェクトの名前を追加します。1.11.0 より前のバージョンでは、root-sync にする必要があります。バージョン 1.11.0 以降の場合は、任意の名前を指定します。
    • ROOT_FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では自分にとって最も便利な方法で構成ファイルを整理できます。
    • ROOT_REPOSITORY: ルート リポジトリとして使用する Git リポジトリの URL を記述します。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。このフィールドは必須です。
    • 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: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

    • ROOT_SECRET_NAME: Secret の名前を追加します。Secret を使用している場合は、Secret の公開鍵を Git プロバイダに追加する必要があります。このフィールドは省略可能です。

    • ROOT_NO_SSL_VERIFY: SSL 証明書の検証を無効にするには、このフィールドを true に設定します。デフォルト値は false です。

    フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

  6. 変更を適用します。

    kubectl apply -f root-sync.yaml
    

ルート リポジトリの同期ステータスを確認する

ルート リポジトリの同期ステータスは、nomos status コマンドを使用して確認できます。

nomos status

出力は次の例のようになります。

my_managed_cluster-1
  --------------------
  <root>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4

RootSync のインストールを確認する

RootSync オブジェクトを作成すると、Config Sync によって接頭辞が root-reconciler の Reconciler が作成されます。Reconciler は、Deployment としてデプロイされる Pod です。Git リポジトリからマニフェストにクラスタに同期します。

RootSync オブジェクトが正しく機能していることは、root-reconciler Deployment のステータスをチェックして確認できます。

Config Sync のバージョンが 1.11.0 より前の場合:

kubectl get -n config-management-system deployment/root-reconciler

Config Sync バージョンが 1.11.0 以降の場合:

kubectl get -n config-management-system deployment -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

ROOT_SYNC_NAME は、RootSync の名前に置き換えます。

出力は次の例のようになります。

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

RootSync オブジェクトのステータスを確認する別の方法については、RootSync オブジェクトと RepoSync オブジェクトのモニタリングをご覧ください。

ルート リポジトリの構成が終了したら、必要に応じて複数のリポジトリからの同期を構成選択できます。これらのリポジトリは、クラスタ全体で特定の Namespace に同期される名前空間スコープの構成ファイルを 1 つのリポジトリに保存する場合に役立ちます。

Config Sync をアップグレードする

Config Sync をアップグレードするには、登録されているクラスタごとに次のコマンドを実行します。

  1. 新しいバージョンの Anthos Config Management マニフェストと nomos コマンドをダウンロードします。

  2. Anthos Config Management マニフェストを適用します。

    kubectl apply -f config-management-operator.yaml
    

    このコマンドにより、Anthos Config Management イメージが更新されます。Kubernetes によって新しいバージョンが取得され、新しいバージョンを使用して Anthos Config Management Pod が再起動されます。Anthos Config Management が起動すると、新しいイメージにバンドルされたマニフェストのセットを適用する調整ループが実行されます。これにより、各コンポーネントの Pod が更新され、再起動されます。

  3. バージョン 1.9.0 以降では、Config Management Operator は kube-system Namespace ではなく、config-management-system Namespace にインストールされます。1.9.0 より前のバージョンから 1.9.0 以降にアップグレードする場合は、古い Config Management Operator を kube-system Namespace から削除する必要があります。

    kubectl delete -n kube-system serviceaccounts config-management-operator
    kubectl delete -n kube-system deployments config-management-operator
    
  4. すべてのクライアントの nomos コマンドを新しいバージョンに置き換えます。この変更により、nomos コマンドを実行して、登録済みのすべてのクラスタのステータスを確実に取得し、構成ファイルを検証できるようになります。

Config Sync をアンインストールする

Config Sync をアンインストールする手順は次のとおりです。

  1. 中央管理者がルート リポジトリを削除する必要があります。

    1. トラブルシューティングの指示に従って、RootSync オブジェクトによって管理されているリソースを管理対象外にするか削除します。

    2. RootSync オブジェクトを削除するには、次のコマンドを実行します。

      kubectl delete -f root-sync.yaml
      
  2. リポジトリを削除します

  3. config-management.yaml ファイルの spec.enableMultiRepo フィールドを削除します。

  4. config-management.yaml ファイルをクラスタに適用します。

Anthos Config Management を完全にアンインストールする場合は、Config Management Operator の削除をご覧ください。

次のステップ