Container Service for Kubernetes:バックアップセンターに関するよくある質問

ジョブステータスの理解

トラブルシューティングを実施する前に、各ステータスの意味を確認してください。

• 失敗：ジョブは完了していません。上記のコマンドを使用してエラー詳細を確認してください。

• 一部失敗：ジョブは完了しましたが、一部のリソースの処理に失敗しています。ジョブの詳細から Errors フィールドおよび Warnings フィールドを確認してください。

• 完了：ジョブは正常に終了しました。復元クラスターに一部のリソースが存在しない場合は、Warnings フィールドを確認してください。構成による除外やビジネスロジックによる再利用により、リソースが除外されている可能性があります。

• InProgress：ジョブは実行中です。ジョブが長時間この状態のままの場合、「ジョブが InProgress のまま停止している理由」をご参照ください。

コンソールに「動作中のコンポーネントが異常です」または「現在のデータの取得に失敗しました」と表示されるのはなぜですか？

バックアップセンターのコンポーネントが正しくインストールされていません。以下の点を確認してください。

• クラスターにノードが存在すること。ノードがない場合、バックアップセンターをデプロイできません。

• クラスターで FlexVolume を使用している場合、まず CSI に切り替えてください。「FlexVolume クラスターにおける migrate-controller コンポーネントの起動失敗」をご参照ください。

• kubectl を使用する場合は、YAML 構成が正しいことを確認してください。詳細については、「kubectl を使用してアプリケーションをバックアップおよび復元する」をご参照ください。

• ACK 専用クラスターおよび登録済みクラスターでは、必要な権限が付与されていることを確認してください。詳細については、「ACK 専用クラスター」および「登録済みクラスター」をご参照ください。

• csdr-controller および csdr-velero のデプロイメントが、csdr 名前空間内でリソース不足またはスケジューリング制約により失敗していないか確認し、問題を解決してください。

コンソールに「名前はすでに使用されています。名前を変更して再試行してください」と表示されるのはなぜですか？

タスクを削除すると、システムはクラスター内に deleterequest リソースを作成し、バックアップリソース自体の削除だけでなく一連の削除操作を実行します。この操作が失敗または中断された場合、同一の名前を持つリソースがクラスター内に残り、このエラーが発生します。

以下のコマンドを実行して、競合するリソースを削除してください。たとえば、エラーが deleterequests.csdr.alibabacloud.com "xxxxx-dbr" already exists の場合：

kubectl -n csdr delete deleterequests xxxxx-dbr

その後、新しい名前でタスクを作成してください。

クラスター間復元時に既存のバックアップを選択できないのはなぜですか？

最も一般的な原因は、ターゲットクラスターでバックアップボールトが初期化されていないことです。復元 ページで バックアップボールト を見つけ、バックアップボールトの初期化 をクリックしてください。初期化が完了したら、バックアップを選択して復元を実行します。

初期化に失敗した場合、ターゲットクラスター内の backuplocation リソースのステータスが Unavailable となります。以下のコマンドで確認してください。

kubectl get -n csdr backuplocation <backuplocation-name>

期待される出力例：

NAME                    PHASE       LAST VALIDATED   AGE
<backuplocation-name>   Available   3m36s            38m

ステータスが Unavailable の場合、「ジョブが「VaultError: xxx」というエラーで失敗する理由」をご参照ください。

バックアップボールトのステータスに問題がない場合、ソースクラスターのコンソールでバックアップジョブのステータスが 完了 となっていることを確認してください。失敗または実行中のバックアップジョブは、クラスター間復元で選択できません。

コンソールに「現在のコンポーネントに必要なサービスロールが承認されていません」（AddonRoleNotAuthorized）と表示されるのはなぜですか？

migrate-controller 1.8.0 以降、ACK マネージドクラスターにおけるクラウドリソース認証ロジックが更新されました。このバージョンを初めてインストールまたはアップグレードする際には、Alibaba Cloud アカウントによる承認が必要です。

• Alibaba Cloud アカウントでログインしている場合、「承認」をクリックしてください。

• RAM ユーザーとしてログインしている場合、「承認リンクのコピー」をクリックし、Alibaba Cloud アカウント所有者に承認を依頼してください。

コンソールに「現在のアカウントに、この操作に必要なクラスターコンポーネント RBAC 権限が付与されていません」（APISERVER.403）と表示されるのはなぜですか？

コンソールは API サーバーと連携してバックアップおよび復元ジョブを送信・監視します。O&M エンジニアおよび開発者のデフォルト権限セットには、バックアップセンターに必要な一部の権限が含まれていません。

次の ClusterRole 権限をバックアップセンター オペレーターに付与します。詳細については、「カスタム RBAC ロールを使用してクラスター内のリソース操作を制限する」をご参照ください。

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 のままになるのはなぜですか？

バックアップセンターが異常終了し、InProgress 状態のジョブが残っています。これらのジョブの finalizers フィールドがリソース削除をブロックしています。

次のコマンドを実行して、名前空間をブロックしているものを特定します。

kubectl describe ns csdr

ブロックされているジョブが不要であることを確認し、その finalizers を削除してください。csdr 名前空間が削除された後：

• アップグレードの場合：migrate-controller コンポーネントを再インストールしてください。

• アンインストールの場合：コンポーネントは正常に削除されます。

ジョブが「internal error」というエラーで失敗するのはなぜですか？

コンポーネントまたは基盤となるクラウドサービスで予期しない例外が発生しました。たとえば、クラウドサービスが現在のリージョンで利用不可である場合があります。

エラーが HBR backup/restore internal error の場合、「Cloud Backup コンソール」にアクセスし、コンテナバックアップ機能がご利用のリージョンで有効であることを確認してください。

ジョブが「create cluster resources timeout」というエラーで失敗するのはなぜですか？

StorageClass 変換または復元中に、バックアップセンターは一時的な Pod、PVC、PV を作成します。これらのリソースが長期間利用不可の状態になると、このタイムアウトエラーが発生します。

1. ブロックされたリソースを特定します。

      kubectl -n csdr describe <applicationbackup/converttosnapshot/applicationrestore> <task-name>

   たとえば、wait for created tmp pvc default/demo-pvc-for-convert202311151045 for convertion bound time out という出力は、demo-pvc-for-convert202311151045 PVC が default 名前空間でバインドされていないことを示します。

2. PVC のステータスを確認して根本原因を特定します。

      kubectl -n default describe pvc demo-pvc-for-convert202311151045

一般的な原因は以下のとおりです。

• クラスターまたはノードのリソース不足。

• 復元クラスターに必要なストレージクラスが存在しない。復元前に、StorageClass 変換機能を使用して利用可能なストレージクラスを選択してください。

• ストレージクラスの基盤となるストレージが利用不可。たとえば、指定されたディスクタイプが現在のゾーンでサポートされていない場合など。

• alibabacloud-cnfs-nas に関連付けられているコンテナ ネットワーク ファイル システム (CNFS) が異常です。詳細については、「CNFS を使用して NAS ファイルシステムを管理する (推奨)」をご参照ください。

• マルチゾーンクラスターで、volumeBindingMode: Immediate を設定したストレージクラスを選択した場合。

ストレージのトラブルシューティングについては、「ストレージの問題をトラブルシューティングする」をご参照ください。

ジョブが「addon status is abnormal」というエラーで失敗するのはなぜですか？

csdr 名前空間内のコンポーネントが異常です。ステータスを確認してください。

kubectl get pod -n csdr
kubectl describe pod <pod-name> -n csdr

対処手順については、「ジョブが InProgress のまま停止している理由」をご参照ください。

ジョブが「VaultError: xxx」というエラーで失敗するのはなぜですか？

このエラーは、バックアップボールトが OSS バケットに到達できないことを意味します。以下の点を確認してください。

1. OSS バケットの存在を確認します。

OSS コンソールにログオンし、バックアップボールトに関連付けられているバケットが存在することを確認します。存在しない場合は、新しいバケットを作成して再関連付けします。詳細については、「バケットの作成」をご参照ください。

削除済みのものと同じ名前のバックアップボールトを作成することはできません。また、名前が cnfs-oss-* 形式に従わない OSS バケットをボールトに関連付けることもできません。誤った名前のバケットに関連付けられた既存のボールトがある場合、別の名前で新しいボールトを作成し、cnfs-oss-* バケットに関連付けてください。

2. OSS アクセス権限を確認します。

• ACK Pro マネージドクラスターの場合、OSS バケット名が cnfs-oss- で始まる場合は、OSS 権限の設定は不要です。

• 詳細については、「migrate-controller のインストールと権限の付与」をご参照ください。ACK 専用クラスターおよび登録済みクラスターの場合、OSS 権限を設定します。

コンソール外でコンポーネントを v1.8.0 以降にインストールまたはアップグレードした ACK マネージドクラスターの場合、以下のコマンドを実行して OSS 権限が設定されているか確認してください。

kubectl get secret -n kube-system | grep addon.aliyuncsmanagedbackuprestorerole.token

期待される出力例：

addon.aliyuncsmanagedbackuprestorerole.token          Opaque                      1      62d

出力が一致する場合、権限は適切に設定されています。一致しない場合は、以下のいずれかの方法で権限を付与してください。

• ACK 専用クラスターおよび登録済みクラスターの手順に従ってください。詳細については、「バックアップサービスコンポーネントのインストールと権限の設定」をご参照ください。

• Alibaba Cloud アカウントを承認するには、「承認」をクリックしてください。これはアカウントごとに一度だけ実行すれば十分です。

3. ネットワーク構成を確認します。

kubectl get backuplocation <backuplocation-name> -n csdr -o yaml | grep network

• network: internal — ボールトは内部ネットワーク経由で OSS にアクセスします。

• network: public — ボールトはインターネット経由で OSS にアクセスします。これによりタイムアウトが発生する場合は、クラスターがインターネットにアクセスできることを確認してください。詳細については、「既存の ACK クラスターがインターネットにアクセスできるようにする」をご参照ください。

以下のシナリオでは、ボールトがパブリックネットワークアクセスを使用する必要があります。

• クラスターと OSS バケットが異なるリージョンにある場合。

• クラスターは ACK Edge クラスターです。

• クラスターが Cloud Enterprise Network（CEN）、Express Connect、または VPN を介して VPC に接続されていない登録済みクラスターである場合、またはリージョンの内部 OSS CIDR ブロックへのルートが設定されていない場合。

パブリックネットワークアクセスに切り替えるには、以下のコマンドを実行してください。

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>"}}]'

<region-id> は OSS バケットのリージョン（例：cn-hangzhou）に置き換えてください。

ジョブが「HBRError: check HBR vault error」というエラーで失敗するのはなぜですか？

Cloud Backup が有効化されていないか、必要な権限が付与されていません。

1. Cloud Backup サービスを有効化します。詳細については、「Cloud Backup の有効化」をご参照ください。

2. 中国 (ウランチャブ)、中国 (河源)、または中国 (広州) のクラスターでは、有効化後に Cloud Backup が API Gateway にアクセスすることも承認してください。詳細については、「(オプション) ステップ 3: Cloud Backup サービスによる API Gateway へのアクセスを承認する」をご参照ください。

3. ACK 専用クラスターおよび登録済みクラスターの場合、Cloud Backup RAM 権限が付与されていることを確認してください。詳細については、「migrate-controller バックアップサービスコンポーネントのインストールと権限の設定」をご参照ください。

ジョブが「HBRError: ... code: 400, Illegal request. Please modify the parameters」というエラーで失敗するのはなぜですか？

該当リージョンの ack-backup-data Cloud Backup リポジトリが削除されています。

リージョンで初めてバックアップを作成すると、バックアップセンターは自動的に ack-backup-data リポジトリを作成してバックアップを保存します。このリポジトリが削除されると、以降のジョブはこのエラーで失敗します。

1. 該当リージョンでバックアップセンターを使用している すべての クラスターで、バックアップボールトのレコードをクリアします。

      kubectl -ncsdr delete backuplocation --all
      kubectl -ncsdr delete backupstoragelocation --all

2. クラスターに戻り、新しいバックアップを作成します。コンポーネントは自動的に新しい ack-backup-data リポジトリを作成し、バックアップボールトに関連付けます。

ジョブが「hbr task finished with unexpected status: FAILED, errMsg ClientNotExist」というエラーで失敗するのはなぜですか？

hbr-client DaemonSet が csdr 名前空間内のノードで正しく実行されていません。

1. 異常な hbr-client Pod を確認します。

      kubectl -n csdr get pod -lapp=hbr-client

2. Pod が異常な状態にある場合、Pod の IP アドレス、メモリ、CPU の不足が原因ではないか確認してください。CrashLoopBackOff 状態の Pod の場合は、ログを確認します。

      kubectl -n csdr logs -p <hbr-client-pod-name>

   ログに SDKError: StatusCode: 403, Code: MagpieBridgeSlrNotExist が含まれている場合は、「(オプション) 手順 3: Cloud Backup に API Gateway へのアクセスを許可する」 を参照して、必要な権限を付与してください。

3. その他の SDK エラーについては、EC エラーコードを使用してトラブルシューティングします。「EC エラーコードを使用して問題をトラブルシューティングする」をご参照ください。

ジョブが InProgress のまま停止しているのはなぜですか？

kubectl get pod -n csdr
kubectl describe pod <pod-name> -n csdr

kubectl get volumesnapshot -n <backup-namespace>

バックアップが「OSS バケットに既にバックアップが存在します」というエラーで失敗するのはなぜですか？

バックアップボールトに関連付けられた OSS バケットに、同じ名前のバックアップが既に存在します。新しい名前でバックアップを作成してください。

バックアップが現在のクラスターで非表示になる理由はいくつかあります。たとえば、実行中または失敗したジョブに属するため（クラスター間で同期されない）、別のクラスターで削除されたため（ファイルはマークされるが OSS から削除されない）、または現在のクラスターがそのバックアップを格納したボールトに関連付けられていないためなどです。

バックアップが「target namespace の取得に失敗しました」というエラーで失敗するのはなぜですか？

通常、スケジュールされたバックアップジョブで発生します。名前空間の選択が無効です。

• 含める を選択した場合、選択したすべての名前空間が削除されています。

• 除外 を選択した場合、除外した名前空間がクラスター内に存在しなくなっています。

バックアッププランを更新して、名前空間の選択を修正してください。

バックアップが「velero backup process timeout」というエラーで失敗するのはなぜですか？

主な原因は以下の 2 つです。

OSS バケットストレージクラス: バケットのストレージクラスがアーカイブストレージ、コールドアーカイブストレージ、またはディープコールドアーカイブストレージの場合、バックアップセンターはメタデータファイルを更新できません (最初にアーカイブされたファイルを解凍する必要があります)。バケットのストレージクラスを標準ストレージに変更します。アーカイブされたデータを低コストで保持するには、ライフサイクルルールを設定してストレージクラスを自動的に変換します。詳細については、「ストレージクラスの変換」をご参照ください。

サブタスクのタイムアウト：バックアップサブタスクのデフォルトタイムアウトは 60 分です（migrate-controller 1.7.7 以降）。クラスターに多数のリソースがある場合や、API サーバーのレイテンシーが高い場合、csdr-config ConfigMap でこの値を増加させることができます。

kubectl edit -n csdr cm csdr-config

velero_timeout_minutes を applicationBackup セクションに追加します。たとえば、タイムアウトを 100 分に設定するには：

apiVersion: v1
data:
  applicationBackup: |
    ...
    velero_timeout_minutes: 100

変更を有効にするには、コントローラーを再起動してください。

kubectl -n csdr delete pod -l control-plane=csdr-controller

バックアップが「HBR backup request failed」というエラーで失敗するのはなぜですか？

主な原因は以下の 3 つです。

互換性のないストレージプラグイン：クラスターで Alibaba Cloud 以外の CSI ストレージプラグインを使用している場合、または PV が NFS や LocalVolume などの標準 Kubernetes ボリュームタイプでない場合、「チケットを送信」してください。

ブロックモードボリューム：Cloud Backup は、VolumeMode が Block のボリュームをサポートしていません。クラスターで CSI を使用している場合、データバックアップにはデフォルトでディスクスナップショットが使用され、ディスクスナップショットはブロックモードボリュームをサポートしています。ストレージプラグインの種類が不適切な場合、CSI に切り替え、バックアップコンポーネントを再インストールしてバックアップを再実行してください。

Cloud Backup クライアントの問題：ファイルシステムボリューム（OSS、NAS、CPFS、またはローカルボリューム）の場合、Cloud Backup クライアントがタイムアウトまたは失敗している可能性があります。調査手順は以下のとおりです。

1. Cloud Backup コンソール にログインします。

2. バックアップ > コンテナバックアップ に移動し、バックアップジョブ タブをクリックします。

3. 上部のナビゲーションバーからリージョンを選択します。

4. <backup-name>-hbr を検索して、ジョブのステータスと失敗理由を確認します。詳細については、「ACK クラスターをバックアップする」をご参照ください。

StorageClass 変換またはバックアップジョブを照会するには、バックアップ名を検索してください。

バックアップが「hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST」というエラーで失敗するのはなぜですか？

サードパーティ製 CSI または自己管理型ストレージタイプ（NFS、Ceph）の場合：

バックアップセンターは、標準 Kubernetes ボリュームマウントパスをデータバックアップパスとして使用します。標準 CSI のデフォルトパスは /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount です。クラスターの kubelet ルートパスが変更されている場合、Cloud Backup はデータを見つけることができません。

ボリュームがマウントされているノードにログインしてトラブルシューティングを行ってください。

1. kubelet ルートパスを特定します。以下のコマンドを実行します。

   • 起動コマンドに --root-dir が含まれている場合、その値が kubelet ルートパスです。

   • --config が含まれている場合、設定ファイルで root-dir フィールドを確認してください。

   • どちらも存在しない場合、/etc/systemd/system/kubelet.service で EnvironmentFile の参照を確認し、そのファイルで ROOT_DIR を確認してください。

   • 何も見つからない場合、kubelet ルートパスはデフォルトの /var/lib/kubelet です。

      ps -elf | grep kubelet

2. ルートパスがシンボリックリンクかどうか確認します。

      ls -al <root-dir>

   出力に kubelet -> /var/lib/container/kubelet のような内容が表示される場合、実際のルートパスは /var/lib/container/kubelet です。

3. 対象ボリュームのデータが <root-dir>/pods/<pod-uid>/volumes の下に存在することを確認してください。

4. KUBELET_ROOT_PATH 環境変数を csdr/csdr-controller デプロイメントに、実際の kubelet ルートパスとして設定してください。

HostPath ストレージの場合：

HostPath は kubelet ルートパスの下にマウントパスを作成しません。バックアップコンポーネントは、デフォルトでノードパスからデータを読み取ることができません。「チケットを送信」してください。

バックアップが「OSS バケット内のバックアップファイルの確認に失敗しました」、「OSS バケットへのバックアップファイルのアップロードに失敗しました」、または「OSS バケットからのバックアップファイルのダウンロードに失敗しました」というエラーで失敗するのはなぜですか？

OSS サーバーがバックアップボールトバケットでのファイル操作中にエラーを返しました。主な原因は以下の 3 つです。

KMS 権限の不足：OSS バケットで KMS CMK を使用したサーバ側暗号化を有効化している場合、バックアップセンターには追加の権限が必要です。「バックアップセンターは関連付けられた OSS バケットの KMS 暗号化をサポートしていますか？」をご参照ください。

不完全な OSS 権限: ACK 専用クラスターおよび登録済みクラスターの場合、コンポーネントのインストール時に使用される RAM ユーザーの権限ポリシーを確認してください。詳細については、「手順 1: 権限の設定」をご参照ください。

取り消された認証情報：ACK 専用クラスターおよび登録済みクラスターの場合、RAM ユーザーの認証情報がまだ有効であるか確認してください。取り消された場合は、新しい認証情報を取得し、alibaba-addon-secret シークレットを csdr 名前空間で更新して、コンポーネントを再起動してください。

kubectl -nkube-system delete pod -lapp=migrate-controller

バックアップのステータスが PartiallyFailed で「PROCESS velero partially completed」と表示されるのはなぜですか？

一部のクラスターリソースのバックアップに失敗しました。以下のコマンドを実行して、どのリソースが失敗し、その理由を確認してください。

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」と表示されるのはなぜですか？

Cloud Backup が一部のファイルシステムボリューム（OSS、NAS、CPFS、またはローカルボリューム）のバックアップに失敗しました。これは以下のような理由で発生する可能性があります。

• 一部のボリュームで使用されているストレージプラグインがサポートされていない。

• バックアップ中にファイルが削除され、整合性エラーが発生した。

調査するには、Cloud Backup コンソールの[バックアップ ジョブ]タブで、<backup-name>-hbr を検索します。正しいリージョンを選択し、ジョブのステータスと障害の原因を確認します。「ACK クラスターのバックアップ」を参照してください。

StorageClass 変換が「storageclass xxx not exists」というエラーで失敗するのはなぜですか？

変換先として選択されたターゲットストレージクラスが、現在のクラスターに存在しません。

1. 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

2. クラスター内に必要なストレージクラスを作成します。

3. StorageClass 変換を設定した状態で、復元ジョブを再度実行します。

StorageClass 変換が「only support convert to storageclass with CSI diskplugin or nasplugin provisioner」というエラーで失敗するのはなぜですか？

StorageClass 変換は、Alibaba Cloud CSI ディスクおよび NAS ボリュームタイプのみをターゲットとしてサポートしています。その他の要件については、「チケットを送信」してください。

パブリックネットワークアクセスをサポートするストレージサービス（例：OSS）を使用している場合、静的にプロビジョニングされた PV および PVC を作成し、StorageClass 変換を行わずにアプリケーションを復元します。詳細については、「ossfs 1.0 を使用した静的にプロビジョニングされたボリュームの利用」をご参照ください。

StorageClass 変換が「current cluster is multi-zoned」というエラーで失敗するのはなぜですか？

マルチゾーンクラスターで、volumeBindingMode が Immediate のディスクタイプ StorageClass に変換する場合、CSI は固定ゾーンに PV を作成します。Pod は別のゾーンにスケジュールできず、Pending のままになります。

1. StorageClass 変換タスクをリセットします（上記と同じコマンドを使用）。

2. 正しいストレージクラスを選択します。

   • コンソール： alicloud-disk を選択します。デフォルトは alicloud-disk-topology-alltype です。

   • コマンドライン： alicloud-disk-topology-alltype を使用します。また、volumeBindingMode を WaitForFirstConsumer に設定することで、PV が Pod と同じゾーンに作成されるように保証できます。

3. 復元ジョブを再度実行します。

復元が「multi-node writing is only supported for block volume」というエラーで失敗するのはなぜですか？

復元対象のアプリケーションには、AccessMode が ReadWriteMany または ReadOnlyMany のボリュームがあります。Alibaba Cloud ディスクストレージ（デフォルトでは複数のマウントをサポートしません）に復元する場合、CSI はマウントをブロックします。

これは以下の 3 つのシナリオで発生します。

• バックアップクラスターでの古い CSI バージョンまたは FlexVolume：以前の CSI バージョンでは、マウント時に AccessModes をチェックしていませんでした。新しい CSI バージョンのクラスターに復元すると、ボリュームが失敗します。v1.8.4 以降では、バックアップコンポーネントが自動的にディスクボリュームの AccessModes を ReadWriteOnce に変換します。コンポーネントをアップグレードして、再度復元してください。

• 復元クラスターにストレージクラスが不足している：ボリュームはデフォルトで Alibaba Cloud ディスクボリュームにマッチします。復元前に、復元クラスターに同じ名前のストレージクラスを作成するか、StorageClass 変換を使用してターゲットを指定してください。

• 手動でのストレージクラスのディスクへの変換: AccessModes を ReadWriteOnce に変換するには、convertToAccessModes パラメーターを追加します。「convertToAccessModes」をご参照ください。

復元が「only disk type PVs support cross-region restore in current version」というエラーで失敗するのはなぜですか？

クロスリージョン復元は、ディスクボリュームに対してのみサポートされています（migrate-controller 1.7.7 以降）。インターネットアクセスをサポートするその他のストレージタイプ（OSS など）の場合は、静的プロビジョニングされた PV および PVC を作成して、アプリケーションを復元します。詳細については、「ossfs 1.0 静的プロビジョニングボリュームを使用する」をご参照ください。

復元が「ECS snapshot cross region request failed」というエラーで失敗するのはなぜですか？

ディスクボリュームのクロスリージョン復元には、ECS ディスクスナップショット権限が必要ですが、すべてのクラスタータイプに対してデフォルトで付与されるわけではありません。

ACK 専用クラスターおよび、ECS インスタンス上にデプロイされたセルフマネージド Kubernetes に接続されている登録済みクラスターの場合、ECS ディスク スナップショットの権限を付与します。詳細については、「登録済みクラスター」をご参照ください。

復元が「accessMode of PVC xxx is xxx」というエラーで失敗するのはなぜですか？

復元中のディスクボリュームには、AccessMode が ReadOnlyMany または ReadWriteMany があります。CSI は以下のルールを適用します。

• multiAttach が有効化されたボリュームのみ、複数のインスタンスにマウントできます。

• VolumeMode: Filesystem（ext4 または xfs）のボリュームは、読み取り専用モードでのみ複数のインスタンスにマウントできます。

推奨される対処方法は以下のとおりです。

• マルチマウントボリューム（OSS または NAS など）をディスクストレージに変換する場合、新しい復元ジョブを作成し、StorageClass の変換先として alibabacloud-cnfs-nas を選択します。これは、複数のマウントをサポートする CNFS 管理の NAS ボリュームを使用します。詳細については、「CNFS を使用した NAS ファイルシステムの管理（推奨）」をご参照ください。

• バックアップ済みディスク PV 自体が現在の CSI 要件を満たさない場合（CSI バージョンが低かったときにバックアップされ、AccessMode 検出が適用されていなかった場合）、スケジューリング中の強制的なディスクデタッチを回避するために、ワークロードを 動的にプロビジョニングされたディスクボリューム を使用するように移行してください。

復元ステータスが Completed ですが、一部のリソースが欠落しています。なぜですか？

完了 ステータスは、すべてのリソースが復元されたことを保証するものではありません。各可能性を確認してください。

リソースがバックアップされていない。 以下のコマンドを実行してバックアップを確認します。

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe backup <backup-name> --details

バックアップ対象として選択されていない名前空間で実行中のPodのクラスター レベルのリソースは、デフォルトでバックアップされません。クラスター レベルのバックアップ構成については、「クラスター レベルのバックアップ」をご参照ください。

復元時にリソースが除外された。 復元ジョブの名前空間、リソースタイプ、その他のフィルターによってリソースが除外されていないか確認し、復元を再実行してください。

復元サブタスクが一部失敗した。 以下のコマンドを実行して失敗を特定します。

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 フィールドの問題を修正してください。

リソースが作成後に再利用された。 リソースの監査ログを確認して、ownerReferences やビジネスロジックにより、作成後に削除されたかどうかを確認してください。

FlexVolume クラスターにおける migrate-controller コンポーネントの起動失敗

migrate-controller コンポーネントは FlexVolume クラスターをサポートしていません。バックアップセンターを使用する前に、CSI に移行してください。

• csi-compatible-controller コンポーネントを使用して FlexVolume から CSI へ移行する

• ストレージクラスターがない場合の FlexVolume から CSI への移行

• FlexVolume で管理される静的にプロビジョニングされた NAS ボリュームを CSI に移行する

• FlexVolume で管理される静的にプロビジョニングされた OSS ボリュームを CSI に移行する

• その他のケースについては、DingTalk ユーザーグループ（グループ ID：35532895）に参加して相談してください。

移行中に FlexVolume クラスターのアプリケーションをバックアップし、CSI クラスターに復元するには、「バックアップセンターを使用して旧バージョンの Kubernetes クラスターのアプリケーションを移行する」をご参照ください。

バックアップボールトを変更できますか？

いいえ。変更を行うには、現在のバックアップボールトを削除し、別の名前で新しいボールトを作成してください。

バックアップボールトは、いつでもアクティブに使用される可能性のある共有リソースであるため、パラメーターを変更すると、進行中のバックアップまたは復元中にデータにアクセスできなくなるリスクがあります。また、削除済みのボールトと同じ名前の新しいボールトを作成することもできません。

「cnfs-oss-*」形式でない名前の OSS バケットを使用できますか？

ACK 専用クラスターおよび登録済みクラスター以外のクラスターの場合、バックアップセンターはデフォルトで cnfs-oss-* 形式の名前の OSS バケットへの読み書きアクセスを持ちます。異なる名前のバケットを使用するには、追加の設定が必要です。

1. コンポーネントに OSS 権限を設定します。「ACK 専用クラスター」をご参照ください。

2. バックアップサービスコンポーネントを再起動してください。

      kubectl -n csdr delete pod -l control-plane=csdr-controller
      kubectl -n csdr delete pod -l component=csdr

非標準のバケット名でボールトを作成した後、バックアップまたは復元操作を開始する前に、接続性チェックが完了するまで（約 5 分）待機してください。ボールトのステータスを確認します。

kubectl -n csdr get backuplocation

期待される出力例：

NAME                    PHASE       LAST VALIDATED   AGE
a-test-backuplocation   Available   7s               6d1h

バックアッププランを作成する際にバックアップスケジュールを指定するにはどうすればよいですか？

バックアップスケジュールは、以下の 2 つの形式をサポートしています。

• Cron 式：たとえば、1 4 * * * は毎日午前 4 時 1 分にバックアップを実行します。

• 間隔：たとえば、6h30m は 6 時間 30 分ごとにバックアップを実行します。

Cron 形式のリファレンス：

 *  *  *  *  *
 |  |  |  |  |
 |  |  |  |  ·----- 曜日（0 - 6、日曜日 - 土曜日）
 |  |  |  ·-------- 月（1 - 12）
 |  |  .----------- 日（1 - 31）
 |  ·-------------- 時（0 - 23）
 ·----------------- 分（0 - 59）

例：0 2 15 * 1 は毎月 15 日の午前 2 時にバックアップを実行します。

復元ジョブはバックアップされた YAML リソースにどのような変更を加えますか？

復元ジョブは、以下の自動調整を行います。

ディスクボリュームサイズ：ディスクボリュームが 20 GiB より小さい場合、サイズは 20 GiB に拡大されます。

サービス：サービスの種類に応じて復元されます。

• NodePort サービス：クロスクラスター復元では、デフォルトでサービスポートが保持されます。

• LoadBalancer サービス：

  • ExternalTrafficPolicy が Local の場合、HealthCheckNodePort にはランダムポートが使用されます。元のポートを保持するには、復元ジョブの spec.preserveNodePorts: true を設定してください。

  • サービスがバックアップクラスターの既存の SLB インスタンスを使用している場合、復元されたサービスは同じ SLB インスタンスを使用しますが、リスナーは無効化されます。SLB コンソールでリスナーを設定してください。

  • バックアップクラスター内の CCM によって SLB インスタンスが管理されている場合、CCM は新しい SLB インスタンスを作成します。 詳細については、「LoadBalancer サービスの設定に関する考慮事項」をご参照ください。

バックアップ内のリソースを確認するにはどうすればよいですか？

クラスターアプリケーションのバックアップ：

バックアップファイルが同期されているクラスターで実行します。

kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1
kubectl -n csdr exec -it csdr-velero-xxx -c velero -- ./velero describe backup <backup-name> --details

または、ACK コンソールを使用します。自分のクラスターに移動し、[操作] > [アプリケーションのバックアップ] > [バックアップ レコード] を選択して、バックアップ レコードをクリックします。

ディスクボリュームのバックアップ：

ECS コンソール で、ストレージ & スナップショット > スナップショット に移動し、ディスク ID でスナップショットを照会します。

ディスク以外のボリュームのバックアップ：

Cloud Backup コンソール で、バックアップ > コンテナバックアップ に移動し、リージョンを選択します。クラスター タブにはバックアップされたクラスターとその PVC が一覧表示されます。バックアップジョブ タブにはジョブのステータスが表示されます。

クライアントステータス が異常な場合、Cloud Backup が ACK クラスターで正しく実行されていません。ACK コンソールの DaemonSets ページでトラブルシューティングを行ってください。

古い Kubernetes バージョンからバックアップし、新しいバージョンに復元できますか？

はい。デフォルトでは、リソースがサポートするすべての API バージョンがバックアップされます。たとえば、Kubernetes 1.16 の Deployment は extensions/v1beta1、apps/v1beta1、apps/v1beta2、apps/v1 をサポートします。これら 4 つのバージョンは、作成時に使用されたバージョンに関係なく、すべてバックアップボールトに保存されます。KubernetesConvert 機能が復元時の API バージョン変換を処理します。

復元時には、復元クラスターが推奨する API バージョンが使用されます。たとえば、Kubernetes 1.28 への復元では、Deployment に apps/v1 が使用されます。

復元時にトラフィックが自動的に SLB インスタンスに切り替わるのですか？

いいえ。復元後、SLB リスナーは無効化されるか、新しい SLB インスタンスが作成されます（元の構成に応じて）。トラフィックは自動的に切り替わりません。

その他のサービス検出メカニズムを使用しており、トラフィックの切り替えタイミングを制御したい場合は、バックアップ時に Service リソースを除外し、切り替え準備が整った時点で手動でデプロイしてください。

なぜ csdr、ack-csi-fuse、kube-system、kube-public、kube-node-lease のリソースはデフォルトでバックアップされないのですか？

• csdr：これはバックアップセンター自身の名前空間です。直接バックアップすると、復元クラスターでコンポーネントが失敗する可能性があります。バックアップの同期は自動的に処理されるため、バックアップを手動で移行する必要はありません。

• ack-csi-fuse：この名前空間は、CSI によって管理される FUSE クライアント Pod を実行します。新しいクラスターの CSI が、ストレージ復元時にこれらのクライアントを自動的に同期します。

• kube-system、kube-public、kube-node-lease：これらは Kubernetes のシステム名前空間です。クラスターのパラメーターおよび構成の違いにより、これらの名前空間をクラスター間で復元することはサポートされていません。復元ジョブを実行する前に、復元クラスターでシステムコンポーネントを手動でインストールおよび設定してください。たとえば、Container Registry のパスワード不要イメージプルコンポーネント（acr-configuration）および ALB Ingress コンポーネント（ALBConfig）などです。

バックアップセンターはディスクボリュームに ECS ディスクスナップショットを使用しますか？デフォルトのスナップショットタイプは何ですか？

バックアップセンターは、以下のシナリオでデフォルトで ECS ディスクスナップショットを使用します。

• クラスターが ACK マネージドまたは専用クラスターである場合。

• このクラスターは、Kubernetes 1.18 以降を実行し、CSI 1.18 以降を使用します。

その他のシナリオでは、Cloud Backup がディスクデータのバックアップに使用されます。

バックアップセンターによって作成された ECS ディスクスナップショットには、インスタントアクセス機能がデフォルトで有効になっています。スナップショットの有効期間は、バックアップ構成で指定された有効期間と一致します。2023 年 10 月 12 日 11:00 以降、Alibaba Cloud はどのリージョンでもスナップショットのインスタントアクセスストレージまたは操作について課金しません。『インスタントアクセス機能を使用する』をご参照ください。

ECS ディスクスナップショットの有効期間がバックアップ構成で指定したものと異なるのはなぜですか？

有効期間の構成は、csi-provisioner コンポーネントに依存します。csi-provisioner のバージョンが 1.20.6 より古い場合、VolumeSnapshots は有効期間またはインスタントアクセス設定なしで作成されるため、バックアップ構成はディスクスナップショットに影響しません。

有効期間が正しく適用されるようにするには、csi-provisioner を 1.20.6 以降にアップグレードしてください。

アップグレードが不可能な場合、代わりにデフォルトのスナップショット有効期間を設定してください。

1. migrate-controller を v1.7.10 以降にアップグレードしてください。

2. 30 日間の保持設定を持つ VolumeSnapshotClass が存在するか確認してください。

      kubectl get volumesnapshotclass csdr-disk-snapshot-with-default-ttl

3. 存在しない場合、または 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 ディスクスナップショットまたは Cloud Backup を使用してボリュームデータをクラウドストレージにコピーします。アプリケーションを復元する際、このコピーから新しいディスクまたは NAS ファイルシステムが作成されます。復元されたアプリケーションと元のアプリケーションは独立したデータを持ち、片方の変更がもう片方に影響を与えることはありません。

データの分離を必要としない場合、またはストレージが既にクロスゾーンまたはクロスリージョンアクセス（OSS など）を提供している場合、ボリュームデータバックアップをスキップできます。PVC および PV の YAML ファイルは、デフォルトでアプリケーションバックアップに含まれます。

使用するタイミング：

• ディザスタリカバリまたはバージョン管理されたデータ記録。

• アプリケーションがディスクボリュームを使用している場合（基本ディスクは単一ノードでのみマウント可能）。

• クロスリージョンバックアップおよび復元が必要な場合（OSS を除くほとんどのストレージタイプはクロスリージョンアクセスをサポートしていません）。

• 元のアプリケーションと復元されたアプリケーションの間にデータの隔離が必要です。

• バックアップクラスターと復元クラスターのストレージプラグインまたはバージョンが大きく異なり、YAML の直接復元が現実的でない場合。

ステートフルアプリケーションのボリュームをバックアップしないリスク：

• Delete 再利用ポリシーを持つボリューム：CSI は復元時に新しい空の PV を作成します。マッチするストレージクラスがない静的プロビジョニングボリュームは、手動で PV またはストレージクラスを作成するまで Pending のままになります。

• Retain 再利用ポリシーを持つボリューム：リソースは PV 優先の順序で復元されます。マルチマウントストレージ（NAS、OSS）の場合、元のファイルシステムまたはバケットが再利用されます。ディスクの場合、強制的なディスクデタッチのリスクがあります。

ボリュームの再利用ポリシーを確認するには：

kubectl get pv -o=custom-columns=CLAIM:.spec.claimRef.name,NAMESPACE:.spec.claimRef.namespace,NAME:.metadata.name,RECLAIMPOLICY:.spec.persistentVolumeReclaimPolicy

データ保護におけるファイルシステムバックアップのノード選択方法は？

デフォルトでは、Cloud Backup ジョブは仮想ノードを除くすべてのノードで実行できます。ノードごとに 1 つのボリュームバックアップジョブのみが実行されます。

3 つのノードスケジューリングポリシーが利用可能です。

ノードにラベルを付けるには：

# ノードを除外
kubectl label node <node-name> csdr.alibabacloud.com/agent-excluded="true"

# ノードを有効化（include ポリシーの場合）
kubectl label node <node-name> csdr.alibabacloud.com/agent-included="true"

ポリシーを変更するには、csdr-config ConfigMap を編集します。

kubectl -n csdr edit cm csdr-config

node_schedule_policy を applicationBackup セクションに追加します。

apiVersion: v1
data:
  applicationBackup: |
    backup_max_worker_num: 15
    restore_max_worker_num: 5
    delete_max_worker_num: 30
    schedule_max_worker_num: 20
    convert_max_worker_num: 15
    node_schedule_policy: include  # 有効な値：include、exclude、prefer
  pvBackup: |
    batch_snapshot_max_num: 20
    enable_ecs_snapshot: "true"
kind: ConfigMap

変更を有効にするには、コントローラーを再起動してください。

kubectl -n csdr delete pod -lapp=csdr-controller

アプリケーションバックアップとデータ保護の違いは何ですか？

アプリケーションバックアップ は、Kubernetes ワークロード（アプリケーション、サービス、名前空間内の構成ファイルなど）のバックアップを目的としています。マウントされたボリュームのボリュームデータをオプションで含めることができます。アプリケーションバックアップは、クラスター間でのアプリケーションの移行や、ディザスタリカバリのためのアプリケーション復元に使用します。

アプリケーションバックアップは、Pod にマウントされていないボリュームはバックアップしません。すべてのボリュームをバックアップするには、データ保護バックアップジョブを作成してください。

データ保護 は、アプリケーションワークロードとは無関係に、ストレージボリューム（PVC および PV）を個別にバックアップするための機能です。データ保護は、削除された PVC をスタンドアロン操作として復元したり、ストレージレイヤーでデータレプリケーションおよびディザスタリカバリを実装したりするために使用します。

特定の永続ボリュームをバックアップおよび復元から除外するにはどうすればよいですか？

ログストレージや高可用性ストレージ（OSS）などの一部のボリュームは、バックアップする必要がない場合があります。Volume A（バックアップ不要）および Volume B（バックアップ必要）を含む名前空間のバックアップ手順を以下に示します。

バックアップ手順：

1. データ保護 を使用して Volume B をバックアップします。これにより、YAML およびデータの両方がバックアップされます。

2. アプリケーションバックアップ を使用して、名前空間を選択し、ボリュームのバックアップ を 無効 に設定します。これにより、Volume A および Volume B の YAML ファイルがデータのコピーなしでバックアップされます。

   Volume A をターゲットクラスターでまったく復元したくない場合、詳細設定で 除外リソース に pvc, pv

復元手順：

1. ターゲットクラスターでデータ保護バックアップを復元します。これにより、Volume B の YAML およびデータが復元されます。

2. ターゲットクラスターでアプリケーションバックアップを復元します。これにより、Volume A の YAML およびその他のすべてのアプリケーションリソースが復元されます。その後、CSI が Volume A の再利用ポリシーに基づいて新しいストレージソースを作成するか、既存のものを再利用します。

両方の復元が完了すると、アプリケーション、Volume A、およびデータを含む Volume B がすべてターゲットクラスターで実行されます。

バックアップセンターは関連付けられた OSS バケットの KMS 暗号化をサポートしていますか？

バックアップセンターは、OSS バケット向けのサーバ側暗号化をサポートしています。OSS コンソールで有効化します。「サーバ側暗号化」を参照してください。

KMS で管理される CMK（BYOK）を使用し、指定された CMK ID を使用する場合、バックアップセンターに KMS へのアクセス権限を付与してください。

1. カスタム権限ポリシーを作成します。

      {
        "Version": "1",
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "kms:List*",
              "kms:DescribeKey",
              "kms:GenerateDataKey",
              "kms:Decrypt"
            ],
            "Resource": [
              "acs:kms:*:141661496593****:*"
            ]
          }
        ]
      }

   これにより、Alibaba Cloud アカウントのすべての KMS キーへのアクセスが許可されます。詳細については、「権限付与情報」をご参照ください。

2. ポリシーをアタッチします。

   • ACK 専用クラスターおよび登録済みクラスターの場合：インストール時に使用した RAM ユーザーにアタッチします。詳細については、「RAM ユーザーへの権限付与」をご参照ください。

   • その他のクラスターの場合: これを AliyunCSManagedBackupRestoreRole ロールにアタッチします。詳細については、「RAM ロールへの権限付与」をご参照ください。

OSS で管理される KMS キーまたは OSS が完全に管理するキーを使用する場合、追加の権限は不要です。

復元時に使用されるコンテナイメージを変更するにはどうすればよいですか？

イメージレジストリアドレスの変更：

ハイブリッドクラウドデプロイまたはオンプレミスからクラウドへの移行の場合、imageRegistryMapping フィールドを使用してイメージレジストリアドレスを再マップします。たとえば、docker.io/library/ を registry.cn-beijing.aliyuncs.com/my-registry/ に変更するには：

docker.io/library/: registry.cn-beijing.aliyuncs.com/my-registry/

イメージリポジトリまたはバージョンの変更：

復元を実行する前に、csdr 名前空間に ConfigMap を作成します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: <configuration-name>
  namespace: csdr
  labels:
    velero.io/plugin-config: ""
    velero.io/change-image-name: RestoreItemAction
data:
  "case1": "app1:v1,app2:v2"
  # リポジトリのみ変更： "case1": "app1,app2"
  # バージョンのみ変更： "case1": "v1:v2"
  # 特定のレジストリイメージを変更： "case1": "docker.io/library/app1:v1,registry.cn-beijing.aliyuncs.com/my-registry/app2:v2"

複数の変更を行うには、case2、case3 などを data フィールドに追加します。ConfigMap を作成した後、imageRegistryMapping フィールドを空白のまま復元ジョブを実行してください。

これらの変更は、クラスター内のすべての復元ジョブに適用されます。意図しない変更を避けるために、特定のパターン（たとえば、特定のレジストリに限定するなど）を使用してください。不要になったら ConfigMap を削除してください。