バックアップクラスターを復元アカウント配下の登録済みクラスターに接続することで、クロスアカウントでのアプリケーションのバックアップと復元が可能になります。
仕組み
バックアップクラスターは、復元アカウント配下の登録済みクラスターに接続します。登録済みクラスター内のバックアップセンターが、両方のアカウントにまたがるバックアップと復元を管理します。
バックアップ対象
| リソースタイプ | バックアップ可否 | 備考 |
|---|---|---|
| Kubernetes リソース (StatefulSet、Deployment、Pod、Service、ConfigMap、Secret、Ingress、CronJob、PersistentVolumeClaim (PVC)、PersistentVolume (PV) など) | 対応 | — |
| NAS ボリューム (Cloud Backup 経由) | 対応 | VPC 経由でのクロスアカウントバックアップおよび復元には対応していません |
| ディスクボリューム (Cloud Backup または ECS スナップショット経由) | 対応 | ECS スナップショットソリューションを使用する場合、追加のクロスアカウント手順が必要です |
| OSS ボリューム | 非対応 | バックアップクラスターの AccessKey ペアを使用して、元の OSS バケットにマッピングすることで復元されます |
| 削除中のリソース | 非対応 | — |
前提条件
以下の要件を満たしていることを確認してください。
-
Cloud Backup が有効になっていること — NAS ボリューム、OSS バケット、ローカルディスクボリュームのファイルベースバックアップに使用します
-
復元クラスターが Kubernetes 1.16 以降 (ECS スナップショットベースのディスク復元には 1.18 以降) で実行されていること。詳細については、「ACK managed cluster の作成」、「ACK dedicated cluster の作成 (廃止)」、または「クラスター登録プロキシを作成し、データセンターにデプロイされた Kubernetes クラスターを登録する」をご参照ください
-
復元クラスターは Container Storage Interface (CSI) プラグインを使用する必要があります。FlexVolume または FlexVolume を使用した
csi-compatible-controllerはサポートされていません -
CSI 1.1.0 以降がインストールされていること (ディスクスナップショットベースのボリュームバックアップに必要)
復元タスクを実行する前に、復元クラスターに以下のコンポーネントをインストールして設定します。
-
aliyun-acr-credential-helper (Container Registry パスワードフリーコンポーネント) :権限を付与し、
acr-configurationを設定します -
alb-ingress-controller (ALB Ingress コンポーネント) :ALBConfig を設定します
課金
バックアップセンター自体は無料です。以下のサービスについて料金が発生する場合があります。
| 課金項目 | 適用条件 | 詳細 |
|---|---|---|
| OSS ストレージ | すべてのバックアップシナリオ — OSS がバックアップ YAML ファイルを保存します | 標準 OSS ストレージ料金が適用されます |
| ECS スナップショットストレージ | ECS スナップショットソリューションを使用したディスクボリュームバックアップ | 2023 年 10 月 12 日 11:00 (UTC+8) 以降、インスタントアクセス機能にストレージ料金および使用料金は発生しません。PL0~PL3 ESSD (拡張 SSD) および ESSD AutoPL ディスクは、デフォルトでインスタントアクセスが有効になっています |
| Cloud Backup | NAS ボリュームバックアップ、および Cloud Backup ソリューションを使用したディスクボリュームバックアップ | OSS ボリューム復元には適用されません |
制限事項
-
両方のクラスターは Kubernetes 1.16 以降で実行されている必要があります。新しい Kubernetes バージョンから古いバージョンへのアプリケーション移行は推奨されません。
-
クロスリージョン復元の場合、登録済みクラスターを復元クラスターと同じリージョンに作成してください。バックアップクラスターはインターネット経由で接続し、復元は内部ネットワークを使用します。
-
バックアップセンターは、復元クラスター内の互換性のある API バージョンにリソースを復元します。互換性のあるバージョンがない場合は、手動でリソースをデプロイしてください。詳細については、「ACK でサポートされている Kubernetes バージョンのリリースノート」および上流の「非推奨 API 移行ガイド」をご参照ください。
-
Kubernetes 1.16 クラスターの Deployment は、
extensions/v1beta1、apps/v1beta1、apps/v1beta2、apps/v1をサポートしています。Kubernetes 1.28 への移行後、Deployment API バージョンはapps/v1に復元されます。 -
Kubernetes 1.16 クラスターの Ingress は、
extensions/v1beta1およびnetworking.k8s.io/v1beta1をサポートしています。Kubernetes 1.22 以降を実行しているクラスターでは Ingress を復元できません。
重要Kubernetes 1.16 では、
appsおよびrbac.authorization.k8s.ioは既に API バージョン v1 をサポートしています。Kubernetes 1.28 への移行後、Ingress および CronJob リソースを手動で復元してください。 -
-
登録済みクラスター用のバックアップセンターテンプレートは、標準 ACK クラスターとは異なります。バックアップクラスターを接続または切断する場合は、ターゲットクラスターでバックアップセンターコンポーネントを再インストールしてください。
-
登録済みクラスターで作成された ECS スナップショットは、バックアップクラスターのアカウントに属します。復元アカウントでディスクボリュームを復元するには、アカウント間でスナップショットを共有する (ECS スナップショットソリューション) か、Cloud Backup を使用してください。
-
CNFS で管理される NAS ボリューム (ストレージクラス:
alibabacloud-cnfs-nas) を復元するには、まずストレージクラスを作成してください。 -
復元クラスターに同名のリソースが存在する場合、バックアップセンターはそれをスキップします。復元は非破壊的です。
サンプルアプリケーション
以下のサンプルアプリケーションは、各ボリュームタイプのバックアップと復元の動作を示しています。
| アプリケーション | ボリュームタイプ | PVC | データバックアップの必要性 | 備考 |
|---|---|---|---|---|
| sts-disk | ディスクボリューム | pvc-disk | 必要 (Cloud Backup または ECS スナップショット) | データ整合性が必要です。バックアップ前に書き込み操作を一時停止してください |
| sts-nas | NAS ボリューム | pvc-nas | 必要 (Cloud Backup) | VPC 経由でのクロスアカウントバックアップおよび復元には対応していません。復元クラスターは元の NAS データを読み取ることができません |
| sts-oss | OSS ボリューム | pvc-oss | 不要 | バックアップクラスターの AccessKey ペアを使用して、元の OSS バケットにマッピングすることで復元されます |
異なるボリュームタイプのアプリケーションを作成するには、「ストレージ - CSI」をご参照ください。
ディスクバックアップソリューションの選択
アプリケーションがディスクボリュームを使用する場合は、ソリューションを選択してください。
| Cloud Backup ソリューション | ECS スナップショットソリューション | |
|---|---|---|
| 仕組み | csdr-config で enable_ecs_snapshot: false を設定します。Cloud Backup がディスクボリュームデータを処理します。復元時にターゲットストレージクラスを disk に設定します。 |
csdr-config で enable_ecs_snapshot: true を設定します。バックアップアカウントから復元アカウントへ ECS スナップショットを共有します。復元タスクを実行する前に、VolumeSnapshotContent および VolumeSnapshot を手動で作成します。 |
| メリット | 追加の手動設定が不要です | 高速です。同一ディスク上のデータ整合性が保証されます |
| デメリット | 低速です。データ整合性を保証できません | 各ディスクボリュームに対して手動での作業が必要です |
| 使用条件 | アプリケーションが厳密なデータ整合性を必要としない場合、または多数のディスクボリュームがある場合 | アプリケーションがデータ整合性を必要とし、スナップショット共有手順を実行できる場合 |
ディスクボリュームを使用しないアプリケーションの場合は、Cloud Backup ソリューションを使用してください。
(オプション) ステップ 1:バックアップクラスターのバックアップセンターコンポーネントをアンインストールする
バックアップクラスターに migrate-controller がインストールされていない場合は、このステップをスキップしてください。
バックアップクラスターに既にバックアップセンターがインストールされている場合は、まずアンインストールしてください。登録済みクラスター用のテンプレートは標準 ACK クラスターとは異なり、両方を共存させることはできません。
-
バックアップクラスターのアカウントで ACK コンソールにログインします。左側のナビゲーションペインで、[クラスター] をクリックします。
-
[クラスター] ページで、バックアップクラスターの名前をクリックします。左側のナビゲーションペインで [アドオン] をクリックします。
-
[アドオン] ページで、[アプリケーション管理] タブをクリックします。
-
[migrate-controller] を見つけて、[アンインストール] をクリックします。
-
[アンインストール] メッセージで、[OK] をクリックします。
ステップ 2:登録済みクラスターにバックアップセンターコンポーネントをインストールする
-
復元アカウントを使用して登録済みクラスターを作成し、バックアップクラスターをそれに接続します。
-
登録済みクラスターでmigrate-controller をインストールして権限を付与します。
登録済みクラスターは復元クラスターと同じリージョンにあるため、OSS 内部ネットワークルートは不要です。
ステップ 3:登録済みクラスターでバックアップタスクを作成する
このステップは、バックアップクラスターではなく、復元アカウント配下の登録済みクラスターで実行してください。
Cloud Backup ソリューション
ディスクボリュームの設定を簡素化したい場合、またはアプリケーションにディスクボリュームがない場合は、このソリューションを選択してください。
-
ECS スナップショット機能を無効にします。
-
csdr-configConfigMap を編集します。kubectl -ncsdr edit cm csdr-config -
enable_ecs_snapshotをfalseに設定します。保存して終了します。 -
コントローラーを再起動します。
kubectl -ncsdr delete pod -l control-plane=csdr-controller
-
-
復元アカウントにバックアップボールトがない場合は、作成し、復元アカウントの
cnfs-oss-*OSS バケットに関連付けます。 -
sts-oss アプリケーションのバックアップタスクを作成します。
-
[ボリュームのバックアップ] を [無効] に設定します — sts-oss は元の OSS バケットにマッピングされるため、ボリュームバックアップは不要です。
-
oss名前空間を選択します。名前空間に他のアプリケーションが含まれている場合は、ラベルを追加してsts-ossのみを選択してください。 -
[アプリケーションバックアップ] ページの [バックアップレコード] タブで、ステータスが [InProgress] から [Completed] に変わるまで待ちます。レコード名をクリックして、StatefulSet、Pod、PVC、PV、および Secret (AccessKey ペアを含む) がバックアップされていることを確認してください。
-
-
sts-nas アプリケーションと sts-disk アプリケーションのバックアップタスクを作成します。
-
[ボリュームのバックアップ] を [マウント済みボリューム] に設定します。
-
enable_ecs_snapshotをfalseに設定すると、Cloud Backup がディスクボリュームデータを処理します。Cloud Backup コンソールの [コンテナバックアップ] > [バックアップジョブ] で進行状況を監視してください。
-
ECS スナップショットソリューション
アプリケーションがディスクボリュームを使用し、データ整合性が必要な場合は、これを選択してください。
-
ECS スナップショット機能を有効にします。
-
csdr-configConfigMap を編集します。kubectl -ncsdr edit cm csdr-config -
enable_ecs_snapshotをtrueに設定します。保存して終了します。 -
コントローラーを再起動します。
kubectl -ncsdr delete pod -l control-plane=csdr-controller
-
-
復元アカウントにバックアップボールトがない場合は、作成し、復元アカウントの
cnfs-oss-*OSS バケットに関連付けます。 -
sts-oss アプリケーションのバックアップタスクを作成します。
-
[ボリュームのバックアップ] を [無効] に設定します。
-
oss名前空間を選択します。名前空間に他のアプリケーションが含まれている場合は、ラベルを追加してsts-ossのみを選択してください。 -
[バックアップレコード] タブで、ステータスが [Completed] に変わるまで待ち、関連するすべてのリソースがバックアップされていることを確認してください。
-
-
sts-nas および sts-disk アプリケーション用に [backup-nas-disk] という名前のバックアップタスクを作成します。
-
[ボリュームのバックアップ] を [マウント済みボリューム] に設定します。
-
ディスクボリュームデータは、デフォルトで ECS スナップショットを使用してバックアップされます。ECS コンソールの [スナップショット] > [ディスクスナップショット] でスナップショットを確認してください。
-
NAS ボリュームデータは Cloud Backup を使用してバックアップされます。Cloud Backup コンソールの [コンテナバックアップ] > [バックアップジョブ] で進行状況を監視してください。
-
ステップ 4:復元クラスターで復元タスクを作成する
復元は非破壊的です。復元クラスターに同名のリソースが存在する場合、バックアップセンターはそれをスキップします。
Service の復元時の動作:
| Service タイプ | 復元時の動作 |
|---|---|
| NodePort | デフォルトでポートが保持されます |
ExternalTrafficPolicy: Local を使用する LoadBalancer |
HealthCheckNodePort はデフォルトでランダムポートを使用します。元のポートを保持するには、復元タスク作成時に spec.preserveNodePorts: true を設定してください |
| 既存の SLB インスタンスを使用する LoadBalancer | 復元された Service は元の SLB インスタンスを保持しますが、すべてのリスナーが無効になります。SLB コンソールでリスナーを手動で設定してください |
| Cloud Controller Manager (CCM) で管理される LoadBalancer | CCM は復元中に新しい SLB インスタンスを作成します。詳細については、「LoadBalancer タイプの Service を設定する際の考慮事項」をご参照ください |
Cloud Backup ソリューション
復元クラスターのアカウントを使用して、以下の手順を実行してください。
-
[sts-oss] アプリケーションを復元します。詳細については、「アプリケーションとボリュームの復元」をご参照ください。
-
[アプリケーションバックアップ] ページで、バックアップファイルを同期するために [今すぐバックアップ] をクリックし、バックアップボールトを選択して初期化し、バックアップファイルの同期を待ちます。
-
[backup-oss] バックアップファイルを選択して、復元タスクを作成します。
-
sts-oss が実行されていることを確認します。
kubectl execを使用してコンテナにログインし、データ整合性を確認してください。
-
-
ストレージクラス変換を使用して、[sts-nas] および [sts-disk] アプリケーションを復元します。詳細については、「アプリケーションとボリュームの復元」をご参照ください。
-
[アプリケーションバックアップ] ページで [今すぐバックアップ] をクリックし、[backup-nas-disk] を選択します。ストレージクラス変換では、
pvc-diskにalicloud-diskを、pvc-nasにalibabacloud-cnfs-nasを選択してください。alicloud-diskは、デフォルトで CSI プラグインのalicloud-disk-topology-alltypeストレージクラスになります。カスタムストレージクラスを使用することもできます。 -
アプリケーションとデータを確認します。ECS コンソールで、復元アカウントに新しいディスクが作成され、正しいノードにマウントされていることを確認してください。
-
ECS スナップショットソリューション
-
復元クラスターのアカウントで、[sts-oss] アプリケーションを復元します。詳細については、「アプリケーションとボリュームの復元」をご参照ください。
-
[アプリケーションバックアップ] ページで、バックアップファイルを同期するために [今すぐバックアップ] をクリックし、バックアップボールトを選択して初期化し、バックアップファイルの同期を待ちます。
-
[backup-oss] バックアップファイルを選択して、復元タスクを作成します。
-
kubectl execを使用して、sts-oss が実行されていることを確認してください。
-
-
バックアップクラスターのアカウントを使用して、ディスクスナップショットを復元アカウントと共有します。ECS コンソールで、各スナップショットを共有してください。バックアップセンターのスナップショットには
snapshot-というプレフィックスが付いています。作成時刻でバックアップレコードと照合してください。 -
共有スナップショットを承諾する前に、バックアップアカウントで PVC とスナップショットのマッピングを記録してください。これらのマッピングは手動での復元に必要です。
-
ECS コンソールで、各スナップショット ID とそれに対応するディスク ID のマッピングを記録します。
-
バックアップクラスターで、ディスクボリュームを使用する各 PV の PVC とディスク ID を照会します。
kubectl get pv <PV-Name> -o jsonpath='{"PVC: "}{.spec.claimRef.name}{"\nNamespace: "}{.spec.claimRef.namespace}{"\nVolumeHandle: "}{.spec.csi.volumeHandle}'想定される出力:
PVC: <disk-pvc-name> Namespace: <disk-pvc-namespace> VolumeHandle: d-2ze323ra0h2v5lxxxxxこれらのマッピングを使用して、各 PVC を対応するスナップショット ID にリンクしてください。
-
-
復元クラスターのアカウントを使用して Resource Management コンソールにログインし、共有スナップショットを承諾します。スナップショット名は同じままですが、ID は変更されます。名前と手順 3 のマッピングを使用して、各 PVC を新しいスナップショット ID にマッピングしてください。
-
復元クラスターでディスクボリュームを手動で復元します。
-
静的プロビジョニングを使用して、復元クラスターに VolumeSnapshotContent と VolumeSnapshot を作成します。詳細については、「ディスクボリュームのスナップショットを作成する」をご参照ください。ターゲット PVC と同じ名前空間に VolumeSnapshot を作成してください。VolumeSnapshotContent の
snapshotHandleを新しいスナップショット ID に設定します。 -
VolumeSnapshot を参照して、元と同じ名前の PVC を作成します。詳細については、「ディスクボリュームのスナップショットを作成する」のステップ 6 をご参照ください。新しい PVC は、VolumeSnapshot を指す
dataSourceパラメータが追加された元の設定と一致します。
-
-
[sts-nas] および [sts-disk] アプリケーションを復元します。詳細については、「アプリケーションとボリュームの復元」をご参照ください。バックアップセンターは、前の手順で復元されたため、sts-disk ボリュームを自動的にスキップします。復元タスクは、同名の PVC をアプリケーションにマウントします。
-
[アプリケーションバックアップ] ページで、バックアップファイルを同期するために [今すぐバックアップ] をクリックし、[backup-nas-disk] を選択します。ストレージクラス変換を行わない場合、ボリュームは元のストレージクラスで復元されます。復元クラスターにそのストレージクラスが存在することを確認してください。
-
ECS コンソールで、復元アカウントに新しいディスクが作成され、正しいノードにマウントされていることを確認してください。
-
(オプション) ステップ 5:バックアップクラスターを切断し、バックアップセンターを再デプロイする
クロスアカウント移行が完了した後:
-
クロスアカウントバックアップまたは復元が不要になった場合は、登録済みクラスターからバックアップクラスターを切断してください。
-
バックアップクラスターでバックアップセンターを引き続き使用する場合は、登録済みクラスターからコンポーネントをアンインストールし、バックアップクラスターに再インストールしてください。