このトピックでは、バックアップセンターに関するよくある質問とその回答を紹介します。
目次
一般的な操作
kubectl でバックアップセンターを使用する場合、問題をトラブルシューティングする前に、migrate-controller コンポーネントを最新バージョンにアップグレードしてください。このアップグレードは既存のバックアップには影響しません。コンポーネントのアップグレード方法の詳細については、「コンポーネントの管理」をご参照ください。
バックアップジョブ、ストレージクラス変換タスク、または復元ジョブのステータスが [Failed] または [PartiallyFailed] の場合、次の方法でエラーメッセージを取得できます。
[ステータス] 列の [Failed] または [PartiallyFailed] にポインターを合わせると、
RestoreError: snapshot cross region request failedのような簡単なエラーメッセージが表示されます。
より詳細なエラーメッセージを取得するには、次のコマンドを実行してタスクのイベントを照会します。エラーメッセージの例は
RestoreError: process advancedvolumesnapshot failed avs: snapshot-hz, err: transition canceled with error: the ECS-snapshot related ram policy is missingです。バックアップジョブ
kubectl -n csdr describe applicationbackup <backup-name>ストレージクラス変換タスク
kubectl -n csdr describe converttosnapshot <backup-name>復元ジョブ
kubectl -n csdr describe applicationrestore <restore-name>
コンソールに「動作中のコンポーネントは異常です」または「現在のデータのフェッチに失敗しました」と表示される
問題
コンソールにエラー [コンポーネントが異常です] または [データの取得に失敗しました] が表示されます。
原因
バックアップセンターコンポーネントが正しくインストールされていませんでした。
解決策
クラスターにノードが存在するかどうかを確認します。ノードが存在しない場合、バックアップセンターはデプロイできません。
クラスターが FlexVolume を使用している場合は、CSI に切り替える必要があります。詳細については、「FlexVolume を使用するクラスターの migrate-controller コンポーネントが起動できない」をご参照ください。
kubectl でバックアップセンターを使用する場合は、YAML 構成が正しいかどうかを確認します。詳細については、「kubectl を使用したアプリケーションのバックアップと復元」をご参照ください。
ご利用のクラスターが ACK 専用クラスターまたは登録済みクラスターである場合は、必要な権限が付与されているかどうかを確認します。詳細については、「ACK 専用クラスター」および「登録済みクラスター」をご参照ください。
csdr 名前空間の csdr-controller および csdr-velero ステートレスアプリケーションが、リソースまたはスケジューリングの制限によりデプロイに失敗したかどうかを確認します。失敗した場合は、問題を解決してください。
コンソールに「名前が既に使用されています。名前を変更して再試行してください」というエラーが表示される
問題
バックアップ、ストレージクラス変換、または復元ジョブの作成または削除時に重複した名前を指定すると、コンソールに [名前が既に使用されています。名前を変更して再試行してください] というエラーが表示されます。
原因
コンソールでタスクを削除すると、クラスター内に deleterequest リソースが作成されます。その後、コンポーネントは一連の削除操作を実行しますが、これには対応するバックアップリソースの削除以上のものが含まれます。同じことがコマンドライン操作にも当てはまります。詳細については、「kubectl を使用したアプリケーションのバックアップと復元」をご参照ください。
deleterequest リソースの処理中に削除操作が正しくないか、エラーが発生した場合、クラスター内の一部のリソースが削除されない可能性があります。これにより、同じ名前のリソースが既に存在することを示すエラーメッセージが表示されます。
解決策
プロンプトに示されているように、同じ名前のリソースを削除します。たとえば、エラーメッセージ
deleterequests.csdr.alibabacloud.com "xxxxx-dbr" already existsが返された場合は、次のコマンドを実行してリソースを削除します。kubectl -n csdr delete deleterequests xxxxx-dbr新しい名前でタスクを作成します。
クラスター間でアプリケーションを復元する際に既存のバックアップを選択できない
問題
クラスター間でアプリケーションを復元する際にバックアップジョブを選択できません。
原因
原因 1：バックアップボールトが現在のクラスターに関連付けられていません。これは、バックアップボールトが初期化されていないことを意味します。
システムはバックアップボールトを初期化し、Object Storage Service (OSS) バケット情報を含む基本情報をクラスターに同期します。その後、システムはクラスター内のバックアップボールトからバックアップファイルを初期化します。初期化が完了した後にのみ、復元用のバックアップファイルを選択できます。
原因 2：バックアップボールトの初期化に失敗しました。現在のクラスターの backuplocation リソースのステータスは
Unavailableです。原因 3：バックアップジョブが不完全であるか、失敗しています。
解決策
解決策 1：
[解凍] ページで、[バックアップボールト] を見つけ、[バックアップボールトの初期化] をクリックします。バックアップボールトが初期化されたら、解凍するジョブを選択します。
解決策 2：
次のコマンドを実行して、backuplocation リソースのステータスを確認します。
kubectl get -n csdr backuplocation <backuplocation-name> 期待される出力：
NAME PHASE LAST VALIDATED AGE
<backuplocation-name> Available 3m36s 38mステータスが Unavailable の場合は、「タスクのステータスが [Failed] になり、「VaultError: xxx」エラーが返される」の解決策をご参照ください。
解決策 3：
バックアップクラスターのコンソールで、バックアップジョブのステータスが [Completed] であることを確認します。バックアップのステータスが [Completed] でない場合は、問題をトラブルシューティングします。詳細については、「インデックス」をご参照ください。
コンソールに「現在のコンポーネントに必要なサービスロールが承認されていません」と表示される
問題
アプリケーションバックアップコンソールにアクセスすると、コンソールに「現在のコンポーネントに必要なサービスロールが承認されていません」というメッセージが表示され、エラーコード AddonRoleNotAuthorized が返されます。
原因
ACK マネージドクラスターの migrate-controller コンポーネントのクラウドリソース認証ロジックは、migrate-controller 1.8.0 で最適化されました。このバージョンに初めてコンポーネントをインストールまたはアップグレードする場合、Alibaba Cloud アカウントはクラウドリソースの権限付与を完了する必要があります。
解決策
Alibaba Cloud アカウントでログインしている場合は、[承認] をクリックして権限付与を完了します。
RAM ユーザーとしてログインしている場合は、[承認リンクのコピー] をクリックし、そのリンクを Alibaba Cloud アカウントに送信して権限付与を依頼します。
コンソールに「現在のアカウントには、この操作に必要なクラスター RBAC 権限が付与されていません」と表示される
問題
アプリケーションバックアップコンソールにアクセスすると、「現在のアカウントには、この操作に必要なクラスター RBAC 権限が付与されていません。プライマリアカウントまたは権限管理者に連絡して承認を依頼してください。」というメッセージが表示されます。エラーコードは APISERVER.403 です。
原因
コンソールは API サーバーと対話して、バックアップおよび復元ジョブを送信し、リアルタイムのジョブステータスを取得します。クラスターの O&M エンジニアおよび開発者向けのデフォルトの権限リストには、バックアップセンターコンポーネントに必要な一部の権限がありません。プライマリアカウントまたは権限管理者がこれらの権限を付与する必要があります。
解決策
「カスタム RBAC を使用してクラスターリソースに対する操作を制限する」を参照し、バックアップセンターのオペレーターに次の ClusterRole 権限を付与します。
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: csdr-console
rules:
- apiGroups: ["csdr.alibabacloud.com","velero.io"]
resources: ['*']
verbs: ["get","create","delete","update","patch","watch","list","deletecollection"]
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["get","list"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get","list"]バックアップセンターコンポーネントのアップグレードまたはアンインストールに失敗する
問題
バックアップセンターコンポーネントのアップグレードまたはアンインストールに失敗し、csdr 名前空間が Terminating 状態のままになります。
原因
バックアップセンターコンポーネントが操作中に異常終了し、csdr 名前空間に InProgress 状態のジョブが残りました。これらのジョブの finalizers フィールドがリソースの削除を妨げ、csdr 名前空間が Terminating 状態のままになる可能性があります。
解決策
次のコマンドを実行して、csdr 名前空間が Terminating 状態にある理由を確認します。
kubectl describe ns csdrスタックしたジョブが不要であることを確認し、その
finalizersを削除します。csdr 名前空間が削除されたことを確認した後：
コンポーネントのアップグレードの場合は、バックアップセンターの migrate-controller コンポーネントを再インストールできます。
コンポーネントのアンインストールの場合は、これでコンポーネントがアンインストールされているはずです。
タスクのステータスが [Failed] になり、「internal error」エラーが返される
問題
タスクのステータスが [Failed] になり、「internal error」エラーが返されます。
原因
コンポーネントまたは基盤となるクラウドサービスで予期しない例外が発生しました。たとえば、現在のリージョンでクラウドサービスが利用できない場合があります。
解決策
エラーメッセージが「HBR backup/restore internal error」の場合は、Cloud Backup コンソールに移動して、コンテナーバックアップ機能が利用可能かどうかを確認してください。
タスクのステータスが [Failed] になり、「create cluster resources timeout」エラーが返される
問題
タスクのステータスが [Failed] になり、「create cluster resources timeout」エラーが返されます。
原因
ストレージクラス変換または復元中に、一時的な Pod、永続ボリューム要求 (PVC)、および永続ボリューム (PV) が作成されることがあります。これらのリソースが作成後も長時間利用できないままである場合、「create cluster resources timeout」エラーが返されます。
解決策
次のコマンドを実行して異常なリソースを特定し、そのイベントに基づいて原因を特定します。
kubectl -n csdr describe <applicationbackup/converttosnapshot/applicationrestore> <task-name>期待される出力：
……wait for created tmp pvc default/demo-pvc-for-convert202311151045 for convertion bound time outこれは、ストレージクラス変換に使用される PVC が長時間バインドされないままであることを示しています。PVC は
default名前空間にあり、名前はdemo-pvc-for-convert202311151045です。次のコマンドを実行して PVC のステータスを確認し、問題の原因を特定します。
kubectl -ndefault describe pvc demo-pvc-for-convert202311151045以下は、バックアップセンターで発生する一般的な問題の原因です。詳細については、「ストレージの問題のトラブルシューティング」をご参照ください。
クラスターまたはノードのリソースが不十分または異常です。
復元クラスターに必要なストレージクラスがありません。ストレージクラス変換機能を使用して、復元クラスターに既存のストレージクラスを選択し、アプリケーションを復元します。
ストレージクラスに関連付けられている基盤ストレージが利用できません。たとえば、指定されたディスクタイプが現在のゾーンでサポートされていません。
alibabacloud-cnfs-nas に関連付けられている Container Network File System (CNFS) が異常です。詳細については、「CNFS を使用して NAS ファイルシステムを管理する (推奨)」をご参照ください。
マルチゾーンクラスターでアプリケーションを復元する際に、volumeBindingMode が
Immediateに設定されているストレージクラスを選択しました。
タスクのステータスが [Failed] になり、「addon status is abnormal」エラーが返される
問題
タスクのステータスが [Failed] になり、「addon status is abnormal」エラーが返されます。
原因
csdr 名前空間のコンポーネントが異常です。
解決策
「原因 1 と解決策：csdr 名前空間のコンポーネントが異常です」をご参照ください。
タスクのステータスが [Failed] になり、「VaultError: xxx」エラーが返される
問題
バックアップ、復元、またはストレージクラス変換タスクのステータスが [Failed] になり、エラーメッセージ VaultError: backup vault is unavailable: xxx が返されます。
原因
指定された OSS バケットが存在しません。
クラスターに OSS にアクセスする権限がありません。
OSS バケットネットワークに到達できません。
解決策
OSS コンソールにログインし、バックアップボールトに関連付けられている OSS バケットが存在するかどうかを確認します。
OSS バケットが存在しない場合は、バケットを作成して再関連付けします。詳細については、「バケットの作成」をご参照ください。
クラスターが OSS にアクセスする権限を持っているかどうかを確認します。
ACK Pro マネージドクラスターの場合、クラスターのバックアップボールトに関連付けられている OSS バケットの名前が cnfs-oss-** で始まる限り、OSS 権限を設定する必要はありません。
ACK 専用クラスターまたは登録済みクラスターの場合、OSS 権限を設定する必要があります。詳細については、「migrate-controller のインストールと権限の付与」をご参照ください。
ACK マネージドクラスターで、コンソールを使用せずにコンポーネントが v1.8.0 以降にインストールまたはアップグレードされた場合、OSS 関連の権限が欠落している可能性があります。次のコマンドを実行して、クラスターが OSS にアクセスする権限を持っているかどうかを確認できます。
kubectl get secret -n kube-system | grep addon.aliyuncsmanagedbackuprestorerole.token期待される出力：
addon.aliyuncsmanagedbackuprestorerole.token Opaque 1 62d返された内容が上記の期待される出力と同じ場合、クラスターは OSS にアクセスする権限を持っています。クラスターには cnfs-oss-* 形式で名前が付けられた OSS バケットを指定するだけで済みます。
返された内容が期待される出力と異なる場合は、次のいずれかの方法で権限を付与します。
ACK 専用クラスターおよび登録済みクラスターの手順を参照して、OSS 権限を設定します。詳細については、「バックアップサービスコンポーネントのインストールと権限の設定」をご参照ください。
[承認] をクリックして、Alibaba Cloud アカウントの権限付与を完了します。この操作は、Alibaba Cloud アカウントごとに 1 回だけ実行する必要があります。
説明削除されたバックアップボールトと同じ名前のバックアップボールトを作成することはできません。また、
cnfs-oss-**形式に従わない名前の OSS バケットにバックアップボールトを関連付けることもできません。誤った名前の OSS バケットに関連付けられた既存のバックアップボールトがある場合は、別の名前で新しいバックアップボールトを作成し、cnfs-oss-**形式に従う OSS バケットに関連付ける必要があります。次のコマンドを実行して、クラスターのネットワーク構成を確認します。
kubectl get backuplocation <backuplocation-name> -n csdr -o yaml | grep network出力は次の内容のようになります。
network: internalnetwork の値が
internalの場合、バックアップボールトは内部ネットワーク経由で OSS バケットにアクセスします。network の値が
publicの場合、バックアップボールトはインターネット経由で OSS バケットにアクセスします。バックアップボールトがインターネット経由で OSS バケットにアクセスし、エラーメッセージがタイムアウトを示す場合は、クラスターがインターネットにアクセスできるかどうかを確認してください。詳細については、「既存の ACK クラスターがインターネットにアクセスできるようにする」をご参照ください。
バックアップボールトは、次のシナリオでパブリックネットワーク経由で OSS バケットにアクセスする必要があります。
クラスターと OSS バケットが異なるリージョンにデプロイされている。
現在のクラスターは ACK Edge クラスターです。
現在のクラスターは、Cloud Enterprise Network (CEN)、Express Connect、または VPN を使用して VPC に接続されていない登録済みクラスターです。別の可能性として、クラスターは VPC に接続されていますが、リージョンの内部 OSS CIDR ブロックへのルートが構成されていません。この場合、内部 OSS CIDR ブロックへのルートを構成する必要があります。
オンプレミスのデータセンターを VPC に接続する方法の詳細については、「データセンターを Alibaba Cloud に接続するために使用される方法」をご参照ください。
内部 OSS エンドポイントと仮想 IP アドレス (VIP) CIDR ブロック間のマッピングの詳細については、「バケットドメイン名を使用した OSS へのアクセス」をご参照ください。
バックアップボールトがパブリックネットワーク経由で OSS バケットにアクセスする必要がある場合は、次のコマンドを実行してアクセス方法をパブリックネットワークアクセスに変更します。次のコードでは、
<backuplocation-name>はバックアップボールトの名前を指定し、<region-id>は OSS バケットがデプロイされているリージョン (cn-hangzhou など) を指定します。kubectl patch -n csdr backuplocation/<backuplocation-name> --type='json' -p '[{"op":"add","path":"/spec/config","value":{"network":"public","region":"<region-id>"}}]' kubectl patch -n csdr backupstoragelocation/<backuplocation-name> --type='json' -p '[{"op":"add","path":"/spec/config","value":{"network":"public","region":"<region-id>"}}]'
タスクのステータスが [Failed] になり、「HBRError: check HBR vault error」エラーが返される
症状
バックアップ、復元、またはストレージクラス変換タスクのステータスが [Failed] になり、「HBRError: check HBR vault error」エラーが返されます。
原因
Cloud Backup がアクティベートされていないか、必要な権限がありません。
解決策
Cloud Backup サービスを有効にしていることを確認します。詳細については、「Cloud Backup の有効化」をご参照ください。
ご利用のクラスターが中国 (ウランチャブ)、中国 (河源)、または中国 (広州) などのリージョンにある場合は、サービスを有効にした後、Cloud Backup サービスが API Gateway にアクセスすることを承認する必要もあります。詳細については、「(オプション) ステップ 3：Cloud Backup サービスが API Gateway にアクセスすることを承認する」をご参照ください。
ご利用のクラスターが ACK 専用クラスターまたは登録済みクラスターである場合は、関連する Cloud Backup RAM 権限が付与されていることを確認してください。詳細については、「migrate-controller バックアップサービスコンポーネントのインストールと権限の設定」をご参照ください。
タスクのステータスが [Failed] になり、「HBRError: ... code: 400, Illegal request. Please modify the parameters」エラーが返される
問題
バックアップ、復元、またはストレージクラス変換タスクのステータスが [Failed] になり、「HBRError: ... code: 400, Illegal request. Please modify the parameters」エラーが返されます。
原因
失敗したタスクのクラスターが存在するリージョンの Cloud Backup サービスの ack-backup-data リポジトリが削除されました。
バックアップセンターを使用してリージョンで初めてバックアップを作成すると、コンポーネントは自動的にそのリージョンに ack-backup-data という名前のリポジトリを作成し、バックアップセンターによって作成されたバックアップを保存します。バックアップは、指定された有効期間が経過すると自動的に削除されます。
解決策
Cloud Backup サービスリポジトリが削除されると、作成されたバックアップは復元できません。以下の手順は、後続のバックアップおよび復元ジョブのために新しい Cloud Backup サービスリポジトリを作成するためにのみ使用できます。
現在のリージョンでバックアップセンターを使用しているすべてのクラスターで、次のコマンドを実行して、初期化されたバックアップボールトのレコードをクリアします。
kubectl -ncsdr delete backuplocation --all kubectl -ncsdr delete backupstoragelocation --allバックアップしたいクラスターに戻り、バックアップを作成します。コンポーネントは自動的に ack-backup-data Cloud Backup サービスリポジトリを作成し、それをバックアップボールトに関連付けます。
タスクのステータスが [Failed] になり、「hbr task finished with unexpected status: FAILED, errMsg ClientNotExist」エラーが返される
問題
バックアップ、復元、またはストレージクラス変換タスクのステータスが [Failed] になり、エラーメッセージ hbr task finished with unexpected status: FAILED, errMsg ClientNotExist が返されます。
原因
対応するノード上の Cloud Backup クライアントが異常にデプロイされています。これは、csdr 名前空間のノード上の hbr-client DaemonSet のレプリカが異常であることを意味します。
解決策
次のコマンドを実行して、クラスターに異常な hbr-client Pod が存在するかどうかを確認します。
kubectl -n csdr get pod -lapp=hbr-clientPod が異常な状態にある場合は、まず Pod の IP アドレス、メモリ、または CPU リソースの不足が原因であるかどうかを確認します。Pod のステータスが CrashLoopBackOff の場合は、次のコマンドを実行して Pod のログを表示します。
kubectl -n csdr logs -p <hbr-client-pod-name>出力に "SDKError:\n StatusCode: 403\n Code: MagpieBridgeSlrNotExist\n Message: code: 403, AliyunServiceRoleForHbrMagpieBridge doesn't exist, please create this role. " が含まれている場合は、「(オプション) ステップ 3：Cloud Backup が API Gateway にアクセスすることを承認する」を参照して、Cloud Backup に権限を付与します。
ログ出力に他の種類の SDK エラーが含まれている場合は、EC エラーコード (Error
Code) を使用してトラブルシューティングできます。詳細については、「EC エラーコードを使用した問題のトラブルシューティング」をご参照ください。
タスクが長時間 [InProgress] 状態のままになる
原因 1 と解決策：csdr 名前空間のコンポーネントが異常です
コンポーネントのステータスを確認し、異常の原因を特定します。
次のコマンドを実行して、csdr 名前空間のコンポーネントが再起動しているか、または起動できないかを確認します。
kubectl get pod -n csdr次のコマンドを実行して、コンポーネントが再起動しているか、または起動できない理由を確認します。
kubectl describe pod <pod-name> -n csdr
原因が OOM による再起動の場合
復元中にメモリ不足 (OOM) 例外が発生した場合、Pod は csdr-velero-*** であり、復元クラスターでは多数のアプリケーション (数十のプロダクション名前空間など) が実行されています。OOM 例外は、Velero がデフォルトで Informer Cache を使用して復元プロセスを高速化し、このキャッシュがメモリを消費するために発生する可能性があります。
復元するリソースの数が少ない場合、または復元中のパフォーマンスへの影響を受け入れられる場合は、次のコマンドを実行して Informer Cache 機能を無効にできます。
kubectl -nkube-system edit deploy migrate-controllermigrate-controller コンテナーの
argsにパラメーター--disable-informer-cache=trueを追加します。name: migrate-controller args: - --disable-informer-cache=trueその他の場合、またはクラスターリソースの復元速度を低下させたくない場合は、次のコマンドを実行して、対応するデプロイメントの Limit 値を調整します。
csdr-controller-***の場合、<deploy-name>はcsdr-controllerです。csdr-velero-***の場合、<deploy-name>はcsdr-veleroです。kubectl patch deploy <deploy-name> -p '{"spec":{"containers":{"resources":{"limits":"<new-limit-memory>"}}}}'
原因が「HBR 権限が構成されていないため、起動に失敗する」場合
クラスターで Cloud Backup サービスが有効になっていることを確認します。
有効になっていない場合は、Cloud Backup サービスを有効にします。詳細については、Cloud Backup をご参照ください。
Cloud Backup が有効になっている場合は、次のステップに進みます。
ACK 専用クラスターと登録済みクラスターに Cloud Backup 権限が構成されていることを確認します。
構成されていない場合は、Cloud Backup 権限を構成します。詳細については、「migrate-controller のインストールと権限の付与」をご参照ください。
構成済み：次のステップに進むことができます。
次のコマンドを実行して、Cloud Backup クライアントコンポーネントに必要なトークンが存在するかどうかを確認します。
kubectl describe <hbr-client-***>イベントエラーメッセージ couldn't find key HBR_TOKEN が返された場合、トークンがありません。問題を解決するには、次の手順を実行します。
次のコマンドを実行して、
hbr-client-***が配置されているノードを照会します。kubectl get pod <hbr-client-***> -n csdr -owide次のコマンドを実行して、対応するノードの
labels: csdr.alibabacloud.com/agent-enableをtrueからfalseに変更します。kubectl label node <node-name> csdr.alibabacloud.com/agent-enable=false --overwrite重要アプリケーションを再度バックアップおよび復元すると、トークンが自動的に作成され、hbr-client が起動します。
別のクラスターから現在のクラスターにトークンをコピーした場合、起動された hbr-client はアクティブになりません。コピーしたトークンと、このトークンによって起動された
hbr-client-*** Podを削除し、上記の手順を実行する必要があります。
原因 2 と解決策：ディスクボリュームバックアップ用にクラスターのスナップショット権限が構成されていません
ディスクボリュームがマウントされたアプリケーションでデータバックアップ機能を使用する場合、バックアップジョブが長時間 InProgress 状態のままである場合は、次のコマンドを実行して、クラスターに新しく作成された VolumeSnapshot リソースを照会します。
kubectl get volumesnapshot -n <backup-namespace>出力例：
NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT ...
<volumesnapshot-name> true <volumesnapshotcontent-name> ...すべての volumesnapshot リソースの READYTOUSE フィールドが長時間 false のままである場合は、次の手順を実行します。
ECS コンソールにログインし、ディスクスナップショット機能が有効になっているかどうかを確認します。
ディスクスナップショット機能が有効になっていない場合は、対応するリージョンで有効にします。詳細については、「スナップショットの有効化」をご参照ください。
ディスクスナップショット機能が有効になっている場合は、次のステップに進みます。
クラスターの CSI コンポーネントが期待どおりに実行されているかどうかを確認します。
kubectl -nkube-system get pod -l app=csi-provisionerディスクスナップショットを使用する権限が構成されているかどうかを確認します。
マネージドクラスター
管理権限を持つ RAM ユーザーとして RAM コンソールにログインします。
左側のナビゲーションウィンドウで、 を選択します。
[ロール] ページで、検索ボックスで AliyunCSManagedBackupRestoreRole を検索し、ロールの権限付与ポリシーに次の内容が含まれていることを確認します：
{ "Statement": [ { "Effect": "Allow", "Action": [ "hbr:CreateVault", "hbr:CreateBackupJob", "hbr:DescribeVaults", "hbr:DescribeBackupJobs2", "hbr:DescribeRestoreJobs", "hbr:SearchHistoricalSnapshots", "hbr:CreateRestoreJob", "hbr:AddContainerCluster", "hbr:DescribeContainerCluster", "hbr:CancelBackupJob", "hbr:CancelRestoreJob", "hbr:DescribeRestoreJobs2" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ecs:CreateSnapshot", "ecs:DeleteSnapshot", "ecs:DescribeSnapshotGroups", "ecs:CreateAutoSnapshotPolicy", "ecs:ApplyAutoSnapshotPolicy", "ecs:CancelAutoSnapshotPolicy", "ecs:DeleteAutoSnapshotPolicy", "ecs:DescribeAutoSnapshotPolicyEX", "ecs:ModifyAutoSnapshotPolicyEx", "ecs:DescribeSnapshots", "ecs:DescribeInstances", "ecs:CopySnapshot", "ecs:CreateSnapshotGroup", "ecs:DeleteSnapshotGroup" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "oss:PutObject", "oss:GetObject", "oss:DeleteObject", "oss:GetBucket", "oss:ListObjects", "oss:ListBuckets", "oss:GetBucketStat" ], "Resource": "acs:oss:*:*:cnfs-oss*" } ], "Version": "1" }AliyunCSManagedBackupRestoreRole ロールがない場合は、RAM クイック承認ページに移動して、AliyunCSManagedBackupRestoreRole ロールを付与します。
AliyunCSManagedBackupRestoreRole ロールは存在するが、ポリシーの内容が不完全な場合は、上記の権限をロールに付与します。詳細については、「カスタムポリシーの作成」および「RAM ロールへの権限の付与」をご参照ください。
専用クラスター
Container Service for Kubernetes (ACK) コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、対象のクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、[クラスター情報] を選択します。
[クラスター情報] ページで、[Master RAM Role] パラメーターを見つけ、右側にあるリンクをクリックします。
[権限管理] タブでは、ディスクスナップショット権限のステータスを確認できます。
k8sMasterRolePolicy-Csi-*** 権限ポリシーが存在しないか、次の権限が含まれていない場合は、次のディスクスナップショット権限ポリシーをマスター RAM ロールに付与します。詳細については、「カスタム権限ポリシーの作成」および「RAM ロールへの権限の付与」をご参照ください。
{ "Statement": [ { "Effect": "Allow", "Action": [ "hbr:CreateVault", "hbr:CreateBackupJob", "hbr:DescribeVaults", "hbr:DescribeBackupJobs2", "hbr:DescribeRestoreJobs", "hbr:SearchHistoricalSnapshots", "hbr:CreateRestoreJob", "hbr:AddContainerCluster", "hbr:DescribeContainerCluster", "hbr:CancelBackupJob", "hbr:CancelRestoreJob", "hbr:DescribeRestoreJobs2" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ecs:CreateSnapshot", "ecs:DeleteSnapshot", "ecs:DescribeSnapshotGroups", "ecs:CreateAutoSnapshotPolicy", "ecs:ApplyAutoSnapshotPolicy", "ecs:CancelAutoSnapshotPolicy", "ecs:DeleteAutoSnapshotPolicy", "ecs:DescribeAutoSnapshotPolicyEX", "ecs:ModifyAutoSnapshotPolicyEx", "ecs:DescribeSnapshots", "ecs:DescribeInstances", "ecs:CopySnapshot", "ecs:CreateSnapshotGroup", "ecs:DeleteSnapshotGroup" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "oss:PutObject", "oss:GetObject", "oss:DeleteObject", "oss:GetBucket", "oss:ListObjects", "oss:ListBuckets", "oss:GetBucketStat" ], "Resource": "acs:oss:*:*:cnfs-oss*" } ], "Version": "1" }
登録済みクラスター
ノードがすべて Alibaba Cloud Elastic Compute Service (ECS) インスタンスである登録済みクラスターのみが、ディスクスナップショット機能を使用できます。CSI ストレージプラグインをインストールする際に、関連する権限が付与されているかどうかを確認します。詳細については、「CSI コンポーネントの RAM 権限の構成」をご参照ください。
原因 3 と解決策：ディスクボリューム以外のストレージボリュームが使用されています
バックアップセンターの migrate-controller コンポーネントは、バージョン 1.7.7 以降でディスクボリュームのバックアップのリージョン間復元をサポートしています。他のボリュームタイプのバックアップはリージョン間で復元できません。OSS などのインターネットアクセスをサポートするストレージサービスを使用している場合は、静的にプロビジョニングされた PV と PVC を作成してからアプリケーションを復元できます。詳細については、「ossfs 1.0 静的プロビジョニングボリュームの使用」をご参照ください。
バックアップタスクのステータスが [Failed] になり、「backup already exists in OSS bucket」エラーが返される
問題
バックアップジョブのステータスが [Failed] になり、「backup already exists in OSS bucket」エラーが返されます。
原因
バックアップボールトに関連付けられている OSS バケットに、同じ名前のバックアップが保存されています。
バックアップが現在のクラスターで表示されない理由は次のとおりです。
進行中のバックアップジョブおよび失敗したバックアップジョブのバックアップは、他のクラスターに同期されません。
ソースバックアップクラスター以外のクラスターでバックアップを削除した場合、OSS バケット内のバックアップファイルにはラベルが付けられますが、削除されません。このラベル付きバックアップファイルは、新しく関連付けられたクラスターには同期されません。
現在のクラスターは、バックアップを保存するバックアップボールトに関連付けられていません。これは、バックアップボールトが初期化されていないことを意味します。
解決策
新しい名前でバックアップボールトを作成します。
バックアップタスクのステータスが [Failed] になり、「get target namespace failed」エラーが返される
問題
バックアップジョブのステータスが [Failed] になり、「get target namespace failed」エラーが返されます。
原因
ほとんどの場合、このエラーはスケジュールされた時間に作成されたバックアップジョブで発生します。原因は、名前空間の選択方法によって異なります。
[含める] を選択した場合、選択したすべての名前空間が削除されます。
[除外] を選択した場合、選択した名前空間はクラスターから除外されます。
解決策
バックアッププランを変更して、名前空間を選択する方法と選択した名前空間を変更します。
バックアップタスクのステータスが [Failed] になり、「velero backup process timeout」エラーが返される
問題
バックアップジョブのステータスが [Failed] になり、「velero backup process timeout」エラーが返されます。
原因
原因 1：アプリケーションバックアップのサブタスクがタイムアウトしました。サブタスクの期間は、クラスターリソースの数と API サーバーの応答遅延によって異なります。migrate-controller 1.7.7 以降では、サブタスクのデフォルトのタイムアウト期間は 60 分です。
原因 2：バックアップボールトで使用されるバケットのストレージクラスは、アーカイブ、コールドアーカイブ、またはディープコールドアーカイブです。バックアッププロセス中のデータ整合性を確保するために、バックアップセンターコンポーネントは OSS サーバー上のメタデータファイルを更新する必要があります。バックアップセンターコンポーネントは、アーカイブストレージから復元されていないファイルを更新できません。
解決策
解決策 1：バックアップクラスターのサブタスクタイムアウト期間のグローバル構成を変更します。
次のコマンドを実行して、applicationBackup に
velero_timeout_minutes構成項目を追加します。単位は分です。kubectl edit -n csdr cm csdr-configたとえば、次のコードブロックはタイムアウト期間を 100 分に設定します。
apiVersion: v1 data: applicationBackup: | ... #詳細は表示されません。 velero_timeout_minutes: 100タイムアウト期間を変更した後、次のコマンドを実行して csdr-controller を再起動し、変更を有効にします。
kubectl -n csdr delete pod -l control-plane=csdr-controller解決策 2：バックアップボールトで使用されるバケットのストレージクラスを標準に変更します。
バックアップデータをアーカイブストレージに保存する場合は、ライフサイクルルールを構成してストレージクラスを自動的に変換できます。リカバリを実行する前にデータを復元する必要があります。詳細については、「ストレージクラスの変換」をご参照ください。
バックアップタスクのステータスが [Failed] になり、「HBR backup request failed」エラーが返される
問題
バックアップジョブのステータスが [Failed] になり、「HBR backup request failed」エラーが返されます。
原因
原因 1：クラスターで使用されているストレージプラグインに互換性がありません。
原因 2：Cloud Backup は、volumeMode が Block のボリュームのバックアップをサポートしていません。詳細については、「ボリュームモード」をご参照ください。
原因 3：Cloud Backup クライアントが異常であるため、OSS ボリューム、NAS ボリューム、CPFS ボリューム、ローカルボリュームなどのファイルシステムボリュームのバックアップまたは復元ジョブがタイムアウトまたは失敗します。
解決策
解決策 1：ご利用のクラスターが Alibaba Cloud 以外の CSI ストレージプラグインを使用している場合、または永続ボリューム (PV) が NFS や LocalVolume などの一般的な Kubernetes ストレージボリュームではなく、互換性の問題が発生した場合は、してサポートを依頼してください
解決策 2：ほとんどの場合、Block モードのボリュームを必要とするのはディスクストレージのみです。ご利用のクラスターのストレージプラグインが CSI の場合、データバックアップにはデフォルトでディスクスナップショットが使用されます。ディスクスナップショットは、Block モードのボリュームのバックアップをサポートしています。ストレージプラグインの種類が正しくない場合は、ストレージプラグインを CSI に切り替え、バックアップコンポーネントを再インストールしてから、再度バックアップを実行してください。
解決策 3：次の手順を実行します。
Cloud Backup コンソールにログインします。
左側のナビゲーションウィンドウで、[バックアップ] > コンテナーのバックアップ を選択します。[コンテナーバックアップ] ページで、[バックアップジョブ] タブをクリックします。
上部のナビゲーションバーで、リージョンを選択します。
[バックアップジョブ] タブで、検索ボックスの横にあるドロップダウンメニューをクリックし、[ジョブ名] を選択し、次に
<backup-name>-hbrを検索して、バックアップジョブのステータスとその理由を確認します。 詳細については、「ACK クラスターをバックアップする」をご参照ください。説明ストレージクラス変換またはバックアップジョブを照会する場合は、対応するバックアップ名を検索してください。
バックアップタスクのステータスが [Failed] になり、「hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST」エラーが返される
問題
バックアップジョブのステータスが [Failed] になり、「hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST」エラーが返されます。
原因
他のクラウドベンダーの CSI、または NFS や Ceph などの自己管理ストレージタイプの場合：
ハイブリッドクラウドシナリオでは、バックアップセンターはデフォルトで標準の Kubernetes ボリュームマウントパスをデータバックアップパスとして使用します。たとえば、標準の CSI ストレージドライバーの場合、デフォルトのマウントパスは
/var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mountです。NFS や FlexVolume など、Kubernetes が公式にサポートしているストレージドライバーにも同じことが当てはまります。この場合、
/var/lib/kubeletはデフォルトの kubelet ルートパスです。Kubernetes クラスターでこのパスを変更すると、Cloud Backup はバックアップが必要なデータにアクセスできなくなる可能性があります。HostPath ストレージタイプの場合：
HostPath ストレージは、kubelet ルートパスの下にマウントパスを作成しません。代わりに、Pod は指定されたノードパスを直接マウントします。デフォルトでは、バックアップコンポーネントはノードパスからデータを読み取ることができず、バックアップが失敗します。
解決策
他のクラウドベンダーの CSI、または NFS や Ceph などの自己管理ストレージタイプの場合：
ボリュームがマウントされているノードにログインし、次の手順を実行して問題をトラブルシューティングします。
ノードの kubelet ルートパスが変更されているかどうかを確認します
次のコマンドを実行して、kubelet 起動コマンドを照会します
ps -elf | grep kubelet起動コマンドに
--root-dirパラメーターが含まれている場合、このパラメーターの値が kubelet ルートパスです。起動コマンドに
--configパラメーターが含まれている場合、このパラメーターの値は kubelet 構成ファイルです。ファイルにroot-dirフィールドが含まれている場合、このフィールドの値が kubelet ルートパスです。起動コマンドにルートパス情報が含まれていない場合は、kubelet サービス起動ファイル
/etc/systemd/system/kubelet.serviceの内容を照会します。ファイルに EnvironmentFile フィールドが含まれている場合、たとえば：EnvironmentFile=-/etc/kubernetes/kubelet環境変数構成ファイルは
/etc/kubernetes/kubeletです。構成ファイルの内容を照会します。ファイルに次の内容が含まれている場合：ROOT_DIR="--root-dir=/xxx"kubelet ルートパスは /xxx です。
変更が見つからない場合、kubelet ルートパスはデフォルトパス
/var/lib/kubeletです。
次のコマンドを実行して、kubelet ルートパスが別のパスへのシンボリックリンクであるかどうかを確認します。
ls -al <root-dir>出力が以下の内容と類似している場合：
lrwxrwxrwx 1 root root 26 Dec 4 10:51 kubelet -> /var/lib/container/kubelet実際のルートパスは
/var/lib/container/kubeletです。対象のストレージボリュームのデータがルートパスの下に存在することを確認します。
ボリュームマウントパス
<root-dir>/pods/<pod-uid>/volumesが存在し、対象タイプのストレージボリュームのサブパスがそのパスの下に存在することを確認します。たとえば、kubernetes.io~csiやkubernetes.io~nfsなどです。環境変数
KUBELET_ROOT_PATH = /var/lib/container/kubelet/podsをcsdr/csdr-controllerステートレスアプリケーションに追加します。/var/lib/container/kubeletは、構成とシンボリックリンクを照会して取得した実際の kubelet ルートパスです。
HostPath ストレージタイプの場合：
チケットを送信してください。
バックアップタスクのステータスが [Failed] になり、「check backup files in OSS bucket failed」、「upload backup files to OSS bucket failed」、または「download backup files from OSS bucket failed」エラーが返される
問題
バックアップジョブのステータスが [Failed] になり、「upload backup files to OSS bucket failed」エラーが返されます。
原因
コンポーネントがバックアップボールトに関連付けられた OSS バケット内のバックアップファイルをチェック、アップロード、またはダウンロードするときに、OSS サーバーがエラーを返します。この問題は、次のいずれかの原因で発生する可能性があります。
原因 1：OSS バケットでデータ暗号化が有効になっていますが、関連する KMS 権限が付与されていません。
原因 2：ACK 専用クラスターおよび登録済みクラスターのコンポーネントをインストールして権限を構成する際に、一部の読み取りおよび書き込み権限がありません。
原因 3：ACK 専用クラスターおよび登録済みクラスターの権限を構成するために使用される RAM ユーザーの認証資格情報が取り消されました。
解決策
解決策 1：「バックアップセンターは関連付けられた OSS バケットのデータ暗号化をサポートしていますか？サーバー側暗号化に Key Management Service (KMS) を使用する権限を付与する方法は？」をご参照ください。
解決策 2：権限を構成するために使用される RAM ユーザーの権限ポリシーを確認します。コンポーネントに必要な権限ポリシーの詳細については、「ステップ 1：権限の構成」をご参照ください。
解決策 3：権限を構成するために使用される RAM ユーザーの認証資格情報が有効になっているかどうかを確認します。取り消されている場合は、新しい認証資格情報を取得し、csdr 名前空間の Secret
alibaba-addon-secretの内容を更新します。次に、次の操作を実行してコンポーネントを再起動します。kubectl -nkube-system delete pod -lapp=migrate-controller
バックアップタスクのステータスが [PartiallyFailed] になり、「PROCESS velero partially completed」エラーが返される
問題
バックアップジョブのステータスが [PartiallyFailed] になり、「PROCESS velero partially completed」エラーが返されます。
原因
velero コンポーネントを使用してアプリケーション (クラスター内のリソース) をバックアップすると、コンポーネントは一部のリソースのバックアップに失敗します。
解決策
次のコマンドを実行して、バックアップに失敗したリソースと失敗の原因を特定します。
kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe backup <backup-name>出力の Errors および Warnings フィールドの情報に基づいて問題を修正します。
失敗の直接的な原因が表示されない場合は、次のコマンドを実行して関連する例外ログを取得します。
kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero backup logs <backup-name>バックアップタスクのステータスが [PartiallyFailed] になり、「PROCESS hbr partially completed」エラーが返される
問題
バックアップジョブのステータスが [PartiallyFailed] になり、エラーメッセージ 「PROCESS hbr partially completed」 が返されます。
原因
Cloud Backup を使用して OSS ボリューム、NAS ボリューム、CPFS ボリューム、ローカルボリュームなどのファイルシステムボリュームをバックアップすると、Cloud Backup は一部のリソースのバックアップに失敗します。この問題は、次のいずれかの原因で発生する可能性があります。
原因 1：一部のボリュームで使用されているストレージプラグインがサポートされていません。
原因 2：Cloud Backup はデータ整合性を保証しません。バックアップ中にファイルが削除されると、バックアップが失敗する可能性があります。
解決策
Cloud Backup コンソールにログインします。
左側のナビゲーションウィンドウで、[バックアップ] > コンテナーのバックアップ を選択します。[コンテナーバックアップ] ページで、[バックアップジョブ] タブをクリックします。
上部のナビゲーションバーで、リージョンを選択します。
[バックアップジョブ] タブで、検索ボックスの横にあるドロップダウンメニューをクリックし、[ジョブ名] を選択し、
<backup-name>-hbrを検索して、永続ボリュームのバックアップが失敗した、または部分的に失敗した理由を特定します。詳細については、「ACK クラスターをバックアップする」をご参照ください。
ストレージクラス変換タスクのステータスが [Failed] になり、「storageclass xxx not exists」エラーが返される
問題
ストレージクラス変換タスクのステータスが [Failed] になり、「storageclass xxx not exists」エラーが返されます。
原因
ストレージクラス変換用に選択したターゲットストレージクラスが現在のクラスターに存在しません。
解決策
次のコマンドを実行して、ストレージクラス変換タスクをリセットします。
cat << EOF | kubectl apply -f - apiVersion: csdr.alibabacloud.com/v1beta1 kind: DeleteRequest metadata: name: reset-convert namespace: csdr spec: deleteObjectName: "<backup-name>" deleteObjectType: "Convert" EOF現在のクラスターに目的のストレージクラスを作成します。
復元ジョブを再度実行し、ストレージクラス変換を構成します。
ストレージクラス変換タスクのステータスが [Failed] になり、「only support convert to storageclass with CSI diskplugin or nasplugin provisioner」エラーが返される
問題
ストレージクラス変換タスクのステータスが [Failed] になり、エラーメッセージ 「only support convert to storageclass with CSI diskplugin or nasplugin provisioner」 が返されます。
原因
ストレージクラス変換用に選択したターゲットストレージクラスは、Alibaba Cloud CSI ディスクボリュームまたは NAS ボリュームではありません。
解決策
現在のバージョンでは、デフォルトでディスク、NAS、OSS タイプのスナップショット作成とリカバリのみをサポートしています。他のリカバリ要件がある場合は、してサポートにお問い合わせください
OSS などのパブリックネットワークアクセスをサポートするストレージサービスを使用している場合は、静的にプロビジョニングされた PV と PVC を作成し、ストレージクラス変換ステップなしでアプリケーションを復元できます。詳細については、「ossfs 1.0 静的プロビジョニングボリュームの使用」をご参照ください。
ストレージクラス変換タスクのステータスが [Failed] になり、「current cluster is multi-zoned」エラーが返される
問題
ストレージクラス変換タスクのステータスが [Failed] になり、「current cluster is multi-zoned」エラーが返されます。
原因
現在のクラスターはマルチゾーンクラスターです。ディスクタイプのストレージクラスに変換する場合、ターゲットストレージクラスの volumeBindingMode は Immediate です。マルチゾーンクラスターでこのタイプのストレージクラスを使用すると、永続ボリュームが作成された後、Pod を指定されたノードにスケジュールできず、Pending 状態のままになります。volumeBindingMode フィールドの詳細については、「ストレージクラス」をご参照ください。
解決策
次のコマンドを実行して、ストレージクラス変換タスクをリセットします。
cat << EOF | kubectl apply -f - apiVersion: csdr.alibabacloud.com/v1beta1 kind: DeleteRequest metadata: name: reset-convert namespace: csdr spec: deleteObjectName: "<backup-name>" deleteObjectType: "Convert" EOFディスクストレージクラスに変換する場合：
コンソールを使用する場合は、[alicloud-disk] を選択します。[alicloud-disk] のデフォルトのストレージクラスは [alicloud-disk-topology-alltype] です。
コマンドラインを使用する場合は、alicloud-disk-topology-alltype タイプを選択します。alicloud-disk-topology-alltype は、CSI ストレージプラグインによって提供されるデフォルトのストレージクラスです。volumeBindingMode を WaitForFirstConsumer に設定することもできます。
復元ジョブを再度実行し、ストレージクラス変換を構成します。
復元タスクのステータスが [Failed] になり、「multi-node writing is only supported for block volume」エラーが返される
問題
復元またはストレージクラス変換タスクのステータスが [Failed] になり、エラーメッセージ 「multi-node writing is only supported for block volume. For Kubernetes users, if unsure, use ReadWriteOnce access mode in PersistentVolumeClaim for disk volume」 が返されます。
原因
ディスクが別のノードにマウントされたときに強制的にディスクがデタッチされるリスクを防ぐために、CSI はマウント中にディスクボリュームの AccessModes 構成をチェックし、ReadWriteMany または ReadOnlyMany の使用を禁止します。
バックアップ対象のアプリケーションは、AccessMode が ReadWriteMany または ReadOnlyMany のボリュームをマウントします。これは、OSS や NAS など、複数のマウントをサポートするネットワークストレージで一般的です。アプリケーションをデフォルトで複数のマウントをサポートしない Alibaba Cloud ディスクストレージに復元すると、CSI が上記のエラーを返す可能性があります。
具体的には、次の 3 つのシナリオでこのエラーが発生する可能性があります。
シナリオ 1：バックアップクラスターの CSI バージョンが古いか、クラスターが FlexVolume ストレージプラグインを使用しています。古い CSI バージョンでは、マウント中に Alibaba Cloud ディスクボリュームの AccessModes フィールドがチェックされません。これにより、元のディスクボリュームが新しい CSI バージョンのクラスターで復元されるときにエラーが報告されます。
シナリオ 2：バックアップボリュームで使用されるカスタムストレージクラスが復元クラスターに存在しません。特定の照合ルールに従って、ボリュームは新しいクラスターでデフォルトで Alibaba Cloud ディスクボリュームとして復元されます。
シナリオ 3：復元中に、ストレージクラス変換機能を使用して、バックアップボリュームを Alibaba Cloud ディスクボリュームとして復元するように手動で指定します。
解決策
シナリオ 1：v1.8.4 以降、バックアップコンポーネントはディスクボリュームの AccessModes フィールドを ReadWriteOnce に自動変換することをサポートしています。バックアップセンターコンポーネントをアップグレードしてから、アプリケーションを再度復元してください。
シナリオ 2：宛先クラスターのコンポーネントによるストレージクラスの自動復元は、データにアクセスできなくなったり、データが上書きされたりするリスクがあります。復元前に宛先クラスターに同じ名前のストレージクラスを作成するか、ストレージクラス変換機能を使用して復元中に使用するストレージクラスを指定してください。
シナリオ 3：ネットワークストレージボリュームをディスクボリュームとして復元する場合は、convertToAccessModes パラメーターを構成して AccessModes を ReadWriteOnce に変換します。詳細については、「convertToAccessModes：ターゲット AccessModes のリスト」をご参照ください。
復元タスクのステータスが [Failed] になり、「only disk type PVs support cross-region restore in current version」エラーが返される
問題
復元ジョブのステータスは失敗となり、エラーメッセージ "only disk type PVs support cross-region restore in current version" が返されます。
原因
migrate-controller 1.7.7 以降のバージョンでは、ディスクボリュームのバックアップはリージョン間で復元できます。他のボリュームタイプのバックアップはリージョン間で復元できません。
解決策
OSS などのインターネットアクセスをサポートするストレージサービスを使用している場合は、静的にプロビジョニングされた PV と PVC を作成してからアプリケーションを復元できます。詳細については、「ossfs 1.0 静的プロビジョニングボリュームの使用」をご参照ください。
復元タスクのステータスが [Failed] になり、「ECS snapshot cross region request failed」エラーが返される
問題
復元ジョブのステータスが [Failed] になり、「ECS snapshot cross region request failed」エラーが返されます。
原因
migrate-controller 1.7.7 以降のバージョンでは、ディスクボリュームのバックアップはリージョン間で復元できますが、ECS ディスクスナップショットを使用する権限が付与されていません。
解決策
ご利用のクラスターが ACK 専用クラスターまたは ECS インスタンスにデプロイされた自己管理 Kubernetes クラスターに接続されている登録済みクラスターである場合は、ECS ディスクスナップショットを使用する権限を付与する必要があります。詳細については、「登録済みクラスター」をご参照ください。
復元タスクのステータスが [Failed] になり、「accessMode of PVC xxx is xxx」エラーが返される
問題
復元ジョブのステータスが [Failed] になり、「accessMode of PVC xxx is xxx」エラーが返されます。
原因
復元するディスクボリュームの AccessMode が ReadOnlyMany (読み取り専用マルチマウント) または ReadWriteMany (読み書きマルチマウント) に設定されています。
ディスクボリュームを復元すると、新しいボリュームは CSI を使用してマウントされます。現在のバージョンの CSI を使用する場合は、次の項目に注意してください。
multiAttach機能が有効になっているボリュームのみが複数のインスタンスにマウントできます。VolumeModeがFilesystem(ext4 や xfs などのファイルシステムを使用してマウント) に設定されているボリュームは、読み取り専用モードでのみ複数のインスタンスにマウントできます。
ディスクストレージの詳細については、「動的にプロビジョニングされたディスクボリュームの使用」をご参照ください。
解決策
ストレージクラス変換機能を使用して、OSS や NAS ボリュームなどの複数のマウントをサポートするボリュームをディスクボリュームに変換し、アプリケーションの異なるレプリカがボリューム上のデータを正常に共有できるようにしたい場合は、新しい復元ジョブを作成し、ストレージクラス変換のターゲットタイプとして
alibabacloud-cnfs-nasを選択することを推奨します。これにより、CNFS によって管理される NAS ボリュームが使用されます。詳細については、「CNFS を使用して NAS ファイルシステムを管理する (推奨)」をご参照ください。ディスク永続ボリュームをバックアップしたときの CSI バージョンが低く (
AccessMode検出なし)、バックアップされた永続ボリューム自体が現在の CSI 作成要件を満たしていない場合は、動的にプロビジョニングされたディスクボリュームを使用して元のワークロードを変換し、他のノードへのスケジューリング時に強制的にディスクがデタッチされる脅威を回避することを優先する必要があります。
復元タスクのステータスは [Completed] だが、一部のリソースが復元クラスターに作成されない
問題
復元ジョブのステータスは [Completed] ですが、一部のリソースは復元クラスターに作成されません。
原因
原因 1：リソースがバックアップされていませんでした。
原因 2：構成に基づいて復元中にリソースが除外されました。
原因 3：アプリケーション復元サブタスクが部分的に失敗しました。
原因 4：リソースは正常に復元されましたが、
ownerReferences構成または他のビジネスロジックのためにリサイクルされました。
解決策
解決策 1：
次のコマンドを実行して、バックアップの詳細を表示します。
kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe backup <backup-name> --detailsターゲットリソースがバックアップされたかどうかを確認します。ターゲットリソースがバックアップされていない場合は、バックアップジョブで指定された名前空間、リソース、またはその他の構成のために除外されたかどうかを確認し、再度リソースをバックアップします。デフォルトでは、選択されていない名前空間で実行中のアプリケーション (Pod) のクラスターレベルのリソースはバックアップされません。すべてのクラスターレベルのリソースをバックアップする場合は、「クラスターレベルのバックアップ」をご参照ください。
解決策 2：
ターゲットリソースが復元されなかった場合は、復元ジョブで指定された名前空間、リソース、またはその他の構成のために除外されたかどうかを確認し、再度リソースを復元します。
解決策 3：
次のコマンドを実行して、復元に失敗したリソースと失敗の原因を特定します。
kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe restore <restore-name> 出力の Errors および Warnings フィールドのプロンプトに従って問題を修正します。
解決策 4：
対応するリソースの監査ログを確認して、作成後に異常に削除されたかどうかを判断します。
FlexVolume を使用するクラスターの migrate-controller コンポーネントが起動できない
migrate-controller コンポーネントは、FlexVolume を使用するクラスターをサポートしていません。バックアップセンター機能を使用するには、次のいずれかの方法を使用して FlexVolume から CSI に移行します。
csi-compatible-controller コンポーネントを使用した FlexVolume から CSI への移行
その他の場合は、DingTalk ユーザーグループ (グループ ID：35532895) に参加してご相談ください。
FlexVolume から CSI への移行中に FlexVolume クラスターのアプリケーションをバックアップし、CSI クラスターで復元するには、「バックアップセンターを使用して古いバージョンの Kubernetes クラスターでアプリケーションを移行する」をご参照ください。
バックアップボールトの変更は可能か
いいえ、バックアップボールトは変更できません。変更するには、現在のバックアップボールトを削除し、別の名前で新しいバックアップボールトを作成する必要があります。
バックアップボールトは共有リソースであるため、いつでも [バックアップ] または [復元] 状態になる可能性があります。ボールトのパラメーターを変更すると、アプリケーションのバックアップまたは復元中にシステムが必要なデータを見つけられなくなる可能性があります。したがって、バックアップボールトを変更したり、同じ名前で新しいバックアップボールトを作成したりすることはできません。
「cnfs-oss-*」形式以外の名前の OSS バケットにバックアップボールトを関連付けることは可能か
ACK 専用クラスターおよび登録済みクラスター以外のクラスターでは、バックアップセンターコンポーネントは、デフォルトで cnfs-oss-* 形式の名前の OSS バケットに対する読み取りおよび書き込み権限を持っています。バックアップがバケット内の既存のデータを上書きするのを防ぐために、バックアップセンター用に cnfs-oss-* 形式の名前を持つ専用の OSS バケットを作成することを推奨します。
「cnfs-oss-*」形式ではない名前の OSS バケットにバックアップボールトを関連付ける場合は、コンポーネントの権限を構成する必要があります。詳細については、「ACK 専用クラスター」をご参照ください。
権限を付与した後、次のコマンドを実行してバックアップサービスコンポーネントを再起動します。
kubectl -n csdr delete pod -l control-plane=csdr-controller kubectl -n csdr delete pod -l component=csdr「cnfs-oss-*」形式ではない名前の OSS バケットに関連付けられたバックアップボールトを作成した場合は、接続性チェックが完了し、ステータスが [Available] に変わるまで待ってから、アプリケーションのバックアップまたは復元を試みてください。接続性チェックの間隔は約 5 分です。次のコマンドを実行して、バックアップボールトのステータスを照会できます。
kubectl -n csdr get backuplocation期待される出力：
NAME PHASE LAST VALIDATED AGE a-test-backuplocation Available 7s 6d1h
バックアッププラン作成時のバックアップサイクルの指定方法
バックアップサイクルは、1 4 * * * などの Crontab 式、または 6h30m などの間隔ベースのバックアップをサポートしています。これは、6 時間 30 分ごとにバックアップが作成されることを意味します。
以下に Crontab 式の解析方法を説明します。オプションの値は標準の Crontab 式と同じですが、分のオプション値は 0 から 59 です。* は、指定されたフィールドで利用可能な任意の値を示します。Crontab 式の例：
1 4 * * *：毎日午前 4 時 1 分にバックアップを作成します。0 2 15 * 1：毎月 15 日の午前 2 時にバックアップを作成します。
* * * * *
| | | | |
| | | | ·----- 曜日 (0 - 6) (日～土)
| | | ·-------- 月 (1 - 12)
| | .----------- 日 (1 - 31)
| ·-------------- 時 (0 - 23)
·----------------- 分 (0 - 59)
復元ジョブ実行時にリソースの YAML ファイルに加えられる変更
リソースを復元すると、リソースの YAML ファイルに次の変更が加えられます。
変更 1：
ディスクボリュームのサイズが 20 GiB 未満の場合、ボリュームサイズは 20 GiB に変更されます。
変更 2：
サービスはタイプに基づいて復元されます。
NodePort サービス：デフォルトでは、クラスター間でサービスを復元するときにサービスポートは保持されます。
LoadBalancer サービス：ExternalTrafficPolicy が Local に設定されている場合、HealthCheckNodePort はデフォルトでランダムなポートを使用します。ポート番号を保持したい場合は、復元ジョブを作成するときに
spec.preserveNodePorts: trueを設定します。バックアップクラスターに既存の Server Load Balancer (SLB) インスタンスを使用するサービスを復元する場合、復元されたサービスは同じ SLB インスタンスを使用し、デフォルトでリスナーを無効にします。SLB コンソールにログインしてリスナーを構成する必要があります。
バックアップクラスターで CCM によって管理されている SLB インスタンスを持つサービスを復元する場合、CCM は新しい SLB インスタンスを作成します。詳細については、「サービスロードバランサーの構成に関する考慮事項」をご参照ください。
バックアップリソースの表示方法
クラスターアプリケーションバックアップのリソース
クラスター内の YAML ファイルは、バックアップボールトに関連付けられた OSS バケットに保存されます。次のいずれかの方法でバックアップリソースを表示できます。
バックアップファイルが同期されているクラスターで次のコマンドを実行して、バックアップリソースを表示します。
kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1 kubectl -n csdr exec -it csdr-velero-xxx -c velero -- ./velero describe backup <backup-name> --detailsこれは Container Service コンソールで表示できます。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] を選択します。
[クラスター] ページで、対象のクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、 を選択します。
[アプリケーションバックアップ] ページで、[バックアップレコード] タブをクリックします。[バックアップレコード] 列で、バックアップレコードをクリックします。
ディスクボリュームバックアップのリソース
ECS コンソールにログインします。
左側のナビゲーションウィンドウで、 を選択します。
上部のナビゲーションバーで、管理するリソースのリージョンとリソースグループを選択します。
[スナップショット] ページで、ディスク ID に基づいてスナップショットを照会します。
非ディスクボリュームバックアップのリソース
Cloud Backup コンソールにログインします。
左側のナビゲーションウィンドウで、 を選択します。
上部のナビゲーションバーで、リージョンを選択します。
クラスターバックアップの基本情報を表示します。
クラスター：バックアップおよび保護されているクラスターのリスト。ACK クラスター ID をクリックして、保護されている永続ボリューム要求 (PVC) を表示します。PVC の詳細については、「永続ボリューム要求 (PVC)」をご参照ください。
クライアント状態 が異常な場合、Cloud Backup は ACK クラスターで期待どおりに実行されていません。ACK コンソールの DaemonSets ページに移動して、問題をトラブルシューティングしてください。
バックアップジョブ：バックアップジョブのステータス。
古い Kubernetes バージョンを実行しているクラスターでアプリケーションをバックアップし、新しい Kubernetes バージョンを実行しているクラスターでアプリケーションを復元することは可能か
はい、サポートされています。
デフォルトでは、リソースをバックアップするときに、リソースでサポートされているすべての API バージョンがバックアップされます。たとえば、Kubernetes 1.16 を実行しているクラスターのデプロイメントは、extensions/v1beta1、apps/v1beta1、apps/v1beta2、および apps/v1 をサポートします。デプロイメントをバックアップすると、デプロイメントの作成時に使用したバージョンに関係なく、バックアップボールトには 4 つすべての API バージョンが保存されます。API バージョンの変換には KubernetesConvert 機能が使用されます。
リソースを復元するときは、復元クラスターが推奨する API バージョンが復元に使用されます。たとえば、Kubernetes 1.28 を実行しているクラスターで上記のデプロイメントを復元し、推奨される API バージョンが apps/v1 の場合、復元されたデプロイメントは apps/v1 を使用します。
両方のクラスターでサポートされている API バージョンがない場合は、リソースを手動でデプロイする必要があります。たとえば、Kubernetes 1.16 を実行しているクラスターの Ingress は、extensions/v1beta1 と networking.k8s.io/v1beta1 をサポートします。これらのクラスターの Ingress は networking.k8s.io/v1 のみをサポートするため、Kubernetes 1.22 以降を実行しているクラスターに Ingress を復元することはできません。Kubernetes API バージョンの移行の詳細については、公式ドキュメントをご参照ください。API バージョンの互換性の問題により、バックアップセンターを使用して、新しい Kubernetes バージョンのクラスターから古い Kubernetes バージョンのクラスターにアプリケーションを移行しないことを推奨します。また、Kubernetes 1.16 より前のバージョンのクラスターから新しい Kubernetes バージョンのクラスターにアプリケーションを移行しないことも推奨します。
復元中にトラフィックは自動的に SLB インスタンスに切り替わるか
いいえ、切り替わりません。
サービスはタイプに基づいて復元されます。
NodePort サービス：デフォルトでは、クラスター間でサービスを復元するときにサービスポートは保持されます。
LoadBalancer サービス：ExternalTrafficPolicy が Local に設定されている場合、HealthCheckNodePort はデフォルトでランダムなポートを使用します。ポート番号を保持したい場合は、復元ジョブを作成するときに
spec.preserveNodePorts: trueを設定します。バックアップクラスターに既存の Server Load Balancer (SLB) インスタンスを使用するサービスを復元する場合、復元されたサービスは同じ SLB インスタンスを使用し、デフォルトでリスナーを無効にします。SLB コンソールにログインしてリスナーを構成する必要があります。
バックアップクラスターで CCM によって管理されている SLB インスタンスを持つサービスを復元する場合、CCM は新しい SLB インスタンスを作成します。詳細については、「サービスロードバランサーの構成に関する考慮事項」をご参照ください。
デフォルトでは、リスナーが無効になった後、または新しい SLB インスタンスが使用された後、トラフィックは自動的に新しい SLB インスタンスに切り替わりません。他のクラウドサービスまたはサードパーティのサービスディスカバリを使用していて、自動サービスディスカバリがトラフィックを新しい SLB インスタンスに切り替えることを望まない場合は、バックアップ中にサービスリソースを除外し、トラフィックを切り替える必要があるときに手動でデプロイできます。
csdr、ack-csi-fuse、kube-system、kube-public、および kube-node-lease 名前空間のリソースがデフォルトでバックアップされない理由
csdr はバックアップセンターの名前空間です。この名前空間を直接バックアップおよび復元すると、復元クラスターでコンポーネントが機能しなくなります。さらに、バックアップセンターにはバックアップ同期ロジックがあるため、バックアップを新しいクラスターに手動で移行する必要はありません。
ack-csi-fuse は CSI ストレージコンポーネントの名前空間であり、CSI によって維持される FUSE クライアント Pod を実行するために使用されます。新しいクラスターでストレージを復元すると、新しいクラスターの CSI は自動的に対応するクライアントに同期されます。この名前空間を手動でバックアップおよび復元する必要はありません。
kube-system、kube-public、および kube-node-lease は、Kubernetes クラスターのデフォルトのシステム名前空間です。クラスターのパラメーターと構成の違いにより、これらの名前空間をクラスター間で復元することはできません。さらに、バックアップセンターはアプリケーションのバックアップと復元に使用されます。復元ジョブを実行する前に、復元クラスターにシステムコンポーネントをインストールして構成する必要があります。たとえば、次のようなものです。
Container Registry パスワードなしのイメージプルコンポーネント：復元クラスターで acr-configuration に権限を付与して構成する必要があります。
ALB Ingress コンポーネント：ALBConfig を構成する必要があります。
kube-system 名前空間のシステムコンポーネントを新しいクラスターに直接バックアップすると、新しいクラスターでシステムコンポーネントが実行できなくなる可能性があります。
バックアップセンターは ECS ディスクスナップショットを使用してディスクボリュームをバックアップするか。デフォルトのスナップショットタイプは何か
次のシナリオでは、バックアップセンターはデフォルトで ECS ディスクスナップショットを使用してディスクボリュームをバックアップします。
クラスターは ACK マネージドクラスターまたは ACK 専用クラスターです。
クラスターは Kubernetes 1.18 以降を実行し、CSI 1.18 以降を使用しています。
他のシナリオでは、バックアップセンターはデフォルトで Cloud Backup を使用してディスクデータをバックアップします。
バックアップセンターによって作成されたディスクスナップショットは、デフォルトでインスタントアクセス機能が有効になっています。ディスクスナップショットの有効期間は、デフォルトでバックアップ構成で指定された有効期間と同じです。2023 年 10 月 12 日 11:00 以降、Alibaba Cloud はすべてのリージョンでスナップショットのインスタントアクセスストレージまたはスナップショットのインスタントアクセス操作に対して課金しなくなりました。詳細については、「インスタントアクセス機能の使用」をご参照ください。
バックアップから作成された ECS ディスクスナップショットの有効期間が、バックアップ構成で指定された有効期間と異なる理由
ディスクスナップショットの作成は、クラスターの csi-provisioner コンポーネントまたは managed-csiprovisioner コンポーネントに依存します。csi-provisioner コンポーネントのバージョンが 1.20.6 より前の場合、VolumeSnapshots を作成するときに有効期間を指定したり、スナップショットのインスタントアクセス機能を有効にしたりすることはできません。この場合、バックアップ構成の有効期間はディスクスナップショットに影響しません。
したがって、ディスクボリュームにボリュームデータバックアップ機能を使用する場合は、csi-provisioner コンポーネントを 1.20.6 以降にアップグレードする必要があります。
csi-provisioner をこのバージョンにアップグレードできない場合は、次の方法でデフォルトのスナップショット有効期間を構成できます。
バックアップセンターコンポーネント migrate-controller を v1.7.10 以降に更新します。
次のコマンドを実行して、retentionDays が 30 の VolumeSnapshotClass がクラスターに存在するかどうかを確認します。
kubectl get volumesnapshotclass csdr-disk-snapshot-with-default-ttlVolumeSnapshotClass が存在しない場合は、次の YAML を使用して csdr-disk-snapshot-with-default-ttl という名前の VolumeSnapshotClass を作成できます。
VolumeSnapshotClass が存在する場合は、デフォルトの csdr-disk-snapshot-with-default-ttl VolumeSnapshotClass の
retentionDaysパラメーターを 30 に設定します。apiVersion: snapshot.storage.k8s.io/v1 deletionPolicy: Retain driver: diskplugin.csi.alibabacloud.com kind: VolumeSnapshotClass metadata: name: csdr-disk-snapshot-with-default-ttl parameters: retentionDays: "30"
構成が完了すると、クラスターで作成されたすべてのディスクボリュームバックアップは、
retentionDaysフィールドと同じ有効期間を持つディスクスナップショットを作成します。重要バックアップから作成された ECS ディスクスナップショットの有効期間をバックアップ構成で指定された有効期間と同じにしたい場合は、csi-provisioner コンポーネントを 1.20.6 以降にアップグレードすることを推奨します。
ボリュームデータバックアップとは何か、また、アプリケーションのバックアップ時にボリュームをバックアップする必要があるシナリオ
ボリュームデータバックアップとは何か
ボリュームデータは、ECS ディスクスナップショットまたは Cloud Backup サービスを使用してクラウドストレージにバックアップされます。アプリケーションを復元すると、データは復元されたアプリケーションが使用するために新しいディスクまたは NAS ファイルシステムに保存されます。復元されたアプリケーションと元のアプリケーションはデータソースを共有せず、互いに影響しません。
データをコピーする必要がない場合、または共有データソースの要件がある場合は、ボリュームデータをバックアップしないことを選択できます。この場合、バックアップの除外リソースリストに PVC または PV リソースが含まれていないことを確認してください。復元中、ボリュームは元の YAML ファイルに基づいて新しいクラスターにデプロイされます。
ボリュームをバックアップする必要があるシナリオ
ディザスタリカバリとバージョンレコード。
ストレージタイプはディスクボリュームです。なぜなら、基本ディスクは単一のノードにのみマウントできるからです。
リージョン間のバックアップと復元を実装したい場合。ほとんどの場合、OSS 以外のストレージタイプはリージョン間のアクセスをサポートしていません。
バックアップアプリケーションと復元アプリケーションの間でデータを分離したい場合。
バックアップクラスターと復元クラスターのストレージプラグインまたはバージョンが大幅に異なり、YAML ファイルを直接復元できない場合。
ステートフルアプリケーションのボリュームをバックアップしない場合のリスク
ステートフルアプリケーションをバックアップするときにボリュームをバックアップしない場合、復元中に次の動作が発生します。
再利用ポリシーが Delete のボリュームの場合：
初めて PVC をデプロイする場合と同様に、復元クラスターに対応するストレージクラスがある場合、CSI は自動的に新しい PV を作成します。たとえば、ディスクストレージの場合、新しい空のディスクが復元されたアプリケーションにマウントされます。ストレージクラスが指定されていない静的ボリュームの場合、または復元クラスターに対応するストレージクラスがない場合、復元された PVC と Pod は、対応する PV またはストレージクラスを手動で作成するまで Pending 状態のままになります。
再利用ポリシーが Retain のボリュームの場合：
復元中、リソースは元の YAML ファイルに基づいて PV が先、次に PVC の順で復元されます。NAS や OSS など、複数のマウントをサポートするストレージの場合、元のファイルシステムまたはバケットを直接再利用できます。ディスクの場合、強制的にディスクがデタッチされるリスクがあります。
次のコマンドを実行して、ボリュームの再利用ポリシーを照会できます。
kubectl get pv -o=custom-columns=CLAIM:.spec.claimRef.name,NAMESPACE:.spec.claimRef.namespace,NAME:.metadata.name,RECLAIMPOLICY:.spec.persistentVolumeReclaimPolicy期待される出力：
CLAIM NAMESPACE NAME RECLAIMPOLICY
www-web-0 default d-2ze53mvwvrt4o3xxxxxx Delete
essd-pvc-0 default d-2ze5o2kq5yg4kdxxxxxx Delete
www-web-1 default d-2ze7plpd4247c5xxxxxx Delete
pvc-oss default oss-e5923d5a-10c1-xxxx-xxxx-7fdf82xxxxxx Retainデータ保護でファイルシステムをバックアップするために使用できるノードの選択方法
デフォルトでは、Alibaba Cloud ディスクボリューム以外のストレージボリュームをバックアップする場合、データバックアップと復元には Cloud Backup が使用されます。このシナリオでは、Cloud Backup タスクをノードで実行する必要があります。ACK スケジューラのデフォルトのスケジューリングポリシーは、コミュニティの Kubernetes スケジューラと同じです。必要に応じて、タスクを特定のノードにのみスケジュールするように構成することもできます。
Cloud Backup ジョブは仮想ノードにスケジュールできません。
デフォルトでは、バックアップジョブは優先度の低いジョブです。同じバックアップジョブの場合、ノードで実行できるボリュームバックアップジョブは最大 1 つです。
バックアップセンターのノードスケジューリングポリシー
exclude ポリシー (デフォルト)：デフォルトでは、すべてのノードをバックアップと復元に使用できます。Cloud Backup ジョブを特定のノードにスケジュールしたくない場合は、ノードに
csdr.alibabacloud.com/agent-excluded="true"ラベルを追加します。kubectl label node <node-name-1> <node-name-2> csdr.alibabacloud.com/agent-excluded="true"include ポリシー：デフォルトでは、ラベルのないノードはバックアップと復元に使用できません。Cloud Backup ジョブの実行を許可するノードに
csdr.alibabacloud.com/agent-included="true"ラベルを追加します。kubectl label node <node-name-1> <node-name-2> csdr.alibabacloud.com/agent-included="true"prefer ポリシー：デフォルトでは、すべてのノードをバックアップと復元に使用できます。スケジューリングの優先順位は次のとおりです。
csdr.alibabacloud.com/agent-included="true"ラベルを持つノードが最も高い優先順位を持ちます。特別なラベルのないノードが 2 番目に高い優先順位を持ちます。
csdr.alibabacloud.com/agent-excluded="true"ラベルを持つノードにスケジュールされます。
ノード選択ポリシーの変更
次のコマンドを実行して、
csdr-configConfigMap を編集します。kubectl -n csdr edit cm csdr-configapplicationBackup構成にnode_schedule_policy構成を追加します。例：次のコマンドを実行して、
csdr-controllerデプロイメントを再起動し、構成を有効にします。kubectl -n csdr delete pod -lapp=csdr-controller
アプリケーションバックアップとデータ保護のシナリオ
アプリケーションバックアップ：
アプリケーション、サービス、構成ファイルなど、クラスター内のビジネスをバックアップしたい場合。
オプション：アプリケーションをバックアップするときに、アプリケーションにマウントされているボリュームもバックアップしたい場合。
説明アプリケーションバックアップ機能は、Pod にマウントされていないボリュームをバックアップしません。
アプリケーションとすべてのボリュームをバックアップしたい場合は、データ保護バックアップジョブを作成できます。
クラスター間でアプリケーションを移行し、ディザスタリカバリのためにアプリケーションを迅速に復元したい場合。
データ保護：
PVC と PV のみを含むボリュームをバックアップしたい場合。
バックアップデータとは独立した PVC を復元したい場合。バックアップセンターを使用して削除された PVC を復元すると、新しいディスクが作成され、ディスク上のデータはバックアップファイル内のデータと同一になります。この場合、新しい PVC のマウントパラメーターは変更されません。新しい PVC はアプリケーションに直接マウントできます。
データレプリケーションとディザスタリカバリを実装したい場合。
一部の永続ボリュームをバックアップとリカバリから除外する方法
本番環境では、ログデータなどの一部のボリュームのデータは使い捨てと見なされ、移行やディザスタリカバリ中に保存する必要はありません。
OSS など、マスストレージ、クロスゾーンまたはクロスリージョンアクセス、マルチコピーディザスタリカバリなどの機能を提供する一部のストレージソースについては、優先度の低いサービスのデータバックアップと復元をスキップすることも検討できます。
バックアップするビジネス名前空間にボリューム A (データのバックアップは不要) とボリューム B (データのバックアップが必要) が含まれていると仮定します。
バックアップフロー
データ保護機能を使用して、バックアップ用の永続ボリューム B を選択します。データ保護機能は永続ボリューム B の YAML ファイルと対応するデータを同時にバックアップします。「クラスター内のアプリケーションのバックアップと復元」をご参照ください。
説明データのバックアップとは、スナップショットまたは Cloud Backup を使用してボリューム B のデータソースから独立したバックアップソースを生成することを意味します。バックアップソースから復元されたボリュームは元のボリュームと同じ内容を持ちますが、これらは 2 つの別々のコピーであり、互いに影響しません。
アプリケーションバックアップ機能を使用して、バックアップしたいアプリケーションを含む名前空間を選択できます。[ボリュームのバックアップ] 機能については、[無効化] を選択します。アプリケーションバックアップ機能は、デフォルトで永続ボリューム A と B の YAML ファイルをバックアップします。詳細については、「クラスター内のアプリケーションのバックアップと復元」をご参照ください。
説明ボリューム A を新しいクラスターに復元する必要がない場合は、詳細設定の [除外リソース] に
pvc, pvを指定できます。
復元フロー
クラスターに新しいアプリケーションをデプロイする場合と同様に、上位層のワークロードを復元する前に、ボリュームとデータを復元する必要があります。
ターゲットクラスターでデータ保護を復元します。これにより、永続ボリューム B の YAML ファイルとデータが復元されます。詳細については、「クラスター内のアプリケーションのバックアップと復元」をご参照ください。
ターゲットクラスターでアプリケーションバックアップを復元します。この操作により、PV A の YAML ファイルと他のアプリケーションリソースが復元されます。その後、Container Storage Interface (CSI) は PV A の再利用ポリシーを使用して、新しいストレージソースを動的に作成するか、既存のものを再利用します。詳細については、「アプリケーションバックアップで永続ボリュームデータをバックアップするタイミング」の「ステートフルアプリケーションの永続ボリュームデータをバックアップしない場合の潜在的なリスク」セクションをご参照ください。
この時点で、アプリケーション、ボリューム A、およびボリューム B (とそのデータ) が復元されます。
バックアップセンターは関連付けられた OSS バケットのデータ暗号化をサポートしているか。サーバー側暗号化に KMS を使用する権限を付与する方法
OSS バケットは、サーバー側暗号化とクライアントベースの暗号化の両方をサポートしています。ただし、バックアップセンターは OSS バケットのサーバー側暗号化のみをサポートしています。アタッチされたバケットのサーバー側暗号化を手動で有効にし、OSS コンソールで暗号化方法を構成できます。OSS バケットのサーバー側暗号化とその有効化方法の詳細については、「サーバー側暗号化」をご参照ください。
KMS で管理されるカスタマーマスターキー (CMK) を暗号化と復号に使用し、独自のキー (BYOK) を使用する場合、つまり CMK ID を指定する場合は、バックアップセンターに KMS へのアクセス権を付与する必要があります。次の手順に従ってください。
次のようにカスタム権限ポリシーを作成します。詳細については、「カスタム権限ポリシーの作成」をご参照ください。
{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "kms:List*", "kms:DescribeKey", "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": [ "acs:kms:*:141661496593****:*" ] } ] }上記のアクセスポリシーを使用すると、Alibaba Cloud アカウント ID の下のすべての KMS キーを呼び出すことができます。より詳細なリソース構成が必要な場合は、「承認情報」をご参照ください。
ACK 専用クラスターおよび登録済みクラスターの場合は、インストール時に使用する RAM ユーザーに権限を付与します。詳細については、「RAM ユーザーへの権限の付与」をご参照ください。他のクラスターの場合は、AliyunCSManagedBackupRestoreRole ロールに権限を付与します。詳細については、「RAM ロールへの権限の付与」をご参照ください。
OSS で管理される KMS キーを使用するか、OSS で完全に管理されるキーを暗号化と復号に使用する場合は、追加の権限を付与する必要はありません。
復元中にアプリケーションが使用するイメージを変更する方法
バックアップのアプリケーションが使用するイメージが次のようであると仮定します： docker.io/library/app1:v1
イメージリポジトリアドレス (レジストリ) の変更
ハイブリッドクラウドシナリオでは、複数のクラウドプロバイダーにまたがってアプリケーションをデプロイしたり、データセンターからクラウドにアプリケーションを移行したりする必要がある場合があります。このような場合、アプリケーションのイメージを Alibaba Cloud Container Registry (ACR) のイメージリポジトリにアップロードする必要があります。
imageRegistryMapping フィールドを使用してイメージリポジトリアドレスを指定する必要があります。たとえば、次の構成ではイメージが
registry.cn-beijing.aliyuncs.com/my-registry/app1:v1に変更されます。docker.io/library/: registry.cn-beijing.aliyuncs.com/my-registry/イメージリポジトリ (リポジトリ) とバージョンの変更
このタイプの調整は高度な構成であり、リカバリ前に ConfigMap で調整ポリシーを定義する必要があります。
イメージリポジトリを
app2:v2に変更したい場合は、次の構成を作成します。apiVersion: v1 kind: ConfigMap metadata: name: <configuration-name> namespace: csdr labels: velero.io/plugin-config: "" velero.io/change-image-name: RestoreItemAction data: "case1":"app1:v1,app2:v2" # リポジトリのみを変更する場合は、次の設定を使用します。 # "case1": "app1,app2" # バージョンのみを変更する場合は、次の設定を使用します。 # "case1": "v1:v2" # 特定のレジストリ内のイメージのみを変更する場合は、次の設定を使用します。 # "case1": "docker.io/library/app1:v1,registry.cn-beijing.aliyuncs.com/my-registry/app2:v2"複数の変更要件がある場合は、
dataフィールドで case2、case3 などを引き続き構成できます。ConfigMap が作成された後、通常どおり復元ジョブを作成し、imageRegistryMapping フィールドは空のままにします。
説明変更はクラスター内のすべての復元ジョブに影響します。上記のコメントに基づいて、特定のレジストリへの変更範囲を制限するなど、詳細な変更を構成することを推奨します。構成が不要になった場合は、削除してください。