すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:Jun 11, 2025

    バックアップセンターを使用して、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 によって管理されている NAS ファイルシステム （[StorageClass] を [alibabacloud-cnfs-nas] に設定することにより）にバックアップをリストアするには、最初に StorageClass を作成する必要があります。 詳細については、「CNFS を使用して NAS ファイルシステムを管理する（推奨）」をご参照ください。

    • バックアップセンターは、できればリストアクラスタに推奨される API バージョンにアプリケーションをリストアします。 リソースの古い Kubernetes バージョンと新しい Kubernetes バージョンの両方でサポートされている API バージョンがない場合は、リソースを手動でデプロイする必要があります。 例：

      • Kubernetes 1.16 を実行するクラスタ内のデプロイメントは、extensions/v1beta1、apps/v1beta1、apps/v1beta2、および apps/v1 をサポートしています。 このシナリオでは、Kubernetes 1.28 を実行するクラスタ内のデプロイメントの API バージョンは 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 バージョンに自動的に適合させることができます。

    前提条件

    • Cloud Backup がアクティブ化されています。 NAS ファイルシステム、OSS バケット、およびローカルディスクを使用するボリュームをバックアップする場合、またはハイブリッドクラウドシナリオでボリュームをバックアップする場合は、Cloud Backup を使用してバックアップを作成するようにバックアップセンターを構成する必要があります。 詳細については、 Cloud Backup をご参照ください。

    • ボリュームが解凍されるクラスターが作成されます。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-controller がインストールされ、権限が付与されている。

    • ディスクスナップショットを作成してボリュームをバックアップするには、CSI 1.1.0 以降をインストールする必要があります。 詳細については、「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: テストアプリケーションをデプロイする

    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

    2. 次のコマンドを実行して、静的にプロビジョニングされた 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

    3. 次のコマンドを実行して、アプリケーションをデプロイし、ディスクボリュームと 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

    4. 次のコマンドを実行して、アプリケーションが正常に実行されていることを確認します。

      kubectl get pod -l app=nginx

      予期される結果：

      NAME                    READY   STATUS    RESTARTS   AGE
nginx-5ffbc895b-xxxxx   1/1     Running   0          2m28s

    ステップ 2: バックアップクラスタにバックアップセンターをインストールする

    1. migrate-controller をインストールするをバックアップ クラスターにインストールします。

      説明

      • ACK コンソールのアドオンページから、Kubernetes バージョンが 1.16 以後のクラスタに migrate-controller 1.7.6 以降を直接インストールできます。

      • バックアップ クラスターが ACK 専用クラスター、登録済みクラスター、または CSI 以外のボリューム プラグイン (FlexVolume など) を使用するクラスターの場合、追加の権限を付与する必要があります。詳細については、「登録済みクラスター」をご参照ください。

    2. (オプション) クラスタが FlexVolume を使用している場合は、次のコマンドを実行して、必要な権限が付与されていることを確認します。

      kubectl -n csdr get secret alibaba-addon-secret

    3. (オプション) クラスタが FlexVolume を使用している場合は、次のコマンドを実行して、kube-system 名前空間に migrate-controller をデプロイするための USE_FLEXVOLUME 環境変数を追加します。

      重要

      FlexVolume を使用するクラスタに migrate-controller がインストールされると、migrate-controller ポッドが例外的に終了し、アプリケーションバックアップページに 404 エラーが表示されます。 この場合は、migrate-controller の 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"}}]'

    4. 次のコマンドを実行して、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: バックアップクラスタにバックアップを作成する

    1. OSS バケットを作成するという名前で、バックアップ クラスタのリージョンに cnfs-oss-* という名前の OSS バケットを作成して、バックアップを保存します。

      説明

      デフォルトでは、ACK マネージドクラスターには、cnfs-oss-*migrate-controller をインストールし、権限を付与する という名前の OSS バケットに対する権限があります。 OSS バケットがこの命名規則に準拠していない場合は、追加の権限を付与する必要があります。 詳細については、「」をご参照ください。

    2. バックアップボールトを作成する。

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

      コンソールでバックアップ パラメーターを構成する方法の詳細については、「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"}'  // バックアップ場所に関するアノテーション。{"name":"<バックアップ ボールト名>","region":"<リージョン ID、例: cn-beijing>","bucket":"<バックアップ ボールトに関連付けられた OSS バケットの名前>","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

      StorageClass、CustomResourceDefinitions（CRD）、Webhook など、すべてのクラスタレベルのリソースをバックアップするかどうかを指定します。

      • true: すべてのクラスタレベルのリソースをバックアップします。

      • false: 指定された名前空間の名前空間レベルのリソースで使用されるクラスタレベルのリソースのみをバックアップします。たとえば、システムがポッドをバックアップすると、ポッドで使用される サービスアカウント にクラスタ ロールが割り当てられます。この場合、クラスタ ロールは自動的にバックアップされます。システムがCustomResource（CR）をバックアップすると、対応するCRDがバックアップされます。

      説明

      IncludeClusterResourcesfalseデフォルトでは、ACK コンソール で作成されたバックアップ タスクの場合、IncludeClusterResources は false に設定されています。

      defaultPvBackup

      ボリューム内のデータをバックアップするかどうかを指定します。

      • true: 実行中のポッドで使用される アプリケーション とボリューム内のデータをバックアップします。

      • false: アプリケーションのみをバックアップします。

      重要

      • デフォルトでは、Kubernetes と CSI のバージョンが両方とも 1.18 以降のクラスタでは、Elastic Compute Service（ECS）スナップショットが作成されてディスク ボリュームがバックアップされます。Cloud Backup は、前述のクラスタ内の他のタイプのボリューム、または Kubernetes と CSI のバージョンが 1.16 から 1.18（1.18 を除く）のクラスタ内のディスク ボリュームをバックアップするために使用されます。

      • 実行中のポッドで使用されていないボリュームの場合、リストア クラスタに静的にプロビジョニングされた PV と PVC を手動で作成し、ディスク ID や OSS バケットなどのボリューム ソースを指定する必要があります。これは、このシナリオではデータ ソースを変更できないことを意味します。

      • ビジネスがデータ整合性に強く依存している場合は、バックアップ プロセス中に書き込み操作を一時停止する必要があります。データ ソースを変更せずに アプリケーション のみバックアップすることもできます。

    4. 次のコマンドを実行して、バックアップタスクのステータスをクエリします。

      kubectl -ncsdr describe applicationbackup <バックアップ名>

      出力の Status 列の Phase が Completed に変わると、バックアップ タスクが作成されます。

    5. 次のコマンドを実行して、バックアップが正常に作成されたことを確認します。

      kubectl get backups.velero.io -n csdr

      バックアップリストでスキップされたリソースを表示し、バックアップパラメーターを変更してから、バックアップタスクを再実行できます。

      NAME           STATUS      CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
nginx-backup   Completed   2023-11-28 12:00:00 +0000 UTC   <never>   default           app=nginx

    ステップ 4: リストアクラスタにバックアップセンターをインストールする

    1. 復元クラスターにバックアップセンターをインストールします。詳細については、「手順 2: バックアップクラスターにバックアップセンターをインストールする」をご参照ください。

    2. 上記のバックアップボールトを復元クラスターに関連付けます。

      1. ACK コンソール にログオンします。

      2. [クラスター] ページで、管理するクラスターを見つけ、その名前をクリックします。左側のペインで、[操作] > [アプリケーションバックアップ] を選択します。

      3. [アプリケーションバックアップ] ページで、[復元] をクリックします。

      4. [バックアップボールト] ドロップダウンリストからバックアップボールトを選択し、[バックアップボールトの初期化] をクリックして、システムが現在のクラスターにバックアップを同期するまで待ちます。

    ステップ 5: アプリケーションをリストアする

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

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

    • 一部のボリュームに保存されているログをスキップして、ボリュームをバックアップする場合。

    • 実行中のポッドで使用されていないボリュームをバックアップする場合。

    • ボリュームをバックアップしたくない、excludedResources リストに persistentvolumeclaims と persistentvolumes が指定されている、または FlexVolume から CSI にアプリケーションを移行する場合。

    手順:

    重要

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

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

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

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

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

      ---
apiVersion: v1
kind: PersistentVolume
metadata:
  labels:
    alicloud-pvname: d-2ze88915lz1il0**** # 動的にプロビジョニングされたディスク。
  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

    3. 次のコマンドを実行して、リストア クラスタの 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-configuration に権限を付与し、構成する必要があります。

      • ALB Ingress コンポーネント: ALBConfig を構成する必要があります。

    説明

    サービスを解凍する場合は、次の点に注意してください。

    • NodePort サービス: デフォルトでは、クラスター間でサービスを解凍する場合、サービス ポートは保持されます。

    • LoadBalancer サービス: デフォルトでは、ExternalTrafficPolicy が Local に設定されている場合、ランダムな HealthCheckNodePort が使用されます。ポートを保持するには、解凍タスクを作成するときに spec.preserveNodePorts: true を指定します。

      • バックアップ クラスター内の既存の SLB インスタンスを使用するサービスを解凍する場合、解凍されたサービスは同じ SLB インスタンスを使用し、デフォルトでリスナーを無効にします。 SLB コンソールにログインして、リスナーを設定する必要があります。

      • LoadBalancer サービスは、バックアップ クラスターのクラウド コントローラー マネージャー ( CCM ) によって管理されます。 LoadBalancer サービスを解凍すると、CCM は解凍されたサービスの SLB インスタンスを自動的に作成します。詳細については、「LoadBalancer タイプのサービスを構成する場合の考慮事項」をご参照ください。

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

    • この例では、バックアップ クラスターは Kubernetes 1.16 を実行し、FlexVolume を使用します。ディスク ボリュームは、Cloud Backup を使用してバックアップされます。そのため、disk-essd PVC には alicloud-disk ストレージクラスを指定できます。これにより、ボリュームは 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 ファイルシステムを管理する（推奨）」をご参照ください。

    手順:

    1. 復元タスクを作成するには、次のコマンドを実行します。

      コンソールで復元タスクを構成する方法の詳細については、「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"}'  // バックアップボールト名、リージョンID、関連付けられたOSSバケット名などを指定します。
  name: <Restore name> // 復元名
  namespace: csdr
spec:
  backupName: <Backup name> // バックアップ名
  excludedNamespaces: // 除外する名前空間のリスト
  - arms-prom
  excludedResources: // 除外するリソースのリスト
  - secrets
  appRestoreOnly: false
  convertedarg: // StorageClass変換リスト
  - convertToStorageClassType: alicloud-disk-topology-alltype // 目的のStorageClass
    namespace: default // PVCの名前空間
    persistentVolumeClaim: alicloud-disk // PVCの名前
  - convertToStorageClassType: alibabacloud-cnfs-nas // 目的のStorageClass
    namespace: default // PVCの名前空間
    persistentVolumeClaim: pvc-nas // PVCの名前
  namespaceMapping: // 名前空間マッピング
    <backupNamespace>: <restoreNamespace>
EOF

      パラメーター

      説明

      excludedNamespaces

      除外する名前空間のリスト。バックアップリストにある名前空間を復元タスクから除外できます。

      excludedResources

      除外するリソースのリスト。バックアップリストにあるリソースを復元タスクから除外できます。

      appRestoreOnly

      ボリュームバックアップからボリュームを復元するかどうかを指定します。

      • true: バックアップセンターは、新しいデータソースを指す動的にプロビジョニングされた PV と PVC を作成します。このパラメーターは、コンソールで作成された復元タスクに対して true に設定されます。

      • false: 復元タスクが開始される前に、静的にプロビジョニングされたボリュームを手動で作成する必要があります。

      説明

      ほとんどの場合、データソースを変更する場合はパラメーターを true に設定し、データソースを変更しない場合は false に設定します。

      convertedarg

      StorageClass 変換リスト。 OSS、NAS、CPFS、ローカルボリュームなどのファイルシステムタイプのボリュームの場合、このパラメーターを構成して、復元プロセス中に PVC の StorageClass を指定された StorageClass に変換できます。たとえば、NAS ボリュームをディスクボリュームに変換できます。

      • convertToStorageClassType: 目的の StorageClass。 StorageClass が現在のクラスターに存在することを確認してください。ディスクまたは NAS StorageClass のみ指定できます。

      • namespace: PVC の名前空間。

      • persistentVolumeClaim: PVC の名前。

      上記は、StorageClass 変換機能に必要なパラメーターです。

    2. 復元タスクのステータスを照会するには、次のコマンドを実行します。

      kubectl -ncsdr describe applicationrestore <Backup name>

      出力の Status 列の Phase が Completed に変わると、復元タスクが作成されます。

    3. リソースが復元できなかったかどうかを確認し、原因を表示するには、次のコマンドを実行します。

      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. // ClusterRoleBinding "kubernetes-proxy" はすでに存在するため復元できませんでした。警告: クラスタ内のバージョンはバックアップされたバージョンと異なります。
  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. // ConfigMap "kube-root-ca.crt" はすでに存在するため復元できませんでした。警告: クラスタ内のバージョンはバックアップされたバージョンと異なります。
               could not restore, Endpoints "kubernetes" already exists. Warning: the in-cluster version is different than the backed-up version. // Endpoints "kubernetes" はすでに存在するため復元できませんでした。警告: クラスタ内のバージョンはバックアップされたバージョンと異なります。
               could not restore, Service "kubernetes" already exists. Warning: the in-cluster version is different than the backed-up version. // Service "kubernetes" はすでに存在するため復元できませんでした。警告: クラスタ内のバージョンはバックアップされたバージョンと異なります。

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) // エンドポイント/xxxxxx/kubernetes の復元エラー: エンドポイント "kubernetes" が無効です: subsets[0].addresses[0].ip: 無効な値: "169.254.128.9": リンクローカル範囲 (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) // endpointslices.discovery.k8s.io/demo-ns/kubernetes の復元エラー: EndpointSlice.discovery.k8s.io "kubernetes" が無効です: endpoints[0].addresses[0]: 無効な値: "169.xxx.128.9": リンクローカル範囲 (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 // サービス/xxxxxx/kubernetes-extranet の復元エラー: サービス "kubernetes-extranet" が無効です: spec.ports[0].nodePort: 無効な値: 31882: 指定されたポートはすでに割り当てられています

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

    4. アプリケーションが正常に動作するかどうかを確認します。

      1. アプリケーションが復元された後、ビジネス制限、コンテナーの例外、またはその他の問題が原因でリソースが異常な状態になっていないかどうかを確認します。異常な状態になっている場合は、手動で問題を修正します。

      2. 問題を修正した後、アプリケーションの apiVersion は自動的に apps/v1 に設定されます。これは、Kubernetes 1.28 を実行する ACK クラスタに推奨されます。