Server Load Balancer:Mettre en œuvre la reprise après sinistre au niveau de la zone avec une passerelle multi-clusters ALB dans ACK One

Fonctionnement

Une architecture métier se compose de trois couches : accès, application et données. La reprise après sinistre au niveau de la zone traite chacune d'elles :

• Couche d'accès — Distributed Cloud Container Platform for Kubernetes (ACK One) déploie l'instance ALB sur plusieurs zones au sein d'une région par défaut, ce qui garantit une haute disponibilité du point d'entrée.

• Couche application — Une passerelle multi-clusters ALB répartit le trafic entre les clusters situés dans différentes zones de disponibilité grâce à des règles Ingress basées sur des pondérations. En cas de défaillance d'un cluster, ALB détecte les pods défectueux et redirige automatiquement le trafic vers le cluster restant.

• Couche données — La reprise au niveau de la couche de données dépend des intergiciels (par exemple, ApsaraDB RDS) et n'est pas abordée ici.

Architecture

Cet exemple utilise une application web (un Deployment et un Service) pour illustrer la reprise après sinistre au niveau de la zone dans la région Chine (Hong Kong) :

• Le cluster 1 s'exécute dans la zone de disponibilité 1 ; le cluster 2 s'exécute dans la zone de disponibilité 2.

• ACK One GitOps distribue web-demo vers les deux clusters.

• Un AlbConfig sur l'instance Fleet crée une passerelle multi-clusters ALB qui achemine le trafic vers les deux clusters.

• Les annotations de pondération Ingress contrôlent la répartition du trafic. Lorsqu'un cluster est défectueux, ALB transfère automatiquement le trafic vers l'autre.

• La synchronisation des données (ApsaraDB RDS) dépend des intergiciels et n'est pas abordée ici.

Prérequis

Assurez-vous de disposer des éléments suivants :

• ALB activé

• Fonctionnalité de gestion Fleet activée. Consultez la section Activer la gestion multi-clusters

• Deux clusters ACK associés à l'instance Fleet, dans le même cloud privé virtuel (VPC). Consultez la section Gérer les clusters associés

• Règles entrantes du groupe de sécurité de chaque cluster associé configurées pour autoriser tout le trafic provenant du bloc CIDR du vSwitch (requis pour permettre à ALB d'atteindre les pods backend)

• kubeconfig de l'instance Fleet téléchargé depuis la console ACK One, avec kubectl connecté

• La dernière version d'Alibaba Cloud CLI installée et configurée

Étape 1 : Distribuer l'application sur plusieurs clusters

Utilisez GitOps pour déployer web-demo sur les deux clusters associés. Vous pouvez également créer une application multi-clusters ou commencer avec la distribution d'applications.

1. Connectez-vous à la console ACK One. Dans le volet de navigation de gauche, sélectionnez Fleet > Multi-cluster Applications.

2. Sur la page Multi-cluster Applications, cliquez sur à côté du nom de l'instance Fleet et sélectionnez votre instance Fleet.

3. Sélectionnez Create Multi-cluster Application > GitOps pour accéder à la page Create Multi-cluster Application - GitOps.

   Si GitOps n'est pas activé, activez GitOps pour l'instance Fleet . Pour autoriser l'accès Internet, activez l'accès public à Argo CD .

4. Dans l'onglet Create from YAML, collez l'ApplicationSet suivant et cliquez sur OK.

   Cet ApplicationSet déploie web-demo sur chaque cluster associé. L'onglet Quick Create propose une alternative basée sur un formulaire — les modifications sont synchronisées automatiquement avec l'onglet Create from YAML .

   apiVersion: argoproj.io/v1alpha1
   kind: ApplicationSet
   metadata:
     name: appset-web-demo
     namespace: argocd
   spec:
     template:
       metadata:
         name: '{{.metadata.annotations.cluster_id}}-web-demo'
         namespace: argocd
       spec:
         destination:
           name: '{{.name}}'
           namespace: gateway-demo
         project: default
         source:
           repoURL: https://github.com/AliyunContainerService/gitops-demo.git
           path: manifests/helm/web-demo
           targetRevision: main
           helm:
             valueFiles:
               - values.yaml
             parameters:
               - name: envCluster
                 value: '{{.metadata.annotations.cluster_name}}'
         syncPolicy:
           automated: {}
           syncOptions:
             - CreateNamespace=true
     generators:
       - clusters:
           selector:
             matchExpressions:
               - values:
                   - cluster
                 key: argocd.argoproj.io/secret-type
                 operator: In
               - values:
                   - in-cluster
                 key: name
                 operator: NotIn
     goTemplateOptions:
       - missingkey=error
     syncPolicy:
       preserveResourcesOnDeletion: false
     goTemplate: true

Étape 2 : Créer la passerelle multi-clusters ALB

Créez un AlbConfig sur l'instance Fleet pour provisionner une instance ALB et y associer vos clusters.

1. Récupérez deux ID de vSwitch dans le VPC de l'instance Fleet.

2. Créez le fichier gateway.yaml avec le contenu suivant. Remplacez ${vsw-id1} et ${vsw-id2} par les ID de vSwitch obtenus à l'étape précédente, et ${cluster1} et ${cluster2} par les ID des clusters associés.

   apiVersion: alibabacloud.com/v1
   kind: AlbConfig
   metadata:
     name: ackone-gateway-demo
     annotations:
       # Cluster IDs to associate with the ALB instance
       alb.ingress.kubernetes.io/remote-clusters: ${cluster1},${cluster2}
   spec:
     config:
       name: one-alb-demo
       addressType: Internet
       addressAllocatedMode: Fixed
       zoneMappings:
       - vSwitchId: ${vsw-id1}
       - vSwitchId: ${vsw-id2}
     listeners:
     - port: 8001
       protocol: HTTP
   ---
   apiVersion: networking.k8s.io/v1
   kind: IngressClass
   metadata:
     name: alb
   spec:
     controller: ingress.k8s.alibabacloud/alb
     parameters:
       apiGroup: alibabacloud.com
       kind: AlbConfig
       name: ackone-gateway-demo

   Paramètres clés :

   Paramètre	Obligatoire	Description
   metadata.name	Oui	Nom de l'AlbConfig.
   metadata.annotations: alb.ingress.kubernetes.io/remote-clusters	Oui	ID de clusters séparés par des virgules. Les clusters doivent déjà être associés à l'instance Fleet.
   spec.config.name	Non	Nom de l'instance ALB.
   spec.config.addressType	Non	Type de réseau : Internet (par défaut, exposé publiquement) ou Intranet (interne au VPC). Les instances ALB exposées sur Internet nécessitent une adresse IP élastique (EIP) et entraînent des frais d'instance et de bande passante. Consultez la section Paiement à l'utilisation.
   spec.config.zoneMappings	Oui	ID de vSwitch. Spécifiez au moins deux zones prises en charge par ALB pour garantir la haute disponibilité. Consultez les sections Régions et zones où ALB est disponible et Créer et gérer un vSwitch.
   spec.listeners	Non	Port et protocole de l'écouteur. L'exemple définit HTTP sur le port 8001. Conservez cette configuration — les Ingress ALB nécessitent un écouteur avant de pouvoir acheminer le trafic.

3. Appliquez la configuration :

   kubectl apply -f gateway.yaml

4. Attendez 1 à 3 minutes, puis vérifiez que la passerelle multi-clusters ALB a été créée :

   kubectl get albconfig ackone-gateway-demo

   Résultat attendu :

   NAME                  ALBID      DNSNAME                               PORT&PROTOCOL   CERTID   AGE
   ackone-gateway-demo   alb-xxxx   alb-xxxx.<regionid>.alb.aliyuncs.com                           4d9h

   Notez la valeur DNSNAME — vous en aurez besoin à l'étape 4.

5. Vérifiez que les clusters sont connectés à la passerelle :

   kubectl get albconfig ackone-gateway-demo -ojsonpath='{.status.loadBalancer.subClusters}'

   Le résultat liste les ID des clusters associés.

Étape 3 : Configurer les règles de routage Ingress

Créez un namespace et un Ingress sur l'instance Fleet. Les annotations de pondération Ingress contrôlent la répartition du trafic entre les clusters.

1. Créez le namespace gateway-demo sur l'instance Fleet. Il doit correspondre au namespace des Services de l'application déployée.

2. Créez le fichier ingress-demo.yaml avec le contenu suivant. Remplacez ${cluster1-id} et ${cluster2-id} par les ID réels des clusters.

   Les pondérations dans les annotations alb.ingress.kubernetes.io/cluster-weight.* doivent totaliser 100.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     annotations:
       alb.ingress.kubernetes.io/listen-ports: |
        [{"HTTP": 8001}]
       alb.ingress.kubernetes.io/cluster-weight.${cluster1-id}: "20"
       alb.ingress.kubernetes.io/cluster-weight.${cluster2-id}: "80"
     name: web-demo
     namespace: gateway-demo
   spec:
     ingressClassName: alb
     rules:
     - host: alb.ingress.alibaba.com
       http:
         paths:
         - path: /svc1
           pathType: Prefix
           backend:
             service:
               name: service1
               port:
                 number: 80

3. Appliquez l'Ingress :

   kubectl apply -f ingress-demo.yaml -n gateway-demo

Étape 4 : Vérifier la reprise après sinistre au niveau de la zone

for i in {1..500}; do curl -H "host: alb.ingress.alibaba.com" alb-xxxx.<regionid>.alb.aliyuncs.com:8001/svc1; done > res.txt

Étapes suivantes

• Prise en main de GitOps

• Créer une application multi-clusters

• Commencer avec la distribution d'applications