Tous les produits
Search
Centre de documentation

Container Service for Kubernetes:Manage north-south traffic

Dernière mise à jour :Aug 11, 2026

Utilisez les passerelles multi-cluster ALB pour gérer le trafic nord-sud entre plusieurs clusters ACK. Bénéficiez de la redondance active des zones, de l'équilibrage de charge et du routage basé sur les en-têtes sans avoir à gérer des contrôleurs Ingress distincts pour chaque cluster.

Prérequis

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

Fonctionnement

Le trafic circule depuis Internet via l'instance ALB vers les pods de vos clusters associés :

Internet → ALB instance → ACK One Fleet instance → Associated cluster 1 (pods)
                                                  → Associated cluster 2 (pods)

L'instance Fleet agit comme plan de contrôle. Un objet AlbConfig sur l'instance Fleet provisionne l'instance ALB. Les règles Ingress sur l'instance Fleet contrôlent l'acheminement du trafic par ALB vers les pods de tous les clusters associés.

Étape 1 : Créer une passerelle multi-cluster ALB

Créez un objet AlbConfig sur l'instance Fleet pour provisionner l'instance ALB et enregistrer les clusters associés en tant que cibles de trafic.

  1. Récupérez les ID de deux vSwitches du VPC où réside l'instance Fleet.

  2. Créez gateway.yaml avec le contenu suivant. Remplacez ${vsw-id1} et ${vsw-id2} par les ID des vSwitches, et remplacez ${cluster1} et ${cluster2} par les ID des clusters associés.

    Pour chaque cluster associé ( ${cluster1} et ${cluster2} ), configurez les règles entrantes de leurs groupes de sécurité afin d'autoriser le trafic provenant de toutes les adresses IP et de tous les ports du bloc CIDR des vSwitches.
    Paramètre Obligatoire Description
    metadata.name Oui Nom de l'AlbConfig.
    metadata.annotations: alb.ingress.kubernetes.io/remote-clusters Oui Liste séparée par des virgules des ID de cluster à ajouter à la passerelle multi-cluster ALB. Chaque ID de cluster doit déjà être associé à l'instance Fleet.
    spec.config.name Non Nom de l'instance ALB.
    spec.config.addressType Non Type de réseau de l'instance ALB. Internet (par défaut) : accessible publiquement, nécessite une adresse IP élastique (EIP), facturation basée sur les frais d'instance et la bande passante. Intranet : privé, accessible uniquement au sein du VPC.
    spec.config.zoneMappings Oui ID des vSwitches pour l'instance ALB. Les vSwitches doivent se trouver dans des zones prises en charge par ALB et dans le même VPC que les clusters. Pour une haute disponibilité, utilisez des vSwitches dans au moins deux zones si la région le permet. Pour obtenir la liste des régions et zones disponibles, consultez Régions et zones où ALB est disponible.
    spec.listeners Non Port et protocole de l'écouteur. L'exemple utilise HTTP sur le port 8001. Conservez cette configuration : sans écouteur, vous ne pouvez pas utiliser les Ingress ALB.
    apiVersion: alibabacloud.com/v1
    kind: AlbConfig
    metadata:
      name: ackone-gateway-demo
      annotations:
        # Add associated clusters that are used to handle 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
  3. Appliquez le manifeste pour créer la passerelle multi-cluster ALB et la classe Ingress :

    kubectl apply -f gateway.yaml
  4. Après 1 à 3 minutes, vérifiez que la passerelle est 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
  5. Vérifiez que les clusters associés sont connectés à la passerelle :

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

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

Étape 2 : Acheminer le trafic avec Ingress

Créez un Ingress avec ingressClassName: alb pour utiliser la passerelle multi-cluster ALB. Les Ingress ALB prennent en charge les annotations couramment utilisées par Nginx Ingress et offrent des fonctionnalités améliorées pour les instances ALB. Pour la liste complète des annotations prises en charge, consultez Configuration Ingress ALB avec annotations.

Le tableau suivant résume les quatre scénarios de routage couverts dans cette section :

Scénario À utiliser lorsque Annotation clé
Équilibrage de charge par défaut Répartir le trafic sur tous les clusters selon le nombre de réplicas Aucune annotation requise
Routage mono-cluster Envoyer tout le trafic vers un seul cluster (pour l'isolation ou les tests) alb.ingress.kubernetes.io/cluster-weight.{clusterID}: "100"
Routage basé sur les en-têtes Acheminer les requêtes contenant un en-tête spécifique vers un cluster désigné alb.ingress.kubernetes.io/conditions.{service}
Routage pondéré Répartir le trafic entre les clusters selon des pourcentages définis alb.ingress.kubernetes.io/cluster-weight.{clusterID} (plusieurs annotations)

Exemple 1 : Équilibrage de charge par défaut

Répartissez le trafic sur tous les pods backend des clusters associés, en pondérant selon le nombre de réplicas. Aucune annotation de pondération de cluster n'est nécessaire. Utilisez cette méthode lorsque vous souhaitez une distribution de charge simple et automatique, sans personnaliser les poids par cluster.

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

Exemple 2 : Routage mono-cluster

Acheminez tout le trafic vers un cluster spécifique, par exemple pour isoler un cluster lors d'un incident ou diriger le trafic canari vers un seul cluster. Définissez le poids du cluster sur "100". Si le cluster spécifié n'existe pas, le système l'ignore.

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

Exemple 3 : Routage basé sur les en-têtes

Acheminez les requêtes comportant une valeur d'en-tête HTTP spécifique vers un cluster désigné, par exemple pour envoyer les requêtes avec stage: gray vers un cluster de déploiement progressif (gray-release). Utilisez l'annotation alb.ingress.kubernetes.io/conditions.{service} pour définir la règle de correspondance de l'en-tête, et alb.ingress.kubernetes.io/cluster-weight.{clusterID} pour spécifier le cluster cible. Si le cluster spécifié n'existe pas, le système l'ignore.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/listen-ports: |
     [{"HTTP": 8001}]
    alb.ingress.kubernetes.io/conditions.service1: |
     [{
       "type": "Header",
       "headerConfig": {
          "key":"stage",
           "values": [
              "gray"
           ]
       }
      }]
    alb.ingress.kubernetes.io/cluster-weight.c6XXXXXXXXXXXXXXXXXXXXXXXXX: "100"
  name: alb-ingress
  namespace: demo
spec:
  ingressClassName: alb
  rules:
  - host: alb.ingress.alibaba.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 80

Exemple 4 : Routage pondéré

Répartissez le trafic entre les clusters selon des pourcentages définis, par exemple pour migrer progressivement le trafic d'un cluster vers un autre. La somme de tous les poids de cluster doit être égale à 100.

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

Dépannage

La passerelle n'est pas créée après 3 minutes

Inspectez le statut de l'AlbConfig pour obtenir les détails de l'erreur :

kubectl describe albconfig ackone-gateway-demo

Causes courantes :

  • Les vSwitches ne se trouvent pas dans des zones prises en charge par ALB. Vérifiez à l'aide de Régions et zones où ALB est disponible.

  • Les règles entrantes du groupe de sécurité des clusters associés n'autorisent pas le trafic provenant du bloc CIDR des vSwitches.

Les clusters associés n'apparaissent pas dans subClusters

Vérifiez que les ID de cluster dans l'annotation alb.ingress.kubernetes.io/remote-clusters correspondent aux ID des clusters associés à l'instance Fleet :

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

Si le résultat est vide, confirmez que les ID de cluster dans gateway.yaml sont corrects et que les clusters sont bien associés à l'instance Fleet.

Étapes suivantes