Config Controller リソースを移行する

このページでは、Config Connector リソースを Config Controller クラスタ間で移行する方法について説明します。プライマリ Config Controller クラスタで障害が発生し、交換が必要な場合、または不変のクラスタ構成を変更する必要がある場合は、リソースを移行することが必要な場合があります。

このページでは、次の用語を使用します。

  • 移行元クラスタ: 移行する必要がある Config Connector リソースを含むクラスタ。
  • 宛先クラスタ: リソースの移行先となるクラスタ。

推奨事項

  • 本番環境で変更を行う前に、テスト環境で次の手順を完了してください。
  • 複数の Config Controller クラスタを移行する必要がある場合は、重要度の低いクラスタから順に移行します。
  • Config Sync クラスタが複数の信頼できる情報源から同期している場合は、各情報源からすべてのリソースを一度に移行します。

さまざまなシナリオでの移行手順

すべてのリソースを移行する

すべてのリソースを移行するには、次の手順を行います。

  1. 宛先クラスタを作成します。

  2. 移行元クラスタが同期元として構成されている信頼できる情報源への変更の push を停止します。Config Sync は、信頼できる情報源からの同期を引き続き行います。移行元クラスタと同期している変更のみを停止する必要があります。

  3. 信頼できる情報源への最近の変更がクラスタで同期され、すべてのリソースが移行元クラスタで最新の状態になっていることを確認します。

    一部のリソースにエラーがある場合は、リソースを個別に分析する必要があります。エラーのためにリソースがまだ作成されていない場合は、後で宛先クラスタの Config Connector によって作成されます。通常、これらのエラーは無視できます。ただし、ほとんどのエラーでは、移行を試みる前に根本原因を特定し、解決する必要があります。

  4. 宛先クラスタで Config Sync を設定し、移行元クラスタで構成されている同じ信頼できる情報源から読み取りを行うようにします。複数の信頼できる情報源から同期するように複数の同期を設定している場合は、この操作を同期ごとに行います。

  5. nomos status コマンドを使用して、宛先クラスタが信頼できる情報源からすべてのリソースを同期したことを確認します。

  6. リソースが同期されたら、移行元クラスタから RootSync または RepoSync を削除します。

  7. 信頼できる各情報源が移行されたら、移行元の Config Controller クラスタを削除します。

一部のリソースを移行する

一部のリソースを移行するには、次の手順を行います。

  1. 上記のすべてのリソースを移行するセクションの手順 1～6 を行います。

  2. 移行先のクラスタに移行するリソースに、cnrm.cloud.google.com/deletion-policy: abandon アノテーションを設定します。このアノテーションにより、Config Connector リソースが Config Controller クラスタから削除されたときに、Config Connector が基盤となるリソースを削除できなくなります。

  3. 放棄としてマークされたリソースを移行元クラスタから削除します。この削除は、Config Sync を再開する前に、これらのリソースが信頼できる情報源から削除された場合にのみ機能します。

  4. これらのリソースを別の信頼できる情報源、または同じ信頼できる情報源内の別のフォルダに移動します。

  5. リソースの移動先のロケーションから同期するように宛先クラスタを設定します。これで、宛先クラスタがこれらのリソースを取得して管理できるようになりました。

リソースを個別に移行する

Config Controller クラスタを削除できない場合（たとえば、リソースのサブセットを別のクラスタに移行する場合など）は、リソースを個別に削除できます。リソースを個別に削除するには、Config Sync を無効にしてから、削除するリソースにアノテーション cnrm.cloud.google.com/deletion-policy: abandon を設定します。

サービスで生成された resourceID を持つリソースを移行する

resourceID フィールドが明示的に指定されていないリソースについては、別の Config Connector インスタンスによるリソースの取得で resourceID を指定する必要はありません。ただし、追加の手順が必要なサービス生成リソース ID を持つリソースがあります。resourceID は、サービスによって生成されますが、別の Config Connector インスタンスから取得するために、これらのリソースを提供する必要があります。これらのリソースについては、宛先クラスタからリソースの取得を試みる前に、resourceID を信頼できる情報源に追加する必要があります。

競合防止ポリシーを使用してリソースを移行する

デフォルトでは、リソースに対して競合防止ポリシーが無効になっています。リソースに対して有効にするには、次のアノテーションを設定します。

cnrm.cloud.google.com/management-conflict-prevention-policy: "resource"

設定が完了すると、Config Connector は変更を行う前に基盤となるリソースにリースを取得する必要があります。リースが移行元クラスタ内の Config Connector によって保持されているため、宛先クラスタは直ちにリースを取得できません。リース期間は 40 分間です。ただし、20 分が経過すると、Config Connector はリースの更新を試みます。このため、移行元クラスタ内の Config Connector が正常に動作している場合、宛先クラスタはリースを取得できません。宛先クラスタがリースを取得するには、移行元クラスタがリースを解放する必要があります。この処理を行うには、移行元クラスタを削除するか、移行元クラスタ内のリソースを削除します。

移行元クラスタがリースを解放すると、宛先クラスタはリースを取得できるようになります。宛先クラスタは最大 40 分後にリースを取得でき、リソースの管理を開始できます。宛先クラスタによってリースが取得されるまで、Config Connector リソースに変更を加えないでください。

次のステップ