このトピックでは、バックアップセンターに関するよくある質問への回答を提供します。
目次
カテゴリ | 問題 |
エラーメッセージの取得 | |
コンソール | |
全般 | |
バックアップ | |
ストレージタイプの変換 (復元中のオプション手順) | |
復元 | |
その他 |
一般的な操作
kubectl でバックアップセンターを使用する場合は、問題のトラブルシューティングを行う前に、migrate-controller コンポーネントを最新バージョンにアップグレードしてください。アップグレードは既存のバックアップには影響しません。コンポーネントのアップグレード方法の詳細については、「コンポーネントの管理」をご参照ください。
バックアップタスク、ストレージタイプ変換タスク、または復元タスクのステータスが失敗または部分的に失敗の場合、次の方法でエラーメッセージを取得できます。
ステータス列の失敗または部分的に失敗にポインタを合わせると、
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 を使用しているかどうかを確認します。クラスタが 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 の場合は、タスクのステータスが「失敗」で、「VaultError: xxx」エラーが返される の解決策をご参照ください。
解決策 3：
バックアップ クラスターのコンソールで、バックアップ タスクが成功したかどうか、つまりバックアップ タスクのステータスが [完了] であるかどうかを確認します。バックアップ タスクのステータスが異常な場合は、問題のトラブルシューティングを行います。詳細については、「目次」をご参照ください。
コンソールに「現在のコンポーネントに必要なサービスロールが承認されていません」と表示される
問題
[アドオンロールが承認されていません] というエラーコードが返され、アプリケーションバックアップコンソールにアクセスすると、コンソールに「現在のコンポーネントに必要なサービスロールが承認されていません」と表示されます。
原因
ACK マネージドクラスター 内の migrate-controller コンポーネントのクラウドリソース認証ロジックは、migrate-controller 1.8.0 で最適化されています。このバージョンに初めてコンポーネントをインストールまたはスペックアップする場合、Alibaba Cloud アカウントはクラウドリソースの権限付与を完了する必要があります。
解決策
Alibaba Cloud アカウントでログオンしている場合は、[承認] をクリックして権限付与を完了します。
RAM ユーザーでログオンしている場合は、[承認リンクのコピー] をクリックし、Alibaba Cloud アカウントにリンクを送信して権限付与を完了します。
コンソールに「現在のアカウントには、この操作に必要なクラスター RBAC 権限が付与されていません」と表示される
問題
アプリケーション バックアップ コンソールにアクセスすると、コンソールに「現在のアカウントには、この操作に必要なクラスター RBAC 権限が付与されていません。権限付与については、プライマリアカウントまたは権限管理者に問い合わせてください。」と表示されます。エラーコードは APISERVER.403 です。
原因
コンソールは API サーバーと対話して、バックアップ タスクと復元タスクを送信し、リアルタイムのタスク ステータスを取得します。クラスター運用担当者と開発者のデフォルトの権限リストには、バックアップ センター コンポーネントに必要な権限の一部がありません。プライマリアカウントまたは権限管理者は、これらの権限を付与する必要があります。
解決策
詳細については、「カスタム 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 コンポーネントを再インストールできます。
コンポーネントのアンインストールシナリオでは、コンポーネントはすでにアンインストールされているはずです。
タスクのステータスが失敗し、「内部エラー」エラーが返されます
問題
タスクのステータスは 失敗 で、「内部エラー」エラーが返されます。
原因
コンポーネントまたは基盤となるクラウドサービスで予期しない例外が発生します。たとえば、クラウドサービスが現在のリージョンで利用できない場合などです。
解決策
エラーメッセージが「HBR バックアップ/リストア内部エラー」の場合は、Cloud Backup コンソールでコンテナーバックアップ機能が利用可能かどうかを確認してください。
この種の質問については、チケットを送信する して処理してください。
タスクのステータスが失敗し、「クラスタリソースの作成タイムアウト」エラーが返される
問題
タスクのステータスは 失敗 で、「クラスタリソースの作成タイムアウト」エラーが返されます。
原因
StorageClass の変換または復元中に、一時的なポッド、永続ボリューム要求（ PVC ）、および永続ボリューム（ PV ）が作成される場合があります。 これらのリソースが作成後に長時間使用できない状態が続くと、「クラスタリソースの作成タイムアウト」エラーが返されます。
解決策
次のコマンドを実行して異常なリソースを見つけ、イベントに基づいて原因を見つけます。
kubectl -n csdr describe <applicationbackup/converttosnapshot/applicationrestore> <task-name>期待される結果：
……wait for created tmp pvc default/demo-pvc-for-convert202311151045 for convertion bound time outこれは、StorageClass 変換に使用された PVC が長時間バインドされていないことを示しています。 PVC は
default名前空間にあり、demo-pvc-for-convert202311151045という名前です。次のコマンドを実行して PVC のステータスを確認し、問題の原因を特定します。
kubectl -ndefault describe pvc demo-pvc-for-convert202311151045バックアップセンターで発生する問題の一般的な原因を次に示します。 詳細については、「ストレージのトラブルシューティング」をご参照ください。
クラスタまたはノードのリソースが不足しているか、異常です。
復元クラスタに対応する StorageClass がありません。 StorageClass 変換機能を使用して、復元クラスタ内の既存の StorageClass を選択してから、アプリケーションを復元します。
StorageClass に関連付けられている基盤となるストレージが使用できません。 たとえば、指定されたディスクタイプは現在のゾーンではサポートされていません。
alibabacloud-cnfs-nas に関連付けられているコンテナ ネットワーク ファイル システム（ CNFS ）が異常です。 詳細については、「CNFS を使用して NAS ファイルシステムを管理する（推奨）」をご参照ください。
マルチゾーンクラスタでアプリケーションを復元するときに、volumeBindingMode が Immediate に設定されている StorageClass を選択します。
タスクのステータスが「失敗」で、「アドオンのステータスが異常です」というエラーが返される
問題
タスクのステータスは [失敗] であり、「アドオンのステータスが異常です」というエラーが返されます。
原因
csdr 名前空間のコンポーネントが異常です。
解決策
詳細については、「原因 1 と解決策: csdr 名前空間のコンポーネントが異常」をご参照ください。
タスクの状態が失敗し、「VaultError: xxx」エラーが返されます
問題
バックアップ、リストア、または StorageClass 変換タスクの状態が「失敗」で、エラーメッセージ VaultError: バックアップボールトが使用できません: xxx が返されます。
原因
指定された OSS バケットが存在しません。
クラスターに OSS にアクセスするための権限がありません。
OSS バケットのネットワークに到達できません。
解決策
OSS コンソール にログインし、バックアップボールトに関連付けられている OSS バケットが存在するかどうかを確認します。
OSS バケットが存在しない場合は、バケットを作成して再度関連付けます。詳細については、「バケットを作成する」をご参照ください。
クラスターに OSS にアクセスするための権限があるかどうかを確認します。
ACK Pro マネージドクラスター: OSS 権限を構成する必要はありません。クラスターのバックアップボールトに関連付けられている OSS バケットの名前が cnfs-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 権限を構成します。詳細については、「migrate-controller をインストールし、権限を付与する」をご参照ください。
Alibaba Cloud アカウントを使用して、[承認] をクリックして承認を完了します。この操作は、Alibaba Cloud アカウントごとに 1 回だけ実行する必要があります。
説明削除されたバックアップボールトと同じ名前のバックアップボールトを作成することはできません。 cnfs-oss-** 形式ではない名前の OSS バケットにバックアップボールトを関連付けることはできません。 cnfs-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 Gateway を使用して VPC （仮想プライベートクラウド）に接続されていない。または、クラスターが VPC に接続されているが、リージョンの内部 OSS エンドポイントを指すルートが構成されていない。リージョンの内部 OSS エンドポイントを指すルートを構成する必要があります。
オンプレミス データセンターを VPC に接続する方法の詳細については、「データセンターを Alibaba Cloud に接続するために使用される方法」をご参照ください。
内部 OSS エンドポイントと仮想 IP アドレス ( VIP ) CIDR ブロック間のマッピングの詳細については、「内部 OSS エンドポイントと VIP の範囲」をご参照ください。
バックアップボールトがインターネット経由で 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>"}}]'
タスクのステータスが「失敗」で、「HBRError: check HBR vault error」エラーが返される
問題
バックアップ、リストア、または StorageClass 変換タスクのステータスが「失敗」で、「HBRError: check HBR vault error」エラーが返されます。
原因
Cloud Backup がアクティブ化されていないか、必要な権限がありません。
解決策
Cloud Backup がアクティブ化されているかどうかを確認します。詳細については、「Cloud Backup をアクティブ化する」をご参照ください。
クラスタが中国 (Ulanqab)、中国 (Heyuan)、または中国 (Guangzhou) にある場合は、Cloud Backup をアクティブ化した後、Cloud Backup に API Gateway へのアクセス権限を付与する必要があります。詳細については、「手順 3 (オプション): Cloud Backup に API Gateway へのアクセスを許可する」をご参照ください。
クラスタが ACK 専用クラスターまたは登録済みクラスターである場合は、使用している Resource Access Management (RAM) ユーザーに Cloud Backup へのアクセス権限があることを確認してください。権限付与の方法の詳細については、「migrate-controller をインストールし、権限を付与する」をご参照ください。
タスクのステータスが「失敗」で、「hbr task finished with unexpected status: FAILED, errMsg ClientNotExist」エラーが返される
問題
バックアップ、リストア、または StorageClass 変換タスクのステータスが「失敗」で、「hbr task finished with unexpected status: FAILED, errMsg ClientNotExist」 エラーメッセージが返されます。
原因
Cloud Backup クライアントが対応するノードに異常デプロイされています。つまり、csdr 名前空間のノードにある hbr-client DaemonSet のレプリカが異常です。
解決策
次のコマンドを実行して、クラスターに異常な hbr-client ポッドが存在するかどうかを確認します。
kubectl -n csdr get pod -lapp=hbr-client // csdr 名前空間で hbr-client ラベルを持つポッドを取得するポッドが異常な状態にある場合は、まず、問題がポッドの IP アドレス、メモリ、または CPU リソースの不足によって発生しているかどうかを確認します。ポッドのステータスが CrashLoopBackOff の場合は、次のコマンドを実行して、ポッドのログを表示します。
kubectl -n csdr logs -p <hbr-client-pod-name> // csdr 名前空間で指定された hbr-client ポッドのログを取得する出力に 「"SDKError:\n StatusCode: 403\n Code: MagpieBridgeSlrNotExist\n Message: code: 403, AliyunServiceRoleForHbrMagpieBridge doesn't exist, please create this role. "」 が含まれている場合は、詳細については、「ステップ 3 (オプション): API Gateway にアクセスするための Cloud Backup の承認」をご参照ください。Cloud Backup に権限を付与します。
ログ出力に他のタイプの SDK エラーが含まれている場合は、[チケットを送信する] を行って処理します。
タスクが長時間 InProgress 状態のままです
問題
コンポーネントのステータスを確認し、異常の原因を特定します。
csdr 名前空間のコンポーネントが再起動しているか、起動できないかを確認するには、次のコマンドを実行します。
kubectl get pod -n csdrコンポーネントが再起動しているか、起動できないかの理由を確認するには、次のコマンドを実行します。
kubectl describe pod <pod-name> -n csdr
原因が [OOM 再起動] の場合
リストア中に OOM 例外が発生した場合、ポッドは csdr-velero-*** であり、数十のプロダクション 名前空間など、多くの アプリケーションがリストア クラスターで実行されています。 OOM 例外が発生する可能性があるのは、Velero がデフォルトで Informer Cache を使用してリストア プロセスを高速化し、キャッシュがメモリを占有するためです。
リストアする リソースの数が少ない場合、またはリストア中のパフォーマンスへの影響を許容できる場合は、次の コマンドを実行して Informer Cache 機能を無効にできます。
kubectl -nkube-system edit deploy migrate-controllerパラメーター
--disable-informer-cache=trueを migrate-controller コンテナーのargsに追加します。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 権限が構成されている場合は、次のステップに進みます。
次の コマンドを実行して、Cloud Backup Client ウィジェットに必要なトークンが存在するかどうかを確認します。
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を削除してから、上記の手順を実行する必要があります。
原因
アプリケーションにマウントされているディスク ボリュームをバックアップするときに、バックアップ タスクが長時間 InProgress 状態のままになっている場合は、次のコマンドを実行して、クラスター内に新しく作成された VolumeSnapshot リソースをクエリします。
kubectl get volumesnapshot -n <backup-namespace>出力例:
NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT ...
<volumesnapshot-name> true <volumesnapshotcontent-name> ...READYTOUSE フィールドがすべての volumesnapshot リソースで長時間 false のままになっている場合は、次の手順を実行します。
ECS コンソール にログインし、ディスクスナップショット機能が有効になっているかどうかを確認します。
ディスクスナップショット機能が有効になっていない場合は、対応するリージョンでディスクスナップショット機能を有効にします。 詳細については、「ECS スナップショットを有効にする」をご参照ください。
ディスクスナップショット機能が有効になっている場合は、次の手順に進みます。
クラスタの Container Storage Interface (CSI) コンポーネントが正常に動作しているかどうかを確認します。
kubectl -nkube-system get pod -l app=csi-provisionerディスクスナップショットを使用するための権限が構成されているかどうかを確認します。
ACK マネージドクラスター
管理者権限を持つ 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 クイック承認 ページに移動して RAM ロールを作成します。
AliyunCSManagedBackupRestoreRole ロールは存在するが、ポリシーの内容が不完全な場合は、上記の権限をロールに付与します。 詳細については、「カスタムポリシーを作成する」および「RAM ロールに権限を付与する」をご参照ください。
ACK 専用クラスター
Container Service for Kubernetes (ACK) コンソール にログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターを見つけ、その名前をクリックします。 左側のウィンドウで、[クラスター情報] をクリックします。
[クラスター情報] ページで、[Master RAM ロール] パラメーターを見つけ、右側のリンクをクリックします。
[権限] タブで、ディスクスナップショットの権限が正常かどうかを確認します。
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 ストレージプラグインをインストールするときに、関連する権限が付与されているかどうかを確認します。 詳細については、「手順 1: RAM ユーザーに CSI プラグインを管理する権限を付与する」をご参照ください。
原因 3 と解決策：ディスクボリューム以外のストレージボリュームが使用されている
migrate-controller 1.7.7 以降のバージョンでは、ディスク ボリュームのバックアップをリージョンを跨いでリストアできます。その他のボリューム タイプのバックアップは、リージョンを跨いでリストアすることはできません。OSS などのインターネット アクセスをサポートするストレージ サービスを使用している場合は、静的にプロビジョニングされた PV と PVC を作成し、アプリケーションをリストアできます。詳細については、「静的にプロビジョニングされた ossfs 1.0 ボリュームをマウントする」をご参照ください。
バックアップタスクのステータスが「失敗」で、「バックアップは OSS バケットにすでに存在します」というエラーが返される
問題
バックアップタスクのステータスは [失敗] で、「OSS バケットにバックアップが既に存在します」というエラーが返されます。
原因
バックアップボールトに関連付けられている OSS バケットに、同じ名前のバックアップが保存されています。
以下の理由により、現在のクラスタでバックアップが表示されない場合があります。
実行中のバックアップタスクおよび失敗したバックアップタスクのバックアップは、他のクラスタに同期されません。
バックアップクラスタ以外のクラスタでバックアップを削除すると、OSS バケット内のバックアップファイルはラベル付けされますが、削除されません。 ラベル付けされたバックアップファイルは、新しく関連付けられたクラスタに同期されません。
現在のクラスタは、バックアップを保存するバックアップボールトに関連付けられていません。つまり、バックアップボールトは初期化されていません。
解決策
新しい名前でバックアップボールトを作成します。
バックアップタスクのステータスが「失敗」で、「get target namespace failed」エラーが返される
問題
バックアップ タスクのステータスは、[失敗] であり、「ターゲット 名前空間の取得に失敗しました」というエラーが返されます。
原因
ほとんどの場合、このエラーはスケジュールされた時間に作成されたバックアップタスクで発生します。原因は、名前空間の選択方法によって異なります。
[含める] を選択した場合、選択したすべての名前空間が削除されます。
[除外する] を選択した場合、選択した名前空間以外の名前空間がクラスターに存在しません。
解決策
バックアッププランを変更して、名前空間を選択するために使用されるメソッドと、選択した名前空間を変更します。
バックアップタスクのステータスが失敗し、「velero backup process timeout」エラーが返されます
問題
バックアップタスクのステータスは 失敗 で、「velero backup process timeout」エラーが返されます。
原因
原因 1：アプリケーションバックアップのサブタスクがタイムアウトしました。サブタスクの期間は、クラスタリソースの量と API サーバーの応答レイテンシによって異なります。 migrate-controller 1.7.7 以降では、サブタスクのデフォルトのタイムアウト期間は 60 分です。
原因 2：バックアップボールトで使用されるバケットのストレージタイプがアーカイブストレージ、コールドアーカイブ、またはディープコールドアーカイブです。バックアッププロセス中のデータ整合性を確保するために、メタデータを記録するファイルは、OSS サーバーのバックアップセンターコンポーネントによって更新される必要があります。バックアップセンターコンポーネントは、解凍されていないファイルを更新できません。
解決策
解決策 1：バックアップクラスタ内のサブタスクタイムアウト期間のグローバル構成を変更します。
velero_timeout_minutes設定項目を applicationBackup に追加するには、次のコマンドを実行します。単位は分です。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：バックアップボールトで使用されるバケットのストレージタイプを標準ストレージに変更します。
バックアップデータをアーカイブストレージに保存する場合は、ライフサイクルルールを構成して、ストレージタイプを自動的に変換し、解凍前にデータを解凍できます。詳細については、「ストレージタイプの変換」をご参照ください。
バックアップタスクのステータスが失敗し、「HBR バックアップリクエストが失敗しました」というエラーが返されます
問題
バックアップ タスクのステータスは [失敗] で、「HBR バックアップ リクエストが失敗しました」というエラーが返されます。
原因
原因 1: クラスタで使用されているストレージプラグインに互換性がありません。
原因 2: Cloud Backup は、volumeMode が Block のボリュームのバックアップをサポートしていません。詳細については、「ボリュームモード」をご参照ください。
原因 3: Cloud Backup クライアントが異常であるため、OSS ボリューム、NAS ファイルシステム (NAS) ボリューム、Cloud Parallel File Storage (CPFS) ボリューム、ローカルボリュームなどのファイルシステムボリュームのバックアップまたは復元タスクがタイムアウトまたは失敗します。
解決策
解決策 1：クラスタが Alibaba Cloud CSI ストレージプラグイン以外を使用している場合、または永続ボリューム（PV）が NFS や LocalVolume などの一般的な Kubernetes ストレージボリュームではなく、互換性の問題が発生した場合は、チケットを送信 してサポートを受けてください。
解決策 2：チケットを送信 して処理を依頼してください。
解決策 3：次の手順を実行します。
Cloud Backup コンソール にログオンします。
左側のナビゲーションウィンドウで、[バックアップ] > コンテナーのバックアップ を選択します。 [コンテナバックアップ] ページで、[バックアップジョブ] タブをクリックします。
上部のナビゲーションバーで、リージョンを選択します。
[バックアップジョブ] タブで、検索ボックスの横にあるドロップダウンリストから [ジョブ名] を選択し、検索ボックスに
<backup-name>-hbrと入力して、検索アイコンをクリックします。バックアップタスクが表示されたら、タスクステータスを確認できます。タスクが異常な状態の場合、異常の原因が表示されます。詳細については、「ACK クラスタをバックアップする」をご参照ください。説明StorageClass 変換タスクまたはバックアップタスクをクエリする場合は、対応するバックアップ名を検索してください。
バックアップタスクのステータスが失敗し、「HBR get empty backup info」エラーが返されます
問題
バックアップタスクのステータスは [失敗] で、「HBR get empty backup info」エラーが返されます。
原因
ハイブリッドクラウド シナリオでは、バックアップ センターはデフォルトで標準 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 はバックアップ対象のデータにアクセスできない可能性があります。
解決策
ボリュームがマウントされているノードにログオンし、次の手順を実行して問題のトラブルシューティングを行います。
ノードの 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 ルート パスです。
バックアップタスクのステータスが失敗し、「OSS バケット内のバックアップファイルのチェックに失敗しました」または「OSS バケットへのバックアップファイルのアップロードに失敗しました」または「OSS バケットからのバックアップファイルのダウンロードに失敗しました」というエラーが返されます
問題
バックアップ タスクのステータスは [失敗] で、「OSS バケットへのバックアップ ファイルのアップロードに失敗しました」というエラーが返されます。
原因
OSS サーバーは、コンポーネントがバックアップボールトに関連付けられた OSS バケット内のバックアップファイルを確認、アップロード、またはダウンロードするときにエラーを返します。この問題は、次のいずれかの原因で発生する可能性があります。
原因 1: OSS バケットのデータ暗号化が有効になっていますが、関連する KMS 権限が付与されていません。
原因 2: 専用クラスターと登録済みクラスターのコンポーネントをインストールして権限を構成するときに、いくつかの読み取りおよび書き込み権限がありません。
原因 3: 専用クラスターと登録済みクラスターの権限を構成するために使用される RAM ユーザーの認証資格情報が取り消されています。
解決策
解決策 1: バックアップ センターは、関連付けられた OSS バケットのデータ暗号化をサポートしていますか? Key Management Service (KMS) を使用してサーバ側暗号化を行うための権限を付与するにはどうすればよいですか? をご覧ください。
解決策 2: 権限の設定に使用される RAM ユーザーの権限ポリシーを確認します。コンポーネントに必要な権限ポリシーの詳細については、「手順 1: 権限を構成する」をご参照ください。
解決策 3: 権限の設定に使用される RAM ユーザーの認証資格情報が有効になっていることを確認します。取り消されている場合は、新しい認証資格情報を取得し、csdr 名前空間のシークレット
alibaba-addon-secretの内容を更新してから、次の操作を実行してウィジェットを再起動します。kubectl -nkube-system delete pod -lapp=migrate-controller // ウィジェットを再起動するための操作
タスクのステータスが「失敗」で、「内部エラー」エラーが返される
問題
バックアップタスクのステータスは [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 クラスタをバックアップする」をご参照ください。
StorageClass 変換タスクのステータスが失敗し、「storageclass xxx not exists」エラーが返される
問題
StorageClass 変換タスクのステータスは [失敗] で、「storageclass xxx not exists」エラーが返されます。
問題
ストレージクラス変換のために選択したターゲット StorageClass は、現在のクラスタに存在しません。
解決策
StorageClass 変換タスクをリセットするには、次のコマンドを実行します。
cat << EOF | kubectl apply -f - apiVersion: csdr.alibabacloud.com/v1beta1 kind: DeleteRequest metadata: name: reset-convert namespace: csdr # 名前空間 csdr spec: deleteObjectName: "<backup-name>" # 削除対象のバックアップ名 deleteObjectType: "Convert" # 削除対象のオブジェクトタイプ EOF現在のクラスターに必要な StorageClass を作成します。
リストア タスクを再実行し、StorageClass 変換を設定します。
StorageClass 変換タスクのステータスが失敗し、「CSI diskplugin または nasplugin プロビジョナーを持つ storageclass への変換のみをサポートしています」というエラーが返されます
問題
StorageClass 変換タスクのステータスは 失敗 で、エラーメッセージ 「CSI diskplugin または nasplugin プロビジョナーを持つ storageclass への変換のみをサポートしています」 が返されます。
原因
StorageClass 変換のために選択したターゲット StorageClass が、Alibaba Cloud CSI ディスクボリュームまたは NAS ボリュームではありません。
解決策
現在のバージョンでは、デフォルトでディスクタイプと NAS タイプのスナップショットの作成と復元のみをサポートしています。その他の復元要件がある場合は、関連するサポート [チケットを送信する] にお問い合わせください。
OSS など、インターネットアクセスをサポートするストレージサービスを使用している場合は、静的にプロビジョニングされた PV と PVC を作成し、StorageClass 変換手順なしでアプリケーションを復元できます。詳細については、「静的にプロビジョニングされた ossfs 1.0 ボリュームをマウントする」をご参照ください。
StorageClass 変換タスクのステータスが失敗し、「現在のクラスターはマルチゾーンです」というエラーが返される
問題
StorageClass 変換タスクのステータスが 失敗 で、「現在のクラスターはマルチゾーンです」というエラーが返されます。
原因
現在のクラスターはマルチゾーン クラスターです。現在の StorageClass が変換される StorageClass はディスク ボリュームであり、volumeBindingMode は Immediate に設定されています。マルチゾーン クラスターでディスク ボリュームを使用する場合、ディスク ボリュームが作成されポッドにマウントされた後、ポッドは指定されたノードにスケジュールできず、Pending 状態のままになります。 volumeBindingMode フィールドの詳細については、「StorageClass」をご参照ください。
解決策
次のコマンドを実行して、StorageClass 変換タスクをリセットします。
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ディスク StorageClass に変換する場合：
コンソールを使用する場合は、[alicloud-disk] を選択します。 [alicloud-disk] は、デフォルトで [alicloud-disk-topology-alltype] StorageClass を使用します。
コマンドラインを使用する場合は、alicloud-disk-topology-alltype タイプを選択します。 alicloud-disk-topology-alltype は、CSI ストレージ プラグインによって提供されるデフォルトの StorageClass です。 volumeBindingMode を WaitForFirstConsumer に設定することもできます。
リストア タスクを再度実行し、StorageClass 変換を設定します。
タスクのステータスが「失敗」で、「アドオンのステータスが異常です」エラーが返される
問題
リストアまたは StorageClass 変換タスクのステータスが「失敗」で、エラーメッセージ 「マルチノード書き込みはブロック ボリュームでのみサポートされています。 Kubernetes ユーザーの場合は、不明な場合は、ディスク ボリュームの PersistentVolumeClaim で ReadWriteOnce アクセスモードを使用してください」 が返されます。
原因
マウント中にディスクが別のノードにマウントされている場合に強制的にディスクがデタッチされるリスクを防ぐため、CSI はマウント中にディスクボリュームの AccessModes 構成を確認し、ReadWriteMany または ReadOnlyMany 構成の使用を禁止します。
バックアップ対象のアプリケーションは、AccessMode が ReadWriteMany または ReadOnlyMany であるボリュームをマウントします（主に OSS や NAS など、複数マウントをサポートするネットワークストレージ）。デフォルトで複数マウントをサポートしていない Alibaba Cloud ディスクストレージにアプリケーションをリストアすると、CSI は上記のエラーをスローする可能性があります。
具体的には、次の 3 つのシナリオでこのエラーが発生する可能性があります。
シナリオ 1：バックアップ クラスタの CSI バージョンが古い（またはクラスタが FlexVolume ストレージ プラグインを使用している）場合。古い CSI バージョンでは、マウント中に Alibaba Cloud ディスク ボリュームの AccessModes フィールドがチェックされないため、元のディスク ボリュームが新しい CSI バージョンのクラスタにリストアされるときにエラーが報告されます。
シナリオ 2: バックアップ ボリュームで使用されるカスタム StorageClass が、リストア クラスターに存在しません。特定のマッチング ルールに従って、ボリュームは新しいクラスターでデフォルトでAlibaba Cloud ディスク ボリュームとしてリストアされます。
シナリオ 3: リストア中に、StorageClass 変換機能を使用して、バックアップ ボリュームが Alibaba Cloud ディスク ボリュームとしてリストアされるように手動で指定します。
解決策
シナリオ 1: v1.8.4 以後、バックアップコンポーネントは、ディスクボリュームの AccessModes フィールドの ReadWriteOnce への自動変換をサポートしています。 バックアップセンターコンポーネントをアップグレードしてから、アプリケーションを再度リストアします。
シナリオ 2: ターゲット クラスタ内のコンポーネントによる StorageClass の自動復元は、データアクセス不能またはデータ上書きのリスクがあります。復元前にターゲット クラスタに同じ名前の StorageClass を作成するか、StorageClass 変換機能を使用して、復元中に使用する StorageClass を指定します。
シナリオ 3: ネットワークストレージ ボリュームをディスク ボリュームとして復元する場合、convertToAccessModes パラメーターを構成して、AccessModes を ReadWriteOnce に変換します。詳細については、「convertToAccessModes: ターゲット AccessModes のリスト」をご参照ください。
タスクのステータスが「失敗」で、「VaultError: xxx」エラーが返される
問題
リストアタスクのステータスは [失敗] で、エラーメッセージ 「現バージョンでは、ディスクタイプ PV のみがリージョン間のリストアをサポートしています」 が返されます。
原因
migrate-controller 1.7.7 以降のバージョンでは、ディスクボリュームのバックアップをリージョンを跨いでリストアできます。その他のボリュームタイプのバックアップは、リージョンを跨いでリストアすることはできません。
解決策
OSS など、インターネットアクセスをサポートするストレージサービスを使用している場合は、静的にプロビジョニングされた PV と PVC を作成してから、アプリケーションをリストアできます。詳細については、「静的にプロビジョニングされた ossfs 1.0 ボリュームをマウントする」をご参照ください。
他のタイプのストレージデータをリージョンをまたいでリカバリする必要がある場合は、チケットを送信するしてください。
タスクのステータスが「失敗」で、「HBRError: HBR ボールトエラーを確認してください」エラーが返される
問題
復元タスクのステータスは [失敗] で、「ECS スナップショットのリージョン間リクエストが失敗しました」というエラーが返されます。
原因
migrate-controller 1.7.7 以降のバージョンでは、ディスク ボリュームのバックアップをリージョンを跨いでリストアできますが、Elastic Compute Service (ECS) ディスク スナップショットを使用するための権限は付与されません。
解決策
クラスターが専用クラスターまたは ECS インスタンスにデプロイされた自己管理型 Kubernetes クラスタに接続されている登録済みクラスターの場合、ECS ディスク スナップショットを使用するための権限を付与する必要があります。詳細については、「登録済みクラスター」をご参照ください。
タスクのステータスが「失敗」で、「hbr タスクが予期しないステータスで終了しました：FAILED、errMsg ClientNotExist」エラーが返される
問題
リストア タスクのステータスは「失敗」で、「PVC xxx の accessMode は xxx です」というエラーが返されます。
原因
復元するディスクボリュームの AccessMode は、ReadOnlyMany (読み取り専用マルチマウント) または ReadWriteMany (読み書きマルチマウント) に設定されています。
ディスクボリュームをリストアすると、新しいボリュームは CSI を使用してマウントされます。 現在のバージョンの CSI を使用する場合は、次の点に注意してください。
multiAttach機能が有効になっているボリュームのみ、複数のインスタンスにマウントできます。VolumeModeがFilesystem（ ext4 や xfs などのファイルシステムを使用してマウント）に設定されているボリュームは、読み取り専用モードでのみ複数のインスタンスにマウントできます。
詳細については、「動的にプロビジョニングされたディスク ボリュームを使用する」をご参照ください。
解決策
OSS ボリュームや NAS ボリュームなど、複数マウントをサポートするボリュームを StorageClass 変換機能を使用してディスクボリュームに変換する場合、ビジネスの異なるレプリカがボリューム上のデータを正常に共有できるようにするには、新しいリストアタスクを作成し、StorageClass 変換のターゲットタイプとして
alibabacloud-cnfs-nasを選択することをお勧めします。 この方法では、CNFS によって管理される NAS ボリュームが使用されます。 詳細については、「CNFS を使用して NAS ファイルシステムを管理する（推奨）」をご参照ください。ディスク PV をバックアップしたときの CSI バージョンが低く（
AccessMode検出なし）、バックアップされた永続ボリューム自体が現在の CSI 作成要件を満たしていない場合は、動的にプロビジョニングされたディスクボリューム を優先して元のワークロードを変換する必要があります。 これにより、他のノードへのスケジューリング時に強制的にディスクがデタッチされる脅威を回避できます。 複数マウントシナリオについてさらに質問や要件がある場合は、チケットを送信 してサポートを受けてください。
リストア タスクのステータスは完了ですが、リストア クラスターに一部のリソースが作成されていません
問題
リストア タスクのステータスは 完了 ですが、リストア クラスターに一部のリソースが作成されていません。
原因
原因 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ターゲット リソースがバックアップされているかどうかを確認します。ターゲット リソースがバックアップされていない場合は、バックアップ タスクで指定された名前空間、リソース、またはその他の構成が原因で除外されているかどうかを確認し、リソースを再度バックアップします。 デフォルトでは、選択されていない名前空間にある実行中のアプリケーション（ポッド）のクラスター レベル リソースはバックアップされません。 すべてのクラスター レベル リソースをバックアップする場合は、「クラスターレベル バックアップ」をご参照ください。
解決策 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 に移行します。
その他のケースについては、DingTalk ユーザーグループ（グループ ID：35532895）にご参加ください。
FlexVolume を使用するクラスター内のアプリケーションをバックアップし、FlexVolume から CSI への移行中に CSI を使用するクラスターにアプリケーションをリストアする必要がある場合は、「古い Kubernetes バージョンを実行している ACK クラスターでバックアップセンターを使用してアプリケーションを移行する」をご参照ください。
バックアップボールトを変更できますか?
バックアップボールトは変更できません。バックアップボールトを変更する場合は、現在のバックアップボールトを削除し、別の名前でバックアップボールトを作成するしかありません。
バックアップボールトは共有されているため、常に [バックアップ] または [復元] 状態になっている可能性があります。バックアップボールトのパラメーターを変更すると、アプリケーションのバックアップまたは復元時に、システムが必要なデータを見つけられない可能性があります。そのため、バックアップボールトを変更したり、同じ名前を使用するバックアップボールトを作成したりすることはできません。
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=csdrcnfs-oss-* 以外の形式の名前を持つ OSS バケットに関連付けられたバックアップボールトを作成した場合は、接続性チェックが完了し、ステータスが Available に変わるまで待ってから、アプリケーションのバックアップまたはリストアを試行してください。接続性チェックの間隔は約 5 分です。次のコマンドを実行して、バックアップボールトのステータスをクエリできます。
kubectl -n csdr get backuplocation期待される結果:
NAME PHASE LAST VALIDATED AGE a-test-backuplocation Available 7s 6d1h
バックアッププランを作成するときに、バックアップサイクルをどのように指定しますか?
バックアップサイクルは、crontab 式 ( 1 4 * * * など) または間隔ベースのバックアップ ( 6h30m など) をサポートしています。これは、6h30m ごとにバックアップが作成されることを意味します。
crontab 式の解析方法について以下に説明します。オプションの値は、分のオプションの値が 0 ～ 59 であることを除いて、標準の crontab 式と同じです。* は、指定されたフィールドで使用可能な任意の値を示します。crontab 式の例:
1 4 * * *: 毎日午前 4 時 01 分にバックアップを作成します。0 2 15 * 1: 毎月 15 日の午前 2 時 00 分にバックアップを作成します。
* * * * *
| | | | |
| | | | ·----- 曜日 (0 - 6) (日曜日から土曜日) // day of week (0 - 6) (Sun to Sat)
| | | ·-------- 月 (1 - 12) // month (1 - 12)
| | .----------- 日 (1 - 31) // day of month (1 - 31)
| ·-------------- 時 (0 - 23) // hour (0 - 23)
·----------------- 分 (0 - 59) // minute (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 インスタンスを作成します。詳細については、「LoadBalancer サービスを構成するための考慮事項」をご参照ください。
バックアップリソースを表示するにはどうすればよいですか？
クラスタアプリケーションバックアップのリソース
クラスター内の 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> --detailsACK コンソールでバックアップリソースを表示します。
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 バージョンが保存されます。 KubernetesConvert 機能は、API バージョンの変換に使用されます。
リソースをリストアするときは、リストア クラスタによって推奨される 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 バージョンのクラスタにアプリケーションを移行しないことをお勧めします。 また、1.16 より前の Kubernetes バージョンを実行するクラスタから新しい Kubernetes バージョンを実行するクラスタにアプリケーションを移行しないこともお勧めします。
リストア中にトラフィックは SLB インスタンスに自動的に切り替えられますか？
いいえ、トラフィックは自動的には切り替えられません。
サービスは、サービスの種類に基づいてリストアされます。
NodePort サービス: デフォルトでは、クラスター間でサービスをリストアするときに、サービスポートは保持されます。
LoadBalancer サービス: ExternalTrafficPolicy が Local に設定されている場合、HealthCheckNodePort はデフォルトでランダムポートを使用します。ポート番号を保持する場合は、リストアタスクの作成時に
spec.preserveNodePorts: trueを設定します。バックアップクラスター内の既存の Server Load Balancer ( SLB ) インスタンスを使用するサービスをリストアする場合、リストアされたサービスは同じ SLB インスタンスを使用し、デフォルトでリスナーを無効にします。 SLB コンソールにログインしてリスナーを設定する必要があります。
バックアップクラスターで CCM によって SLB インスタンスが管理されているサービスをリストアする場合、CCM は新しい SLB インスタンスを作成します。詳細については、「LoadBalancer サービスを構成する際の考慮事項」をご参照ください。
デフォルトでは、リスナーが無効化された後、または新しい SLB インスタンスが使用された後、トラフィックは新しい SLB インスタンスに自動的に切り替えられません。他のクラウドサービスまたはサードパーティのサービスディスカバリを使用していて、自動サービスディスカバリによってトラフィックが新しい SLB インスタンスに切り替えられることを望まない場合は、バックアップ中にサービスリソースを除外し、トラフィックを切り替える必要があるときに手動でデプロイできます。
なぜ csdr、ack-csi-fuse、kube-system、kube-public、および kube-node-lease 名前空間のリソースはデフォルトでバックアップされないのですか? kube-system、kube-public、kube-node-lease などの名前空間のリソースはどうでしょうか?
csdr はバックアップセンターの名前空間です。この名前空間を直接バックアップおよびリストアすると、リストア クラスターでコンポーネントが機能しなくなります。さらに、バックアップセンターにはバックアップ同期ロジックがあるため、バックアップを手動で新しいクラスターに移行する必要はありません。
ack-csi-fuse は CSI ストレージコンポーネントの名前空間であり、CSI によって維持される FUSE クライアント ポッドを実行するために使用されます。新しいクラスターにストレージをリストアすると、新しいクラスターの CSI は対応するクライアントに自動的に同期されます。この名前空間を手動でバックアップおよびリストアする必要はありません。
kube-system、kube-public、および kube-node-lease は、Kubernetes クラスターのデフォルトのシステム名前空間です。クラスターのパラメーターと構成の違いにより、これらの名前空間をクラスター間でリストアすることはできません。さらに、バックアップセンターはアプリケーションのバックアップとリストアに使用されます。リストアタスクを実行する前に、リストア クラスターにシステムコンポーネントをインストールして構成する必要があります。例：
コンテナーレジストリパスワード不要イメージプルコンポーネント: リストア クラスターで acr-configuration に権限を付与して構成する必要があります。
Application Load Balancer (ALB) Ingress: ALBConfigs を構成する必要があります。
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 より前の場合、VolumeSnapshot を作成するときに有効期間を指定したり、インスタントアクセス機能を有効にしたりすることはできません。この場合、バックアップ構成の有効期間はディスクスナップショットに影響しません。
そのため、ディスクボリュームのボリュームデータバックアップ機能を使用する場合は、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 ファイルを直接リストアできない場合。
ステートフル アプリケーションのボリュームをバックアップしない場合のリスクは何ですか?
ステートフル アプリケーションをバックアップするときにボリュームをバックアップしないと、リストア中に次の動作が発生します。
再利用ポリシーが削除のボリュームの場合:
初めて PVC をデプロイする場合と同様に、リストア クラスタに対応する StorageClass がある場合、CSI は自動的に新しい PV を作成します。 たとえば、ディスクストレージの場合、新しい空のディスクがリストアされたアプリケーションにマウントされます。 StorageClass が指定されていない静的ボリュームの場合、またはリストア クラスタに対応する StorageClass がない場合、リストアされた PVC とポッドは、対応する PV または StorageClass を手動で作成するまで、保留中の状態のままになります。
再利用ポリシーが保持のボリュームの場合:
リストア中、リソースは元の 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
アプリケーションのバックアップとデータ保護のシナリオとは何ですか?
アプリケーション バックアップ:
クラスター内のビジネス (アプリケーション、サービス、構成ファイルなど) をバックアップする必要がある。
オプション: アプリケーションをバックアップするときに、アプリケーションにマウントされているボリュームもバックアップする。
説明アプリケーション バックアップ機能では、ポッドにマウントされていないボリュームはバックアップされません。
アプリケーションとすべてのボリュームをバックアップする場合は、データ保護バックアップ タスクを作成できます。
クラスター間でアプリケーションを移行し、ディザスタリカバリのためにアプリケーションを迅速にリストアする必要がある。
データ保護:
PVC と PV のみをバックアップする必要がある。
バックアップデータとは無関係に PVC をリストアする必要がある。バックアップ センターを使用して削除された PVC をリストアすると、新しいディスクが作成され、ディスク上のデータはバックアップ ファイル内のデータと同じになります。この場合、新しい PVC のマウント パラメーターは変更されません。新しい PVC はアプリケーションに直接マウントできます。
データ レプリケーションとディザスタリカバリを実装する必要がある。
バックアップセンターは、関連付けられた OSS バケットのデータ暗号化をサポートしていますか? Key Management Service (KMS) を使用したサーバ側暗号化の権限を付与するにはどうすればよいですか?
OSS バケットは、サーバ側暗号化とクライアント側暗号化の両方をサポートしています。ただし、バックアップセンターは、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 であると仮定します。
イメージリポジトリアドレス（レジストリ）を変更する
ハイブリッドクラウド シナリオでは、複数のクラウド サービス プロバイダーのクラウドにアプリケーションをデプロイしたり、データセンターからクラウドにアプリケーションを移行したりする必要がある場合があります。この場合、アプリケーションで使用されるイメージを Container Registry のイメージリポジトリにアップロードする必要があります。
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: <ConfigMap 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 などを続けて構成できます。imageRegistryMapping フィールドを空のままにするConfigMap が作成された後、通常どおりリストアタスクを作成し、。
説明変更は、クラスタ内のすべてのリストアタスクに有効になります。上記の記述に基づいて詳細な変更を構成することをお勧めします。たとえば、単一のリポジトリ内のイメージの変更を構成します。 ConfigMap が不要になった場合は、削除してください。