Container Service for Kubernetes:Migrate stateful applications with cloud disks across zones

Cas d'utilisation

NAS et OSS prennent en charge les montages interzones et multiples. Les disques sont liés à une zone : ils ne peuvent pas être transférés d'une zone à l'autre ni réutiliser les persistent volume claims (PVC) et persistent volumes (PV) existants. Créez de nouveaux disques dans la zone cible à partir de snapshots.

Principales contraintes

Examinez ces contraintes avant la migration :

• Interruption de service requise : Pour garantir la cohérence des données, la migration réduit le nombre de réplicas du StatefulSet à 0, puis les restaure tous simultanément après la migration des disques. Il ne s'agit pas d'une mise à jour progressive. Prévoyez une période d'indisponibilité. La durée dépend du nombre de réplicas, du temps de démarrage des conteneurs et de la capacité des disques.

• Disques ESSD requis : Tous les éléments de stockage utilisés par le StatefulSet doivent être des disques ESSD. La migration utilise des instant access snapshots, qui ne sont compatibles qu'avec les disques ESSD.

• Exigences relatives à la zone cible : La zone cible doit prendre en charge les disques ESSD et le cluster doit disposer de nœuds disponibles dans cette zone pour la planification.

Si votre application utilise des disques autres que des ESSD, effectuez l'une des opérations suivantes avant la migration :

• Changer le type de disque en ESSD.

• Créez manuellement un snapshot pour un seul volume de disque et reconstruisez le disque entre les zones.

Fonctionnement

La migration interzone crée des snapshots des disques source et utilise l'accès instantané pour réduire au minimum le temps de création. Consultez la section Facturation des snapshots.

storage-operator exécute les étapes suivantes :

1. Prévalidation : Vérifie que l'application est en cours d'exécution et identifie les disques à migrer. Le processus s'arrête si la prévalidation échoue.

2. Réduction à zéro : Réduit le nombre de réplicas du StatefulSet à 0, mettant ainsi l'application en pause.

3. Création de snapshots : Crée des instant access snapshots pour tous les disques montés. Les snapshots sont indépendants des zones.

4. Provisionnement de nouveaux disques : Une fois la disponibilité des snapshots confirmée, crée de nouveaux disques dans la zone cible contenant les mêmes données.

5. Reconstruction des PVC et PV : Reconstruit les PVC portant les mêmes noms et leurs PV correspondants, liés aux nouveaux disques.

6. Restauration des réplicas : Restaure le nombre initial de réplicas. Les réplicas se lient aux PVC reconstruits et montent les nouveaux disques.

7. (Facultatif) Suppression des ressources d'origine : Après avoir confirmé l'état de santé de l'application, supprimez les PV et les disques d'origine. Consultez la section Facturation du stockage par blocs.

Prérequis

Assurez-vous que les conditions suivantes sont remplies :

• Un cluster exécutant Kubernetes 1.20 ou version ultérieure avec le pilote Container Storage Interface (CSI) installé.

• storage-operator v1.26.2-1de13b6-aliyun ou version ultérieure installé.

• csi-plugin et csi-provisioner installés, csi-provisioner utilisant la version non gérée.

  Si la version gérée est installée, basculez vers la version non gérée. Redémarrez ensuite le contrôleur de stockage : kubectl delete pod -n kube-system <storage-controller-pod-name>

• (Clusters dédiés ACK uniquement) Les rôles RAM des nœuds de travail et maîtres disposent de l'autorisation ModifyDiskSpec sur l'API ECS. Consultez la page Créer une stratégie personnalisée. Affichez la stratégie RAM requise :

  Les clusters gérés ACK ne nécessitent pas l'autorisation ModifyDiskSpec .

  {
      "Version": "1",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "ecs:CreateSnapshot",
                  "ecs:DescribeSnapshot",
                  "ecs:DeleteSnapshot",
                  "ecs:ModifyDiskSpec",
                  "ecs:DescribeTaskAttribute"
              ],
              "Resource": "*"
          }
      ]
  }

  </details>

Migrer un StatefulSet entre zones

kubectl patch configmap/storage-operator \
  -n kube-system \
  --type merge \
  -p '{"data":{"storage-controller":"{\"imageRep\":\"acs/storage-controller\",\"imageTag\":\"\",\"install\":\"true\",\"template\":\"/acs/templates/storage-controller/install.yaml\",\"type\":\"deployment\"}"}}'

cat <<EOF | kubectl apply -f -
apiVersion: storage.alibabacloud.com/v1beta1
kind: ContainerStorageOperator
metadata:
  name: default
spec:
  operationType: APPMIGRATE
  operationParams:
    stsName: web
    stsNamespace: default
    stsType: kube
    targetZone: cn-beijing-h,cn-beijing-j
    checkWaitingMinutes: "1"
    healthDurationMinutes: "1"
    snapshotRetentionDays: "2"
    retainSourcePV: "true"
EOF

Exemples

Les exemples suivants utilisent un cluster ACK Pro avec des nœuds répartis sur trois zones :

• Zone B : cn-shanghai.192.168.5.245

• Zone G : cn-shanghai.192.168.2.214

• Zone M : cn-shanghai.192.168.3.236, cn-shanghai.192.168.3.237

FAQ

Si une tâche de migration renvoie le code FAILED, obtenez le message d'erreur :

kubectl describe cso <ContainerStorageOperator-name> | grep Message -A 1

Exemple de sortie :

  Message:
    Consume: failed to get target pvc, err: no pvc mounted in statefulset or no pvc need to migrated web

Le composant n'a pas pu trouver de PVC à migrer. Causes courantes :

• Le StatefulSet ne possède aucun stockage monté.

• Tous les disques se trouvent déjà dans la zone cible : aucune migration n'est nécessaire.

• Le composant n'a pas pu récupérer les informations sur les PVC.

Résolvez le problème en fonction du message d'erreur, puis appliquez à nouveau la tâche de migration.