Équilibrage de charge avancé sur les clusters GKE

Preview

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

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

Vous pouvez utiliser l'équilibrage de charge avancé pour:

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

Limites

• Des limites générales s'appliquent à l'utilisation de l'équilibrage de charge avancé sur Google Cloud .
• Cette fonctionnalité n'est disponible que pour les utilisateurs de Cloud Service Mesh gérés qui utilisent Traffic Director comme plan de contrôle. Elle nécessite la version du plan de données 1.19.10-asm.22 ou ultérieure.
• Tous les champs de GCPTrafficDistributionPolicy et GCPBackendPolicy ne sont pas compatibles avec le service de gestion Cloud Service Mesh (TD). Les champs acceptés sont les suivants :
  • GCPTrafficDistributionPolicy
    • ServiceLbAlgorithm
    • AutoCapacityDrain
    • FailoverConfig
  • GCPBackendPolicy
    • MaxRatePerEndpoint
    • BackendPreference
• L'équilibrage de charge avancé ne peut être appliqué qu'aux services Kubernetes basés sur des charges de travail exécutées 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 stratégies d'équilibrage de charge à l'échelle de l'espace de noms/du réseau maillé ne sont pas acceptées.
• Seule la capacité en requêtes par seconde est prise en charge.
• Seules les versions GKE 1.31.1 et ultérieures sont compatibles.
• Les règles d'équilibrage de charge avancées du service de maillage ne doivent être appliquées qu'aux services qui ne gèrent que le trafic de maillage. Il ne doit pas être appliqué aux services servant de backends GKE Gateway. Les comportements de trafic ne sont pas définis lorsqu'un trafic d'équilibrage de charge avancé cible 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 de la ressource 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 d'effectuer les opérations suivantes:

• Choisissez un algorithme d'équilibrage de charge personnalisé. Les algorithmes compatibles sont décrits dans le tableau d'équilibrage de charge avancé.
• Activez le drainage de capacité automatique.
• Ajustez le seuil d'état de basculement.

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

GCPBackendPolicy

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

• Capacité du backend du service.
• Désignation de backends préférés.

Si plusieurs règles GCPBackendPolicy ciblent le même service dans un cluster, la règle la plus ancienne est appliquée.

État de la règle

GCPTrafficDistributionPolicy et GCPBackendPolicy comportent un champ d'état indiquant l'état d'association de la stratégie.

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 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, ou 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 uniformément entre tous les backends de service en bon état d'un maillage de services Cloud Service Mesh. Vous pouvez créer la stratégie GCPTrafficDistributionPolicy suivante afin que le trafic soit distribué à 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

Remarque :Les paramètres de GCPTrafficDistributionPolicy prévalent sur ceux de l'API Kubernetes Service principale.

Par défaut, les backends de service sont traités comme s'ils avaient une capacité infinie. Lorsque suffisamment d'hôtes opérationnels se trouvent dans la zone locale/la plus proche, le trafic n'est jamais distribué en dehors de la zone locale/la plus proche pour une certaine localité 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

Ajuster le comportement de basculement

Par défaut, le basculement ne se déclenche pas tant qu'un pourcentage suffisant d'hôtes est 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 basculement. 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 passe sous 90% dans les backends principaux, vous pouvez configurer le GCPTrafficDistributionPolicy suivant:

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

GCPTrafficDistributionPolicy et GCPBackendPolicy sont appliqués à des portées différentes dans un service mesh multicluster.

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

Lorsqu'une règle GCPBackendPolicy cible un service multicluster, elle définit des 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 le même service multicluster, il est possible de définir différents paramètres de niveau backend dans différents clusters.

Dans l'exemple suivant, un GCPTrafficDistributionPolicy est créé dans le cluster A pour définir l'algorithme d'équilibrage de charge à utiliser dans l'ensemble de la flotte, tandis que les GCPBackendPolicies se trouvent dans chaque cluster. Les deux GCPBackendPolicy configurent une capacité de 10 qps par pod pour les pods backend de leur cluster local, tandis que le GCPBackendPolicy du cluster A configure les pods backend du cluster A en tant que 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 qps par pod.
  • Ce comportement est principalement défini par la règle GCPBackendPolicy qui a défini 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 une explication plus détaillée des backends préférés, consultez la section 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 GCPBackendPolicy, qui définit la capacité du backend, dans les clusters A et B.

Remarque :Cette section présente la capacité de Cloud Service Mesh à équilibrer la charge du trafic sur plusieurs clusters. À des fins de démonstration, déployez l'exemple de service foo et ses pods de backend dans les deux clusters.

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 de cluster. Bien que le GCPTrafficDistributionPolicy suivant cible le service Kubernetes foo standard, il s'applique au service multicluster foo composé de charges de travail correspondantes dans deux clusters.

1. Créez la stratégie 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 stratégie 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 stratégie 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

• En savoir plus sur l'équilibrage de charge avancé