バックアップセンターを使用して、ACK クラスター内のアプリケーションをバックアップし、同一リージョン内の別のクラスターに復元します。これは、クラスターのアップグレード、インフラストラクチャのリフレッシュ、および同一リージョン内でのクラスター間ディザスタリカバリに推奨される手法です。
制限事項
開始前に以下の制約を確認してください。条件を満たさない場合、移行は失敗します。
Kubernetes バージョン：復元先クラスターは、ECS インスタンスのスナップショットを用いたディスクデータ復元を実行するために、Kubernetes 1.18 以降を実行している必要があります。
ストレージプラグイン：復元先クラスターは、Container Storage Interface (CSI) プラグインを使用している必要があります。FlexVolume を使用するクラスター、または csi-compatible-controller と FlexVolume の組み合わせを使用するクラスターでは、移行はサポートされていません。
システムコンポーネント：復元タスクを実行する前に、復元先クラスターに以下のコンポーネントをインストール・構成してください。
aliyun-acr-credential-helper：必要な権限を付与し、acr-configurationを構成します。alb-ingress-controller：ALBConfig リソースを構成します。
クロスリージョン：本プロシージャは同一リージョン内での移行のみをサポートします。クロスリージョン移行については、「異なるリージョン間でのクラスター間アプリケーション移行」をご参照ください。
ボリュームプラグインの互換性: 異なるボリュームプラグインを使用している、または古い Kubernetes バージョンを実行しているクラスターの場合は、「バックアップセンターを使用して、古い Kubernetes バージョンを実行している ACK クラスターのアプリケーションを移行する」をご参照ください。
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
同一リージョン内の 2 つの ACK マネージドクラスター（バックアップ対象クラスターおよび復元先クラスター）
バックアップ対象クラスターおよび復元先クラスターの両方に、必要な権限付きで migrate-controller コンポーネントがインストール済みであること。詳細については、「migrate-controller のインストールと権限付与」をご参照ください。
migrate-controller のインストール時に作成または特定されたバックアップボールト。インストール時に既存のボールトが自動検出されるため、ボールトが存在しない場合のみ新規作成が必要です。詳細については、「バックアップボールトの作成」をご参照ください。
仕組み
バックアップセンターは、クラスター間の中継として共有バックアップボールトを使用します。バックアップ対象クラスターでバックアップタスクを作成すると、バックアップセンターはアプリケーションの状態およびボリュームデータをボールトにアップロードします。その後、バックアップセンターはバックアップレコードを復元先クラスターに同期し、同期完了後にバックアップを復元ポイントとして利用可能にします。
復元タスク実行時には、Kubernetes リソースの API バージョンが、復元先クラスターで推奨されるバージョンに自動的にアップグレードされます。たとえば、Kubernetes 1.16 クラスター内で extensions/v1beta1 を使用する Deployment は、Kubernetes 1.28 クラスターへ復元時に apps/v1 に変更されます。
ACK クラスター間での WordPress アプリケーション移行
この例では、中国 (フフホト) リージョン内の 2 つの ACK マネージドクラスター（Cluster_A をバックアップ対象クラスター、Cluster_B を復元先クラスター）を使用します。WordPress アプリケーションは、テキストコンテンツ用にディスクボリューム、画像用に NAS ファイルシステムボリュームを使用します。
ステップ 1：クラスターの準備
同一リージョン内で ACK マネージドクラスター Cluster_A および Cluster_B を作成します。ディスク復元に ECS スナップショットを用いるため、Cluster_B を Kubernetes 1.18 以降に更新します。
Helm を使用して Cluster_A に WordPress をインストールします。詳細については、「Helm を使用した WordPress アプリケーションのデプロイ」をご参照ください。
WordPress で画像を含むブログ投稿を行います。これにより、ディスクボリューム（テキスト）および NAS ファイルシステムボリューム（画像）の両方にデータが書き込まれ、移行後の検証に利用できます。
ステップ 2：Cluster_A への migrate-controller のインストールおよびバックアップボールトの作成
Cluster_A に migrate-controller コンポーネントをインストールし、必要な権限を付与します。インストール時にバックアップボールトを作成します。詳細については、「migrate-controller のインストールと権限付与」をご参照ください。
すでにバックアップボールトが存在する場合は、システムが自動検出します。新たに作成する必要はありません。
ステップ 3：Cluster_A におけるアプリケーションのバックアップ
Cluster_A で 123backup-1 という名前のバックアップタスクを作成し、default 名前空間をバックアップします。詳細については、「バックアッププランの作成または即時バックアップ」をご参照ください。
バックアップタスクのステータスが 完了 に変更されるまで待ちます。完了後、バックアップレコードは、ボールトの同期完了後に Cluster_B の バックアップとスナップショット タブ（アプリケーションバックアップ ページ）に表示されます。
ステップ 4：Cluster_B におけるアプリケーションの復元
Cluster_B の アプリケーションバックアップ ページで、今すぐ復元 をクリックし、共有バックアップボールトを選択します。
ボールトの初期化を促すメッセージが表示された場合は、バックアップボールトの初期化 をクリックして、Cluster_B との関連付けを行います。
初期化後、バックアップファイル 123backup-1 を選択し、復元タスクを開始します。詳細については、「アプリケーションおよびボリュームの復元」をご参照ください。
ステップ 5：移行の検証
ワークロードの健全性の検証：
Cluster_B の詳細ページ左側ナビゲーションウィンドウから、ワークロード > デプロイメント に移動します。
WordPress のデプロイメントを見つけ、詳細 をクリックします（操作 列）。
デプロイメントのステータスが 実行中 であることを確認します。
アプリケーションのアクセス可能性およびデータ整合性の検証：
左側ナビゲーションウィンドウから、ネットワーク > サービス に移動します。
サービスページで WordPress のサービスを検索し、外部エンドポイント 列のリンクをクリックします。
WordPress のホームページが正常にロードされ、NAS に保存された画像を含むブログ投稿が完全な状態で表示されることを確認します。
次のステップ
コマンドラインからバックアップおよび復元を管理するには、「kubectl を使用したアプリケーションのバックアップおよび復元」をご参照ください。
リージョン間でのアプリケーションの移行については、「異なるリージョンのクラスター間でのアプリケーションの移行」をご参照ください。
ボリュームプラグインまたは Kubernetes のバージョンが異なるクラスターについては、「バックアップセンターを使用して古い Kubernetes バージョンを実行する ACK クラスターのアプリケーションを移行する」をご参照ください。