Container Service for Kubernetes:Zone-disaster recovery system

Aperçu de la reprise après sinistre

Les solutions de reprise après sinistre basées sur le cloud se répartissent généralement en trois catégories :

• Reprise après sinistre inter-zone (cross-AZ) : cette catégorie englobe les stratégies active-active et active-passive. Les centres de données situés au sein d'une même région étant physiquement proches, la latence réseau reste faible. Ce dispositif protège contre les sinistres au niveau des zones de disponibilité, tels que les incendies, les pannes réseau ou les coupures d'alimentation. Pragmatique, cette solution offre une sauvegarde des données simple et une récupération rapide.

• Redondance géographique active : bien que cette approche entraîne une latence réseau plus élevée, elle protège contre les sinistres affectant toute une région, comme les séismes ou les inondations.

• Deux régions, trois centres : ce modèle associe une configuration à deux centres dans une région à un site de reprise après sinistre dans une autre, combinant ainsi les avantages des deux approches. Il convient idéalement aux scénarios exigeant une continuité et une disponibilité élevées des applications et des données.

D'un point de vue architectural métier, un système d'entreprise classique se divise en couche d'accès, couche applicative et couche de données.

• Couche d'accès : sert de point d'entrée du trafic, reçoit et transfère le trafic vers la couche applicative backend selon des règles de routage.

• Couche applicative : héberge les services applicatifs qui traitent les données en fonction des requêtes et renvoient les réponses à la couche amont.

• Couche de données : fournit des services de stockage de données pour la couche applicative.

Pour assurer une reprise après sinistre complète de bout en bout, implémentez des mesures de reprise à chacun de ces niveaux.

• Couche d'accès : la passerelle multi-cluster ALB d'ACK One fait office de couche d'accès et offre une haute disponibilité native entre les zones de disponibilité au sein d'une même région.

• Couche applicative : la passerelle multi-cluster ALB d'ACK One gère la reprise après sinistre de la couche applicative, permettant une reprise inter-zone active-active/active-passive ainsi qu'une redondance géographique active.

• Couche de données : la reprise après sinistre et la synchronisation des données au niveau de la couche de données dépendent des capacités du middleware utilisé.

Avantages

L'utilisation de la passerelle multi-cluster ALB d'ACK One pour la reprise après sinistre présente les avantages suivants par rapport aux solutions basées sur DNS :

• La reprise après sinistre basée sur DNS nécessite plusieurs adresses IP d'équilibreur de charge (une par cluster). En revanche, une solution fondée sur une passerelle ne requiert qu'une seule adresse IP d'équilibreur de charge par région et assure par défaut une haute disponibilité sur plusieurs zones de disponibilité.

• La solution basée sur une passerelle prend en charge le routage de couche 7, contrairement aux solutions DNS.

• Avec les solutions DNS, les modifications d'adresse IP peuvent provoquer des interruptions temporaires de service dues au cache DNS côté client. La solution basée sur une passerelle permet un basculement transparent du trafic vers le backend de service d'un autre cluster.

• La passerelle multi-cluster est une ressource régionale. Toutes les opérations sont gérées depuis une instance Fleet centrale, ce qui élimine la nécessité d'installer un contrôleur Ingress et de créer des ressources Ingress dans chaque cluster ACK. Cela offre une gestion régionale du trafic tout en réduisant la charge de gestion multi-cluster.

Architecture de la solution

Cette rubrique s'appuie sur un exemple d'application web, comprenant des ressources Deployment et Service, pour illustrer l'architecture d'une solution de reprise après sinistre inter-zone construite avec une passerelle multi-cluster ALB.

• Créez deux clusters ACK, Cluster 1 et Cluster 2, dans deux zones de disponibilité différentes (AZ 1 et AZ 2) au sein de la même région.

• Utilisez GitOps ACK One pour distribuer l'application vers Cluster 1 et Cluster 2.

• Créez une passerelle multi-cluster ALB en créant une ressource AlbConfig dans l'instance ACK One Fleet.

• Après avoir créé la passerelle multi-cluster ALB, créez un Ingress pour router le trafic en fonction de pondérations ou d'en-têtes. Si un cluster devient indisponible, le trafic est automatiquement redirigé vers le cluster sain.

• La synchronisation des données pour ApsaraDB RDS dépend des capacités du middleware.

Prérequis

• Activez le service Application Load Balancer (ALB).

• Activez la fonctionnalité de gestion de fleet.

• Associez deux clusters ACK à la fleet ACK One. Les clusters doivent se trouver dans le même Virtual Private Cloud (VPC) que l'instance Fleet. Pour plus d'informations, consultez la section Gérer les clusters associés.

• Récupérez le KubeConfig de l'instance Fleet depuis la console ACK One, puis connectez-vous à l'instance Fleet à l'aide de kubectl.

• Installez la dernière version de Cloud Assistant CLI et configurez Cloud Assistant CLI.

Étape 1 : Déployer des applications sur plusieurs clusters

ACK One permet de déployer des applications sur plusieurs clusters via GitOps multi-cluster ou la distribution d'applications multi-clusters. Pour plus d'informations, consultez les rubriques Démarrage rapide pour GitOps, Créer une application multi-cluster et Démarrage rapide pour la distribution d'applications. Cette rubrique utilise GitOps à titre d'exemple.

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

2. Dans le coin supérieur gauche de la page Multi-cluster GitOps, cliquez sur le bouton situé à côté du nom de la fleet, puis sélectionnez la fleet cible dans la liste déroulante.

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

   Remarque

   • Assurez-vous que GitOps est activé pour l'instance ACK One Fleet. Pour plus d'informations, consultez la section Activer GitOps dans une instance ACK One Fleet.

   • Pour accéder à GitOps via Internet, consultez la section Activer l'accès public à GitOps.

4. Sous l'onglet Create from YAML, copiez le contenu YAML suivant dans l'éditeur, puis cliquez sur OK pour créer et déployer l'application.

   Remarque

   Le code YAML suivant déploie l'application web-demo sur tous les clusters associés. Vous pouvez également sélectionner des clusters spécifiques sous l'onglet Quick Create ; vos sélections seront alors reflétées dans le contenu 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 une passerelle multi-cluster ALB

Créez un objet AlbConfig dans l'instance ACK One Fleet afin de créer une passerelle multi-cluster ALB ACK One et d'y associer des clusters.

1. Récupérez deux ID de vSwitch depuis le VPC où réside l'instance ACK One Fleet.

2. Créez un fichier nommé gateway.yaml contenant le code suivant.

   Remarque

   • Remplacez ${vsw-id1} et ${vsw-id2} par les ID de vSwitch obtenus à l'étape précédente. Remplacez ${cluster1} et ${cluster2} par les ID des clusters associés que vous souhaitez ajouter.

   • Pour les clusters associés ${cluster1} et ${cluster2}, configurez les règles entrantes de leurs groupes de sécurité afin d'autoriser le trafic provenant du bloc CIDR des vSwitch sur tous les ports.

   apiVersion: alibabacloud.com/v1
   kind: AlbConfig
   metadata:
     name: ackone-gateway-demo
     annotations:
       # Add the associated clusters that will process traffic to the ALB multi-cluster 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

   Le tableau suivant décrit les paramètres.

   Paramètre	Obligatoire	Description
   metadata.name	Oui	Nom de l'AlbConfig.
   metadata.annotations: alb.ingress.kubernetes.io/remote-clusters	Oui	Clusters associés à ajouter à la passerelle multi-cluster ALB. Les ID de cluster indiqués ici 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 de l'instance ALB. Valeurs possibles : Internet (par défaut) : instance orientée Internet qui fournit des services via Internet. Remarque Application Load Balancer utilise une adresse IP élastique (EIP) pour fournir des services via Internet. Si vous utilisez une instance ALB orientée Internet, des frais d'instance ainsi que des frais de bande passante ou de transfert de données pour l'EIP vous seront facturés. Pour plus d'informations, consultez la section Paiement à l'utilisation. Intranet : instance de réseau privé qui fournit des services au sein d'un VPC et n'est pas accessible depuis Internet.
   spec.config.zoneMappings	Oui	ID des vSwitches pour l'instance ALB. Pour plus d'informations sur la création d'un vSwitch, consultez la section Créer et gérer des vSwitches. Remarque Les vSwitches spécifiés doivent se trouver dans des zones de disponibilité prises en charge par ALB et dans le même VPC que vos clusters. Pour plus d'informations sur les régions et zones de disponibilité prises en charge par ALB, consultez la section Régions et zones. Pour garantir une haute disponibilité, sélectionnez des vSwitches situés dans au moins deux zones de disponibilité différentes si la région en prend en charge plusieurs.
   spec.listeners	Non	Port d'écoute et protocole de l'instance ALB. Cet exemple configure un écouteur HTTP sur le port 8001. Un écouteur définit la manière dont le trafic pénètre dans l'équilibreur de charge. Conservez cette configuration ; sinon, vous devrez créer un écouteur avant d'utiliser l'Ingress ALB.

3. Exécutez la commande suivante pour déployer gateway.yaml et créer la passerelle multi-cluster ALB ainsi que l'IngressClass :

   kubectl apply -f gateway.yaml

4. Attendez 1 à 3 minutes, puis exécutez la commande suivante pour vérifier que la passerelle multi-cluster ALB a bien é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.aliyuncsslb.com                           4d9h

5. Exécutez la commande suivante pour vérifier que les clusters associés ont bien été ajoutés :

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

   Le résultat attendu est une liste d'ID de cluster.

Étape 3 : Implémenter la reprise après sinistre avec Ingress

La passerelle multi-cluster utilise un Ingress pour gérer le trafic entre plusieurs clusters. Créez un objet Ingress dans l'instance ACK One Fleet afin de mettre en œuvre une reprise après sinistre inter-zone active-active.

1. Dans l'instance Fleet, créez le namespace où réside le Service. Dans cet exemple, le namespace est gateway-demo.

2. Créez un fichier nommé ingress-demo.yaml contenant le code suivant.

   Remarque

   • La somme des pondérations spécifiées dans les annotations alb.ingress.kubernetes.io/cluster-weight doit être égale à 100.

   • Cette règle de routage expose le service backend service1 sur le chemin /svc1 du domaine alb.ingress.alibaba.com. Remplacez ${cluster1-id} et ${cluster2-id} par vos ID de cluster.

   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. Exécutez la commande suivante pour déployer l'Ingress dans l'instance ACK One Fleet :

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

Étape 4 : Vérifier la reprise après sinistre inter-zone

curl -H "host: alb.ingress.alibaba.com" alb-xxxx.<regionid>.alb.aliyuncsslb.com:<listeners port>/svc1

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

grep poc-ack-1 res.txt |wc -l
      108
grep poc-ack-2 res.txt |wc -l
      392

for i in {1..500}; do curl -H "host: alb.ingress.alibaba.com" alb-xxxx.cn-beijing.alb.aliyuncsslb.com:8001/svc1; sleep 1; done

This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!