このトピックでは、バックアップセンターに関するよくある質問に対する回答を提供します。
目次
共通操作
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 (Object Storage Service) バケット情報を含むバックアップボールトに関する基本情報がクラスターに同期されます。 次に、システムはクラスター内のバックアップボールトからバックアップファイルを初期化します。 バックアップボールトからバックアップファイルを選択して、バックアップボールトが初期化された後にのみアプリケーションを復元できます。
原因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アカウントへのリンクを送信して権限付与を完了します。
タスクのステータスが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エラーが表示されます。
発生原因
指定された OSS バケットは存在しません。
クラスターにはOSSにアクセスする権限がありません。
OSSバケットのネットワークに到達できません。
ソリューション
OSSコンソールにログインします。 バックアップボールトに関連付けられているOSSバケットが存在するかどうかを確認します。
OSSバケットが存在しない場合は、作成してバックアップボールトに関連付けます。 詳細は、「バケットの作成」をご参照ください。
クラスターにOSSへのアクセス権限があるかどうかを確認します。
Container Service for Kubernetes (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バケットにアクセスし、接続タイムアウトエラーが返された場合は、クラスターがインターネットにアクセスできるかどうかを確認します。 詳細については、「既存のACKクラスターによるインターネットへのアクセスの有効化」をご参照ください。
次のシナリオでは、インターネット経由で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: DescribeResourcesModification"、 "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: バックアップボールトで使用されるバケットのストレージクラスは、Archive、Cold Archive、またはDeep Cold Archiveです。 メタデータを記録するファイルは、バックアッププロセスの一貫性を確保するために、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: バックアップボールトで使用するバケットのストレージクラスを標準に変更します。
アーカイブにバックアップデータを保存する場合は、ストレージクラスを自動的に変換し、復旧前にデータを復元するようにライフサイクルルールを設定できます。 詳細については、「ストレージクラスの変換」をご参照ください。
バックアップタスクのステータスがFailedで、「HBRバックアップ要求に失敗しました」エラーが返された場合はどうすればよいですか。
説明
バックアップタスクのステータスがFailedで、「HBRバックアップ要求に失敗しました」エラーが返されます。
発生原因
原因1: クラスターで使用されるボリュームプラグインがCloud Backupと互換性がありません。
原因2: Cloud Backupは、ボリュームモードがBlockのボリュームのバックアップ作成をサポートしていません。 詳細については、「ボリュームモード」をご参照ください。
原因3: Cloud Backupクライアントで例外が発生します。 この場合、OSSボリューム、Apsara file Storage NAS (NAS) ボリューム、CPFSボリューム、ローカルボリュームなどのファイルシステムボリュームをバックアップまたは復元するタスクはタイムアウトまたは失敗します。
ソリューション
解決策1: クラスターがCSIプラグインを使用しない場合、またはクラスターがNFSボリュームやローカルボリュームなどの一般的なKubernetesボリュームを使用しない場合、チケットを起票します。
解決策2: チケットの送信
解決策3: 次の手順を実行します。
にログインします。Cloud Backupコンソール.
左側のナビゲーションウィンドウで、[バックアップ]> コンテナーのバックアップ を選択します。
上部のナビゲーションバーで、リージョンを選択します。
[バックアップジョブ] タブで、[ジョブ名] 検索ボックスで
<Backup-name>-hbrを検索し、バックアップタスクのステータスを確認して原因を特定します。 詳細については、「ACKクラスターのバックアップ」をご参照ください。説明StorageClassの変換またはバックアップタスクを照会するには、対応するバックアップ名を検索します。
バックアップタスクのステータスがFailedで、「OSSバケットのバックアップファイルのチェックに失敗しました」、「OSSバケットへのバックアップファイルのアップロードに失敗しました」、または「OSSバケットからのバックアップファイルのダウンロードに失敗しました」エラーが返された場合はどうすればよいですか?
説明
バックアップタスクのステータスがFailedで、「OSSバケットへのバックアップファイルのアップロードに失敗しました」エラーが返されます。
原因
このエラーは、バックアップボールトに関連付けられているOSSバケットのチェック、アップロード、またはダウンロード時に発生する可能性があります。 考えられる原因：
原因1: OSSバケットにデータ暗号化が設定されていますが、関連するキー管理サービス (KMS) 権限が付与されていません。
原因2: ACK専用クラスターまたは登録済みクラスターでのインストールおよび設定中に、コンポーネントに特定の読み取りおよび書き込み権限がない場合があります。
原因3: ACK専用クラスターまたは登録済みクラスターの権限設定中にRAMユーザーが使用した認証トークンが無効になります。
解決策
解決策1: 「バックアップセンターの関連するOSSバケットのデータ暗号化を有効にできますか? 」 KMSに基づいてサーバー側の暗号化を有効にする場合、関連する権限を追加するにはどうすればよいですか。
解決策2: 権限を設定するときにRAMユーザーに使用される権限ポリシーを確認します。 コンポーネントに必要な権限の詳細については、「手順1: 関連する権限の付与」をご参照ください。
解決策3: 権限設定中に使用されたRAMユーザーの認証トークンがアクティブかどうかを確認します。 取り消された場合は、トークンを再生成し、
csdr名前空間のSecretalibaba-addon-secretの内容を更新してから、次のコマンドを実行してコンポーネントを再起動します。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>出力の [エラー] および [警告] フィールドの内容に基づいて問題を修正します。
コンテンツにエラーが返されない場合は、次のコマンドを実行してエラーログを取得します。
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を検索し、バックアップ失敗の原因を特定します。 詳細については、「ACKクラスターのバックアップ」をご参照ください。
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" エラーが返されます。
原因
復元が必要なディスクボリュームのAccessModeは、ReadOnlyMany (読み取り専用、マルチアタッチ) またはReadWriteMany (読み取り /書き込み、マルチアタッチ) に設定されています。
CSIプラグインは、ディスクボリュームの復元中のマウントに使用されます。 CSIの現在のバージョンでは、以下が適用されます。
複数のインスタンスをディスクにアタッチするには、
multiAttachパラメーターを指定する必要があります。VolumeModeをFilesystemに設定したボリューム (ext4やxfsなどのファイルシステムが使用されることを意味する) は、読み取り専用のマルチアタッチのみをサポートできます。
クラウドディスクストレージの詳細については、「動的にプロビジョニングされたディスクボリュームの使用」をご参照ください。
解決策
ストレージクラス変換機能を使用して、OSSやNASなどのマルチアタッチタイプをサポートするボリュームをクラウドディスクに変換する場合は、新しい復元タスクを作成することを推奨します。 このタスクでは、ストレージクラス変換のターゲットタイプを
alibabacloud-cnfs-nasとして選択し、CNFSが管理するNASボリュームを使用します。 これにより、アプリケーションの異なるレプリカがボリューム上のデータを共有できるようになります。 詳細については、「CNFSを使用したNASファイルシステムの管理 (推奨) 」をご参照ください。ディスクボリュームがバックアップされたときのCSIバージョンが低すぎて
AccessModeフィールドを検証しない場合、バックアップされたボリュームが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=csdrを削除する
cnfs-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時に実行されます。
* * * * *
| | | | |
| | | | | ----- 曜日 (0 - 6) (日曜日から土へ)
| | | · -------- 月 (1 - 12)
| | | .----------- 月の日 (1 - 31)
| · -------------- 時間 (0 - 23)
・ ----------------- 分 (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インスタンスに切り替えられますか?
いいえ。
サービスはサービスタイプに基づいて復元されます。
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ファイルを復元クラスターに直接デプロイします。
バックアップクラスターと復元クラスターで異なるボリュームプラグインを使用する場合、元のボリュームのYAMLファイルは使用できません。 FlexVolumeからCSIに移行する必要があります。 詳細については、「バックアップセンターを使用して、古いKubernetesバージョンを実行するACKクラスターでアプリケーションを移行する」をご参照ください。
ボリュームのバックアップに適したシナリオは何ですか?
ディザスタリカバリとバージョンの記録。
ディスクボリュームのみが使用されます。 各基本ディスクは1つのノードにのみマウントできます。 元のディスクボリュームのYAMLファイルを使用すると、元のノードからディスクボリュームがマウント解除される可能性があります。
クロスリージョンバックアップと復元。 ほとんどの場合、OSSのみがリージョン間通信をサポートしています。
バックアップクラスター内のアプリケーションのデータは、復元クラスター内のアプリケーションのデータから分離する必要があります。
バックアップクラスターと復元クラスターは異なるボリュームプラグインを使用するか、バージョンの違いが大きいです。 この場合、元のボリュームのYAMLファイルを直接使用することはできません。
ボリュームをバックアップしたい場合はどうすればよいですか?
コンソールでバックアップタスクを作成するときに、[ボリュームバックアップ] を選択します。
kubectlを使用してバックアップタスクを作成する場合は、
spec.pvBackup.de faultPvBackupをtrueに設定します。
アプリケーションのバックアップとデータ保護はそれぞれどのようなシナリオで適用できますか?
アプリケーションのバックアップ:
バックアップターゲットは、アプリケーション、サービス、構成ファイルなど、クラスターで実行されている任意のリソースにすることができます。
アプリケーションによってマウントされたボリュームからデータをバックアップすることもできます。
説明どのポッドによってもマウントされていないボリュームからのデータはバックアップされません。
アプリケーションと関連するすべてのデータの両方をボリュームからバックアップするには、データ保護タイプを使用してバックアップを作成することをお勧めします。
ディザスタリカバリシナリオでのクラスターの移行とアプリケーションの迅速な復旧。
データ保護 (新):
バックアップ対象はボリューム内のデータであり、永続ボリュームクレーム (PVC) と永続ボリューム (PV) のリソースのみが含まれます。
リカバリターゲットは、アプリケーションが直接マウントできるPVCです。 このPVCによってポイントされるデータは、バックアップデータとは無関係である。 PVCが意図せず削除された場合、バックアップセンターから復元すると、バックアップされたデータと同じデータを含む新しいクラウドディスクが作成されます。 PVCが指すクラウドディスクインスタンスを除いて、PVCのすべてのマウントパラメーターは変更されません。 これにより、アプリケーションは復元されたPVCを直接マウントできます。
データ複製とデータ災害復旧のシナリオ。
バックアップセンターで関連するOSSバケットのデータ暗号化を有効にできますか。 有効にするときKMSに基づくサーバー側暗号化、関連する権限を追加するにはどうすればよいですか?
OSSバケットは、サーバー側暗号化またはクライアント側暗号化のいずれかを使用して暗号化できます。 バックアップセンターは、OSSバケットのサーバー側暗号化のみをサポートしています。 OSSコンソールを使用して、関連付けられたバケットのサーバー側暗号化を有効化および設定できます。 OSSバケットのサーバー側暗号化とその設定の詳細については、「サーバー側暗号化」をご参照ください。
暗号化と復号化にKMS-managedによる独自のキー (BYOK) を使用し、カスタマーマスターキー (CMK) IDを指定する場合は、次の手順を実行して、バックアップセンターに関連するKMS権限を追加する必要があります。
次の内容を使用して、カスタム権限ポリシーを作成します。 詳細については、「JSONタブでカスタムポリシーを作成する」をご参照ください。
{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "kms:List*", "kms:DescribeKey", "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": [ "acs:kms:*:141661496593****:*" ] } ] }上記の権限ポリシーでは、Alibaba Cloudアカウントに属するすべてのKMS管理CMKを使用できます。 要件に基づいてきめ細かいリソースポリシーを構成するには、「権限ポリシー」をご参照ください。
ACK専用クラスターと登録済みクラスターの場合、インストール時に使用するRAMユーザーに権限を付与するには、「RAMユーザーへの権限の付与」をご参照ください。 他のクラスターについては、AliyunCSManagedBackupRestoreRoleに権限を付与するには、「RAMロールへの権限の付与」をご参照ください。
KMSで管理されているデフォルトのCMKを使用するか、暗号化と復号化に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に調整する必要があるとしたら、次のYAMLテンプレートを使用して構成ファイルを作成できます。apiVersion: v1 kind: ConfigMap metadata: name: <CONFIG_NAME> namespace: csdr labels: velero.io/plugin-config: "" velero.io/change-image-name: RestoreItemAction data: "case1":"app1:v1,app2:v2" # Modify only the image repositry: # "case1": "app1,app2" # Modify only the version of the image repository: # "case1": "v1:v2" # Modify only the image under a specific registry: # "case1": "docker.io/library/app1:v1,registry.cn-beijing.aliyuncs.com/my-registry/app2:v2"複数の変更が必要な場合は、データセクションでcase2やcase3などのオプションを設定できます。
構成ファイルが作成されたら、復元タスクの開始に進みます。 imageRegistryMappingフィールドは空です。
説明構成の変更は、クラスター内のすべての復元タスクに影響します。 特定のレジストリに調整を制限するなど、正確な調整ポリシーを構成するには、上記のコメントを参照してください。 設定が不要になった場合は削除します。