Container Service for Kubernetes:同一リージョン内の VPC 間でのアプリケーション移行とストレージリソースの再利用

前提条件

注意事項

バックアップに関する注意事項

• バックアップセンターは、削除中のリソースをバックアップしません。

• 同一 VPC 内の異なるクラスターの Pod は相互に通信できます。バックアップクラスターから別の VPC の新しいクラスターにアプリケーションを移行した後、新しいクラスターの Pod は、バックアップクラスターが存在する VPC 内の Pod および Elastic Compute Service (ECS) インスタンスと通信できません。詳細については、「ACK マネージドクラスターのネットワーク計画」をご参照ください。

リストアに関する注意事項

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

  • Kubernetes 1.16 を実行するクラスターの Deployment は、extensions/v1beta1、apps/v1beta1、apps/v1beta2、および apps/v1 をサポートします。このシナリオでは、Kubernetes 1.28 を実行するクラスターの Deployment の 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 リソースを手動でリストアする必要があります。

• リストアクラスターでバックアップクラスターが使用する NAS ボリュームまたは OSS バケットを再利用する場合、両方のクラスターが NAS ボリュームまたは OSS バケットからデータを読み書きできます。ただし、リストアクラスターでバックアップクラスターが使用するディスクを再利用する場合、ディスクはバックアップクラスターからデタッチされ、リストアクラスターにアタッチされます。この場合、バックアップクラスターが使用するディスクボリュームをバックアップし、リストアクラスター用に新しいディスクを作成することを推奨します。

  説明

  • 移行中にバックアップクラスターのサービスの可用性を確保する必要がある場合や、データ整合性を損なうことができない場合は、バックアップクラスターが使用するディスクを強制的にデタッチしないことを推奨します。

  • デフォルトでは、Enterprise SSD (ESSD) は高速スナップショット機能をサポートしています。この機能は、バックアッププロセス中のデータセキュリティを確保し、移行プロセスを大幅に高速化します。

課金

バックアップセンター機能は無料です。ただし、この機能を使用する際に、以下の関連サービスに対して課金される場合があります：

• OSS は、YAML ファイルなど、ACK クラスター内のリソースのバックアップファイルを保存するために使用できます。OSS の課金ルールに関する詳細については、「課金の概要」をご参照ください。

• ディスクスナップショットは、ディスクボリュームのバックアップに使用できます。スナップショットの課金ルールに関する詳細については、「スナップショットの課金」をご参照ください。

  説明

  • 2023 年 10 月 12 日 11:00 (UTC+08:00) 以降、スナップショットの高速スナップショットストレージや高速スナップショット機能の有効化に対しては課金されなくなりました。詳細については、「高速スナップショット機能の使用」をご参照ください。

  • デフォルトでは、PL0、PL1、PL2、PL3 のパフォーマンスレベルの ESSD または ESSD AutoPL ディスク用に作成されたスナップショットに対して、高速スナップショット機能が有効になります。

例

このケースでは、NGINX アプリケーション用に nginx-svc という名前の LoadBalancer Service が作成されます。対応する SLB インスタンスは、クラウドコントローラーマネージャー (CCM) によって作成されます。SLB インスタンスの作成方法については、「LoadBalancer Service の設定に関する考慮事項」をご参照ください。

# 動的にプロビジョニングされたディスクボリュームの設定。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-disk
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 20Gi
  storageClassName: alicloud-disk-topology-alltype
---
# 静的にプロビジョニングされたディスクボリュームの設定。
apiVersion: v1
kind: Secret
metadata:
  name: oss-secret
  namespace: default
stringData:
  akSecret: <yourAccessKey Secret>
  akId: <yourAccessKey ID>
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-oss
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: ossplugin.csi.alibabacloud.com
    volumeHandle: pv-oss
    nodePublishSecretRef:
      name: oss-secret
      namespace: default
    volumeAttributes:
      bucket: "a-new-bucket"
      url: "http://oss-cn-beijing.aliyuncs.com"
      otherOpts: "-o allow_other -oumask=000"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-oss
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  volumeName: pv-oss
---
# 動的にプロビジョニングされた NAS ボリュームの設定。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-nas
spec:
  accessModes:
  - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 20Gi
  storageClassName: alibabacloud-cnfs-nas
---
apiVersion: apps/v1
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: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        ports:
        - containerPort: 80
        volumeMounts:
          - name: nas
            mountPath: /nas-data
          - name: oss
            mountPath: /oss-data
          - name: disk
            mountPath: /disk-data
      volumes:
        - name: nas
          persistentVolumeClaim:
            claimName: pvc-nas 
        - name: disk  
          persistentVolumeClaim:
            claimName: pvc-disk
        - name: oss
          persistentVolumeClaim:
            claimName: pvc-oss
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: slb.s1.small
  name: nginx-svc
  namespace: default
spec:
  externalTrafficPolicy: Local
  internalTrafficPolicy: Cluster
  ipFamilies:
    - IPv4
  ports:
    - name: nginx
      nodePort: 31463
      port: 8080
      protocol: TCP
      targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

移行手順

移行を開始する前に、NAS、OSS、およびディスクボリュームのリクレームポリシーが Retain であることを確認してください。

ステップ 1：新しい VPC での新しい NAS マウントターゲットの作成

バックアップクラスターで使用される NAS ボリュームのタイプに基づいて、新しいマウントターゲットを作成します。

• NAS ボリュームが Container Network File System (CNFS) を使用して管理されている場合、まず CNFS によって管理されている NAS ファイルシステムの ID を取得する必要があります。CNFS を使用して管理されている NAS ボリュームをリストアする場合、関連する CNFS オブジェクトと StorageClass もリストアする必要があります。

• NAS ボリュームがカスタム StorageClass に基づいて静的または動的にプロビジョニングされている場合、新しい VPC に NAS ファイルシステム用の新しいマウントターゲットを作成し、リストアクラスターに新しい StorageClass とボリュームを作成する必要があります。

ステップ 2：NAS および OSS ボリュームの移行

1. バックアップクラスターで NAS および OSS ボリュームをプロビジョニングするために使用される永続ボリューム要求 (PVC) と永続ボリューム (PV) にラベルを追加します。これにより、バックアッププロセス中にラベルに基づいて PVC と PV を選択できます。

   kubectl label pvc pvc-nas pvc-oss backup="true"
   kubectl label pv `kubectl get pvc -l backup="true" | grep Bound | awk '{print $3}'| xargs` backup="true"

2. NAS の PVC と PV にタグを付けることで、タグに基づいてマウントポイントの設定をバッチで簡単に変更できます。

   kubectl label pvc pvc-nas nas-volume="true"
   kubectl label pv `kubectl get pvc -l nas-volume="true" | grep Bound | awk '{print $3}'| xargs` nas-volume="true"

3. バックアップクラスターで NAS および OSS ボリュームのバックアップタスクを作成します。詳細については、「バックアッププランの作成または即時バックアップ」の「即時バックアップ」セクションをご参照ください。

   重要

   バックアップタスクを設定するときは、[ラベル] を backup=true に、[リソースの指定] を pvc,pv に、[ボリュームのバックアップ] を Disabled に設定します (これにより、ボリュームの YAML ファイルのみがバックアップされます。アプリケーションが解凍されると、ボリュームは新しいマウントポイントを介して VPC をまたいで元のデータソースにアクセスできるため、ボリュームのコピーを作成する必要はありません)。

   • [アプリケーションバックアップ] ページで、[バックアップレコード] タブをクリックします。バックアップレコードの [ステータス] 列に [完了] と表示されている場合、バックアップは作成済みです。

   • [アプリケーションバックアップ] ページで、[バックアップレコード] タブをクリックします。バックアップレコードの名前をクリックします。次の例は、バックアップレコードの詳細を示します。この例は、すべての NAS および OSS ボリュームがバックアップされていることを示しています。

     {
       "v1/PersistentVolume": [
         "nas-916c0c04-e91e-4fc3-9115-d8a9********", # PV は動的にプロビジョニングされます。
         "pv-oss"
       ],
       "v1/PersistentVolumeClaim": [
         "default/pvc-nas",
         "default/pvc-oss"
       ]
     }

4. 次の YAML ファイルを使用して、リストアクラスターに ConfigMap を作成します。この ConfigMap は、Velero が提供するリソース修飾子を使用して NAS マウントターゲットを変更します。

   説明

   • リソース修飾子を使用するには、リストアクラスターに migrate-controller 1.8.2 以降がインストールされており、使用する Resource Access Management (RAM) ユーザーにクラスターに対するロールベースアクセス制御 (RBAC) の管理者権限が付与されていることを確認してください。コンポーネントの更新方法に関する詳細については、「コンポーネントの管理」をご参照ください。RBAC 管理者権限の付与方法に関する詳細については、「RAM ユーザーまたは RAM ロールへの RBAC 権限の付与」をご参照ください。

   • 次の YAML ファイルは一例です。この例では、元の NAS ボリュームはデフォルトの alibabacloud-cnfs-nas StorageClass を使用しています。元の NAS ボリュームが静的または動的にプロビジョニングされている場合は、ボリュームのプロビジョニングに使用される PVC と PV に基づいて YAML ファイルを修正する必要があります。

   apiVersion: v1
   data:
     modifier: |
       version: v1
       resourceModifierRules:
       - conditions:
            groupResource: pvcs
            labelSelector:
               matchLabels:
                  nas-volume: "true"
         patches:
         - operation: replace
           path: "/spec/storageClassName"
           value: "alibabacloud-cnfs-nas" 
       - conditions:
            groupResource: pods
            labelSelector:
               matchLabels:
                  nas-volume: "true"
         patches:
         - operation: replace
           path: "/spec/csi/volumeAttributes/containerNetworkFileSystem"
           value: "cnfs-nas-restore-from-c529e33c3f8704e27a8e2abff********"
         - operation: replace
           path: "/spec/storageClassName"
           value: "alibabacloud-cnfs-nas"
         - operation: remove
           path: "/spec/csi/volumeAttributes/storage.kubernetes.io/csiProvisionerIdentity"
   kind: ConfigMap
   metadata:
     name: <Backup task name>-resource-modifier
     namespace: csdr

5. 任意：次の YAML テンプレートを使用して、backuplocation.yaml という名前のファイルを作成します。このファイルは、リストアクラスターでバックアップボールトを初期化するために使用されます。バックアップボールトがすでに初期化されている場合は、このステップをスキップしてください。

   apiVersion: csdr.alibabacloud.com/v1beta1
   kind: BackupLocation
   metadata:
     name: <Backup vault name>
     namespace: csdr
   spec:
     backupSyncPeriod: 0s
     # 次のパラメーターに元のバックアップボールトの設定を指定します。ACK コンソールでリストアクラスターのバックアップボールトを迅速に初期化することもできます。
     config:
       network: internal
       region: <Region of the OSS bucket associated with the backup vault>
     objectStorage:
       bucket: <OSS bucket associated with the backup vault>
       prefix: <OSS subdirectory associated with the backup vault>
     provider: alibabacloud

6. 次のコマンドを実行して、バックアップがリストアクラスターに同期されているかどうかを確認します：

   kubectl get -ncsdr applicationbackup <Backup name>

   出力が空でない場合、バックアップタスクは同期されています。

7. 次の YAML テンプレートを使用して、applicationrestore.yaml という名前のファイルを作成します。このファイルは、リストアクラスターでリストアタスクを作成するために使用されます。

   説明

   リソース修飾子を使用して高度な操作を実行する場合は、CLI を使用する必要があります。

   apiVersion: csdr.alibabacloud.com/v1beta1
   kind: ApplicationRestore
   metadata:
     name: nas-oss-restore
     namespace: csdr
   spec:
     backupName: <Backup task name>
     resourceModifier:
       kind: ConfigMap
       name: <Backup task name>-resource-modifier

   kubectl apply -f applicationrestore.yaml

8. 解凍タスクが [完了] 状態であることを確認してください。解凍クラスター内の PVC と PV が完全に解凍され、Bound 状態になっていることを確認してください。また、PVC と PV の構成の特定のパラメーターが、解凍クラスターに基づいて変更されていることを確認してください。

ステップ 3：ディスクボリュームの移行

ACK コンソールで即時バックアップタスクを作成する際に、[ボリュームのバックアップ] を選択すると、Bound 状態のボリュームがバックアップされます。

1. 次の YAML テンプレートを使用して、applicationbackup.yaml という名前のファイルを作成します。このファイルは、バックアップクラスター内のすべてのディスクボリュームをバックアップするために使用されます。

   apiVersion: csdr.alibabacloud.com/v1beta1
   kind: ApplicationBackup
   metadata:
     annotations:
     # バックアップボールトがすでにバックアップクラスターで使用されている場合、このアノテーションを追加する必要はありません。
     # csdr.alibabacloud.com/backuplocations: >-
       # {"name":"<Backup vault name>","region":"<Region of the OSS bucket associated with the backup vault>","bucket":"<OSS bucket associated with the backup vault>","prefix":"<OSS subdirectory associated with the backup vault>","provider":"alibabacloud"}
     name: backup-disk
     namespace: csdr
   spec:
     # includedNamespaces: # ボリュームをバックアップする名前空間 (ディスクボリュームやその他のタイプのボリュームを含む)。このパラメーターまたは pvcList を設定する必要があります。
     # - default 
     backupType: PvBackup
     pvBackup:
       defaultPvBackup: true
       pvcList:  # バックアップする PVC。このパラメーターを設定すると、includedNamespaces パラメーターは有効になりません。
       - name: pvc-disk 
         namespace: default
     storageLocation: <Backup vault name>
     ttl: 720h0m0s

2. バックアップクラスターで次のコマンドを実行して、applicationbackup オブジェクトをデプロイします：

   kubectl apply -f applicationbackup.yaml

3. バックアップクラスターで次のコマンドを実行して、リアルタイムバックアップタスクのステータスをクエリします：

   kubectl describe applicationbackup <yourApplicationBackupName> -n csdr

   システムは次のような情報を表示します：

   ...
   Status:
     Completion Timestamp:  2022-12-05T15:02:35Z
     Expiration:            2023-01-04T15:02:25Z
     Message:               success
     Phase:                 Completed

   即時バックアップタスクのステータスが Inprogress から Completed に変わると、タスクは作成されます。

4. 次のコマンドを実行して、バックアップがリストアクラスターに同期されているかどうかを確認します：

   kubectl get -ncsdr applicationbackup <Backup name>

5. 次の YAML テンプレートを使用して、applicationrestore.yaml という名前のファイルを作成します。このファイルは、リストアクラスターでリストアタスクを作成するために使用されます。

   apiVersion: csdr.alibabacloud.com/v1beta1
   kind: ApplicationRestore
   metadata:
     name: disk-restore
     namespace: csdr
   spec:
     backupName: <Backup task name>

   kubectl apply -f applicationrestore.yaml

6. 解凍タスクが [完了] 状態であることを確認します。解凍クラスター内の PVC と PV が完全に解凍され、Bound 状態になっているかどうかを確認します。また、PV で指定されているディスク ID が更新されていることを確認します。

ステップ 4：Service および Ingress のアノテーション上書きポリシーの設定

バックアップクラスターに nginx-svc という名前の Service を作成します。対応する SLB インスタンスは CCM によって作成されます。SLB インスタンスには、次のアノテーションとラベルがあります：

アノテーション：

service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: slb.s1.small

ラベル：

service.k8s.alibaba/loadbalancer-id: lb-2ze2hxgbuw145******

この例では、nginx-svc Service 用に作成された SLB インスタンスの ID は lb-2ze2hxgbuw145****** です。リストアクラスターでこのインスタンスを再利用する場合は、次の YAML ファイルを使用してアノテーション上書きポリシーを設定します：

apiVersion: v1
data:
  # use-nlb: "true" は新しい SLB インスタンスが作成される場合にのみ有効です。
  default.nginx-svc: | 
    {"service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id":"lb-2ze2hxgbuw145******","xxx":"yyy"}
  # <ns>.<svc>
  # {"xxx": "yyy", ...} 
kind: ConfigMap
metadata:
  name: service-annotation-overwrite
  namespace: csdr

上記の上書きポリシーは、nginx-svc Service の設定にある service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec アノテーションを service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id アノテーションに置き換えます。このポリシーを使用して、他のアノテーションを保持または変更することもできます。

• Service アノテーションに関する詳細については、「アノテーションを使用した CLB インスタンスの設定」および「アノテーションを使用した NLB インスタンスの設定」をご参照ください。

• アノテーション上書きポリシーはすべての設定を上書きします。ポリシーを使用して新しい SLB インスタンスを作成できます。

• デフォルトでは、再利用された SLB インスタンスのリスナーは上書きされません。service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners アノテーションのデフォルト値は false です。クラスター内のアプリケーションが起動したことを確認してから、トラフィックをリストアクラスターに切り替えることを推奨します。

ステップ 5：アプリケーションの移行 (ボリュームを除く)

1. バックアップクラスターで、移行するアプリケーションをバックアップします。バックアップタスクを設定するときは、[ボリュームデータをバックアップ] を選択しないでください。詳細については、バックアッププランの作成または即時バックアップの「即時バックアップ」セクションをご参照ください。

2. [アプリケーションバックアップ] ページで、[バックアップレコード] タブをクリックします。バックアップレコードが [完了] 状態であるかどうかを確認します。

3. バックアップがリストアクラスターに同期されるまで待ってから、バックアップからアプリケーションをリストアします。詳細については、「アプリケーションのリストア」をご参照ください。

4. [アプリケーションバックアップ] ページで、[復元レコードの表示] をクリックします。復元タスクが [完了] 状態であることを確認します。

5. リストアクラスターの Deployment ページで、NGINX アプリケーションが起動しているか、また同じボリュームがアプリケーションにマウントされているかを確認します。アプリケーション詳細ページに移動し、nginx-svc Service を見つけて [詳細] をクリックします。Service の詳細ページで、同じ SLB インスタンスが再利用されているかを確認します。

関連ドキュメント

• kubectl を使用したアプリケーションの移行方法に関する詳細については、「kubectl を使用したアプリケーションのバックアップとリストア」をご参照ください。

• Terraform を使用したアプリケーションのバックアップとリストア方法に関する詳細については、「Terraform を使用したアプリケーションのバックアップとリストア」をご参照ください。