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

前提条件

使用上の注意

バックアップノート

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

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

ノートを復元

• バックアップセンターは、復元クラスタについて提案された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リソースを手動で復元する必要があります。

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

  説明

  • バックアップクラスターのサービスの可用性を確保する必要がある場合、または移行中にデータの一貫性を損なわない場合は、バックアップクラスターで使用されているディスクを強制的にデタッチしないことをお勧めします。

  • デフォルトでは、エンタープライズSSD (ESSD) はインスタントアクセス機能をサポートしています。 この機能により、バックアッププロセス中のデータセキュリティが確保され、移行プロセスが大幅に高速化されます。

課金

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

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

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

  説明

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

  • デフォルトでは、インスタンスアクセス機能は、PL0、PL1、PL2、およびPL3のパフォーマンスレベルでESSDまたはESSD AutoPLディスク用に作成されたスナップショットに対して有効になっています。

例：

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

# The configurations of a dynamically provisioned disk volume.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-disk
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 20Gi
  storageClassName: alicloud-disk-topology-alltype
---
# The configurations of a statically provisioned disk volume.
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
---
# The configurations of a dynamically provisioned NAS volume.
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、およびディスクボリュームの再利用ポリシーが [保持] であることを確認してください。

手順1: 新しいVPCで新しいNASマウントターゲットを作成

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

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

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

手順2: NASおよびOSSボリュームの移行

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

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

2. 移行するNASボリュームのプロビジョニングに使用するPVCおよびPVにラベルを追加します。 新しいNASマウントターゲットを指定すると、ラベルに基づいてPVCとPVを統一して選択できます。

   kubectl label pvc sts-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] に設定します。

   [アプリケーションバックアップ] ページの [バックアップレコード] タブで、バックアップレコードの [ステータス] 列に [完了] が表示されると、バックアップが作成されます。

4. 次のコマンドを実行して、バックアップタスクを名前で照会します。 バックアップクラスター内のNASボリュームとOSSボリュームがバックアップされているかどうかを確認できます。

   kubectl describe applicationbackup <yourApplicationBackupName> -n csdr

   次の出力が返されると、バックアップクラスター内のNASボリュームとOSSボリュームがバックアップされます。

   {
     "v1/PersistentVolume": [
       "nas-916c0c04-e91e-4fc3-9115-d8a9********", # The PV is dynamically provisioned. 
       "pv-oss"
     ],
     "v1/PersistentVolumeClaim": [
       "default/pvc-nas",
       "default/pvc-oss"
     ]
   }

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

   説明

   • リソース修飾子を使用するには、migrate-controller 1.8.2以降が復元クラスターにインストールされ、使用するRAM (resource Access Management) ユーザーにクラスターに対するロールベースのアクセス制御 (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: "alibaba-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: "alibaba-cnfs-nas"
         - operation: remove
           path: "/spec/csi/volumeAttributes/storage.kubernetes.io/csiProvisionerIdentity"
   kind: ConfigMap
   metadata:
     name: <Backup task name>-resource-modifier
     namespace: csdr

6. オプション: backuplocation. YAMLという名前のファイルを作成するには、次のyamlテンプレートを使用します。 このファイルは、復元クラスターのバックアップボールトを初期化するために使用されます。 バックアップコンテナーが既に初期化されている場合は、この手順をスキップします。

   apiVersion: csdr.alibabacloud.com/v1beta1
   kind: BackupLocation
   metadata:
     name: <Backup vault name>
     namespace: csdr
   spec:
     backupSyncPeriod: 0s
     # Specify the configurations of the original backup vault in the following parameters. You can also quickly initialize the backup vault in the restore cluster in the ACK console. 
     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

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

   kubectl get -ncsdr applicationbackup <Backup name>

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

8. 次の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

9. 復元タスクの状態が完了であることを確認します。 復元クラスターのPVCとPVが完全に復元され、バインド状態になっているかどうかを確認します。 さらに、復元クラスターに基づいて、PVCおよびPV構成の特定のパラメーターが変更されていることを確認します。

ステップ2: ディスクボリュームの移行

ACKコンソールでインスタントバックアップタスクを作成するときに、[ボリュームバックアップ] を選択すると、[バインド済み] 状態のボリュームがバックアップされます。

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

   apiVersion: csdr.alibabacloud.com/v1beta1
   kind: ApplicationBackup
   metadata:
     annotations:
     # If the backup vault is already used by the backup cluster, you do not need to add this annotation. 
     # 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: # The namespaces in which you want to back up volumes, including disk volumes and other types of volumes. You must set this parameter or pvcList. 
     # - default 
     backupType: PvBackup
     pvBackup:
       defaultPvBackup: true
       pvcList:  # The PVCs that you want to back up. If you set this parameter, the includedNamespaces parameter does not take effect. 
       - 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

   インスタントバックアップタスクのステータスが未完了から完了に変わると、タスクが作成されます。

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が完全に復元され、バインド状態になっているかどうかを確認します。 また, PVで指定したディスクIDが更新されていることを确认してください。

手順3: ServiceとIngressのアノテーション上書きポリシーの設定

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

注釈:

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

ラベル:

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

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

apiVersion: v1
data:
  # use-nlb: "true" takes effect only when new SLB instances are created. 
  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アノテーションに置き換えます。 このポリシーを使用して、他の注釈を保持または変更することもできます。

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

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

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

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

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

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

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

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

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

関連ドキュメント

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

• Terraformを使用してアプリケーションをバックアップおよび復元する方法の詳細については、「Terraformを使用してアプリケーションをバックアップおよび復元する」をご参照ください。