コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Config Controller リソースの移行

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

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

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

推奨事項

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

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

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

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

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

  2. 移行元クラスタと同期するように構成された Git リポジトリへの新しい変更の push を停止します。Config Sync はリポジトリからの同期を継続する必要があります。移行元クラスタと同期している Git ブランチの変更のみを停止する必要があります。

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

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

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

  5. nomos status コマンドを使用して、宛先クラスタが Git リポジトリからすべてのリソースを同期したことを確認します。

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

  7. すべてのリポジトリの同期を移行したら、移行元の Config Controller クラスタを削除します。

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

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

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

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

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

  4. これらのリソースを別の Git リポジトリ、または同じリポジトリ内の別のフォルダに移動します。

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

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

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

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

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

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

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

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

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

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

次のステップ