バックアップセンターを使用して、古いKubernetesバージョンを実行するACKクラスターでアプリケーションを移行する - Container Service for Kubernetes

バックアップセンターを使用して、FlexVolumeを使用するContainer Service for Kubernetes (ACK) クラスターからCSIを使用するACKクラスターにアプリケーションを移行できます。バックアップセンターを使用して、古いKubernetesバージョンを実行するACKクラスターから新しいKubernetesバージョンを実行するACKクラスターにアプリケーションを移行することもできます。バックアップセンターは、異なるボリュームプラグインを使用したり、異なるバージョンのKubernetesを実行したりするクラスター間でアプリケーションを移行するのに役立ちます。たとえば、アイドル状態のクラスターレベルのリソースをバックアップしたり、リソースが復元されるクラスターでサポートされているAPIバージョンに自動的に切り替えたりする場合に、バックアップセンターを使用できます。このトピックでは、バックアップセンターを使用してアプリケーションを移行する方法について説明します。このトピックでは、FlexVolumeを使用し、Kubernetes 1.16を実行するクラスター内のアプリケーションは、CSIを使用し、Kubernetes 1.28を実行するクラスターに移行されます。

使用上の注意

バックアップクラスターと復元クラスターは、同じリージョンにデプロイする必要があります。バックアップクラスターはKubernetes 1.16以降を実行する必要があります。 APIバージョンの互換性の問題が発生した場合に備えて、バックアップセンターを使用して、新しいKubernetesバージョンを実行するクラスターから古いKubernetesバージョンを実行するクラスターにアプリケーションを移行しないことを推奨します。
バックアップセンターは、削除中のリソースをバックアップしません。
CNFSが管理するFile Storage NAS (NAS) ボリュームにバックアップを復元するには (StorageClassをalibabacloud-cnfs-nasに設定して) 、最初にStorageClassを作成する必要があります。詳細については、「CNFSを使用したNASファイルシステムの管理 (推奨) 」をご参照ください。
バックアップセンターは、復元クラスタについて提案されたAPIバージョンにアプリケーションを復元することが好ましい。リソースの新旧バージョンでAPIバージョンがサポートされていない場合は、リソースを手動でデプロイする必要があります。例：
- Kubernetesを実行するクラスターでのデプロイは、拡張機能 /v1beta1、apps/v1beta1、apps/v1beta2、およびapps/v1をサポート1.16ます。このシナリオでは、Kubernetes 1.28を実行するクラスター内のAPIバージョンのDeploymentsがapps/v1に復元されます。
- Kubernetes 1.16を実行するクラスターのIngressは、extensions/v1beta1とnetworking.k8s.io/v1beta1をサポートしています。このシナリオでは、Kubernetes 1.22以降を実行するクラスターでIngressを復元することはできません。
異なるバージョンのKubernetesのAPIアップデートの詳細については、「ACKでサポートされているKubernetesバージョンのリリースノート」および「非推奨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に切り替えることができます。バックアップセンターを使用して、複数のKubernetesバージョン間でアプリケーションを移行できます。バックアップセンターは、APIバージョンなどのアプリケーションテンプレートの基本構成を新しいKubernetesバージョンに自動的に適合させることができます。

前提条件

クラウドバックアップが有効化されました。 NASファイルシステム、OSSバケット、ローカルディスクを使用するボリュームをバックアップするか、ハイブリッドクラウドシナリオでボリュームをバックアップするには、クラウドバックアップを使用してバックアップを作成するようにバックアップセンターを設定する必要があります。詳しくは、「API を介したメトリックデータのアクセス」をご参照ください。
「クラウドバックアップ」をご参照ください。
ボリュームが復元されるクラスターが作成されます。 Elastic Compute Service (ECS) インスタンスのスナップショットを使用してディスクデータを復元できるようにするには、Kubernetesバージョンのクラスターを1.18以降に更新することを推奨します。詳細については、「ACK管理クラスターの作成」、「ACK専用クラスターの作成」、または「クラスター登録プロキシの作成とデータセンターにデプロイされたKubernetesクラスターの登録」をご参照ください。
重要
- 復元クラスターでは、Container Storage Interface (CSI) プラグインを使用する必要があります。 FlexVolumeを使用するクラスター、またはcsi-compatible-controllerとFlexVolumeを使用するクラスターでは、アプリケーションの復元はサポートされません。
- バックアップセンターは、アプリケーションのバックアップと復元に使用されます。復元タスクを実行する前に、復元クラスターにシステムコンポーネントをインストールして構成する必要があります。例：
  - aliyun-acr-credential-helper: 復元クラスターにアクセス許可を付与し、acr-configurationを設定する必要があります。
  - alb-ingress-controller: ALBConfigを設定する必要があります。
migrate-コントローラがインストールされ、権限が付与されます。詳細については、「migrate-controllerのインストールと権限の付与」をご参照ください。
ディスクスナップショットを作成してボリュームをバックアップするには、CSI 1.1.0以降をインストールする必要があります。 CSIプラグインのインストール方法の詳細については、「CSIプラグインの管理」をご参照ください。
kubectlクライアントがクラスターに接続されています。

移行ワークフロー

移行ワークフローは、バックアップクラスターで使用されるボリュームプラグインによって異なります。以下の図は詳細を示す。

バックアップクラスターのアプリケーションはボリュームを使用しません

バックアップクラスターでFlexVolumeを使用

バックアップクラスターがCSIを使用

手順

この例では、FlexVolumeを使用し、Kubernetes 1.16を実行するACKクラスターを使用します。この例では、クラスターからCSIを使用してKubernetes 1.28を実行するACKクラスターにアプリケーション、設定、ボリュームを移行する方法を示します。移行は、データソースの変更またはデータソースの変更なしで実行できます。ボリュームを使用しないアプリケーションを移行したり、CSIを使用するクラスターからアプリケーションを移行したりするには、オプションの手順をスキップできます。

重要

データソースを変更しない場合は、バックアップクラスターの永続ボリューム (PV) の再利用ポリシーをRetainに設定します。それ以外の場合、ボリュームの削除後にデータが削除されます。

kubectl patch pv/<pv-name> --type='json' -p '[{"op":"replace","path":"/spec/persistentVolumeReclaimPolicy","value":"Retain"}]'

移動方法	説明	使用シナリオ
データソースの変更	バックアップクラスターのボリュームに保存されているデータをバックアップし、バックアップを復元クラスターに同期します。つまり、バックアップクラスターと復元クラスターはそれぞれデータソースを使用します。データ復元プロセスは、動的にプロビジョニングされたボリュームを使用します。 StorageClassを変更することで、ボリュームタイプを変換できます。たとえば、NASボリュームをディスクボリュームに変換できます。	バックアップおよび復元クラスターのアプリケーションでは、異なるデータソースを使用するようにします。データを復元するときにStorageClassを変更します。
データソースを変更しない	復元プロセスでは、バックアップ内の永続ボリューム (PV) および永続ボリューム要求 (PVC) から復元された静的にプロビジョニングされたボリュームを使用します。したがって、バックアップクラスターと復元クラスターは、ディスクIDやObject Storage Service (OSS) バケットなど、同じデータソースを使用します。 FlexVolumeからCSIにアプリケーションを移行する場合、CSIはFlexVolume YAMLテンプレートをサポートしていないため、静的にプロビジョニングされたPVおよびPVCを手動で作成する必要があります。	データの復元中にビジネスの書き込み操作を一時停止することはできません。ビジネスではデータの一貫性が必要です。

環境の準備

移動方法	バックアップクラスター	クラスターの復元
Kubernetes バージョン	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
その他	テストアプリケーションを展開します。アプリケーションの`apiVersion`はextensions/v1beta1です。ディスクとNASボリュームをアプリケーションにマウントします。	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に設定されています。このAPIバージョンは、Kubernetes 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のインストールと権限の付与」をご参照ください。
説明
- ACKコンソールの [アドオン] ページから、Kubernetesバージョンが1.16以降のクラスターにmigrate-controller 1.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-controllerポッドは例外的に終了し、アプリケーションのバックアップページに404エラーが表示されます。この場合、USE_FLEXVOLUME環境変数をmigrate-controllerのYAMLファイルに追加する必要があります。
```
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"}}]'
```

次のコマンドを実行して、migrate-controllerが正常に実行されることを確認します。

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バケットに対する権限があります。 OSSバケットが命名規則に準拠していない場合は、追加の権限を付与する必要があります。詳細については、「migrate-controllerのインストールと権限の付与」をご参照ください。
バックアップコンテナーを作成します。詳細については、「バックアップコンテナーの作成」をご参照ください。

次のコマンドを実行して、リアルタイムバックアップタスクを作成します。

コンソールでバックアップパラメーターを設定する方法の詳細については、「ACKクラスターでのアプリケーションのバックアップと復元」をご参照ください。このステップでは、実際のシナリオに基づいて推奨設定を変更できます。

cat << EOF | kubectl apply -f -
apiVersion: csdr.alibabacloud.com/v1beta1
kind: ApplicationBackup
metadata:
  annotations:
    csdr.alibabacloud.com/backuplocations: '{"name":"<Backup vault name>","region":"<Region ID, such as cn-beijing>","bucket":"<Name of the OSS bucket associated with the backup vault>","provider":"alibabacloud"}'
  labels:
    csdr/schedule-name: fake-name
  name: <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: <Backup vault name>
  ttl: 720h0m0s
EOF

パラメーター	説明
excludedNamespaces	バックアップタスクから除外する名前空間のリスト。次の名前空間を除外することを推奨します。 `csdr`: バックアップセンターの名前空間。バックアップセンターは、クラスター間でデータを自動的に同期します。 csdr名前空間のバックアップおよび復元タスクを手動でバックアップしないでください。要件に従っていない場合、例外が発生する可能性があります。 `kube-system`、`kube-public`、および`kube-node-lease`: ACKクラスターのデフォルトの名前空間。クラスターパラメーターや設定が異なるため、これらの名前空間を直接復元することはできません。
excludedResources	バックアップタスクから除外するリソースのリスト。ビジネス要件に基づいてリストを設定します。
includeClusterResources	StorageClasses、CustomResourceDefinitions (CRD) 、webhooksなど、すべてのクラスターレベルのリソースをバックアップするかどうかを指定します。 `true`: すべてのクラスターレベルのリソースをバックアップします。 `false`: 指定された名前空間内の名前空間レベルのリソースによって使用されるクラスターレベルのリソースのみをバックアップします。たとえば、システムがポッドをバックアップすると、ポッドで使用されるサービスアカウントにクラスターロールが割り当てられます。この場合、クラスターロールは自動的にバックアップされます。システムがCustomResource (CR) をバックアップすると、対応するCRDがバックアップされます。説明デフォルトでは、ACKコンソールで作成されたバックアップタスクでは、`IncludeClusterResources`が`false`に設定されます。
defaultPvBackup	ボリューム内のデータをバックアップするかどうかを指定します。 `true`: ボリューム内でポッドを実行することによって使用されるアプリケーションとデータをバックアップします。 `false`: アプリケーションのみをバックアップします。重要デフォルトでは、ECS (Elastic Compute Service) スナップショットは、KubernetesとCSIの両方のバージョンが1.18またはそれ以降のクラスター内のディスクボリュームをバックアップするために作成されます。クラウドバックアップを使用して、前述のクラスター内の他のタイプのボリューム、またはKubernetesおよびCSIのバージョンが1.16〜1.18 (1.18を除く) のクラスター内のディスクボリュームをバックアップします。実行中のポッドによって使用されないボリュームの場合、復元クラスターに静的にプロビジョニングされたPVおよびPVCを手動で作成し、ディスクIDやOSSバケットなどのボリュームソースを指定する必要があります。つまり、このシナリオではデータソースを変更できません。ビジネスがデータの一貫性に強く依存している場合は、バックアッププロセス中に書き込み操作を一時停止する必要があります。データソースを変更せずにアプリケーションのみをバックアップすることもできます。

次のコマンドを実行して、バックアップタスクのステータスを照会します。
```
kubectl -ncsdr describe applicationbackup <Backup name>
```
出力の [ステータス] 列の [フェーズ] が [完了] に変更された場合、バックアップタスクが作成されます。

次のコマンドを実行して、バックアップするリソースのリストを確認します。

kubectl -ncsdr get pod | grep csdr-velero
kubectl -ncsdr exec -it <Name of the csdr-velero pod> -- /velero describe backup <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: バックアップクラスターにバックアップセンターをインストールする」をご参照ください。
前述のバックアップコンテナーを復元クラスターに関連付けます。
1. ACKコンソールにログインします。
2. [クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[操作] > [アプリケーションのバックアップ] を選択します。
3. [アプリケーションバックアップ] ページで、[復元] をクリックします。
4. [バックアップボールト] ドロップダウンリストからバックアップボールトを選択し、[バックアップボールトの初期化] をクリックして、システムが現在のクラスターにバックアップを同期するのを待ちます。

(オプション) 手順5: 復元クラスターにPVとPVCを手動で作成する

ほとんどのシナリオでは、復元クラスターで復元タスクを作成するには、手順6を実行するだけです。バックアップセンターは、バックアップからPVとPVCを自動的に作成します。

データを保護するために、バックアップセンターが復元タスクを実行するときに、バックアップと同じ名前の既存のPVおよびPVCを再作成または上書きしません。次のシナリオでは、復元タスクの開始前にPVとPVCを作成できます。

ボリュームをバックアップし、一部のボリュームに保存されているログをスキップします。
ポッドの実行によって使用されていないボリュームをバックアップします。
excludedResourcesリストで指定されているボリュームおよびpersistentvolumeclaimsおよびpersistentvolumesをバックアップしないか、またはアプリケーションをFlexVolumeからCSIに移行します。

手順：

重要

ゾーン間でディスクをマウントすることはできません。復元クラスター内の別のゾーンのリソースを復元する場合は、次のいずれかのソリューションを使用します。

データソースを変更してデータを同期します。
ECS コンソールにログインします。ディスクのスナップショットを作成し、新しいゾーンのスナップショットからディスクを作成します。詳細については、「ディスクのスナップショットの作成」をご参照ください。 outputfile.txtという名前の次のYAMLファイルのnodeAffinityとディスクIDのゾーンIDを置き換えます。

(オプション) バックアップクラスターでFlexVolumeを使用する場合、FlexVolumeとCSIによって管理されるPVおよびPVCのYAMLファイルが異なるため、Flexvolume2CSI CLIを使用してYAMLファイルをバッチ変換する必要があります。詳細については、「Flexvolume2CSIを使用したPVおよびPVCのバッチ変換」をご参照ください。

次のコマンドを実行して、Flexvolume2CSIを使用し、CSIでサポートされているYAMLファイルを生成します。

outputfile.txtは、Flexvolume2CSIによって生成されたYAMLファイルです。

outputfile.txtファイルの内容を表示

---
apiVersion: v1
kind: PersistentVolume
metadata:
  labels:
    alicloud-pvname: d-2ze88915lz1il0**** # The dynamically provisioned disk. 
  name: d-2ze88915lz1il0****
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 20Gi
  csi:
    driver: diskplugin.csi.alibabacloud.com
    fsType: ext4
    volumeHandle: d-2ze88915lz1il0****
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.diskplugin.csi.alibabacloud.com/zone
          operator: In
          values:
          - cn-beijing-i
  persistentVolumeReclaimPolicy: Delete
  storageClassName: alicloud-disk-essd
  volumeMode: Filesystem

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: disk-essd
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  selector:
    matchLabels:
      alicloud-pvname: d-2ze88915lz1il0****
  storageClassName: alicloud-disk-essd
  volumeMode: Filesystem

---
apiVersion: v1
kind: PersistentVolume
metadata:
  labels:
    alicloud-pvname: pv-nas
  name: pv-nas
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 5Gi
  csi:
    driver: nasplugin.csi.alibabacloud.com
    volumeAttributes:
      server: 1758axxxxx-xxxxx.cn-beijing.nas.aliyuncs.com
    volumeHandle: pv-nas
  mountOptions:
  - vers=3
  - nolock,tcp,noresvport
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nas
  volumeMode: Filesystem

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-nas
  namespace: default
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  selector:
    matchLabels:
      alicloud-pvname: pv-nas
  storageClassName: nas
  volumeMode: Filesystem

kubectl apply -f outputfile.txt

次のコマンドを実行して、復元クラスターのPVCがバインド状態であることを確認します。

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: 復元クラスターでの復元タスクの作成

重要

同じ名前のリソースが復元クラスターにすでに存在する場合、復元タスクはリソースをスキップします。
バックアップセンターは、アプリケーションをバックアップおよび復元するために開発されています。復元タスクを実行する前に、復元クラスターにシステムコンポーネントをインストールして構成する必要があります。例：
- Container Registryのパスワード不要のイメージプルコンポーネント: 復元クラスターにアクセス許可を付与し、acr-configurationを設定する必要があります。
- ALB Ingressコンポーネント: ALBConfigを設定する必要があります。

説明

サービスを復元するときは、次の項目に注意してください。

NodePortサービス: デフォルトでは、クラスター間でサービスを復元するときにサービスポートが保持されます。
LoadBalancerサービス: デフォルトでは、ExternalTrafficPolicyがLocalに設定されている場合、ランダムなHealthCheckNodePortが使用されます。ポートを保持するには、復元タスクの作成時にspec.preserveNodePorts: trueを指定します。
- バックアップクラスター内の既存のSLBインスタンスを使用するサービスを復元する場合、復元されたサービスは同じSLBインスタンスを使用し、デフォルトでリスナーを無効にします。リスナーを設定するには、SLBコンソールにログインする必要があります。
- LoadBalancerサービスは、バックアップクラスターのクラウドコントローラマネージャー (CCM) によって管理されます。 LoadBalancerサービスを復元すると、復元されたサービスのSLBインスタンスがCCMによって自動的に作成されます。詳細については、「LoadBalancerタイプのサービスの設定に関する考慮事項」をご参照ください。

ボリュームのバックアップを選択した場合、復元クラスターは別のデータソースを使用します。 convertedargを使用して、ボリュームタイプを変換できます。たとえば、NASボリュームをディスクボリュームに変換できます。ビジネス要件に基づいてStorageClassを選択できます。

この例では、バックアップクラスターはKubernetes 1.16を実行し、FlexVolumeを使用します。ディスクボリュームは、Cloud Backupを使用してバックアップされます。したがって、disk-essd PVCにはalicloud-disk StorageClassを指定できます。これは、ボリュームをCSIによって管理されるディスクボリュームに変換する。デフォルトのStorageClassはalicloud-disk-topology-alltypeです。バックアップクラスターがKubernetes 1.18以降を実行し、CSIを使用する場合、ディスクボリュームを変換する必要はありません。
この例では、pvc-nas PVCにalibabacloud-cnfs-nas StorageClassを指定します。これにより、FlexVolumeが管理するNASボリュームがCNFSが管理するNASボリュームに変換されます。 alibabacloud-cnfs-nas StorageClassがクラスターで使用されていない場合は、「CNFSを使用してNASファイルシステムを管理する (推奨) 」をご参照ください。

手順：

次のコマンドを実行して、復元タスクを作成します。

コンソールで復元タスクを設定する方法の詳細については、「ACKクラスターでのアプリケーションのバックアップと復元」をご参照ください。このステップでは、実際のシナリオに基づいて推奨設定を変更できます。

cat << EOF | kubectl apply -f -
apiVersion: csdr.alibabacloud.com/v1beta1
kind: ApplicationRestore
metadata:
    csdr.alibabacloud.com/backuplocations: >-
       '{"name":"<Backup vault name>","region":"<Region ID, such as cn-beijing>","bucket":"<Name of the OSS bucket associated with the backup vault>","provider":"alibabacloud"}'
  name: <Restore name>
  namespace: csdr
spec:
  backupName: <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`: バックアップセンターは、新しいデータソースを指す動的にプロビジョニングされたPVとPVCを作成します。コンソールで作成された復元タスクのパラメーターはtrueに設定されます。 `false`: 復元タスクを開始する前に、静的にプロビジョニングされたボリュームを手動で作成する必要があります。説明ほとんどの場合、データソースを変更する場合はパラメーターを`true`に設定し、データソースを変更しない場合はパラメーターを`false`に設定します。
convertedarg	StorageClass変換リスト。 OSS、NAS、CPFS、ローカルボリュームなどのFileSystemタイプのボリュームの場合、このパラメーターを設定して、復元プロセス中にPVCのStorageClassesを指定されたStorageClassに変換できます。たとえば、NASボリュームをディスクボリュームに変換できます。 convertToStorageClassType: 目的のStorageClass。現在のクラスターにStorageClassが存在することを確認します。指定できるのは、ディスクまたはNAS StorageClassのみです。 namespace: PVCの名前空間。 persistentVolumeClaim: PVCの名前。 `kubectl -ncsdr describe <backup-name>` コマンドを実行して、バックアップのPVC情報を照会できます。返された`status.resourceList.dataResource.pvcBackupInfo`リストのdataTypeフィールドには、PVCのデータ型 (FileSystemまたはSnapshot) が表示されます。 nameSpaceフィールドとpvcNameフィールドには、PVCの名前空間と名前が表示されます。

次のコマンドを実行して、復元タスクのステータスを照会します。
```
kubectl -ncsdr describe applicationrestore <Backup name>
```
出力の [ステータス] 列の [フェーズ] が [完了] に変更された場合、復元タスクが作成されます。

次のコマンドを実行して、リソースの復元に失敗したかどうかを確認し、原因を確認します。

kubectl -ncsdr get pod | grep csdr-velero
kubectl -ncsdr exec -it <Name of the csdr-velero pod> -- /velero describe restore <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

上記の出力の警告情報は、復元タスクによって一部のリソースがスキップされることを示しています。エラー情報は、NodePortの再利用が失敗したことを示します。元のポートは、サービスがクラスター間で復元されるときに保持されます。

アプリケーションが正常に実行されるかどうかを確認します。
1. アプリケーションが復元された後、ビジネスの制限、コンテナの例外、またはその他の問題により、リソースが異常なステータスになっているかどうかを確認します。はいの場合、手動で問題を修正します。
2. 問題を修正すると、アプリケーションのapiVersionが自動的にapps/v1に設定されます。これは、Kubernetes 1.28を実行するACKクラスターに推奨されます。