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

コンソールに "The working component is abnormal" または "Failed to fetch current data" と表示されるのはなぜですか？

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

• クラスターにノードがあることを確認してください。バックアップセンターは、ノードがないクラスターにはデプロイできません。

• クラスターが FlexVolume を使用している場合は、まず CSI (Container Storage Interface) に切り替えてください。詳細については、「FlexVolume クラスターで migrate-controller コンポーネントが起動できない」をご参照ください。

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

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

• csdr 名前空間の csdr-controller および csdr-velero デプロイメントが、リソース不足またはスケジューリング制約が原因で失敗したかどうかを確認し、問題があれば解決します。

コンソールに "The name has been used. Change the name and try again" と表示されるのはなぜですか？

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

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

kubectl -n csdr delete deleterequests xxxxx-dbr

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

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

考えられる原因の 1 つは、ターゲットクラスターでバックアップボールトが初期化されていないことです。復元タスクの作成 ページで、バックアップボールトを探し、リポジトリの初期化をクリックします。初期化が完了したら、バックアップを選択して復元します。

初期化に失敗した場合、ターゲットクラスターの backuplocation リソースに Unavailable ステータスが表示されます。次のコマンドを実行して確認します。

kubectl get -n csdr backuplocation <backuplocation-name>

期待される出力：

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

ステータスが Unavailable の場合は、「ジョブが "VaultError: xxx" で失敗するのはなぜですか？」をご参照ください。

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

コンソールに "The service role required by the current component has not been authorized" (AddonRoleNotAuthorized) と表示されるのはなぜですか？

migrate-controller 1.8.0 から、ACK マネージドクラスターのクラウドリソース認証ロジックが更新されました。このバージョンを初めてインストールまたはアップグレードする場合、Alibaba Cloud アカウントで権限付与を完了させる必要があります。

• Alibaba Cloud アカウントでログインしている場合は、権限付与 をクリックしてください。

• RAM ユーザーとしてログインしている場合は、権限リンクのコピー をクリックし、承認を得るために Alibaba Cloud アカウントの所有者に送信します。

コンソールに "The current account has not been granted the cluster RBAC permissions required for this operation" (APISERVER.403) と表示されるのはなぜですか？

コンソールは API サーバーと対話し、バックアップジョブと復元ジョブを送信および監視します。運用保守エンジニアと開発者向けのデフォルトの権限セットには、バックアップセンターで必要な一部の権限がありません。

バックアップセンターのオペレーターに、次の 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 Namespace が Terminating 状態のままになるのはなぜですか？

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

次のコマンドを実行して、Namespace をブロックしているものを特定してください：

kubectl describe ns csdr

csdr 名前空間が削除された後、スタックしたジョブが不要であることを確認し、その finalizers を削除します。

• アップグレードの場合は、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 のような出力は、default 名前空間の PVC demo-pvc-for-convert202311151045 がバインドされていないことを意味します。

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

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

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

• クラスターまたはノードのリソースが不足しています。

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

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

• alibabacloud-cnfs-nas に関連するコンテナネットワークファイルシステム (CNFS) が異常です。 「方法 3: 既存の NAS ファイルシステムを使用する」をご参照ください。

• マルチゾーンクラスターで volumeBindingMode: Immediate のストレージクラスが選択されました。

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

「addon status is abnormal」でジョブが失敗するのはなぜですか?

csdr 名前空間のコンポーネントは異常です。ステータスを確認します：

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

解決手順については、「ジョブが InProgress のままになっているのはなぜですか?」をご参照ください。

「VaultError: xxx」でジョブが失敗するのはなぜですか?

このエラーは、バックアップボールトが Object Storage Service (OSS) バケットにアクセスできないことを意味します。以下の項目を順番に確認してください。

1. OSS バケットの存在確認

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

2. OSS アクセス権限の確認

必要な手順は、クラスタータイプによって異なります。

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

• ACK 専用クラスターおよび登録済みクラスター：「migrate-controller のインストールと権限の設定」の説明に従って OSS 権限を設定してください。

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

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

  期待される出力：

  addon.aliyuncsmanagedbackuprestorerole.token          Opaque                      1      62d

  出力が一致する場合、権限は付与されています。一致しない場合は、次のいずれかの方法を使用して権限を付与してください。

  • ACK 専用クラスターおよび登録済みクラスターの手順に従ってください。「migrate-controller のインストールと権限の設定」をご参照ください。

  • 権限付与をクリックして、Alibaba Cloud アカウントを承認してください。この操作は、アカウントごとに 1 回のみ実行する必要があります。

3. ネットワーク設定の確認

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

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

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

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

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

• クラスターが ACK Edge クラスターの場合。

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

  • オンプレミスのデータセンターを VPC に接続する方法については、「複数の接続方法を組み合わせてエンタープライズクラスのハイブリッドクラウドを構築する」をご参照ください。

  • OSS 内部エンドポイントと VIP CIDR ブロックのマッピングについては、「エンドポイントとバケットドメインを介した OSS へのアクセス」をご参照ください。

パブリックネットワークアクセスに切り替えるには、次のコマンドを実行します。

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> を、cn-hangzhou などの OSS バケットのリージョンに置き換えます。

「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 (Resource Access Management) 権限が付与されていることを確認してください。「migrate-controller のインストールと権限の設定」をご参照ください。

「HBRError: ... code: 400, Illegal request. Please modify the parameters」でジョブが失敗するのはなぜですか?

リージョン内の ack-backup-data Cloud Backup リポジトリが削除されました。

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

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

   kubectl -n csdr delete backuplocation --all
   kubectl -n csdr delete backupstoragelocation --all

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

「hbr task finished with unexpected status: FAILED, errMsg ClientNotExist」でジョブが失敗するのはなぜですか?

csdr 名前空間内のノードにある Cloud Backup クライアント (hbr-client DaemonSet) が正常に実行されていません。

1. 異常な hbr-client ポッドの確認:

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

2. いずれかのポッドが異常な状態にある場合、原因がポッドの IP アドレス、メモリ、または CPU の不足であるかを確認します。CrashLoopBackOff 状態のポッドについては、ログを表示します:

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

   ログに SDKError: StatusCode: 403, Code: MagpieBridgeSlrNotExist が含まれている場合は、(オプション) ステップ 3: Cloud Backup に API Gateway の権限を付与する に従って必要な権限を付与してください。

3. その他の SDK エラーについては、EC エラーコードを使用してトラブルシューティングを行ってください。「エラーコードを使用したセルフヘルプトラブルシューティング」をご参照ください。

ジョブが InProgress のままになっているのはなぜですか?

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

kubectl get volumesnapshot -n <backup-namespace>

「backup already exists in OSS bucket」エラーによるバックアップの失敗

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

現在のクラスターでバックアップが表示されない理由はいくつか考えられます。実行中または失敗したジョブに属している (これらはクラスター間で同期されません)、別のクラスターで削除された (ファイルにマークが付けられますが、OSS からは削除されません)、または現在のクラスターがバックアップを保存したバックアップボールトに関連付けられていない、などが考えられます。

「get target namespace failed」エラーによるバックアップの失敗

これは通常、スケジュールされたバックアップジョブで発生します。Namespace の選択が無効なことが原因です。

• 含む を選択した場合、選択したすべてのネームスペースが削除されています。

• 除外 を選択した場合、クラスターには、除外された名前空間以外の名前空間はありません。

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

「velero backup process timeout」エラーによるバックアップの失敗

主な原因は 2 つあります：

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

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

kubectl edit -n csdr cm csdr-config

applicationBackup セクションに velero_timeout_minutes を追加してください。たとえば、タイムアウトを 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 が標準の Kubernetes ボリュームタイプ (NFS や LocalVolume など) でない場合は、チケットを送信してサポートを受けてください。

ブロックモードボリューム：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 ルートパスを見つけてください：

   ps -elf | grep kubelet

   出力は次のように解釈してください：

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

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

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

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

2. ルートパスがシンボリックリンクかどうかを確認してください：

   ls -al <root-dir>

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

3. ターゲットボリュームのデータが、<root-dir>/pods/<pod-uid>/volumes のルートパス配下に存在することを確認してください。

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

HostPath ストレージの場合：

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

「check backup files in OSS bucket failed」、「upload backup files to OSS bucket failed」、または「download backup files from OSS bucket failed」エラーによるバックアップの失敗

バックアップボールトのバケットに対するファイル操作中に、OSS サーバーからエラーが返されました。考えられる原因は 3 つあります：

KMS 権限の欠如：OSS バケットで Key Management Service (KMS) のカスタマーマスターキー (CMK) を使用したサーバー側の暗号化を有効にしている場合、バックアップセンターには追加の権限が必要です。詳細については、「バックアップセンターは、関連付けられた OSS バケットの KMS 暗号化をサポートしていますか?」をご参照ください。

OSS 権限の不足：ACK 専用クラスターおよび登録クラスターの場合は、コンポーネントのインストール時に使用した RAM ユーザーの権限ポリシーを確認してください。詳細については、「ステップ 1：権限を設定する」をご参照ください。

認証情報の失効：ACK 専用クラスターおよび登録クラスターの場合は、RAM ユーザーの認証情報がまだ有効であることを確認してください。失効している場合は、新しい認証情報を取得し、csdr Namespace 内の alibaba-addon-secret Secret を更新して、コンポーネントを再起動してください：

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

「PROCESS velero partially completed」によりバックアップが PartiallyFailed と表示される理由

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

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>

「PROCESS hbr partially completed」によりバックアップが PartiallyFailed と表示される理由

Cloud Backup は、一部のファイルシステムボリューム (OSS、NAS、CPFS、またはローカルボリューム) のバックアップに失敗しました。原因として、以下が考えられます：

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

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

調査するには、Cloud Backup コンソールの[バックアップジョブ]タブを開き、正しいリージョンを選択し、検索ボックスの前にあるドロップダウンリストからジョブ名を選択して <backup-name>-hbr を検索します。 ジョブのステータスと失敗理由を確認します。 詳細については、「ACK クラスターをバックアップする」をご参照ください。

StorageClass 変換が "storageclass xxx not exists" で失敗するのはなぜですか？

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

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. クラスターに必要な StorageClass を作成します。

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. 正しい StorageClass を選択します：

   • コンソール: デフォルトで alicloud-disk-topology-alltype ストレージクラスを使用する alicloud-disk を選択します。

   • コマンドライン: alicloud-disk-topology-alltype を使用します。 または、PV がポッドと同じゾーンに作成されるように、volumeBindingMode を WaitForFirstConsumer に設定します。

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

リストアが "multi-node writing is only supported for block volume" で失敗するのはなぜですか？

リストア対象のアプリケーションには、AccessMode が ReadWriteMany または ReadOnlyMany のボリュームがあります。Alibaba Cloud ディスクストレージ (デフォルトでは複数マウントをサポートしていません) にリストアする際、CSI はマウント中にディスクボリュームの AccessModes 設定を検証し、マウントをブロックします。これにより、マウント中にディスクが別のノードによってマウントされ、強制的なディスクのデタッチが引き起こされるのを防ぎます。

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

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

• リストアクラスターに StorageClass がない場合：ボリュームは、デフォルトで Alibaba Cloud ディスクボリュームにマッチングされます。StorageClass を自動的にリストアすると、データにアクセスできなくなったり、データが上書きされたりする可能性があります。リストアする前に、リストアクラスターに同じ名前の StorageClass を作成するか、StorageClass 変換を使用してターゲットを指定してください。

• ディスクへの手動での StorageClass 変換：convertToAccessModes パラメーターを追加して、AccessModes を ReadWriteOnce に変換してください。詳細については、「convertToAccessModes」をご参照ください。

リストアが "only disk type PVs support cross-region restore in current version" で失敗するのはなぜですか？

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

リストアが "accessMode of PVC xxx is xxx" で失敗するのはなぜですか？

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

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

Why does my restore fail with "accessMode of PVC xxx is xxx"?

The disk volume being restored has an AccessMode of ReadOnlyMany or ReadWriteMany. CSI enforces the following rules:

• Only volumes with multiAttach enabled can be mounted to multiple instances.

• Volumes with VolumeMode: Filesystem (ext4 or xfs) can only be mounted to multiple instances in read-only mode.

Two recommended approaches:

• If you are converting a multi-mount volume (such as OSS or NAS) to disk storage, create a new restore job and select alibabacloud-cnfs-nas as the target for StorageClass conversion. This uses a CNFS-managed NAS volume, which supports multiple mounts. See Use CNFS to manage NAS file systems (recommended).

• If the backed-up disk PV does not meet current CSI requirements (backed up when CSI version was lower and AccessMode detection was not enforced), migrate your workloads to use dynamically provisioned disk volumes to avoid forced disk detachment during scheduling.

リストアステータスは Completed ですが、一部のリソースが見つかりません。なぜですか？

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>

バックアップ対象として選択されていない名前空間で実行されている 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 に移行する

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

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

• その他のケースについては、DingTalk グループ (ID： 35532895) でお問い合わせください。

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

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

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

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

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

ACK 専用クラスターおよび登録クラスター以外のクラスターの場合、バックアップセンターはデフォルトで cnfs-oss-* 形式の名前の OSS バケットへの読み取り/書き込みアクセス権を持っています。異なる名前のバケットを使用するには、追加の設定が必要です。バケット内の既存データがバックアップによって上書きされるのを防ぐために、バックアップセンター専用の 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 に増やされます。

Service： Service タイプに基づいて復元されます。

• NodePort Service： クラスター間の復元時に、Service ポートはデフォルトで保持されます。

• LoadBalancer Service：

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

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

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

バックアップ内のリソースを表示する方法は？

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

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

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 コンソールの DaemonSet ページに移動してトラブルシューティングを行ってください。

古い 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 namespace のリソースがデフォルトでバックアップされないのはなぜですか？

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

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

• kube-system、kube-public、kube-node-lease： これらは Kubernetes のシステム namespace です。クラスターのパラメータと設定の違いにより、これらの namespace のクラスター間での復元はサポートされていません。kube-system のシステムコンポーネントを新しいクラスターに直接バックアップすると、誤動作する可能性があります。復元ジョブを実行する前に、復元クラスターにシステムコンポーネントを手動でインストールして設定してください。たとえば、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 より古い場合、VolumeSnapshot は有効期限または高速アクセス設定なしで作成されるため、バックアップ設定はディスクスナップショットに影響しません。

有効期限が正しく適用されるように、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 ファイルシステムが作成されます。復元されたアプリケーションと元のアプリケーションは独立したデータを持ち、一方の変更は他方に影響しません。

データのコピーまたは共有データソースが不要な場合は、ボリュームデータバックアップをスキップできます。PVC と PV の YAML ファイルは、デフォルトでアプリケーションバックアップに含まれています。復元時にボリュームが元の YAML から新しいクラスターにデプロイされるように、PVC と PV リソースがバックアップ除外リストに含まれていないことを確認してください。

いつ使用するか：

• 災害復旧またはバージョン管理されたデータレコードが必要な場合。

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

• クロスリージョンバックアップと復元が必要な場合 (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 つのノードで一度に実行されるボリュームバックアップジョブは 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

applicationBackup セクションに node_schedule_policy を追加してください：

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 ワークロード (namespace 内のアプリケーション、Service、設定ファイルを含む) をバックアップします。マウントされたボリュームのボリュームデータをオプションで含めることができます。アプリケーションバックアップを使用して、クラスター間でアプリケーションを移行したり、災害復旧のためにアプリケーションを復元したりできます。

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

データ保護 は、アプリケーションワークロードとは独立して、ストレージボリューム (PVC と PV) をバックアップします。データ保護を使用して、削除された PVC をスタンドアロン操作として復元したり、ストレージレイヤーでデータレプリケーションと災害復旧を実装したりできます。

特定の PersistentVolume をバックアップと復元から除外する方法は？

ログストレージや高可用性ストレージ (OSS) など、一部のボリュームはバックアップする必要がありません。以下は、ボリューム A (バックアップ不要) とボリューム B (バックアップ必要) を含む namespace をバックアップするワークフローです。

バックアップフロー：

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

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

   ターゲットクラスターでボリューム A を一切復元したくない場合は、詳細設定の 除外されたリソース に pvc, pv を追加してください。

復元フロー：

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

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

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

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

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

指定された CMK ID を持つ KMS 管理の CMK (Bring Your Own Key、または BYOK) を使用する場合は、バックアップセンターに 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 namespace に 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"

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

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

csdr namespace 内のサブコンポーネントで使用可能なリソースを調整する方法は？

csdr-controller のデフォルトのリソース設定は次のとおりです：

resources:
  limits:
    cpu: "1"
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 256Mi

csdr-velero のデフォルトのリソース設定は次のとおりです：

resources:
  limits:
    cpu: "1"
    memory: 2Gi
  requests:
    cpu: 500m
    memory: 128Mi

csdr-controller と csdr-velero の Deployment 設定 (リソースを含む) は、kube-system namespace 内の migrate-controller コンポーネントによって管理されています。直接編集するとリセットされます。リソース設定を変更するには、migrate-controller コンテナの args に次のパラメータを追加してください：

name: migrate-controller
args:
  - --velero-pod-cpu-limit=500m
  - --velero-pod-mem-limit=512Mi
  - --velero-pod-cpu-request=250m
  - --velero-pod-mem-request=256Mi
  - --csdr-pod-cpu-limit=500m
  - --csdr-pod-mem-limit=512Mi
  - --csdr-pod-cpu-request=250m
  - --csdr-pod-mem-request=256Mi

各パラメータはオプションです。省略されたパラメータはデフォルト値を保持します。各制限値が対応する要求値以上であることを確認してください。

大規模なクラスターでは、velero-pod-mem-limit を下げると、初期化と復元中に csdr-velero がメモリ不足になる可能性があります。代わりに disable-informer-cache パラメータの設定を検討してください。「ジョブが InProgress のままになっているのはなぜですか?」をご参照ください。