Équilibrage de charge avancé sur les clusters GKE

Cette page explique comment configurer l'équilibrage de charge avancé sur les clusters GKE pour les utilisateurs de Cloud Service Mesh (TD) géré à l'aide de l'API Kubernetes. Pour obtenir le guide de l'utilisateur correspondant permettant de configurer l'équilibrage de charge avancé à l'aide de l'APIGoogle Cloud , consultez Configurer l'équilibrage de charge avancé.

L'équilibrage de charge avancé vous permet de :

  • Conservez le trafic vers un service zonal jusqu'à ce que la capacité locale soit épuisée.
  • Envoyez du trafic vers le service dans un emplacement "principal" avec basculement vers un emplacement secondaire lorsque suffisamment de points de terminaison dans l'emplacement principal deviennent défectueux.
  • Contrôlez le moment où le basculement se produit (en fonction du pourcentage d'hôtes opérationnels).

Limites

  • Les limites générales concernant l'utilisation de l'équilibrage de charge avancé sur Google Cloud s'appliquent.
  • Cette fonctionnalité n'est disponible que pour les utilisateurs de Cloud Service Mesh géré qui utilisent Traffic Director comme plan de contrôle et nécessite la version 1.19.10-asm.22 ou ultérieure du plan de données.

  • Tous les champs de GCPTrafficDistributionPolicy et GCPBackendPolicy ne sont pas compatibles avec managedCloud Service Mesh (TD). Les champs acceptés sont les suivants :

    • GCPTrafficDistributionPolicy
      • ServiceLbAlgorithm
      • AutoCapacityDrain
      • FailoverConfig
    • GCPBackendPolicy
      • MaxRatePerEndpoint
      • BackendPreference

    Tous les champs non listés ne sont pas acceptés. Une règle avec au moins un champ non accepté configuré n'est pas appliquée dans Cloud Service Mesh.

  • L'équilibrage de charge avancé ne peut être appliqué qu'aux services Kubernetes soutenus par des charges de travail s'exécutant sur Google Cloud. Les services ou charges de travail externes (comme ServiceEntry) ne sont pas compatibles.

  • Les règles d'équilibrage de charge ne peuvent être appliquées qu'à des services Kubernetes individuels. Les règles d'équilibrage de charge à l'échelle de l'espace de noms ou du maillage ne sont pas acceptées.

  • Seule la capacité de requêtes par seconde est acceptée.

  • Seules les versions de GKE supérieures ou égales à 1.31.1 sont compatibles.

  • Les règles d'équilibrage de charge avancées du service mesh ne doivent être appliquées qu'aux services qui ne diffusent que du trafic mesh. Il ne doit pas être appliqué aux services servant de backends GKE Gateway. Les comportements du trafic ne sont pas définis lorsqu'une cible de trafic d'équilibrage de charge avancé est un service Kubernetes qui diffuse à la fois du trafic de maillage et du trafic provenant d'une passerelle GKE.

Configurer l'équilibrage de charge avancé

Vous pouvez utiliser les ressources personnalisées suivantes pour configurer l'équilibrage de charge avancé sur GKE. Vous trouverez la définition détaillée des ressources dans le dépôt gke-gateway-api.

GCPTrafficDistributionPolicy

GCPTrafficDistributionPolicy configure la règle d'équilibrage de charge au niveau du service pour les services Kubernetes. Elle vous permet :

Si plusieurs règles GCPTrafficDistributionPolicy ciblent le même service, la plus ancienne sera appliquée.

GCPBackendPolicy

GCPBackendPolicy configure les propriétés des backends de service qui ont un impact sur le comportement de l'équilibrage de charge, y compris :

Si plusieurs GCPBackendPolicies ciblent le même service dans un cluster, la plus ancienne sera appliquée.

État de la règle

Les règles GCPTrafficDistributionPolicy et GCPBackendPolicy comportent un champ d'état indiquant l'état de l'association de la règle.

Par exemple, l'exécution de kubectl describe gcpbackendpolicies example-policy -n example génère un résultat semblable à celui-ci :

...
Status:
  Ancestors:
    Ancestor Ref:
      Group:
      Kind:       Service
      Name:       example-svc
      Namespace:  example
    Conditions:
      Last Transition Time:  2024-10-13T01:15:03Z
      Message:
      Observed Generation:   1
      Reason:                Attached
      Status:                True
      Type:                  Attached
    Controller Name:         gsmconfig.gke.io/controller

Configuration préliminaire

Avant de pouvoir suivre ce guide, vous devez provisionner Cloud Service Mesh sur un cluster GKE.

  1. Vérifiez que les CRD sont installés :

    kubectl get crd

    Le résultat est semblable à :

    ...
gcptrafficdistributionpolicies.networking.gke.io   2024-07-18T21:50:12Z
gcpbackendpolicies.networking.gke.io               2024-07-18T21:50:12Z
...

  2. Installez le CRD GCPBackendPolicy si ce n'est pas déjà fait :

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcpbackendpolicies.yaml

  3. Installez le CRD GCPTrafficDistributionPolicy si ce n'est pas déjà fait :

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcptrafficdistributionpolicies.yaml

Les exemples de règles de ce guide de l'utilisateur ciblent le service foo dans l'espace de noms foo à des fins de démonstration. Vous pouvez exécuter la commande suivante pour créer le service et l'espace de noms de test. Si vous préférez, vous pouvez utiliser votre propre service et espace de noms :

kubectl apply -f - <<EOF
kind: Namespace
apiVersion: v1
metadata:
  name: foo
  labels:
    istio-injection: enabled
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: foo
  namespace: foo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test-backend
  template:
    metadata:
      labels:
        app: test-backend
    spec:
      containers:
      - name: whereami
        image: gcr.io/google-samples/whereami:v1.2.23
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: foo
  namespace: foo
spec:
  selector:
    app: test-backend
  ports:
  - port: 8080
    targetPort: 8080
EOF

Configurer l'algorithme d'équilibrage de charge

Par défaut, le trafic vers un service est réparti de manière égale entre tous les backends de service sains d'un maillage de services Cloud Service Mesh. Vous pouvez créer la GCPTrafficDistributionPolicy suivante afin que le trafic soit réparti vers la zone la plus proche jusqu'à la capacité du backend :

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: lb-policy
  namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
    serviceLbAlgorithm: WATERFALL_BY_ZONE
EOF

Par défaut, les backends de service sont traités comme s'ils avaient une capacité infinie. Lorsqu'il existe suffisamment d'hôtes opérationnels dans la zone locale/la plus proche, le trafic ne sera jamais distribué en dehors de la zone locale/la plus proche pour une certaine localité du client. Vous pouvez éventuellement configurer la capacité du backend de votre service à l'aide de GCPBackendPolicy afin qu'une seule zone ne soit pas surchargée.

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
  namespace: foo
spec:
  targetRef:
    kind: Service
    group: ""
    name: foo-backend
  default:
    maxRatePerEndpoint: 5
EOF

Comportement de basculement du réglage

Par défaut, le basculement ne sera pas déclenché tant qu'un pourcentage suffisant d'hôtes sera opérationnel dans les backends principaux. Pour en savoir plus sur les backends principaux et d'autres termes, consultez la présentation de l'équilibrage de charge avancé. GCPTrafficDistributionPolicy vous permet de configurer le seuil de pourcentage d'hôtes opérationnels jusqu'à ce que le trafic soit transféré des backends principaux vers les backends de secours. Le basculement est déclenché plus tôt avec un seuil plus élevé. Par exemple, si vous souhaitez que le basculement soit déclenché dès que le pourcentage d'hôtes opérationnels tombe en dessous de 90 % dans les backends principaux, vous pouvez configurer la GCPTrafficDistributionPolicy suivante :

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: lb-policy
  namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
   failoverConfig:
     failoverHealthThreshold: 90
EOF

Configurer l'équilibrage de charge avancé dans un maillage de services multicluster

Les règles GCPTrafficDistributionPolicy et GCPBackendPolicy sont appliquées à différents niveaux dans un maillage de services multicluster.

Lorsqu'une GCPTrafficDistributionPolicy cible un service multicluster, elle définit le comportement d'équilibrage de charge au niveau du service dans tous les clusters. Une seule GCPTrafficDistributionPolicy doit être créée pour un service multicluster spécifique. Si vous utilisez l'API Istio pour configurer votre service mesh, vous pouvez créer une GCPTrafficDistributionPolicy dans n'importe quel cluster du parc. Vous pouvez vérifier si une règle est en conflit avec une autre en examinant son état.

Lorsqu'une GCPBackendPolicy cible un service multicluster, elle définit les paramètres au niveau du backend (par exemple, la capacité par pod) pour les pods de backend sélectionnés par son service de ciblage dans son cluster local. Pour un même service multicluster, il est possible de définir différents paramètres au niveau du backend dans différents clusters.

Dans l'exemple suivant, une GCPTrafficDistributionPolicy est créée dans le cluster A pour définir l'algorithme d'équilibrage de charge à utiliser dans le parc, tandis que les GCPBackendPolicies se trouvent dans chaque cluster. Les deux GCPBackendPolicy configurent une capacité de 10 requêtes par seconde et par pod pour les pods de backend dans leur cluster local, tandis que la GCPBackendPolicy du cluster A configure les pods de backend du cluster A comme backend préféré.

Ensemble, ces règles configurent les comportements d'équilibrage de charge pour le trafic dans le maillage envoyé au service foo :

  • Le trafic provenant de n'importe où préfère les backends du cluster A jusqu'à ce que les pods de backend du cluster A doivent gérer 10 requêtes par seconde par pod.
    • Ce comportement est principalement défini par la règle GCPBackendPolicy qui définit backendPreference sur PREFERRED dans le cluster A.
  • Le trafic dépassant la capacité configurée des backends du cluster A est acheminé vers le cluster B à l'aide de l'algorithme WATERFALL_BY_ZONE. Pour obtenir une explication plus détaillée des backends préférés, consultez la présentation de l'équilibrage de charge avancé.
    • Ce comportement est principalement défini par GCPTrafficDistributionPolicy, qui définit l'algorithme dans le cluster A, et par GCPBackendPolicy, qui définit la capacité du backend dans les clusters A et B.

Maillage de services multicluster avec équilibrage de charge avancé

Dans Istio, les services Kubernetes standards deviennent implicitement "multiclusters" lorsqu'il existe plusieurs clusters dans le maillage de services et que le service est créé au-delà des limites du cluster. Bien que la GCPTrafficDistributionPolicy suivante cible le service Kubernetes standard foo, elle s'applique au service multicluster foo composé des charges de travail correspondantes dans deux clusters.

  1. Créez la GCPTrafficDistributionPolicy pour le cluster A :

    kubectl apply --context cluster-a-context -f - <<EOF
kind: GCPTrafficDistributionPolicy
apiVersion: networking.gke.io/v1
metadata:
name: foo-traffic-distribution-policy
namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
    serviceLbAlgorithm: WATERFALL_BY_ZONE

EOF

  2. Créez la GCPBackendPolicy pour le cluster A :

    kubectl apply --context cluster-a-context -f - <<EOF
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
name: foo-backend-policy
namespace: foo
spec:
  default:
    maxRatePerEndpoint: 100
    backendPreference: PREFERRED
  targetRef:
    group: ""
    kind: Service
    name: foo-service
EOF

  3. Créez la GCPBackendPolicy pour le cluster B :

    kubectl apply --context cluster-b-context -f - <<EOF
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
name: foo-backend-policy
namespace: foo
spec:
  default:
    maxRatePerEndpoint: 10
  targetRef:
    group: ""
    kind: Service
    name: foo-service
EOF

Étape suivante