Application zone-disaster recovery with an ACK One multi-cluster gateway - Container Service for Kubernetes

Fonctionnement

Les passerelles multi-cluster ACK One reposent sur des Ingress Microservices Engine (MSE) managés. Couplées à ACK One GitOps (Argo CD), elles fonctionnent selon le principe suivant :

Déployez votre application sur plusieurs clusters ACK répartis dans différentes zones de disponibilité à l'aide d'Argo CD.
Créez une passerelle multi-cluster (MseIngressConfig) dans l'instance de flotte. La passerelle provisionne une seule adresse IP Server Load Balancer (SLB) au niveau de la région et découvre automatiquement les ressources Ingress dotées de la classe ingressClass spécifiée dans tous les clusters associés.
Définissez des objets Ingress dans l'instance de flotte pour établir les règles de routage du trafic. La passerelle achemine les requêtes vers les services backend des clusters associés et assure automatiquement le basculement du trafic si un cluster devient indisponible.

Composants clés :

Composant	Rôle
Instance de flotte ACK One	Plan de contrôle dédié à la gestion des ressources multi-clusters ; c'est ici que vous créez la passerelle et les objets Ingress
Ingress MSE (MseIngressConfig)	Passerelle cloud-native qui assure le routage de couche 7, l'équilibrage de charge et le basculement entre les clusters
Argo CD (GitOps)	Déploie et synchronise l'application sur plusieurs clusters ACK à partir d'un dépôt Git
Clusters ACK (Cluster 1, Cluster 2)	Clusters de charge de travail situés dans des zones de disponibilité distinctes et exécutant l'application ; ils sont ajoutés à la passerelle en tant que backends

Modes de reprise

Ces deux modes protègent contre les pannes au niveau de la zone de disponibilité. Ils se distinguent par la manière dont le trafic est distribué en conditions normales.

Mode	Distribution du trafic en conditions normales	Comportement lors du basculement	Cas d'usage idéal
Redondance active entre zones	Répartition équilibrée sur tous les clusters selon le ratio de réplicas	Reroutage automatique vers les clusters sains	Applications sans état pouvant être mises à l'échelle horizontalement
Principal/secondaire	L'intégralité du trafic est dirigée vers le cluster principal	Reroutage automatique vers le secondaire lorsque le principal est indisponible	Applications avec backends avec état (bases de données, caches) où le mode actif-actif ajouterait de la complexité

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

Activation de MSE
Activation de la fonctionnalité Gestion de flotte
Association de deux clusters ACK à l'instance de flotte au sein du même Virtual Private Cloud (VPC) — consultez la section Associer des clusters
Téléchargement du fichier kubeconfig de l'instance de flotte depuis la console ACK One et configuration de kubectl pour y accéder
Activation de GitOps sur l'instance de flotte
Activation de la fonctionnalité de passerelle multi-cluster — consultez les Règles de facturation pour les tarifs
Création d'un namespace gateway-demo dans l'instance de flotte (il doit correspondre au namespace où l'application est déployée dans les clusters associés)

Étape 1 : Déployer l'application sur plusieurs clusters

Utilisez Argo CD pour déployer l'application web-demo sur le Cluster 1 et le Cluster 2. L'application comprend un Deployment et un Service.

Choisissez l'interface utilisateur d'Argo CD ou la CLI.

Déploiement via l'interface utilisateur d'Argo CD

Connectez-vous à la console ACK One. Dans le volet de navigation de gauche, sélectionnez Fleet > Multi-cluster Applications.
Sur la page Multi-cluster GitOps, cliquez sur GitOps Console.

Si GitOps n'est pas encore activé, cliquez sur Enable GitOps . Pour accéder à GitOps via le réseau public, consultez la section Activer l'accès public à Argo CD .

Ajoutez le dépôt de l'application.

Dans le volet de navigation de gauche d'Argo CD, cliquez sur Settings, puis choisissez Repositories > + Connect Repo.

Configurez les paramètres suivants et cliquez sur CONNECT.

Section	Paramètre	Valeur
Choose your connection method	—	VIA HTTP/HTTPS
CONNECT REPO USING HTTP/HTTPS	Type	git
	Project	default
	Repository URL	`https://github.com/AliyunContainerService/gitops-demo.git`
	Skip server verification	Cochez cette case

Lorsque la connexion est établie, le champ CONNECTION STATUS indique Successful.

Créez une application pour chaque cluster. Sur la page Applications, cliquez sur + NEW APP et configurez les paramètres ci-dessous. Répétez cette opération pour le Cluster 2 en adaptant l'URL du cluster et la valeur envCluster en conséquence.

Section	Paramètre	Valeur
GENERAL	Application Name	Nom unique pour l'application
	Project Name	`default`
	SYNC POLICY	Manual (synchronisation à la demande) ou Automatic (Argo CD vérifie le dépôt Git toutes les 3 minutes et déploie les modifications automatiquement)
SYNC OPTIONS	—	Sélectionnez `AUTO-CREATE NAMESPACE`
SOURCE	Repository URL	`https://github.com/AliyunContainerService/gitops-demo.git`
	Revision	Branches : `gateway-demo`
	Path	`manifests/helm/web-demo`
DESTINATION	Cluster URL	Sélectionnez l'URL du Cluster 1 (ou du Cluster 2 pour la seconde application)
	Namespace	`gateway-demo`
Helm > Parameters	`envCluster`	`cluster-demo-1` pour le Cluster 1, `cluster-demo-2` pour le Cluster 2

Déploiement via la CLI Argo CD

Ajoutez le dépôt Git.

argocd repo add https://github.com/AliyunContainerService/gitops-demo.git --name ackone-gitops-demos

Résultat attendu :

Repository 'https://github.com/AliyunContainerService/gitops-demo.git' added

Vérifiez que le dépôt a bien été ajouté et confirmez l'enregistrement des deux clusters.

argocd repo list

Résultat attendu :

TYPE  NAME  REPO                                                       INSECURE  OCI    LFS    CREDS  STATUS      MESSAGE  PROJECT
git         https://github.com/AliyunContainerService/gitops-demo.git  false     false  false  false  Successful           default

argocd cluster list

Liste des clusters attendue :

SERVER                          NAME                                        VERSION  STATUS      MESSAGE                                                  PROJECT
https://1.1.XX.XX:6443      c83f3cbc90a****-temp01   1.22+    Successful
https://2.2.XX.XX:6443      c83f3cbc90a****-temp02   1.22+    Successful
https://kubernetes.default.svc  in-cluster                                           Unknown     Cluster has no applications and is not being monitored.

Créez le manifeste de l'application. Remplacez repoURL par l'URL réelle de votre dépôt, ainsi que ${cluster1_url} et ${cluster2_url} par les URL des serveurs API des clusters obtenues à l'étape précédente. apps-web-demo.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-demo-cluster1
  namespace: argocd
spec:
  destination:
    namespace: gateway-demo
    # https://1.1.XX.XX:6443
    server: ${cluster1_url}
  project: default
  source:
    helm:
      releaseName: "web-demo"
      parameters:
      - name: envCluster
        value: cluster-demo-1
      valueFiles:
      - values.yaml
    path: manifests/helm/web-demo
    repoURL: https://github.com/AliyunContainerService/gitops-demo.git
    targetRevision: gateway-demo
  syncPolicy:
    syncOptions:
    - CreateNamespace=true
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-demo-cluster2
  namespace: argocd
spec:
  destination:
    namespace: gateway-demo
    server: ${cluster2_url}
  project: default
  source:
    helm:
      releaseName: "web-demo"
      parameters:
      - name: envCluster
        value: cluster-demo-2
      valueFiles:
      - values.yaml
    path: manifests/helm/web-demo
    repoURL: https://github.com/AliyunContainerService/gitops-demo.git
    targetRevision: gateway-demo
  syncPolicy:
    syncOptions:
    - CreateNamespace=true

Déployez les applications.
```
kubectl apply -f apps-web-demo.yaml
```

Vérifiez que les deux applications sont synchronisées et saines.

argocd app list

Résultat attendu :

NAME                      CLUSTER                  NAMESPACE  PROJECT  STATUS  HEALTH   SYNCPOLICY  CONDITIONS  REPO                                                       PATH                     TARGET
argocd/web-demo-cluster1  https://10.1.XX.XX:6443             default  Synced  Healthy  Auto        <none>      https://github.com/AliyunContainerService/gitops-demo.git  manifests/helm/web-demo  main
argocd/web-demo-cluster2  https://10.1.XX.XX:6443             default  Synced  Healthy  Auto        <none>      https://github.com/AliyunContainerService/gitops-demo.git  manifests/helm/web-demo  main

Étape 2 : Créer la passerelle multi-cluster

Créez une ressource MseIngressConfig dans l'instance de flotte pour provisionner la passerelle et associer les deux clusters en tant que backends.

Récupérez les ID de vSwitch de l'instance de flotte — consultez la section Obtenir un ID de vSwitch.

Créez le manifeste de la passerelle. gateway.yaml

Remplacez ${vsw-id1} et ${vsw-id2} par les ID de vSwitch, ainsi que ${cluster1} et ${cluster2} par les ID des clusters associés. Pour chaque cluster associé, configurez les règles entrantes de son groupe de sécurité afin d'autoriser l'accès depuis toutes les adresses IP et ports du bloc CIDR du vSwitch.

Paramètre	Description
`mse.alibabacloud.com/remote-clusters`	ID des clusters à ajouter à la passerelle, séparés par des virgules. Il doit s'agir de clusters déjà associés à l'instance de flotte.
`spec.name`	Nom de l'instance de passerelle.
`spec.common.instance.spec`	(Facultatif) Type d'instance. Par défaut : `4c8g`.
`spec.common.instance.replicas`	(Facultatif) Nombre de réplicas de la passerelle. Par défaut : `3`.
`spec.ingress.local.ingressClass`	(Facultatif) Nom de la classe Ingress à écouter. La passerelle écoute toutes les ressources Ingress de l'instance de flotte dont le paramètre `ingressClass` est défini sur `mse`.

apiVersion: mse.alibabacloud.com/v1alpha1
kind: MseIngressConfig
metadata:
  annotations:
    mse.alibabacloud.com/remote-clusters: ${cluster1},${cluster2}
  name: ackone-gateway-hongkong
spec:
  common:
    instance:
      replicas: 3
      spec: 2c4g
    network:
      vSwitches:
      - ${vsw-id}
  ingress:
    local:
      ingressClass: mse
  name: mse-ingress

Déployez la passerelle.
```
kubectl apply -f gateway.yaml
```

Attendez que la passerelle atteigne le statut Listening. La phase Pending, durant laquelle la passerelle cloud-native est en cours de création, peut durer environ 3 minutes.

Statut	Description
`Pending`	La passerelle est en cours de provisionnement (~3 minutes)
`Running`	La passerelle est créée et en cours d'exécution
`Listening`	La passerelle est en cours d'exécution et surveille les ressources Ingress
`Failed`	La passerelle est invalide ; vérifiez le champ `Status` pour plus de détails

kubectl get mseingressconfig ackone-gateway-hongkong

Résultat attendu :

NAME                      STATUS      AGE
ackone-gateway-hongkong   Listening   3m15s

Valeurs possibles du statut de la passerelle :

Confirmez que les deux clusters ont bien été ajoutés.
```
kubectl get mseingressconfig ackone-gateway-hongkong -ojsonpath="{.status.remoteClusters}"
```
Résultat attendu :
```
[{"clusterId":"c7fb82****"},{"clusterId":"cd3007****"}]
```
Les deux ID de cluster apparaissent sans message Failed, ce qui confirme que les clusters sont connectés à la passerelle.

Étape 3 : Configurer la reprise après sinistre au niveau de la zone à l'aide d'Ingress

La passerelle multi-cluster utilise les ressources Ingress définies dans l'instance de flotte pour router le trafic entre les clusters. Créez les objets Ingress dans le namespace gateway-demo — le même namespace que celui où l'application est déployée.

Important

Le namespace gateway-demo doit exister dans l'instance de flotte avant la création des ressources Ingress.

Sélectionnez le mode de reprise adapté à votre application :

Redondance active entre zones

En mode redondance active entre zones, le trafic est réparti équitablement sur tous les backends de cluster selon le ratio de réplicas. Si un cluster devient indisponible, la passerelle reroute automatiquement sa part de trafic vers les clusters sains restants.

Exemple : Avec 9 réplicas dans le Cluster 1 et 1 réplica dans le Cluster 2, 90 % du trafic est dirigé vers le Cluster 1 et 10 % vers le Cluster 2 par défaut. Si tous les backends du Cluster 1 tombent en panne, 100 % du trafic bascule vers le Cluster 2.

Créer un Ingress pour la redondance active entre zones

Créez un Ingress qui route le trafic vers service1 sous le domaine example.com. La passerelle distribue les requêtes vers le Service portant le même nom dans les deux clusters.

ingress-demo.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-demo
spec:
  ingressClassName: mse
  rules:
  - host: example.com
    http:
      paths:
      - path: /svc1
        pathType: Exact
        backend:
          service:
            name: service1
            port:
              number: 80

Déployez l'Ingress dans l'instance de flotte.

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

Vérifier la redondance active entre zones

Récupérez l'adresse IP publique de la passerelle multi-cluster.

kubectl get ingress web-demo -n gateway-demo -ojsonpath="{.status.loadBalancer}"

Envoyez 100 requêtes et observez la distribution du trafic. Remplacez XX.XX.XX.XX par l'adresse IP de la passerelle.

for i in {1..100}; do curl -H "host: example.com" XX.XX.XX.XX; done

Résultat attendu : Le trafic est réparti entre le Cluster 1 et le Cluster 2 selon un ratio de 9:1.

for i in {1..50}; do curl -H "host: example.com" .../svc1; sleep 1; done
This is cluster-demo-2!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-2!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-2!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-2!

Simulez une panne de cluster en ramenant le nombre de réplicas du Deployment dans le Cluster 1 à 0. Tout le trafic est automatiquement rerouté vers le Cluster 2.

This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-2!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!

Exécuter des versions canari avec un routage basé sur les en-têtes

En mode redondance active entre zones, vous pouvez tester une version canari dans un cluster sans impacter le trafic en production. Déployez la version canari en tant que Service et Deployment distincts, puis utilisez une annotation Ingress pour router vers celle-ci les requêtes contenant un en-tête spécifique.

Déployez l'application canari dans le Cluster 1. new-app.yaml

apiVersion: v1
kind: Service
metadata:
  name: service1-canary-1
  namespace: gateway-demo
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: web-demo-canary-1
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-demo-canary-1
  namespace: gateway-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web-demo-canary-1
  template:
    metadata:
      labels:
        app: web-demo-canary-1
    spec:
      containers:
        - env:
            - name: ENV_NAME
              value: cluster-demo-1-canary
          image: 'registry-cn-hangzhou.ack.aliyuncs.com/acs/web-demo:0.6.0'
          imagePullPolicy: Always
          name: web-demo

kubectl apply -f new-app.yaml

Créez un Ingress canari basé sur les en-têtes dans l'instance de flotte. Les requêtes contenant l'en-tête canary-dest: cluster1 sont routées vers le Service canari. new-ingress.yaml

Annotation	Description
`nginx.ingress.kubernetes.io/canary`	Définissez sur `"true"` pour activer le routage basé sur les en-têtes pour cet Ingress
`nginx.ingress.kubernetes.io/canary-by-header`	Clé d'en-tête à faire correspondre (`canary-dest`)
`nginx.ingress.kubernetes.io/canary-by-header-value`	Valeur d'en-tête à faire correspondre (`cluster1`)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-demo-canary-1
  namespace: gateway-demo
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "canary-dest"
    nginx.ingress.kubernetes.io/canary-by-header-value: "cluster1"
spec:
  ingressClassName: mse
  rules:
  - host: example.com
    http:
      paths:
      - path: /svc1
        pathType: Exact
        backend:
          service:
            name: service1-canary-1
            port:
              number: 80

kubectl apply -f new-ingress.yaml

Vérifiez que les requêtes contenant l'en-tête sont bien routées vers la version canari.

for i in {1..100}; do curl -H "host: example.com" -H "canary-dest: cluster1" XX.XX.XX.XX/svc1; sleep 1; done

Résultat attendu : Toutes les requêtes contenant canary-dest: cluster1 sont traitées par la version canari du Cluster 1.

→ gateway  for i in {1..1000}; do curl -H "host: example.com" -H "canary-dest: cluster1" xxx/svc1; sleep
1; done
This is cluster-demo-1-canary!
This is cluster-demo-1-canary!
This is cluster-demo-1-canary!
This is cluster-demo-1-canary!
This is cluster-demo-1-canary!
This is cluster-demo-1-canary!
This is cluster-demo-1-canary!
This is cluster-demo-1-canary!
This is cluster-demo-1-canary!
This is cluster-demo-1-canary!

Reprise après sinistre principal/secondaire

En mode principal/secondaire, tout le trafic est dirigé vers le Cluster 1 (principal) en conditions normales. Si le Cluster 1 devient indisponible, la passerelle reroute automatiquement le trafic vers le Cluster 2 (secondaire).

Ce mode s'appuie sur deux annotations spécifiques à MSE pour fixer les routes Ingress à un cluster donné :

Annotation	Description
`mse.ingress.kubernetes.io/service-subset`	Libellé lisible pour le sous-ensemble de service. Utilisez un nom indiquant le cluster cible.
`mse.ingress.kubernetes.io/subset-labels`	ID du cluster vers lequel router, en utilisant le libellé `topology.istio.io/cluster`.

Pour la liste complète des annotations Ingress MSE, consultez la section Annotations prises en charge par les passerelles Ingress MSE.

Créer un Ingress pour la reprise après sinistre principal/secondaire

Créez l'Ingress principal qui fixe le trafic sur le Cluster 1. Remplacez ${cluster1-id} par l'ID réel du cluster. ingress-demo-cluster-one.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    mse.ingress.kubernetes.io/service-subset: cluster-demo-1
    mse.ingress.kubernetes.io/subset-labels: |
      topology.istio.io/cluster ${cluster1-id}
  name: web-demo-cluster-one
spec:
  ingressClassName: mse
  rules:
  - host: example.com
    http:
      paths:
      - path: /service1
        pathType: Exact
        backend:
          service:
            name: service1
            port:
              number: 80

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

Exécuter des versions canari au niveau du cluster

Utilisez un Ingress canari basé sur les en-têtes conjointement à l'Ingress principal pour router certaines requêtes vers le Cluster 2 à des fins de validation, sans modifier le chemin de trafic par défaut.

Créez l'Ingress canari ciblant le Cluster 2. Remplacez ${cluster2-id} par l'ID réel du cluster. ingress-demo-cluster-gray.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    mse.ingress.kubernetes.io/service-subset: cluster-demo-2
    mse.ingress.kubernetes.io/subset-labels: |
      topology.istio.io/cluster ${cluster2-id}
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "app-web-demo-version"
    nginx.ingress.kubernetes.io/canary-by-header-value: "gray"
  name: web-demo-cluster-gray
spec:
  ingressClassName: mse
  rules:
  - host: example.com
    http:
      paths:
      - path: /service1
        pathType: Exact
        backend:
          service:
            name: service1
            port:
              number: 80

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

Vérifier la reprise après sinistre principal/secondaire

Récupérez l'adresse IP publique de la passerelle multi-cluster.

kubectl get ingress web-demo -n gateway-demo -ojsonpath="{.status.loadBalancer}"

Confirmez que le trafic par défaut est dirigé vers le Cluster 1.

for i in {1..100}; do curl -H "host: example.com" XX.XX.XX.XX/service1; sleep 1; done

Résultat attendu : Tout le trafic par défaut est traité par le Cluster 1.

for i in {1..100}; do curl -H "host: example.com" xx.xx.xx.xx/service1; sleep 1;  done
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!

Confirmez que le trafic canari est dirigé vers le Cluster 2.

for i in {1..50}; do curl -H "host: example.com" -H "app-web-demo-version: gray" XX.XX.XX.XX/service1; sleep 1; done

Résultat attendu : Toutes les requêtes contenant app-web-demo-version: gray sont traitées par le Cluster 2.

À la fin de la commande, toutes les requêtes renvoient This is cluster-demo-2!, confirmant que toutes les requêtes avec l'en-tête canari ont été routées vers la version canari.

This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!

Simulez une panne du Cluster 1 en ramenant le nombre de réplicas du Deployment à 0. Tout le trafic par défaut est automatiquement rerouté vers le Cluster 2.

for i in {1..100}; do curl -H "host: example.com" 8.xxx.xxx.217.xxx/service1; sleep 1; done
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-1!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!
This is cluster-demo-2!

Étapes suivantes

Gérer le trafic nord-sud — explorez l'ensemble des capacités de gestion du trafic des passerelles multi-cluster ACK One
Démarrage rapide pour GitOps — approfondissez le déploiement d'applications avec Argo CD sur ACK One