同一リージョン内のクラスター間でのアプリケーション移行 - Container Service for Kubernetes

制限事項

以下の条件が満たされない場合、移行は失敗します。

Kubernetes バージョン：復元クラスターは、Elastic Compute Service (ECS) スナップショットを使用してディスクを復元するために、Kubernetes 1.18 以降を実行している必要があります。
ストレージプラグイン：復元クラスターは Container Storage Interface (CSI) プラグインを使用する必要があります。FlexVolume または FlexVolume と csi-compatible-controller を使用しているクラスターはサポートされていません。
システムコンポーネント：復元前に、復元クラスターに以下のコンポーネントをインストールおよび設定してください。
- aliyun-acr-credential-helper：必要な権限を付与し、acr-configuration を設定してください。
- alb-ingress-controller：ALBConfig リソースを設定してください。
クロスリージョン：この手順は、同一リージョン内の移行にのみ対応します。クロスリージョンの移行については、「異なるリージョンのクラスター間でのアプリケーション移行」をご参照ください。
ボリュームプラグインの互換性：異なるボリュームプラグインを使用している、または古い Kubernetes バージョンを実行しているクラスターについては、「古い Kubernetes バージョンを実行する ACK クラスターでバックアップセンターを使用してアプリケーションを移行する」をご参照ください。

前提条件

開始する前に、以下の準備が整っていることを確認してください。

同一リージョン内に 2 つの ACK マネージドクラスター (バックアップクラスターと復元クラスター) があること
両方のクラスターに、必要な権限を持つ 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 でのアプリケーションのバックアップ

default 名前空間をバックアップするために、Cluster_A で [123backup-1] という名前のバックアップタスクを作成します。詳細については、「バックアップ計画の作成または即時バックアップ」をご参照ください。

バックアップタスクのステータスが [完了] に変わるまで待ちます。その後、ボールトが同期されると、バックアップレコードが Cluster_B の [アプリケーションバックアップ] ページの [バックアップとスナップショット] タブに表示されます。

ステップ 4：Cluster_B でのアプリケーションの復元

Cluster_B の [アプリケーションバックアップ] ページで、[今すぐ復元] をクリックし、共有バックアップボールトを選択します。
ボールトの初期化を求められた場合は、[バックアップボールトの初期化] をクリックして、Cluster_B に関連付けます。
初期化後、バックアップファイル [123backup-1] を選択し、復元タスクを開始します。詳細については、「アプリケーションとボリュームの復元」をご参照ください。

ステップ 5：移行の検証

ワークロードの健全性の検証：

Cluster_B の詳細ページの左側メニューで、[ワークロード] > [Deployments] を選択します。
WordPress の Deployment を探し、[操作] 列の [詳細] をクリックします。
Deployment のステータスが [実行中] であることを確認します。

アクセシビリティとデータ整合性の検証：

左側メニューで、[ネットワーク] > [Services] を選択します。
[Services] ページで、WordPress の Service を探し、[外部エンドポイント] リンクをクリックします。
WordPress のホームページと画像付きのブログ投稿が正しく表示されることを確認します。

次のステップ

コマンドラインからバックアップと復元を管理するには、「kubectl を使用したアプリケーションのバックアップと復元」をご参照ください。
リージョン間でアプリケーションを移行するには、「異なるリージョンのクラスター間でのアプリケーション移行」をご参照ください。
異なるボリュームプラグインまたは Kubernetes バージョンを使用しているクラスターについては、「古い Kubernetes バージョンを実行する ACK クラスターでバックアップセンターを使用してアプリケーションを移行する」をご参照ください。