Server Load Balancer:Mettre en œuvre la reprise après sinistre au niveau des zones à l'aide d'une passerelle multi-clusters ALB dans ACK One

Fonctionnement

Une architecture métier classique comporte trois couches : la couche d'accès qui reçoit le trafic entrant, la couche applicative qui le traite et la couche de données qui le persiste. La reprise après sinistre au niveau des zones concerne chacune de ces couches :

• Couche d'accès — ACK One déploie l'instance ALB par défaut sur plusieurs zones au sein d'une même région, ce qui rend le point d'entrée intrinsèquement hautement disponible.

• Couche applicative — 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 de données — La reprise après sinistre et la synchronisation des données dépendent de middleware (par exemple, ApsaraDB RDS). Cette rubrique ne couvre pas la configuration de la couche de données.

Architecture

Cette rubrique utilise une application web (un Deployment et un Service) pour illustrer la reprise après sinistre au niveau des zones dans la région Chine (Hong Kong) :

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

• ACK One GitOps distribue l'application web-demo aux deux clusters.

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

• Des 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) présente des dépendances middleware et sort du cadre de cette rubrique.

Prérequis

Avant de commencer, assurez-vous d'avoir :

• Activé ALB

• Activé la fonctionnalité de gestion Fleet — consultez la section Activer la gestion multi-clusters

• Associé deux clusters ACK à l'instance Fleet, tous deux situés dans le même virtual private cloud (VPC) que l'instance Fleet — consultez la section Gérer les clusters associés

• Configuré les règles entrantes du groupe de sécurité de chaque cluster associé pour autoriser le trafic provenant de toutes les adresses IP et ports au sein du bloc CIDR du vSwitch (requis pour permettre à l'instance ALB d'atteindre les pods backend)

• Téléchargé le fichier kubeconfig de l'instance Fleet depuis la console ACK One et connecté un client kubectl à l'instance Fleet

• Installé la dernière version d'Alibaba Cloud CLI et l'avoir configurée

Étape 1 : Distribuer l'application à plusieurs clusters

Utilisez GitOps pour déployer l'application web-demo sur les deux clusters associés. Vous pouvez également utiliser la fonctionnalité de distribution d'applications multi-clusters — consultez les sections Créer une application multi-clusters et Premiers pas 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. Dans le coin supérieur gauche de la page Multi-cluster Applications, cliquez sur à droite du nom de l'instance Fleet et sélectionnez votre instance Fleet dans la liste déroulante.

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

   Si GitOps n'est pas activé pour l'instance Fleet, activez-le d'abord. Consultez la section Activer GitOps pour l'instance Fleet . Pour autoriser l'accès Internet à GitOps, consultez la section Activer 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'instance Fleet. L'onglet Quick Create propose une alternative basée sur un formulaire : les modifications apportées y sont synchronisées automatiquement avec le code YAML de 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 les ID de deux vSwitch dans le VPC où réside 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 remplacez ${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 des clusters à associer à l'instance ALB, séparés par des virgules. Ces 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, orienté public) ou Intranet (interne au VPC). Les instances ALB orientées 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 pour l'instance ALB. Spécifiez des vSwitch dans au moins deux zones prises en charge par ALB pour garantir la haute disponibilité. Consultez les sections Régions et zones dans lesquelles 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 l'utiliserez pour envoyer des requêtes de test à 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 où les Services de l'application sont déployés.

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 des zones

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

• Premiers pas avec GitOps

• Créer une application multi-clusters

• Premiers pas avec la distribution d'applications