このトピックでは、バックアップセンターに関するよくある質問に対する回答を提供します。
目次
共通操作
kubectl CLIを使用してバックアップセンターにアクセスする場合、問題のトラブルシューティングを行う前に、migrate-controllerという名前のバックアップコンポーネントを最新バージョンに更新する必要があります。 更新は既存のバックアップには影響しません。 コンポーネントの更新方法の詳細については、「コンポーネントの管理」をご参照ください。
バックアップ、StorageClass変換 (FKAスナップショットの作成) 、または復元タスクのステータスが [失敗] または [部分的失敗] の場合、次の方法でエラーメッセージを取得できます。
ステータス列の [失敗] または [部分的失敗] にポインターを移動して、
RestoreError: snapshot cross region request Failedなどの簡単なエラー情報を表示します。
詳細なエラー情報を表示するには、次のコマンドのいずれかを実行して、
RestoreError: process advancedvolumesapshot failed avs: snapshot-hz、err: transition canceled with error: the ECS-snapshot関連のramポリシーが見つかりませんなど、タスクのリソースイベントを照会します。バックアップタスク
kubectl -n csdr describe applicationbackup <backup-name>StorageClass変換 (FKAスナップショット作成) タスク
kubectl -n csdr describe converttosnapshot <backup-name>復元タスク
kubectl -n csdr describe applicationrestore <restore-name>
コンソールに「コンポーネントが異常です」または「現在のデータの取得に失敗しました」と表示された場合はどうすればよいですか。
説明
コンソールプロンプトコンポーネントは異常です。 または現在のデータの取得に失敗しました。
原因
バックアップセンターコンポーネントのインストールが異常です。
ソリューション
バックアップセンターコンポーネントがインストールされているクラスターノードが存在するかどうかを確認します。 クラスターノードが存在しない場合、バックアップセンターコンポーネントをインストールできません。
クラスターがFlexVolumeを使用しているかどうかを確認します。 クラスターがFlexVolumeを使用している場合は、Container Storage Interface (CSI) に切り替えます。 詳細については、「」をご参照ください。FlexVolumeを使用するクラスター内の移行コントローラーコンポーネントを起動できない場合はどうすればよいですか。
kubectl CLIを使用してバックアップセンターにアクセスする場合は、YAML設定にエラーが含まれているかどうかを確認します。 詳細については、「kubectlを使用したアプリケーションのバックアップと復元」をご参照ください。
クラスターがACK専用クラスターまたは登録済みクラスターの場合、必要な権限が設定されているかどうかを確認します。 詳細については、「ACK専用クラスター」および「登録済みクラスター」をご参照ください。
csdr名前空間のcsdr-controllerおよびcsdr-veleroデプロイメントが、リソースまたはスケジューリングの制限によりデプロイに失敗していないかどうかを確認します。 はいの場合、問題を修正します。
コンソールに次のエラーが表示された場合はどうすればよいですか。 名前を変更してもう一度やり直しますか?
説明
バックアップ、StorageClass変換 (FKAスナップショット作成) 、または復元タスクを作成または削除すると、コンソールに表示されます。 名前を変更して、もう一度お試しください。
原因
コンソールでタスクを削除すると、クラスターにdeletrequestリソースが作成されます。 対応するコンポーネントは、バックアップリソースの削除を含む複数の削除操作を実行します。 kubectlを使用して関連する操作を実行する方法の詳細については、「kubectlを使用してデータをバックアップおよび復元する」をご参照ください。
コンポーネントが削除操作を実行したり、deleterequestリソースを処理したりするときにエラーが発生した場合、クラスター内の一部のリソースは保持されます。 したがって、同じ名前のリソースが存在する可能性があります。
ソリューション
プロンプトに従って、同じ名前のリソースを削除します。 たとえば、
deleterequests.csdr.alibabacloud.com "xxxxx-dbr" already existsエラーが表示された場合、次のコマンドを実行してリソースを削除できます。kubectl -n csdr delete deleterequests xxxxx-dbr新しい名前でタスクを作成します。
クラスター間でアプリケーションを復元するときに既存のバックアップを選択できない場合はどうすればよいですか?
説明
クラスター間でアプリケーションを復元する場合、既存のバックアップを選択してアプリケーションを復元することはできません。
発生原因
原因1: バックアップコンテナーが現在のクラスターに関連付けられていないため、バックアップコンテナーが初期化されていません。
システムがバックアップボールトを初期化すると、OSSバケット情報を含むバックアップボールトに関する基本情報がクラスターに同期されます。 次に、システムはクラスター内のバックアップボールトからバックアップファイルを初期化します。 バックアップボールトからバックアップファイルを選択して、バックアップボールトが初期化された後にのみアプリケーションを復元できます。
原因2: バックアップボールトの初期化に失敗しました。これは、現在のクラスターのbackuplocationリソースが
Unavailable状態であることを意味します。原因3: バックアップタスクが完了していないか、バックアップタスクが失敗しました。
ソリューション
解決策1:
[復元タスクの作成] パネルで、[バックアップボールト] の右側にある [バックアップボールトの初期化] をクリックし、バックアップボールトが初期化されるまで待ち、バックアップファイルを選択します。
解決策2:
次のコマンドを実行して、backuplocationリソースのステータスを照会します。
kubectl get -ncsdr backuplocation <backuplocation-name> 期待される出力:
NAME PHASE LAST VALIDATED AGE
<backuplocation-name> Available 3m36s 38mステータスがUnavailableの場合は、タスクのステータスがFailedで、"VaultError: xxx" エラーが返された場合の対処方法を参照してください。
解決策3:
バックアップクラスターのコンソールにログインし、バックアップタスクのステータスが完了かどうかを確認します。 バックアップタスクのステータスが異常な場合は、問題のトラブルシューティングを行います。 詳細については、「目次」をご参照ください。
現在のコンポーネントの依存するサービスにリンクされたロールが割り当てられていないことをコンソールで確認した場合はどうすればよいですか。
説明
アプリケーションのバックアップページにアクセスすると、コンソールは、現在のコンポーネントの依存するサービスにリンクされたロールが割り当てられていないことを確認します。 エラーコードAddonRoleNotAuthorizedが表示されます。
原因
クラウドリソース認証ロジックは、ACK管理クラスター用にバックアップセンターコンポーネントmigrate-controller 1.8.0で最適化されています。 Alibaba Cloudアカウントでこのコンポーネントバージョンを初めてインストールまたは更新する場合は、アカウントのクラウドリソース認証を完了する必要があります。
解決策
Alibaba Cloudアカウントでコンソールにログインする場合は、[権限付与リンクのコピー] をクリックし、[権限付与] をクリックしてAlibaba Cloudアカウントに権限を付与します。
Resource Access Management (RAM) ユーザーでコンソールにログインする場合、[権限付与リンクのコピー] をクリックし、対応するAlibaba Cloudアカウントへのリンクを送信して権限付与を完了します。
私は何をしますか?バックアップセンターコンポーネントの更新またはアンインストールに失敗しましたか?
説明
バックアップセンターコンポーネントのmigrate-controllerの更新またはアンインストールに失敗し、csdr名前空間は終了状態のままです。
原因
操作中に、バックアップセンターコンポーネントに予期しない終了または同様の例外が発生し、タスクがcsdr名前空間内でInProgress状態で停止することがあります。 これらのタスクには、クラスターリソースに対応するファイナライザーフィールドがあり、リソースが削除されない可能性があります。 その結果、csdr名前空間は終了状態になります。
解決策
次のコマンドを実行して、
csdr名前空間が終了状態になっていることを確認します。kubectl describe ns csdrスタックしたタスクが不要になったことを確認します。 対応する
ファイナライザーを削除して、リソースを削除できるようにします。csdr名前空間が削除された後:コンポーネントを更新する場合は、コンポーネントを再インストールします。
コンポーネントをアンインストールする場合は、完全に削除する必要があります。
タスクのステータスがFailedで、「内部エラー」エラーが返された場合はどうすればよいですか?
この問題を解決するには、
チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。タスクのステータスがFailedで、"create cluster resources timeout" エラーが返された場合はどうすればよいですか。
説明
タスクのステータスがFailedで、"create cluster resources timeout" エラーが返されます。
原因
システムがStorageClass変換 (FKAスナップショットの作成) または復元タスクを実行すると、一時ポッド、永続ボリュームクレーム (PVC) 、および永続ボリューム (PV) が作成されることがあります。 これらのリソースが長期間使用できない場合、「create cluster resources timeout」エラーが返されます。
ソリューション
次のコマンドを実行して、異常なリソースを特定し、イベントに基づいて原因を見つけます。
kubectl -ncsdr describe <applicationbackup/converttosnapshot/applicationrestore> <task-name>期待される出力:
……wait for created tmp pvc default/demo-pvc-for-convert202311151045 for convertion bound time out出力は、StorageClassの変換に使用されるPVCが、Bound以外の状態のままであることを示しています。 PVCの名前空間は
defaultで、PVCの名前はdemo-pvc-for-convert202311151045です。次のコマンドを実行して、PVCのステータスを照会し、原因を特定します。
kubectl -ndefault describe pvc demo-pvc-for-convert202311151045次のリストは、バックアップセンター関連の問題を引き起こす一般的な理由を説明しています。 詳細については、「ストレージのトラブルシューティング」をご参照ください。
クラスタまたはノードのリソースが不十分または異常です。
StorageClassは復元クラスターに存在しません。 この場合、StorageClass変換 (FKAスナップショット作成) タスクを作成して、現在のStorageClassを復元クラスター内の既存のStorageClassに変換します。
StorageClassに関連付けられているストレージリソースが使用できません。 たとえば、指定されたディスクタイプは現在のゾーンではサポートされていません。
alibabacloud-CNFS-nasに関連付けられているContainer Network File System (cnfs) システムが異常です。 詳細については、「CNFSを使用したNASファイルシステムの管理 (推奨) 」をご参照ください。
マルチゾーンクラスターでアプリケーションを復元するときに、volumeBindingModeがImmediateであるStorageClassを選択しました。
タスクのステータスがFailedで、"addon status is abnormal" エラーが返された場合はどうすればよいですか?
説明
タスクのステータスがFailedで、「アドオンステータスが異常です」エラーが返されます。
原因
csdr名前空間のコンポーネントが異常です。
ソリューション
詳細については、「原因1と解決策: csdr名前空間のコンポーネントが異常」をご参照ください。
タスクのステータスがFailedで、"VaultError: xxx" エラーが返された場合はどうすればよいですか?
説明
バックアップ、復元、またはスナップショット変換タスクのステータスがFailedで、VaultError: backup vault is unavailable: xxxエラーが表示されます。
発生原因
指定されたObject Storage Service (OSS) バケットは存在しません。
クラスターにはOSSにアクセスする権限がありません。
OSSバケットのネットワークに到達できません。
ソリューション
OSSコンソールにログインします。 バックアップボールトに関連付けられているOSSバケットが存在するかどうかを確認します。
OSSバケットが存在しない場合は、作成してバックアップボールトに関連付けます。 詳細は、「バケットの作成」をご参照ください。
クラスターにOSSへのアクセス権限があるかどうかを確認します。
ACK Proクラスター: OSS権限は必要ありません。 バックアップボールトに関連付けられているOSSバケットの名前がcnfs-oss-** 形式であることを確認します。
ACK専用クラスターと登録済みクラスター: OSS権限が必要です。 詳細については、「migrate-controllerのインストールと権限の付与」をご参照ください。
コンソール以外の方法を使用してmigrate-controller 1.8.0をインストールするか、ACKマネージドクラスターでこのバージョンに更新すると、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バケットにバックアップボールトがすでに関連付けられている場合は、別の名前を使用する別のバックアップボールトを作成し、そのバックアップボールトを、名前が要件を満たすOSSバケットに関連付けます。
次のコマンドを実行して、クラスターのネットワーク構成を確認します。
kubectl get backuplocation <backuplocation-name> -n csdr -o yaml | grep network期待される出力:
network: internalネットワークが
internalに設定されている場合、バックアップボールトは内部ネットワークを介してOSSバケットにアクセスします。ネットワークが
publicに設定されている場合、バックアップボールトはインターネット経由でOSSバケットにアクセスします。 バックアップボールトがインターネット経由でOSSバケットにアクセスし、アクセスがタイムアウトしたことを示すエラーが返された場合は、クラスターがインターネットにアクセスできるかどうかを確認します。 詳細については、「既存のACSクラスターによるインターネットへのアクセスの有効化」をご参照ください。
次のシナリオでは、インターネット経由でOSSバケットにアクセスするようにバックアップボールトを設定する必要があります。
クラスターとOSSバケットは異なるリージョンにデプロイされています。
クラスターはACK Edgeクラスターです。
クラスターは登録済みクラスターであり、cloud Enterprise Network (CEN) 、Express Connect、またはVPN接続を介して仮想プライベートクラウド (VPC) に接続されていないか、またはクラスターはVPCに接続された登録済みクラスターですが、OSSバケットが存在するリージョンの内部ネットワークを指すルートはありません。 この場合、OSSバケットが存在するリージョンの内部ネットワークを指すルートを設定する必要があります。
データセンターをVPCに接続する方法の詳細については、「複数の接続方法を組み合わせてエンタープライズクラスのハイブリッドクラウドを構築する」をご参照ください。
OSSバケットの内部エンドポイントとVIP範囲の詳細については、「OSSバケットとVIP範囲の内部エンドポイント」をご参照ください。
インターネット経由でOSSバケットにアクセスするようにクラスターを設定するには、次のコマンドを実行してOSSバケットのインターネットアクセスを有効にします。
<backuplocation-name>を実際のバックアップボールト名に置き換え、<region-id>をOSSバケットのリージョンID (cn-hangzhouなど) に置き換えます。kubectl patch -ncsdr backuplocation/<backuplocation-name> --type='json' -p '[{"op":"add","path":"/spec/config","value":{"network":"public","region":"<region-id>"}}]' kubectl patch -ncsdr backupstoragelocation/<backuplocation-name> --type='json' -p '[{"op":"add","path":"/spec/config","value":{"network":"public","region":"<region-id>"}}]'
バックアップ、復元、またはスナップショット変換タスクのステータスがFailedで、バックアップ場所がokではない場合はどうすればよいですか? エラーが返されますか?
説明
バックアップ、復元、またはスナップショット変換タスクのステータスがFailedで、バックアップ場所がokではありません。please check access ossエラーが返されます。
原因と解決策
Kubernetes 1.20以降
原因の失敗
migrate-controllerのバージョンが古いです。
ソリューション
migrate-controllerを最新バージョンに更新します。 詳細については、「コンポーネントの管理」をご参照ください。
1.20より前のKubernetesバージョン
原因の失敗
バックアップボールトに関連付けられているOSSサブディレクトリは、別のバックアップボールトに関連付けられているOSSサブディレクトリの親ディレクトリまたは子ディレクトリにすることはできません。 たとえば、ディレクトリ
/と/A、またはディレクトリ/Aと/A/Bを同時に使用することはできません。 さらに、バックアップボールトに関連付けられているOSSサブディレクトリには、バックアップセンターによって生成されたバックアップのみを格納できます。 他のデータをOSSサブディレクトリに保存すると、バックアップボールトは使用できなくなります。で説明した同じ原因タスクのステータスがFailedで、"VaultError: xxx" エラーが返された場合はどうすればよいですか?.
ソリューション
バックアップボールトに関連付けられているOSSサブディレクトリは、別のバックアップボールトに関連付けられているOSSサブディレクトリの親ディレクトリまたは子ディレクトリにすることはできません。 さらに、バックアップボールトに関連付けられているOSSサブディレクトリには、バックアップセンターによって生成されたバックアップのみを格納できます。 次のコマンドを実行して、OSSサブディレクトリを確認します。 <backuplocation-name> を実際のバックアップコンテナー名に置き換えます。
kubectl describe backupstoragelocation <backuplocation-name> -n csdr | grep message期待される出力:
Backup store contains invalid top-level directories: ****出力は、バックアップボールトに関連付けられたOSSディレクトリに他のデータが格納されていることを示します。 この問題を解決するには、次のいずれかの方法を使用します。
クラスターのKubernetesバージョンをKubernetes 1.20以降に更新し、migrate-controllerを最新バージョンに更新します。
OSSサブディレクトリに関連付けられていないバックアップボールトを作成し、バックアップボールトの名前を変更します。 同じ名前のバックアップボールトは削除しないでください。
バックアップ、復元、またはスナップショット変換タスクが長期間未進行状態のままである場合はどうすればよいですか?
原因1と解決策: csdr名前空間のコンポーネントが異常です
コンポーネントのステータスを確認し、原因を特定します。
次のコマンドを実行して、csdr名前空間のコンポーネントが再起動されているか起動できないかを確認します。
kubectl get pod -n csdr次のコマンドを実行して原因を特定します。
kubectl describe pod <pod-name> -n csdr
コンポーネントがメモリ不足 (OOM) エラーにより再起動された場合は、次の手順を実行します。
次のコマンドを実行して、デプロイメントのリソース制限を変更します。
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>"}}}}'クラウドバックアップの権限が不足してコンポーネントを起動できない場合は、次の手順を実行します。
クラスターに対してクラウドバックアップが有効化されていることを確認します。
クラウドバックアップが有効化されていない場合は、有効化します。 詳しくは、
参照クラウドバックアップ.「API を介したメトリックデータのアクセス」 をご参照ください。 クラウドバックアップが有効になっている場合は、次の手順に進みます。
ACK専用クラスターまたは登録済みクラスターにクラウドバックアップ権限があることを確認します。
クラスターにクラウドバックアップ権限がない場合は、必要な権限を付与します。 詳細については、「migrate-controllerのインストールと権限の付与」をご参照ください。
クラスターに権限がある場合は、次の手順に進みます。
次のコマンドを実行して、Cloud Backupクライアントに必要なトークンが存在するかどうかを確認します。
kubectl describe <hbr-client-***>couldnt 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-*** ポッドを削除し、上記の手順を繰り返す必要があります。
原因2と解決策: クラスターにディスクスナップショットを作成するスナップショット権限がありません
アプリケーションにマウントされているディスクボリュームをバックアップするときに、バックアップタスクが長い間InProgress状態のままである場合は、次のコマンドを実行して、クラスター内に新しく作成されたVolumeSnapshotsを照会します。
kubectl get volumesnapshot -n <backup-namespace>期待される出力:
NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT ...
<volumesnapshot-name> true <volumesnapshotcontent-name> ...すべてのVolumeSnapshotsのREADYTOUSE状態がfalseのままである場合は、次の手順を実行します。
Elastic Compute Service (ECS) コンソールにログインし、ディスクスナップショット機能が有効になっているかどうかを確認します。
機能が無効になっている場合は、対応するリージョンで機能を有効にします。 詳細については、「ECSスナップショットの有効化」をご参照ください。
機能が有効になっている場合は、次のステップに進みます。
クラスターのCSIコンポーネントが正常に実行されるかどうかを確認します。
kubectl -nkube-system get pod -l app=csi-provisionerディスクスナップショットの使用権限が付与されているかどうかを確認します。
ACK専用クラスター
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[クラスター情報] をクリックします。
[クラスター情報] ページで、[クラスターリソース] タブをクリックします。 マスターRAMロールの横にあるリンクをクリックして、権限管理ページに移動します。
[ポリシー] ページで、ディスクスナップショットを使用する権限が付与されているかどうかを確認します。
k8sMasterRolePolicy-Csi-*** ポリシーが存在し、ポリシーが
チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。k8sMasterRolePolicy-Csi-***およびk8sMasterRolePolicy-Csi-***権限を提供する場合、必要な権限が付与されます。 この場合、k8sMasterRolePolicy-Csi-*** ポリシーが存在しない場合は、次のポリシーをマスターRAMロールにアタッチして、ディスクスナップショットを使用する権限を付与します。 詳細については、「カスタムポリシーの作成」および「RAMロールへの権限付与」をご参照ください。
{ "Version": "1", "Statement": [ { "Action": [ "ecs:DescribeDisks", "ecs:DescribeInstances", "ecs:DescribeAvailableResource", "ecs:DescribeInstanceTypes", "nas:DescribeFileSystems", "ecs:CreateSnapshot", "ecs:DeleteSnapshot", "ecs:DescribeSnapshotGroups", "ecs:CreateAutoSnapshotPolicy", "ecs:ApplyAutoSnapshotPolicy", "ecs:CancelAutoSnapshotPolicy", "ecs:DeleteAutoSnapshotPolicy", "ecs:DescribeAutoSnapshotPolicyEX", "ecs:ModifyAutoSnapshotPolicyEx", "ecs:DescribeSnapshots", "ecs:CopySnapshot", "ecs:CreateSnapshotGroup", "ecs:DeleteSnapshotGroup" ], "Resource": [ "*" ], "Effect": "Allow" } ] }
上記の手順を実行しても問題が解決しない場合は、
チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。
ACK管理クラスター
にログインします。RAMコンソール管理者権限を持つRAMユーザーとして
左側のナビゲーションウィンドウで、.
[ロール] ページで、検索ボックスにAliyunCSManagedCsiRoleと入力します。 ロールのポリシーに次の内容が含まれているかどうかを確認します。
{ "Version": "1", "Statement": [ { "Action": [ "ecs:DescribeDisks", "ecs:DescribeInstances", "ecs:DescribeAvailableResource", "ecs:DescribeInstanceTypes", "nas:DescribeFileSystems", "ecs:CreateSnapshot", "ecs:DeleteSnapshot", "ecs:DescribeSnapshotGroups", "ecs:CreateAutoSnapshotPolicy", "ecs:ApplyAutoSnapshotPolicy", "ecs:CancelAutoSnapshotPolicy", "ecs:DeleteAutoSnapshotPolicy", "ecs:DescribeAutoSnapshotPolicyEX", "ecs:ModifyAutoSnapshotPolicyEx", "ecs:DescribeSnapshots", "ecs:CopySnapshot", "ecs:CreateSnapshotGroup", "ecs:DeleteSnapshotGroup" ], "Resource": [ "*" ], "Effect": "Allow" } ] }AliyunCSManagedCsiRoleロールが存在しない場合、
チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。AliyunCSManagedCsiRoleロールが存在するが、ポリシーに上記のコンテンツが含まれていない場合は、ロールに上記の権限を付与します。 詳細については、「カスタムポリシーの作成」および「RAMロールへの権限付与」をご参照ください。
登録済みクラスター
ディスクスナップショット機能は、ECSノードのみを含む登録済みクラスターでのみ使用できます。 CSIプラグインを使用する権限があるかどうかを確認します。 詳細については、「RAMユーザーにCSIプラグインを管理する権限を付与する」をご参照ください。
原因3と解決策: ディスクボリューム以外のボリュームタイプが使用されています
migrate-controller 1.7.7以降のバージョンでは、ディスクボリュームのバックアップをリージョン間で復元できます。 他のボリュームタイプのバックアップは、リージョン間で復元できません。 OSSなどのパブリックアクセスをサポートするストレージサービスを使用している場合は、静的にプロビジョニングされたPVとPVCを作成してから、アプリケーションを復元できます。 詳細については、「静的にプロビジョニングされたOSSボリュームのマウント」をご参照ください。
バックアップタスクのステータスがFailedで、「OSSバケットにバックアップがすでに存在します」というエラーが返された場合はどうすればよいですか。
説明
バックアップタスクのステータスがFailedで、「OSSバケットにバックアップが既に存在します」エラーが返されます。
発生原因
同じ名前のバックアップは、バックアップボールトに関連付けられたOSSバケットに保存されます。
現在のクラスターでバックアップが表示されない理由:
進行中のバックアップタスクおよび失敗したバックアップタスクのバックアップは、他のクラスターに同期されません。
バックアップクラスター以外のクラスター内のバックアップを削除すると、OSSバケット内のバックアップファイルにラベルが付けられますが、削除されません。 ラベル付きバックアップファイルは、新しく関連付けられたクラスターには同期されません。
現在のクラスターは、バックアップを格納するバックアップコンテナーに関連付けられていません。つまり、バックアップコンテナーは初期化されていません。
ソリューション
別の名前でバックアップコンテナーを再作成します。
バックアップタスクのステータスがFailedで、"get target namespace failed" エラーが返された場合はどうすればよいですか?
説明
バックアップタスクのステータスがFailedで、"get target namespace failed" エラーが返されます。
発生原因
ほとんどの場合、このエラーは、スケジュールされた時間に作成されたバックアップタスクで発生します。 原因は、名前空間の選択方法によって異なります。
includeリストを作成すると、選択したすべての名前空間が削除されます。
除外リストを作成する場合、除外された名前空間以外の名前空間がクラスターに存在しないことが原因です。
ソリューション
バックアップ計画を変更して、名前空間の選択および選択した名前空間の変更に使用する方法を変更します。
バックアップタスクのステータスがFailedで、"velero backup process timeout" エラーが返された場合はどうすればよいですか?
説明
バックアップタスクのステータスがFailedで、"velero backup process timeout" エラーが返されます。
発生原因
原因1: バックアップタスクのサブタスクがタイムアウトします。 サブタスクの期間は、クラスターリソースの量とAPIサーバーの応答遅延によって異なります。 migrate-controller 1.7.7以降では、サブタスクのデフォルトのタイムアウト時間は60分です。
原因2: バックアップボールトに関連付けられているOSSバケットのストレージクラスは、アーカイブ、コールドアーカイブ、またはディープコールドアーカイブです。 バックアッププロセス中にデータの一貫性を確保するには、メタデータを記録するファイルをOSSサーバー上のバックアップセンターコンポーネントで更新する必要があります。 バックアップセンターコンポーネントは、復元されていないファイルを更新できません。
ソリューション
解決策1: バックアップクラスターのサブタスクのグローバルタイムアウト期間を変更します。
次のコマンドを実行して、
velero_timeout_minutesをapplicationBackupに追加します。 単位：分kubectl edit -ncsdr cm csdr-configたとえば、次のコードブロックはタイムアウト期間を100分に設定します。
apiVersion: v1 data: applicationBackup: | ... #Details not shown. velero_timeout_minutes: 100タイムアウト期間を変更した後、次のコマンドを実行して、変更を有効にするためにcsdr-controllerを再起動します。
kubectl -ncsdr delete pod -l control-plane=csdr-controller解決策2: OSSバケットのストレージクラスを標準に変更します。
OSSバケットに保存されているデータに標準ストレージクラスを使用する場合は、ストレージクラスの変換を自動化するようにライフサイクルルールを設定できます。 バックアップファイルを復元する前に、OSSバケット内のデータを復元する必要があります。 詳細については、「ストレージクラスの変換」をご参照ください。
バックアップタスクのステータスがFailedで、「HBRバックアップ要求に失敗しました」エラーが返された場合はどうすればよいですか。
説明
バックアップタスクのステータスがFailedで、「HBRバックアップ要求に失敗しました」エラーが返されます。
発生原因
原因1: クラスターで使用されるボリュームプラグインがCloud Backupと互換性がありません。
原因2: Cloud Backupは、ボリュームモードがBlockのボリュームのバックアップ作成をサポートしていません。 詳細については、「ボリュームモード」をご参照ください。
原因3: Cloud Backupクライアントで例外が発生します。 この場合、OSSボリューム、NASボリューム、CPFSボリューム、ローカルボリュームなどのファイルシステムボリュームをバックアップまたは復元するタスクはタイムアウトまたは失敗します。
ソリューション
解決策1: クラスターがCSIプラグインを使用しない場合、またはクラスターがNFSボリュームやローカルボリュームなどの一般的なKubernetesボリュームを使用しない場合、
チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。解決策2:
チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。解決策3: 次の手順を実行します。
にログインします。Cloud Backupコンソール.
左側のナビゲーションウィンドウで、[バックアップ]> コンテナーのバックアップ を選択します。
上部のナビゲーションバーで、リージョンを選択します。
[バックアップジョブ] タブで、[ジョブ名] 検索ボックスで
<Backup-name>-hbrを検索し、バックアップタスクのステータスを確認して原因を特定します。 詳細については、「クラスターバックアップの表示」をご参照ください。説明StorageClassの変換またはバックアップタスクを照会するには、対応するバックアップ名を検索します。
バックアップタスクのステータスがFailedで、「OSSバケットのバックアップファイルの確認に失敗しました」、「OSSバケットへのバックアップファイルのアップロードに失敗しました」、または「OSSバケットからのバックアップファイルのダウンロードに失敗しました」というエラーが返された場合はどうすればよいですか。
説明
バックアップタスクのステータスがFailedで、「OSSバケットへのバックアップファイルのアップロードに失敗しました」エラーが返されます。
発生原因
上記のエラーは、バックアップセンターコンポーネントがバックアップボールトに関連付けられたOSSバケット内のバックアップファイルをチェック、アップロード、またはダウンロードすると、OSSサーバーによって返されます。 考えられる原因：
原因1: OSSバケットのデータ暗号化は有効ですが、バックアップボールトにはKMSにアクセスする権限がありません。
原因2: ACK専用クラスターまたは登録済みクラスターを使用しています。 ただし、バックアップセンターコンポーネントをインストールすると、コンポーネントに特定の読み取りおよび書き込み権限が付与されません。
原因3: ACK専用クラスターまたは登録済みクラスターを使用しています。 ただし、使用するRAMユーザーのAccessKeyペアは取り消されます。
ソリューション
解決策1: 詳細については、「バックアップセンターに関連付けられているOSSバケットのデータ暗号化を有効にすることができますか? 」をご参照ください。 KMSに基づいてサーバー側の暗号化を有効にする場合、バックアップセンターに権限を付与するにはどうすればよいですか。
解決策2: 使用するRAMユーザーにアタッチされているポリシーに、バックアップセンターコンポーネントに必要な権限が含まれているかどうかを確認します。 詳細については、「手順1: 関連する権限の付与」をご参照ください。
解決策3: 使用するRAMユーザーのAccessKeyペアが有効になっているかどうかを確認します。 AccessKeyペアが無効になっている場合は、新しいAccessKeyペアを取得し、新しいAccessKeyペアに基づいてcsdr名前空間の
alibaba-addon-secretSecretを更新します。 次に、次のコマンドを実行して、バックアップセンターコンポーネントを再起動します。kubectl -nkube-system delete pod -lapp=migrate-controller
バックアップタスクのステータスがPartiallyFailedで、"PROCESS velero partially completed" エラーが返された場合はどうすればよいですか?
説明
バックアップタスクのステータスはPartiallyFailedで、"PROCESS velero partially completed" エラーが返されます。
原因
veleroコンポーネントを使用してアプリケーション (クラスター内のリソース) をバックアップすると、一部のリソースのバックアップに失敗します。
ソリューション
次のコマンドを実行して、コンポーネントがバックアップに失敗したリソースを照会し、原因を特定します。
kubectl -ncsdr exec -it $(kubectl -ncsdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe backup <backup-name>出力の [エラー] および [警告] フィールドの内容に基づいて問題を修正します。
失敗の原因が表示されない場合は、次のコマンドを実行してveleroコンポーネントのログを照会します。
kubectl -ncsdr exec -it $(kubectl -ncsdr 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ボリューム、ローカルボリュームなどのファイルシステムボリュームをバックアップすると、一部のリソースのバックアップに失敗します。 考えられる原因：
原因1: ボリュームプラグインがCloud Backupをサポートしていません。
原因2: クラウドバックアップはデータの一貫性を保証できません。 バックアッププロセス中にファイルが削除されると、バックアップタスクは失敗します。
ソリューション
にログインします。Cloud Backupコンソール.
左側のナビゲーションウィンドウで、[バックアップ]> コンテナーのバックアップ を選択します。
上部のナビゲーションバーで、リージョンを選択します。
[バックアップジョブ] タブで、[ジョブ名] 検索ボックスで
<Backup-name>-hbrを検索し、バックアップ失敗の原因を特定します。 詳細については、「クラスターバックアップの表示」をご参照ください。
StorageClass変換 (FKAスナップショット作成) タスクのステータスがConvertFailedで、"storageclass xxx not exists" エラーが返された場合はどうすればよいですか?
説明
StorageClass変換 (FKAスナップショット作成) タスクのステータスがConvertFailedで、"storageclass xxx not exists" エラーが返されます。
原因
現在のStorageClassが変換されたStorageClassは、現在のクラスターに存在しません。
ソリューション
次のコマンドを実行して、StorageClass変換 (FKAスナップショット作成) タスクをリセットします。
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を作成します。
StorageClass変換 (FKAスナップショット作成) タスクを再実行します。
StorageClass変換 (FKAスナップショットの作成) タスクのステータスがConvertFailedで、「CSI diskpluginまたはnasplugin provisionerを使用したstorageclassへの変換のみサポート」エラーが返された場合はどうすればよいですか。
説明
StorageClass変換 (FKAスナップショット作成) タスクのステータスがConvertFailedで、「CSI diskpluginまたはnasplugin provisionerを使用したstorageclassへの変換のみサポート」エラーが返されます。
原因
現在のStorageClassが変換されるStorageClassは、CSIコンポーネントによってサポートされない。
ソリューション
現在のCSIバージョンは、ディスクボリュームとNASボリュームのスナップショットのみをサポートしています。 他のボリュームタイプのスナップショットを使用する場合は、
チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。OSSなどのパブリックアクセスをサポートするストレージサービスを使用している場合は、静的にプロビジョニングされたPVCとPVを作成してから、アプリケーションを直接復元する必要があります。 StorageClass変換は必要ありません。 詳細については、「静的にプロビジョニングされたOSSボリュームのマウント」をご参照ください。
StorageClass変換 (FKAスナップショットの作成) タスクのステータスがConvertFailedで、"current cluster is multi-zoned" エラーが返された場合はどうすればよいですか?
説明
StorageClass変換 (FKAスナップショットの作成) タスクのステータスはConvertFailedで、"current cluster is multi-zoned" エラーが返されます。
原因
現在のクラスターはマルチゾーンクラスターです。 現在のStorageClassが変換されるStorageClassはディスクボリュームであり、volumeBindingModeはImmediateに設定されています。 マルチゾーンクラスターでディスクボリュームを使用する場合、ディスクボリュームが作成されてポッドにマウントされた後、指定されたノードにポッドをスケジュールすることはできず、Pending状態のままになります。 volumeBindingModeの詳細については、「ディスクボリュームの概要」をご参照ください。
解決策
次のコマンドを実行して、StorageClass変換 (FKAスナップショット作成) タスクをリセットします。
cat << EOF | kubectl apply -f - apiVersion: csdr.alibabacloud.com/v1beta1 kind: DeleteRequest metadata: name: reset-convert namespace: csdr spec: deleteObjectName: "<backup-name>" deleteObjectType: "Convert" EOFStorageClassをディスクボリュームに変換するには、次の手順を実行します。
コンソールを使用してStorageClassをディスクボリュームに変換するには、alicloud-diskを選択します。 デフォルトでは、alicloud-diskはalicloud-disk-topology-alltype StorageClassを使用します。
CLIを使用してStorageClassをディスクボリュームに変換するには、alicloud-disk-topology-alltypeを選択することを推奨します。これは、CSIプラグインによって提供されるデフォルトのStorageClassです。 volumeBindingModeをWaitForFirstConsumerに設定することもできます。
StorageClass変換 (FKAスナップショット作成) タスクを再実行します。
復元タスクのステータスがFailedで、「現在のバージョンでディスクタイプのPVのみがクロスリージョンリストアをサポートしています」というエラーが返された場合はどうすればよいですか。
説明
リストアタスクのステータスが失敗で、「現在のバージョンでディスクタイプのPVのみがクロスリージョンリストアをサポートしています」というエラーが返されます。
原因
migrate-controller 1.7.7以降のバージョンでは、ディスクボリュームのバックアップをリージョン間で復元できます。 他のボリュームタイプのバックアップは、リージョン間で復元できません。
ソリューション
OSSなどのパブリックアクセスをサポートするストレージサービスを使用している場合は、静的にプロビジョニングされたPVとPVCを作成してから、アプリケーションを復元できます。 詳細については、「静的にプロビジョニングされたOSSボリュームのマウント」をご参照ください。
リージョン間で他のボリュームタイプのバックアップを復元する場合は、
チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。
復元タスクのステータスがFailedで、「ECSスナップショットクロスリージョンリクエストに失敗しました」エラーが返された場合はどうすればよいですか。
説明
リストアタスクのステータスがFailedで、「ECSスナップショットクロスリージョンリクエストに失敗しました」エラーが返されます。
原因
migrate-controller 1.7.7以降のバージョンでは、ディスクボリュームのバックアップをリージョン間で復元できます。 ただし、クラスターはECSディスクスナップショットの使用を許可されていません。
解決策
お使いのクラスターがACK専用クラスターまたは自己管理Kubernetesクラスターに接続されている登録済みクラスターの場合、ECSディスクスナップショットを使用するためにクラスターを承認する必要があります。 詳細については、「登録済みクラスターへの権限付与」をご参照ください。
復元タスクのステータスがFailedで、"accessMode of PVC xxx is xxx" エラーが返された場合はどうすればよいですか?
説明
復元タスクのステータスがFailedで、"accessMode of PVC xxx is xxx" エラーが返されます。
発生原因
復元するディスクボリュームのプロビジョニングに使用されるPVCのAccessModeパラメーターは、ReadOnlyManyまたはReadWriteManyに設定されています。
ディスクボリュームを復元すると、CSIを使用して新しいボリュームがマウントされます。 現在のバージョンのCSIを使用する場合は、次の項目に注意してください。
ディスクボリュームを複数のECSインスタンスにマウントする場合は、ボリュームに関連付けられているディスクの
マルチアタッチ機能を有効にする必要があります。PVCの
VolumeModeパラメーターがFilesystemに設定されている場合、ext4またはxfsファイルシステムを使用するディスクがマウントされます。 この場合、ディスクボリュームはReadOnlyManyアクセスモードのみをサポートしています。
詳細については、「動的にプロビジョニングされたディスクボリュームの使用」をご参照ください。
ソリューション
復元タスクでStorageClass変換機能を使用して、OSSやNASボリュームなどのマルチアタッチをサポートするボリュームをディスクボリュームに変換する場合は、新しい復元タスクを作成することを推奨します。 StorageClassを
alibabacloud-cnfs-nasに変換するように、新しい復元タスクを設定します。 このようにして、このタスクは新しいCNFS管理NASボリュームを作成し、ボリュームがマウントされているアプリケーションの異なるポッド間でデータを確実に共有します。 詳細については、「CNFSを使用したNASファイルシステムの管理 (推奨) 」をご参照ください。ボリュームの
チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。AccessModeパラメーターをチェックしない比較的古いバージョンのCSIを使用してバックアップディスクボリュームをプロビジョニングし、現在のクラスターで使用されているCSIバージョンでバックアップボリュームを作成できない場合は、動的にプロビジョニングされたディスクボリュームを使用して元のアプリケーションを変更することを推奨します。 これにより、ボリュームが他のノードにマウントされるときにディスクがデタッチされることを防ぎます。 マルチアタッチシナリオについて質問がある場合は、
復元タスクのステータスが完了しても、一部のリソースが復元クラスターに作成されていない場合はどうすればよいですか。
説明
復元タスクのステータスは完了ですが、一部のリソースは復元クラスターに作成されていません。
発生原因
原因1: リソースのバックアップが作成されていません。
原因2: リソースが復元リストから除外されます。
原因3: アプリケーション復元タスクの一部のサブタスクが失敗しました。
原因4: リソースは復元されますが、ownerReferencesまたはビジネスロジックのために再利用されます。
ソリューション
解決策1:
次のコマンドを実行して、バックアップの詳細を照会します。
kubectl -ncsdr exec -it $(kubectl -ncsdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe backup <backup-name> --detailsリソースのバックアップが作成されているかどうかを確認します。 バックアップが作成されていない場合は、リソースとリソースの名前空間がバックアップタスクのincludeリストに指定されているか、リソースと名前空間がバックアップタスクのexcludeリストに指定されていないことを確認してください。 次に、バックアップタスクを再実行します。 バックアップタスクがポッドの名前空間をバックアップするように構成されていない場合、クラスターレベルのポッドリソースはバックアップされません。 すべてのクラスターレベルのリソースをバックアップするには、「バックアップクラスターでのバックアップの作成」をご参照ください。
解決策2:
リソースが復元されていない場合は、復元タスクのincludeリストにリソースとリソースの名前空間が指定されているか、復元タスクのexcludeリストにリソースと名前空間が指定されていないことを確認してください。 次に、復元タスクを再実行します。
解決策3:
次のコマンドを実行してリソースを照会し、原因を特定します。
kubectl -ncsdr exec -it $(kubectl -ncsdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe restore <restore-name> 出力の [エラー] および [警告] フィールドの内容に基づいて問題を修正します。 原因を特定できない場合は、
解決策4:
リソースの監査レコードを照会し、リソースが誤って削除されたかどうかを確認します。
FlexVolumeを使用するクラスター内の移行コントローラーコンポーネントを起動できない場合はどうすればよいですか。
migrate-コントローラは、FlexVolumeを使用するクラスターをサポートしません。 バックアップセンター機能を使用するには、次のいずれかの方法でFlexVolumeからCSIに移行します。
他のシナリオでFlexVolumeからCSIに切り替えるには、DingTalkグループ35532895に参加してテクニカルサポートを行います。
FlexVolumeからCSIへの移行時に、FlexVolumeクラスターでバックアップを作成し、CSIクラスターでバックアップを復元する場合は、「バックアップセンターを使用して、以前のバージョンのKubernetesを実行しているACKクラスターからアプリケーションを移行する」をご参照ください。
バックアップコンテナーを変更できますか?
バックアップセンターのバックアップボールトは変更できません。 現在のもののみを削除し、別の名前でバックアップコンテナーを作成できます。
バックアップコンテナーは共有リソースです。 既存のバックアップコンテナーは、[バックアップアップ] または [復元] 状態になります。 バックアップコンテナーのパラメーターを変更すると、アプリケーションのバックアップまたは復元時に必要なデータが見つからない場合があります。 したがって、バックアップボールトを変更したり、同じ名前を使用するバックボールトを作成したりすることはできません。
"cnfs-OSS-*" 形式で名前が付けられていないossバケットにバックアップボールトを関連付けることはできますか?
ACK専用クラスターおよび登録済みクラスター以外のクラスターの場合、バックアップセンターコンポーネントには、デフォルトでcnfs-OSS-* 形式のossバケットに対する読み取りおよび書き込み権限があります。 バックアップがOSSバケット内の元のデータを上書きしないように、バックアップセンターにcnfs-OSS-* 形式のossバケットを作成することを推奨します。
cnfs-OSS-* 形式で名前が付けられていないossバケットをバックアップボールトに関連付けるには、バックアップセンターコンポーネントに権限を付与する必要があります。 詳細については、「ACK専用クラスター」をご参照ください。
権限を付与したら、次のコマンドを実行してコンポーネントを再起動します。
kubectl -ncsdr delete pod -l control-plane=csdr-controller kubectl -ncsdr delete pod -l component=csdrcnfs-OSS-* 形式で名前が付けられていないossバケットがすでにバックアップボールトに関連付けられている場合、接続テストが完了し、バックアップボールトのステータスがAvailableに変更された後、バックアップまたは復元タスクを再実行します。 接続性テストは5分間隔で行う。 次のコマンドを実行して、バックアップコンテナーのステータスを照会できます。
kubectl -ncsdr get backuplocation期待される出力:
NAME PHASE LAST VALIDATED AGE a-test-backuplocation Available 7s 6d1h
バックアップ計画を作成するときにバックアップサイクルを指定するにはどうすればよいですか?
1 4 * * * などのcrontab式を使用して、バックアップサイクルを指定できます。 間隔を直接指定することもできます。 たとえば、バックアップサイクルを6h30mに設定した場合、バックアップ操作は6時間30分ごとに実行されます。
crontab式のアスタリスク (*) は、対応するフィールドの有効な値を表します。 分フィールドの有効値は0〜59である。 サンプルcrontab式:
1 4 * **: バックアップ操作は、毎日午前4時1分に実行されます。0 2 15*1: バックアップ操作は、毎月15日の午前2時に実行されます。
* * * * *
| | | | |
| | | | ·----- day of week (0 - 6) (Sun to Sat)
| | | ·-------- month (1 - 12)
| | .----------- day of month (1 - 31)
| ·-------------- hour (0 - 23)
·----------------- minute (0 - 59)
復元タスクを実行したときのリソースYAMLファイルのデフォルトの変更は何ですか?
リソースを復元すると、リソースのYAMLファイルに次の変更が加えられます。
変更1:
ディスクボリュームのサイズが20 GiB未満の場合、ボリュームサイズは20 GiBに変更されます。
変更2:
サービスはサービスタイプに基づいて復元されます。
NodePortサービス: NodePortサービスのポートは、クラスター間の復元中にデフォルトで保持されます。
LoadBalancerサービス: ExternalTrafficPolicyがLocalに設定されている場合、HealthCheckNodePortはデフォルトでランダムポートを使用します。 ポートを保持するには、復元タスクの作成時に
spec.preserveNodePorts: trueを指定します。バックアップクラスターのサービスが既存のServer Load Balancer (SLB) インスタンスを使用している場合、復元クラスターに復元されたサービスは元のSLBインスタンスを使用しますが、すべてのリスナーがデフォルトで無効になっています。 SLBコンソールでリスナーを設定する必要があります。
バックアップクラスターのLoadBalancerサービスは、クラウドコントローラマネージャー (CCM) によって管理されます。 システムがこれらのサービスを復元すると、CCMはSLBインスタンスを作成します。 詳細については、「LoadBalancerタイプのサービスの設定に関する考慮事項」をご参照ください。
バックアップリソースを表示する方法?
アプリケーション関連のバックアップリソース
クラスター内のYAMLファイルは、バックアップボールトに関連付けられたOSSバケットに保存されます。 次のいずれかの方法を使用して、バックアップリソースを表示できます。
バックアップファイルが同期されているクラスターで次のコマンドを実行し、バックアップリソースを表示します。
kubectl -ncsdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1 kubectl -ncsdr exec -it csdr-velero-xxx -cvelero -- ./velero describe backup <backup-name> --detailsACKコンソールでバックアップリソースを表示します。
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、 を選択します。
[アプリケーションバックアップ] ページで、[バックアップレコード] タブをクリックします。 [バックアップレコード] 列で、表示するバックアップレコードをクリックします。
ディスクボリューム関連のバックアップリソース
にログインします。ECSコンソール.
左側のナビゲーションウィンドウで、.
上部のナビゲーションバーで、リソースが属するリージョンとリソースグループを選択します。
[スナップショット] ページで、ディスクIDに基づいてスナップショットを照会します。
その他のバックアップリソース
にログインします。Cloud Backupコンソール.
左側のナビゲーションウィンドウで、 を選択します。
上部のナビゲーションバーで、リージョンを選択します。
クラスターバックアップの基本情報を表示します。
クラスター: バックアップおよび保護されたクラスターのリスト。 ACK クラスター ID をクリックして、保護された永続ボリュームクレーム (PVC) を表示します。 PVCの詳細については、「Persistent volume claim (PVC) 」をご参照ください。
クライアント状態が異常な場合、ACKクラスターでクラウドバックアップが期待どおりに実行されていません。 ACKコンソールの [DaemonSets] ページに移動して、問題のトラブルシューティングを行います。
バックアップジョブ: バックアップジョブのステータス。
以前のバージョンのKubernetesを実行しているクラスターのデータをバックアップした場合、それ以降のバージョンのKubernetesを実行しているクラスターのデータを復元できますか。
はい。
デフォルトでは、リソースをバックアップすると、リソースでサポートされているすべてのAPIバージョンがバックアップされます。 たとえば、Kubernetes 1.16を実行するクラスターでのデプロイは、拡張機能 /v1beta1、apps/v1beta1、apps/v1beta2、およびapps/v1をサポートしています。 展開をバックアップすると、展開の作成時に使用するバージョンに関係なく、バックアップコンテナーに4つのAPIバージョンすべてが保存されます。 Kubernetes変換機能は、APIのバージョン変換に使用されます。
リソースを復元する場合、復元クラスターが推奨するAPIバージョンを使用してリソースを復元します。 たとえば、Kubernetes 1.28を実行するクラスターで、推奨されるAPIバージョンがapps/v1である場合、復元されたデプロイはapps/v1を使用します。
両方のクラスターでAPIバージョンがサポートされていない場合は、リソースを手動でデプロイする必要があります。 たとえば、Kubernetes 1.16を実行するクラスターのIngressは、拡張機能 /v1beta1とnetworking.k8s.io/v1beta1をサポートしています。 Kubernetes 1.22以降を実行するクラスターのIngressはネットワーク化のみをサポートしているため、これらのクラスターのIngressは復元できません。k8s.io/v1。 APIバージョンの移行の詳細については、「公式ドキュメント」をご参照ください。 APIバージョンの互換性の問題のため、バックアップセンターを使用して、新しいバージョンのKubernetesクラスターから以前のバージョンのKubernetesクラスターにアプリケーションを移行しないことを推奨します。 また、1.16より前のバージョンのKubernetesクラスターからそれ以降のバージョンのKubernetesクラスターにアプリケーションを移行しないことを推奨します。
復元タスクを実行すると、トラフィックは自動的に新しいSLBインスタンスに切り替えられますか?
cGPUはGPUの課金には影響しません。
サービスはサービスタイプに基づいて復元されます。
NodePortサービス: NodePortサービスのポートは、クラスター間の復元中にデフォルトで保持されます。
LoadBalancerサービス: ExternalTrafficPolicyがLocalに設定されている場合、HealthCheckNodePortはデフォルトでランダムポートを使用します。 ポートを保持するには、復元タスクの作成時に
spec.preserveNodePorts: trueを指定します。バックアップクラスターのサービスが既存のServer Load Balancer (SLB) インスタンスを使用している場合、復元クラスターに復元されたサービスは元のSLBインスタンスを使用しますが、すべてのリスナーがデフォルトで無効になっています。 SLBコンソールでリスナーを設定する必要があります。
バックアップクラスターのLoadBalancerサービスは、クラウドコントローラマネージャー (CCM) によって管理されます。 システムがこれらのサービスを復元すると、CCMはSLBインスタンスを作成します。 詳細については、「LoadBalancerタイプのサービスの設定に関する考慮事項」をご参照ください。
デフォルトでは、リスナーが無効になった後、または新しいSLBインスタンスが使用された後、トラフィックは新しいSLBインスタンスに自動的に切り替えられません。 他のクラウドサービスまたはサードパーティのサービス検出を使用し、サービス検出でトラフィックを新しいSLBインスタンスに切り替えたくない場合は、リソースのバックアップ時にサービスを除外できます。 トラフィックを切り替える場合は、手動でサービスを展開できます。
csdr、kube-system、kube-public、およびkube-node名前空間のリソースがデフォルトでバックアップされないのはなぜですか。
csdrはバックアップセンターの名前空間です。 名前空間を直接バックアップして復元すると、復元クラスターでコンポーネントが機能しなくなります。 さらに、バックアップセンターのバックアップおよび同期ロジックでは、バックアップを新しいクラスターに手動で移行する必要はありません。
kube-system、kube-public、およびkube-node-leaseは、Kubernetesクラスターのデフォルトのシステム名前空間です。 クラスターパラメーターと設定の違いにより、クラスター間で名前空間を復元することはできません。 バックアップセンターは、アプリケーションのバックアップと復元に使用されます。 復元タスクを実行する前に、復元クラスターにシステムコンポーネントをインストールして構成する必要があります。たとえば、システムがクラスターを作成すると、次のアドオンが自動的にインストールされます。
Container Registryのパスワード不要のイメージプルコンポーネント: 復元クラスターでacr-configurationに権限を付与し、acr-configurationを設定する必要があります。
ALB Ingress: ALBConfigsを設定する必要があります。
新しいクラスターでkube-systemコンポーネントを直接復元することはできません。 そうしないと、システムコンポーネントが期待どおりに機能しません。
バックアップセンターはECSディスクスナップショットを使用してディスクをバックアップしますか。 デフォルトのスナップショットタイプは何ですか?
次のシナリオでは、バックアップセンターはECSディスクスナップショットを使用してディスクをバックアップします。
クラスターは、ACK管理クラスターまたはACK専用クラスターです。
クラスターのKubernetesバージョンが1.18以降で、クラスターCSIプラグインのバージョンが1.18以降です。
他のシナリオでは、バックアップセンターはCloud Backupを使用してディスクをバックアップします。
デフォルトでは、バックアップセンターによって作成されたディスクスナップショットに対してインスタントアクセス機能が有効になっています。 スナップショットの有効期間は、バックアップ設定で指定された有効期間と同じです。 2023年10月12日の11:00 (UTC + 8) 以降、インスタントアクセス機能のストレージ料金と機能使用料金は課金されなくなります。 詳細については、「インスタントアクセス機能の使用」をご参照ください。
バックアップセンターによって作成されたディスクスナップショットの有効期間が、バックアップ設定で指定された有効期間と異なるのはなぜですか。
ディスクスナップショットの作成は、クラスターの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が存在する場合、
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コンポーネントをv1.20.6以降に更新することを推奨します。
ボリュームのバックアップに適したシナリオと、ボリュームをバックアップする場合はどうすればよいですか?
ボリュームバックアップとは
ECSディスクスナップショットまたはクラウドバックアップを使用して、ボリュームに保存されているデータをクラウド内のデータストアにバックアップできます。 その後、バックアップファイルから、アプリケーションが使用するディスクまたはNASファイルシステムにデータを復元できます。 元のアプリケーションと復元されたアプリケーションは、データソースを共有しません。
データをレプリケートしたり、データソースを共有したりする必要がない場合は、ボリュームのバックアップ手順をスキップできます。 バックアップタスクの除外リストにPVCまたはPVが含まれていないことを確認します。 アプリケーションを復元するときは、元のボリュームのYAMLファイルを復元クラスターに直接デプロイします。
ボリュームのバックアップに適したシナリオは何ですか?
ディザスタリカバリとバージョンの記録。
ディスクボリュームのみが使用されます。 各基本ディスクは1つのノードにのみマウントできます。
クロスリージョンバックアップと復元。 ほとんどの場合、OSSのみがリージョン間通信をサポートしています。
バックアップクラスター内のアプリケーションのデータは、復元クラスター内のアプリケーションのデータから分離する必要があります。
バックアップクラスターと復元クラスターは異なるボリュームプラグインを使用するか、バージョンの違いが大きいです。 この場合、元のボリュームのYAMLファイルを直接使用することはできません。
ステートフルアプリケーションで使用されるボリュームをバックアップしないと、どのようなリスクが発生しますか?
ステートフルなアプリケーションをバックアップするバックアップタスクを作成する場合、アプリケーションが使用するボリュームをバックアップしない場合、アプリケーションの復元時に次の操作が実行されます。
Delete reclaimポリシーを使用するボリューム:
元のボリュームで使用されているStorageClassが復元クラスターに存在する場合、CSIはアプリケーションで使用されているStorageClassとPVCに基づいて新しいPVを自動的にプロビジョニングします。 この操作は、初めてPVCを展開するのと似ています。 たとえば、ステートフル・アプリケーションがディスク・ボリュームを使用している場合、復元タスクによって作成された新しいアプリケーションに新しい空のディスクがマウントされます。 元のボリュームがStorageClassを使用せずに静的にプロビジョニングされている場合、または元のボリュームで使用されているStorageClassが復元クラスターに存在しない場合、復元タスクで作成された新しいPVCとポッドは、PVまたはStorageClassを手動で作成するまで保留状態のままになります。
Retain relaimポリシーを使用するボリューム:
復元タスクがYAMLファイルに基づいてアプリケーションを復元すると、PVはPVCの前に復元されます。 元のボリュームがOSSまたは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ボリュームをバックアップしたい場合はどうすればよいですか?
コンソールでバックアップタスクを作成するときに、[ボリュームバックアップ] を選択します。
kubectlを使用してバックアップタスクを作成する場合は、
spec.pvBackup.de faultPvBackupをtrueに設定します。
アプリケーションのバックアップとデータ保護の使用シナリオは何ですか?
アプリケーションのバックアップ
アプリケーション、サービス、構成ファイルなど、クラスター内のビジネスをバックアップしたい場合。
オプション: アプリケーションをバックアップするときに、アプリケーションにマウントされたボリュームもバックアップします。
説明アプリケーションバックアップ機能では、ポッドにマウントされていないボリュームはバックアップされません。
アプリケーションとすべてのボリュームをバックアップする場合は、データ保護バックアップタスクを作成できます。
クラスター間でアプリケーションを移行し、ディザスタリカバリのためにアプリケーションを迅速に復元する必要があります。
データ保護 (新):
PVCとPVのみを含むボリュームをバックアップします。
バックアップデータとは独立したPVCを復元します。 バックアップセンターを使用して削除されたPVCを復元すると、新しいディスクが作成され、ディスク上のデータはバックアップファイル内のデータと同じになります。 この場合、新しいPVCのマウントパラメータは変更されません。 新しいPVCは、アプリケーションに直接取り付けることができます。
データレプリケーションとディザスタリカバリを実装します。
バックアップセンターに関連付けられているOSSバケットのデータ暗号化を有効にできますか。 KMSに基づいてサーバー側の暗号化を有効にする場合、バックアップセンターに権限を付与するにはどうすればよいですか。
OSSバケットは、サーバー側暗号化とクライアント側暗号化をサポートしています。 バックアップセンター機能は、サーバー側の暗号化のみをサポートします。 バックアップセンターに関連付けられているOSSバケットのサーバー側暗号化を有効にし、OSSコンソールで暗号化方法を設定できます。 詳細については、「サーバー側の暗号化」をご参照ください。
Bring Your Own Key (BYOK) マテリアルを使用してカスタマーマスターキー (CMK) を生成し、CMKを使用してデータを暗号化および復号化する場合は、バックアップセンターの権限にCMK IDを指定する必要があります。 KMSにアクセスする権限をバックアップセンターに付与する必要があります。 以下の手順を実行します。
次のコードブロックに基づいてカスタムポリシーを作成します。 詳細については、「カスタムポリシーの作成」をご参照ください。
{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "kms:List*", "kms:DescribeKey", "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": [ "acs:kms:*:141661496593****:*" ] } ] }上記のポリシーには、現在のAlibaba Cloudアカウントに属するすべてのKMSキーにアクセスする権限が含まれています。 特定のリソースに対して詳細な権限制御を設定する場合は、「権限付与情報」をご参照ください。
ACK専用クラスターまたは登録済みクラスターを使用する場合は、バックアップセンターコンポーネントのインストールに使用するRAMユーザーに権限を付与する必要があります。 詳細については、「RAM ユーザーへの権限の付与」をご参照ください。 他のタイプのクラスターを使用する場合は、AliyunCSManagedBackupRestoreRoleロールに権限を付与する必要があります。 詳細については、「RAM ロールへの権限の付与」をご参照ください。
デフォルトのKMS管理CMKまたは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に変更する場合は、次のコードブロックに基づいてConfigMapを作成します。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" # If you want to change only the image repository, use the following setting. # "case1": "app1,app2" # If you want to change only the image version, use the following setting. # "case1": "v1:v2" # If you want to change only an image in an image repository, use the following setting. # "case1": "docker.io/library/app1:v1,registry.cn-beijing.aliyuncs.com/my-registry/app2:v2"複数のイメージリポジトリとバージョンを変更する場合は、case2、case3、... 、およびcaseNを
dataセクションに追加します。ConfigMapを作成した後、復元タスクを作成するときにimageRegistryMappingフィールドを空のままにします。
説明変更は、クラスター内のすべての復元タスクに適用されます。 上記の説明に基づいて、きめ細かい変更を設定することを推奨します。 たとえば、単一のリポジトリ内でイメージの変更を設定します。 ConfigMapが不要になった場合は、削除します。