バックアップセンターを使用して、FlexVolume プラグインを使用するクラスターから Container Storage Interface (CSI) プラグインを使用するクラスターにアプリケーションを移行できます。また、古い Kubernetes クラスターから新しいクラスターにアプリケーションを移行することもできます。バックアップセンターは、異なるストレージプラグインや Kubernetes バージョンを持つクラスター間でのアプリケーション移行中に発生する問題を解決します。たとえば、アプリケーションで使用されていないクラスターレベルのリソースをバックアップしたり、リストアクラスターと互換性のある API バージョンを自動的に使用したりできます。このトピックでは、FlexVolume を使用し Kubernetes 1.16 を実行するクラスターから、CSI を使用し Kubernetes 1.28 を実行するクラスターにアプリケーションを移行する例を用いて、バックアップセンターを使用したアプリケーションの移行方法について説明します。
注意事項
バックアップクラスターとリストアクラスターは、同じリージョンにある必要があります。バックアップクラスターは Kubernetes 1.16 以降を実行している必要があります。API バージョンの互換性の問題を避けるため、バックアップセンターを使用して新しい Kubernetes バージョンから古いバージョンにアプリケーションを移行することは推奨されません。
バックアップセンターは、削除中のリソースをバックアップしません。
-
Container Network File System (CNFS) によって管理されるネットワークアタッチトストレージ (NAS) ボリュームにデータをリストアするには、リストア中に StorageClass の変更 パラメーターを alibabacloud-cnfs-nas に設定する場合、StorageClass を作成する必要があります。詳細については、「CNFS を使用した NAS ファイルシステムの管理」をご参照ください。
アプリケーションがリストアされる際、リソースはリストアクラスターの Kubernetes バージョンで推奨される apiVersion を使用して優先的にリストアされます。リソースに両方のクラスターバージョンでサポートされている apiVersion がない場合、そのリソースを手動でデプロイする必要があります。例：
Kubernetes 1.16 クラスターの Deployment は、
extensions/v1beta1、apps/v1beta1、apps/v1beta2、およびapps/v1の API バージョンをサポートします。Kubernetes 1.28 クラスターにリストアされると、apps/v1を使用してリストアされます。Kubernetes 1.16 クラスターの Ingress は、
extensions/v1beta1およびnetworking.k8s.io/v1beta1の API バージョンをサポートします。Kubernetes 1.22 以降を実行するクラスターに直接リストアすることはできません。
Kubernetes バージョン間の API の変更に関する詳細については、「ACK リリースノート」および「非推奨 API 移行ガイド」をご参照ください。
重要Kubernetes 1.16 クラスターでは、
appsやrbac.authorization.k8s.ioなどの API グループは既に v1 をサポートしています。Kubernetes 1.28 クラスターにアプリケーションを移行する場合、Ingress や CronJob などのリソースを手動でリストアする必要があります。
利用シーン
ストレージプラグイン間のアプリケーション移行
Kubernetes 1.20 以降を実行する ACK クラスターは、FlexVolume ストレージプラグインをサポートしなくなりました。バックアップセンターを使用して、ステートフルアプリケーションを FlexVolume クラスターから CSI クラスターに移行できます。
説明FlexVolume または CSI ストレージプラグインのいずれかを使用するクラスターからアプリケーションを移行できますが、リストアクラスターは CSI ストレージプラグインを使用する必要があります。
Kubernetes のバージョン差が大きいクラスター間の切り替え
一部のシナリオでは、古い Kubernetes クラスター (1.16 以降) から新しいクラスターにサービスを移行する必要がある場合があります。たとえば、ネットワークプラグインを Flannel から Terway に切り替える場合などです。バックアップセンターは、大きなバージョン差があるアプリケーション移行をサポートし、アプリケーションテンプレートの
apiVersionなどの基本構成を新しい Kubernetes バージョンに合わせて自動的に調整します。
前提条件
Cloud Backup のアクティベート。NAS、OSS、またはローカルディスクの永続ボリュームをバックアップする場合、およびハイブリッドクラウドのシナリオでは、バックアップセンターはファイルバックアップのために Cloud Backup を使用する必要があります。
ボリュームがリストアされるクラスターが作成されていること。Elastic Compute Service (ECS) インスタンスのスナップショットを使用してディスクデータをリストアできるように、クラスターの Kubernetes バージョンを 1.18 以降に更新することを推奨します。詳細については、「ACK マネージドクラスターの作成」、「ACK 専用クラスターの作成 (提供終了)」、または「ACK One 登録済みクラスターの作成」をご参照ください。
重要リストアクラスターは Container Storage Interface (CSI) プラグインを使用する必要があります。FlexVolume または csi-compatible-controller と FlexVolume を使用するクラスターでは、アプリケーションのリストアはサポートされていません。
バックアップセンターは、アプリケーションのバックアップとリストアに使用されます。リストアタスクを実行する前に、リストアクラスターにシステムコンポーネントをインストールして構成する必要があります。例：
aliyun-acr-credential-helper：リストアクラスターに権限を付与し、acr-configuration を構成する必要があります。
alb-ingress-controller：ALBConfig を構成する必要があります。
-
migrate-controller バックアップサービスコンポーネントがインストールされ、その権限が構成されていること。詳細については、「migrate-controller バックアップサービスコンポーネントのインストールと権限の構成」をご参照ください。
-
クラウドディスクスナップショットを使用してボリュームをバックアップするには、CSI プラグイン v1.1.0 以降をインストールする必要があります。詳細については、「CSI コンポーネントのインストールとアップグレード」をご参照ください。
移行ワークフロー
移行ワークフローは、バックアップクラスターが使用するストレージプラグインによって異なります。以下の図に詳細を示します。
ストレージアプリケーションがないバックアップクラスター
FlexVolume を使用するバックアップクラスター
CSI を使用するバックアップクラスター
操作手順
このセクションでは、FlexVolume を使用し Kubernetes 1.16 を実行する ACK クラスターから、CSI を使用し Kubernetes 1.28 を実行する ACK クラスターに、アプリケーション、構成、およびボリュームデータを移行する例を使用します。移行には、データソースの変更またはデータソースの不変のいずれかの方法を使用します。ストレージを使用しないアプリケーションを移行する場合、またはバックアップクラスターが CSI ストレージプラグインを使用する場合は、オプションとマークされた手順をスキップできます。
データソース不変のメソッドを使用する場合、バックアップクラスター内の PersistentVolume (PV) のリクレームポリシーを Retain に変更する必要があります。これにより、ボリュームが削除されたときにデータが削除されるのを防ぎます。
kubectl patch pv/<pv-name> --type='json' -p '[{"op":"replace","path":"/spec/persistentVolumeReclaimPolicy","value":"Retain"}]'メソッド | 説明 | 利用シーン |
データソースの変更 | このメソッドは、バックアップクラスターのボリュームからデータをバックアップし、リストアクラスターのアプリケーション用に新しいデータのコピーを作成します。このメソッドは、完全に独立した 2 つのストレージセットを作成します。データリストアプロセスでは動的マウントが使用され、StorageClass を変換することでストレージタイプを変更できます。たとえば、NAS ストレージをディスクストレージに変換できます。 |
|
データソースの不変 | このメソッドは、リストアプロセス中に静的マウントを使用して、バックアップされた PersistentVolumeClaim (PVC) と PersistentVolume (PV) に基づいて、元のデータソース (ディスク ID や OSS バケットなど) を再利用します。FlexVolume クラスターから CSI クラスターにアプリケーションを移行する場合、YAML テンプレートに互換性がないため、静的な PVC と PV を手動で作成する必要があります。 | バックアップとリストアのプロセス中にアプリケーションのデータ書き込みを一時停止できず、強力なデータ整合性が要求される場合。 |
環境の準備
項目 | バックアップクラスター | リストアクラスター |
クラスターバージョン | 1.16.9-aliyun.1 | 1.28.3-aliyun.1 |
ランタイムバージョン | Docker 19.03.5 | containerd 1.6.20 |
ストレージコンポーネントのバージョン | FlexVolume: v1.14.8.109-649dc5a-aliyun | CSI: v1.26.5-56d1e30-aliyun |
その他 |
| csi-plugin および csi-provisioner ストレージコンポーネントがインストールされています。詳細については、「コンポーネントの管理」をご参照ください。 |
ステップ 1：テストアプリケーションのデプロイ
次のコマンドを実行して、動的にプロビジョニングされたディスクボリュームをデプロイします。
alicloud-disk-topologyを、ご利用のクラスターの FlexVolume ストレージプラグイン用のデフォルトディスク StorageClass の名前に置き換えます。cat << EOF | kubectl apply -f - kind: PersistentVolumeClaim apiVersion: v1 metadata: name: disk-essd spec: accessModes: - ReadWriteOnce storageClassName: alicloud-disk-topology resources: requests: storage: 20Gi EOF次のコマンドを実行して、静的にプロビジョニングされた NAS ボリュームをデプロイします。
serverを、ご利用のアカウントの NAS ファイルシステムのマウントポイントに置き換えます。cat << EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolume metadata: name: pv-nas spec: capacity: storage: 5Gi storageClassName: nas accessModes: - ReadWriteMany flexVolume: driver: "alicloud/nas" options: server: "1758axxxxx-xxxxx.cn-beijing.nas.aliyuncs.com" vers: "3" options: "nolock,tcp,noresvport" --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc-nas spec: accessModes: - ReadWriteMany storageClassName: nas resources: requests: storage: 5Gi EOF次のコマンドを実行して、アプリケーションをデプロイします。このアプリケーションは、前の手順で作成したディスクと NAS の両方のボリュームをマウントします。
以下のコードの
apiVersionは extensions/v1beta1 を使用しています。このapiVersionは、バージョン 1.28 のクラスターでは非推奨となっています。cat << EOF | kubectl apply -f - apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx labels: app: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 volumeMounts: - name: nas mountPath: /cold - name: disk mountPath: /hot volumes: - name: nas persistentVolumeClaim: claimName: pvc-nas - name: disk persistentVolumeClaim: claimName: disk-essd EOF次のコマンドを実行して、デプロイされたアプリケーションが起動したことを確認します。
kubectl get pod -l app=nginx想定される出力：
NAME READY STATUS RESTARTS AGE nginx-5ffbc895b-xxxxx 1/1 Running 0 2m28s
ステップ 2：バックアップセンターのインストール
バックアップクラスターに、migrate-controller バックアップサービスコンポーネントをインストールします。
説明Kubernetes 1.16 以降を実行するクラスターの場合、コンポーネントマーケットプレイスから直接 V1.7.6 以降のバックアップサービスコンポーネントをインストールできます。
バックアップクラスターが ACK 専用クラスターまたは登録済みクラスターであるか、CSI 以外のストレージプラグイン (FlexVolume など) を使用している場合は、追加の権限を構成する必要があります。詳細については、「登録済みクラスター」をご参照ください。
(オプション) ご利用のクラスターが FlexVolume クラスターである場合、次のコマンドを実行して、必要な権限が構成されていることを確認します。
kubectl -n csdr get secret alibaba-addon-secret(オプション) ご利用のクラスターが FlexVolume クラスターである場合、次のコマンドを実行して、kube-system 名前空間の migrate-controller に
USE_FLEXVOLUME環境変数を追加します。重要FlexVolume クラスターでは、
migrate-controllerバックアップサービスコンポーネントをインストールした後、migrate-controllerPod が予期せず終了し、クラスターの [アプリケーションバックアップ] ページを開くと 404 エラーが返されます。この場合、コンポーネントの YAML ファイルを編集してUSE_FLEXVOLUME環境変数を追加する必要があります。kubectl -n kube-system patch deployment migrate-controller --type json -p '[{"op":"add","path":"/spec/template/spec/containers/0/env/-","value":{"name":"USE_FLEXVOLUME","value":"true"}}]'次のコマンドを実行して、バックアップサービスコンポーネントが正常に実行されていることを確認します。
kubectl -n kube-system get pod -l app=migrate-controller kubectl -n csdr get pod想定される出力：
NAME READY STATUS RESTARTS AGE migrate-controller-6c8b9c6cbf-967x7 1/1 Running 0 3m55s NAME READY STATUS RESTARTS AGE csdr-controller-69787f6dc8-f886h 1/1 Running 0 3m39s csdr-velero-58494f6bf4-52mv6 1/1 Running 0 3m37s
ステップ 3：バックアップの作成
バックアップクラスターと同じリージョンに、バックアップを保存するために
cnfs-oss-*形式で名前が付けられた OSS バケットを作成します。詳細については、「バケットの作成」をご参照ください。説明ACK マネージドクラスターは、デフォルトで名前が
cnfs-oss-*で始まる OSS バケットに対する権限を持っています。バケットの命名形式が要件を満たしていない場合は、追加の権限も構成する必要があります。詳細については、「コンソールでのコンポーネントのインストールと権限の構成」をご参照ください。次のコマンドを実行して、即時バックアップタスクを作成します。
ACK コンソールでバックアップ設定を構成する方法については、「クラスター内のアプリケーションのバックアップとリストア」をご参照ください。この手順では、サンプルシナリオの推奨構成を提供します。特定のシナリオに合わせて設定を調整してください。
cat << EOF | kubectl apply -f - apiVersion: csdr.alibabacloud.com/v1beta1 kind: ApplicationBackup metadata: annotations: csdr.alibabacloud.com/backuplocations: '{"name":"<your-backup-vault-name>","region":"<your-region-id>","bucket":"<your-oss-bucket-name>","provider":"alibabacloud"}' labels: csdr/schedule-name: fake-name name: <your-backup-name> namespace: csdr spec: excludedNamespaces: - csdr - kube-system - kube-public - kube-node-lease excludedResources: - storageclasses - clusterroles - clusterrolebindings - events - persistentvolumeclaims - persistentvolumes includeClusterResources: true pvBackup: defaultPvBackup: true storageLocation: <your-backup-vault-name> ttl: 720h0m0s EOFパラメーター
説明
excludedNamespaces
バックアップから除外する名前空間。以下の名前空間を除外することを推奨します：
csdr：バックアップセンターの作業用名前空間。バックアップセンターにはクラスター間の同期ロジックがあります。csdr 名前空間でバックアップやリストアなどのタスクを手動でバックアップしないでください。この操作は予期しない動作を引き起こす可能性があります。kube-system、kube-public、およびkube-node-leaseは、ACK クラスターにデフォルトで存在する名前空間です。クラスターのパラメーターや構成の違いにより、クラスター間で簡単にリストアすることはできません。
excludedResources
除外するリソース。ビジネス要件に基づいてこのパラメーターを構成できます。
includeClusterResources
StorageClass、CRD、Webhook などのクラスターレベルのリソースをバックアップするかどうかを指定します。
true：すべてのクラスターレベルのリソースをバックアップします。false：選択した名前空間の名前空間レベルのリソースによって参照されるクラスターレベルのリソースのみをバックアップします。たとえば、Pod をバックアップするときに、参照される ServiceAccount が ClusterRole によって承認されている場合、ClusterRole は自動的にバックアップされます。CR をバックアップすると、CRD は自動的にバックアップされます。
説明デフォルトでは、[ACK コンソール] で作成されたバックアップタスクでは、
IncludeClusterResourcesはfalseに設定されています。defaultPvBackup
ボリュームデータをバックアップするかどうかを指定します。
true：アプリケーションと実行中の Pod が使用するボリューム内のデータをバックアップします。false：アプリケーションのみをバックアップします。
重要Kubernetes と CSI の両方のバージョンが 1.18 以降のクラスターでは、バックアップセンターはデフォルトで ECS スナップショットを使用してディスクデータをバックアップします。他のストレージタイプや、Kubernetes バージョンが 1.16 から 1.18 (1.18 を含まない) までのクラスターのディスクデータについては、Cloud Backup が使用されます。
実行中の Pod によって使用されていないボリュームについては、データソース不変のメソッドのみを使用できます。これには、新しいクラスターで静的な PV と PVC を手動で作成し、元のデータソース (ディスク ID や OSS バケットなど) を指定する必要があります。
アプリケーションが強力なデータ整合性を必要とする場合は、バックアップ期間中にデータ書き込みを一時停止してください。または、データソース不変のメソッドを選択し、アプリケーションのみをバックアップすることもできます。
次のコマンドを実行して、バックアップタスクのステータスをクエリします。
kubectl -ncsdr describe applicationbackup <your-backup-name>想定される出力では、
StatusのPhaseパラメーターがCompletedに変わり、バックアップタスクが正常に作成されたことを示します。次のコマンドを実行して、このバックアップのリソースリストを確認します。
kubectl -ncsdr get pod | grep csdr-velero kubectl -ncsdr exec -it <csdr-velero-pod-name> -- /velero describe backup <your-backup-name> --detailsバックアップされなかったリソースのリストを確認し、バックアップ構成を調整して再度バックアップを実行できます。
Resource List: apiextensions.k8s.io/v1/CustomResourceDefinition: - volumesnapshots.snapshot.storage.k8s.io v1/Endpoints: - default/kubernetes v1/Namespace: - default v1/PersistentVolume: - d-2ze88915lz1il01v1yeq - pv-nas v1/PersistentVolumeClaim: - default/disk-essd - default/pvc-nas v1/Secret: - default/default-token-n7jss - default/oss-secret - default/osssecret v1/Service: - default/kubernetes v1/ServiceAccount: - default/default ...
ステップ 4：バックアップセンターのインストール
リストアクラスターにバックアップセンターをインストールします。詳細については、「ステップ 2：バックアップセンターのインストール」をご参照ください。
作成したバックアップボールトをリストアクラスターに関連付けます。
ACK コンソールにログインします。
クラスターリストページで、対象のクラスターの名前をクリックします。左側のナビゲーションウィンドウで、を選択します。
アプリケーションのバックアップページで、今すぐ復元するをクリックします。
バックアップに使用したバックアップリポジトリを選択し、リポジトリの初期化をクリックし、バックアップがこのクラスターに同期されるのを待ちます。
(オプション) ステップ 5：PVC と PV の手動作成
ほとんどのシナリオでは、ステップ 6 に従って、リストアクラスターで直接リストアタスクを作成するだけです。バックアップセンターコンポーネントは、バックアップに基づいてストレージクレームとボリュームを自動的に生成します。
バックアップセンターがリストアタスクを実行する際、既存のデータを保護するために同じ名前の PVC と PV のリストアをスキップします。これは、それらを再構築したり、ボリューム内のデータを上書きしたりしないことを意味します。したがって、以下のシナリオでは、より柔軟なリカバリのために、リストアタスクの前に PVC と PV を事前に作成できます：
ボリュームをバックアップしましたが、一部のボリュームにはログなど移行する必要のないデータが含まれています。空のボリュームを事前に作成できます。
ボリュームをバックアップしましたが、バックアップクラスター内の実行中の Pod によって使用されていないボリュームもリストアクラスターに移行する必要があります。
ボリュームをバックアップしておらず、
excludedResourcesリストにpersistentvolumeclaimsとpersistentvolumesが含まれているか、移行に FlexVolume クラスターから CSI クラスターへのアプリケーションの移動が含まれている場合。
具体的な手順は次のとおりです：
ディスクはアベイラビリティゾーンをまたいでマウントすることはできません。リストアクラスターで別のアベイラビリティゾーンに切り替える場合は、次のいずれかの方法を選択してください：
データソース変更方式を使用してデータを同期します。
ECS 管理コンソールにログインし、ディスクの単一スナップショットを手動で作成し、そのスナップショットを使用して新しいアベイラビリティゾーンにディスクを作成します。詳細については、「スナップショットからのディスク作成」をご参照ください。以下の
outputfile.txtYAML ファイルで、ディスク ID とnodeAffinityのアベイラビリティゾーン ID を置き換えます。
(オプション) バックアップクラスターが FlexVolume クラスターの場合、FlexVolume と CSI の間で PV と PVC の YAML が異なるため、コマンドラインツールを使用して YAML ファイルをバッチ変換できます。詳細については、「FlexVolume2CSI コマンドラインツールを使用した YAML ファイルのバッチ変換」をご参照ください。
次のコマンドを実行して、FlexVolume2CSI から取得した CSI YAML ファイルをデプロイします。
ここで、
outputfile.txtはコマンドラインツールの YAML 変換の出力です。kubectl apply -f outputfile.txt次のコマンドを実行して、リストアクラスターの PVC が
Bound状態であることを確認します。kubectl get pvc想定される出力：
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE disk-essd Bound d-2ze88915lz1il0xxxxxx 20Gi RWO alicloud-disk-essd 29m pvc-nas Bound pv-nas 5Gi RWX nas 29m
ステップ 6：リストアタスクの作成
リストアクラスターに同じ名前のリソースが既に存在する場合、リストアタスクはそのリソースをスキップします。
バックアップセンターは、ビジネスアプリケーションのバックアップとリストアに重点を置いています。リストアタスクを開始する前に、リストアクラスターに必要なシステムコンポーネントをインストールして構成する必要があります。例：
ACR シークレットフリーコンポーネント：リストアクラスターを再承認し、
acr-configurationを構成する必要があります。ALB Ingress コンポーネント：
ALBConfigおよびその他の関連リソースを事前に構成する必要があります。
Service リソースをリストアする際、バックアップセンターは Service タイプに基づいてそれらを適応させます：
NodePortService：クラスター間でリストアする場合、バックアップセンターはデフォルトでポート番号を保持します。タイプが LoadBalancer の Service で、
ExternalTrafficPolicyがLocalに設定されている場合、HealthCheckNodePortはデフォルトでランダムなポート番号を使用します。ポート番号を保持するには、リストアタスクを作成する際にspec.preserveNodePorts: trueを設定します。バックアップクラスターの Service が指定された既存の SLB インスタンスを使用している場合、リストアされたサービスは元の SLB インスタンスを使用し、デフォルトで強制リスニングを無効にします。SLB コンソールでリスナーを構成する必要があります。
バックアップクラスターの Service の SLB インスタンスが CCM によって管理されている場合、リストア時に CCM によって新しい SLB インスタンスが作成されます。詳細については、「Service のロードバランサー構成に関する注意事項」をご参照ください。
バックアップ作成時にボリュームをバックアップした場合、データソース変更方式でバックアップとリストアを行っています。StorageClass 変換 (convertedarg) を使用して、ストレージタイプを変更できます。たとえば、NAS ストレージをディスクストレージに変換できます。要件に基づいてターゲットの StorageClass を選択できます。
この例では、バックアップクラスターが v1.16 の FlexVolume クラスターであり、ディスクボリュームのバックアップは Cloud Backup を使用するため、disk-essd ストレージクレーム (CSI ディスククラスに変換され、デフォルトで alicloud-disk-topology-alltype になります) のターゲット StorageClass として alicloud-disk を選択できます。バックアップクラスターが v1.18 以降の CSI クラスターである場合、ディスクボリュームに関連する構成を行う必要はありません。
この例では、FlexVolume NAS ボリュームを CNFS 管理の分離された NAS ボリュームに変換するために、
pvc-nasPVC のターゲット StorageClass としてalibabacloud-cnfs-nasを選択します。ご利用のクラスターにalibabacloud-cnfs-nasStorageClass がない場合は、「CNFS を使用した NAS ファイルシステムの管理」をご参照ください。
具体的な手順は次のとおりです：
次のコマンドを実行して、リストアタスクを作成します。
ACK コンソールでリストアタスクを構成する方法については、「アプリケーションとデータボリュームのリストア」をご参照ください。この手順では、サンプルシナリオの推奨構成を提供します。特定のシナリオに合わせて設定を調整してください。
cat << EOF | kubectl apply -f - apiVersion: csdr.alibabacloud.com/v1beta1 kind: ApplicationRestore metadata: annotations: csdr.alibabacloud.com/backuplocations: >- '{"name":"<your-backup-vault-name>","region":"<your-region-id>","bucket":"<your-oss-bucket-name>","provider":"alibabacloud"}' name: <your-restore-name> namespace: csdr spec: backupName: <your-backup-name> excludedNamespaces: - arms-prom excludedResources: - secrets appRestoreOnly: false convertedarg: - convertToStorageClassType: alicloud-disk-topology-alltype namespace: default persistentVolumeClaim: alicloud-disk - convertToStorageClassType: alibabacloud-cnfs-nas namespace: default persistentVolumeClaim: pvc-nas namespaceMapping: <backupNamespace>: <restoreNamespace> EOFパラメーター
説明
excludedNamespaces
除外する名前空間。バックアップリソースリストから不要な名前空間を除外できます。
excludedResources
除外するリソース。バックアップリソースリストから不要なリソースタイプを除外できます。
appRestoreOnly
ボリュームを含むバックアップの場合、このパラメーターはボリュームをリストアするかどうかを指定します。
true：リストア中に新しいデータソースを指す動的ボリュームとストレージクレームを作成します。コンソールで作成されたバックアップタスクはデフォルトで true です。false：静的ボリュームは作成されません。事前に静的ボリュームを手動でデプロイする必要があります。
説明通常、データソースの変更の場合は
trueに、データソース不変の場合はfalseに設定します。convertedarg
StorageClass 変換リスト。OSS、NAS、CPFS、ローカルボリュームなどの FileSystem タイプのボリュームの場合、このパラメーターを構成して、リストアプロセス中にそれらの PVC の StorageClass を指定された StorageClass に変換できます。たとえば、NAS ボリュームをディスクボリュームに変換できます。
convertToStorageClassType：目的の StorageClass。現在のクラスターに StorageClass が存在することを確認してください。ディスクまたは NAS の StorageClass のみを指定できます。
namespace：PVC の名前空間。
persistentVolumeClaim：PVC の名前。
上記は、StorageClass 変換機能の必須パラメーターです。
次のコマンドを実行して、リストアタスクのステータスをクエリします。
kubectl -ncsdr describe applicationrestore <your-restore-name>想定される出力では、
StatusのPhaseがCompletedに変わり、タスクが正常にリストアされたことを示します。次のコマンドを実行して、リストアに失敗したリソースを確認し、失敗の原因を見つけます。
kubectl -ncsdr get pod | grep csdr-velero kubectl -ncsdr exec -it <csdr-velero-pod-name> -- /velero describe restore <your-restore-name> --details想定される出力：
Warnings: Velero: <none> Cluster: could not restore, ClusterRoleBinding "kubernetes-proxy" already exists. Warning: the in-cluster version is different than the backed-up version. Namespaces: demo-ns: could not restore, ConfigMap "kube-root-ca.crt" already exists. Warning: the in-cluster version is different than the backed-up version. could not restore, Endpoints "kubernetes" already exists. Warning: the in-cluster version is different than the backed-up version. could not restore, Service "kubernetes" already exists. Warning: the in-cluster version is different than the backed-up version. Errors: Velero: <none> Cluster: <none> Namespaces: demo-ns: error restoring endpoints/xxxxxx/kubernetes: Endpoints "kubernetes" is invalid: subsets[0].addresses[0].ip: Invalid value: "169.254.128.9": may not be in the link-local range (169.xxx.0.0/16, fe80::/10) error restoring endpointslices.discovery.k8s.io/demo-ns/kubernetes: EndpointSlice.discovery.k8s.io "kubernetes" is invalid: endpoints[0].addresses[0]: Invalid value: "169.xxx.128.9": may not be in the link-local range (169.xxx.0.0/16, fe80::/10) error restoring services/xxxxxx/kubernetes-extranet: Service "kubernetes-extranet" is invalid: spec.ports[0].nodePort: Invalid value: 31882: provided port is already allocated上記の出力から、リストアクラスターでリストアされなかったリソースがあるかどうかを確認できます。たとえば、
Warningsはリソースが既に存在し、スキップされたことを示します。Errorsは、クラスター間のリストア中に元のポートが保持されるため、NodePort の競合を示します。リストアされたアプリケーションが正常に実行されていることを確認します。
アプリケーションがリストアされた後、アプリケーションの制約、コンテナランタイムの例外、またはその他の理由により、異常な状態のリソースがあるかどうかを確認します。もしあれば、手動で修正します。
リカバリが確認された後、Nginx アプリケーションの
apiVersionは、バージョン 1.28 のクラスターで推奨される apps/v1 にデフォルトで調整されます。