Créer un équilibreur de charge à protocole mixte

Ce document explique comment exposer une application exécutée dans un cluster Google Kubernetes Engine (GKE) à l'aide d'un service LoadBalancer externe ou interne à protocole mixte pour le trafic TCP et UDP.

Pour en savoir plus sur les équilibreurs de charge de couche 4, consultez À propos des services LoadBalancer.

Présentation

Vous pouvez exposer des applications qui utilisent les protocoles TCP et UDP à l'aide de deux services LoadBalancer GKE distincts avec une adresse IP partagée coordonnée manuellement. Toutefois, cette approche est inefficace, car elle nécessite de gérer plusieurs services pour une seule application et peut entraîner des problèmes tels que des erreurs de configuration ou des quotas d'adresses IP épuisés.

Les services LoadBalancer à protocole mixte vous permettent d'utiliser un seul service pour gérer le trafic TCP et UDP. L'utilisation d'un seul service simplifie votre configuration en vous permettant d'utiliser une seule adresse IP et un ensemble consolidé de règles de transfert pour les deux protocoles. Cette fonctionnalité est compatible avec les équilibreurs de charge réseau passthrough externes régionaux et les équilibreurs de charge réseau passthrough internes.

GKE est compatible avec les services à protocole mixte avec des configurations IPv4, IPv6 et à double pile. Les services à protocole mixte utilisent des règles de transfert de couche 3 (L3). Par conception, ces règles transfèrent tout le trafic qui arrive sur l'adresse IP virtuelle (VIP) de l'équilibreur de charge directement vers les nœuds de cluster.

Pour assurer la sécurité, GKE crée et gère automatiquement des règles de pare-feu avec la priorité 999 qui n'autorisent que le trafic TCP et UDP spécifique défini dans votre fichier manifeste de service. Tout autre trafic non autorisé dirigé vers l'adresse IP virtuelle de l'équilibreur de charge est bloqué par les règles de pare-feu gérées par GKE à l'aide de la priorité 1000. Si vous créez des règles de pare-feu de priorité plus élevée, assurez-vous qu'elles n'autorisent pas accidentellement le trafic non autorisé à atteindre vos nœuds. Pour en savoir plus, consultez Règles de pare-feu du service GKE.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
  • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la gcloud components update commande. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
  • Assurez-vous de disposer d'un cluster Autopilot ou Standard existant. Pour créer un cluster, consultez la page Créer un cluster Autopilot.

Conditions requises

Pour créer un service LoadBalancer qui utilise des protocoles mixtes, votre cluster doit répondre aux exigences suivantes :

  • L'équilibrage de charge à protocole mixte est généralement disponible à partir de GKE version 1.36.2-gke.1498000 et versions ultérieures. La version généralement disponible est compatible avec les équilibreurs de charge externes et internes avec des configurations IPv4, IPv6 et à double pile.
  • Pour les versions 1.34.1-gke.2190000 à 1.36.2-gke.1498000, l'équilibrage de charge à protocole mixte n'est compatible qu'avec les équilibreurs de charge externes qui utilisent des adresses IPv4.
  • Vous devez avoir activé l'addon HttpLoadBalancing sur votre cluster.
  • Pour les équilibreurs de charge internes, le sous-paramètre GKE doit être activé pour le cluster.
  • Pour les nouveaux services LoadBalancer internes, dans le fichier manifeste du service, définissez la valeur du champ spec.loadBalancerClass sur networking.gke.io/l4-regional-internal. Pour les services internes existants, votre fichier manifeste comporte déjà l'annotation networking.gke.io/load-balancer-type: "Internal", et vous pouvez la laisser telle quelle.
  • Pour les nouveaux services LoadBalancer externes, définissez le champ spec.loadBalancerClass sur networking.gke.io/l4-regional-external dans le fichier manifeste du service. Pour les services externes existants, votre fichier manifeste comporte déjà l' cloud.google.com/l4-rbs: "enabled" annotation, et vous pouvez laisser l' annotation telle quelle.

Limites

  • Dans les versions 1.34.1-gke.2190000 à 1.36.2-gke.1498000, les équilibreurs de charge à protocole mixte n'acceptent que les adresses IPv4.
  • Les services existants qui comportent les finaliseurs gke.networking.io/l4-ilb-v1 ou gke.networking.io/l4-netlb-v1 ne peuvent pas être utilisés pour l'équilibrage de charge à protocole mixte. Si vous souhaitez utiliser des protocoles mixtes sur ces services, vous devez supprimer et recréer le service conformément aux exigences précédentes.
  • La mise à jour des ports sur le service peut entraîner une brève interruption du trafic pour tout le trafic acheminé via l'équilibreur de charge.
  • Vous ne pouvez pas associer Private Service Connect à des services à protocole mixte.

Tarifs

Cloud de Confiance vous facture par règle de transfert, pour toutes les adresses IP externes et pour les données envoyées. Le tableau suivant décrit le nombre de règles de transfert et d'adresses IP externes utilisées pour les configurations spécifiées. Pour en savoir plus, consultez Tarifs du réseau VPC.

Type Couche de transport Couche Internet Nombre de règles de transfert Nombre d'adresses IP externes
Interne Unique ou mixte (TCP, UDP ou les deux) IPv4 1 0
IPv6 1 0
IPv4 et IPv6 (DualStack) 2 0
Externe Unique ou mixte (TCP, UDP ou les deux) IPv4 1 1
IPv6 1 1
IPv4 et IPv6 (DualStack) 2 2

Déployer une charge de travail

Cette section explique comment déployer un exemple de charge de travail qui écoute sur les ports TCP et UDP. Notez que la configuration du déploiement est la même, que vous utilisiez un service LoadBalancer à protocole mixte ou deux services LoadBalancer à protocole unique distincts.

  1. Le fichier manifeste suivant concerne un exemple d'application qui écoute sur le port 8080 pour le trafic TCP et UDP. Enregistrez le fichier manifeste suivant sous le nom mixed-app-deployment.yaml :

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: mixed-app-deployment
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: mixed-app
      template:
        metadata:
          labels:
            app: mixed-app
        spec:
          containers:
          - image: gcr.io/kubernetes-e2e-test-images/agnhost:2.6
            name: agnhost
            args: ["serve-hostname", "--port=8080", "--tcp=true", "--udp=true", "--http=false"]
            ports:
              - name: tcp8080
                protocol: TCP
                containerPort: 8080
              - name: udp8080
                protocol: UDP
                containerPort: 8080
    
  2. Appliquez le fichier manifeste à votre cluster :

    kubectl apply -f mixed-app-deployment.yaml
    

Créer un équilibreur de charge à protocole mixte

Créez un service de type LoadBalancer qui expose le déploiement au trafic TCP et UDP. Vous pouvez créer un équilibreur de charge externe ou interne.

  1. Pour créer un équilibreur de charge externe, enregistrez le fichier manifeste suivant sous le nom mixed-protocol-lb.yaml :

    apiVersion: v1
    kind: Service
    metadata:
      name: mixed-protocol-external-lb
    spec:
      loadBalancerClass: "networking.gke.io/l4-regional-external"
      type: LoadBalancer
      selector:
        app: mixed-app
      ports:
      - name: tcp-port
        protocol: TCP
        port: 8080
      - name: udp-port
        protocol: UDP
        port: 8080
    

    Pour créer un équilibreur de charge interne, définissez la valeur du champ spec.loadBalancerClass sur networking.gke.io/l4-regional-internal.

    Le service précédent comporte deux ports, un pour TCP et un pour UDP, tous deux sur le port 8080.

  2. Appliquez le fichier manifeste à votre cluster :

    kubectl apply --server-side -f mixed-protocol-lb.yaml
    

Vérifier l'équilibreur de charge à protocole mixte

Une fois le service créé, vérifiez que GKE a créé l'équilibreur de charge.

  1. Inspectez le service :

    kubectl describe service SERVICE_NAME
    

    Remplacez SERVICE_NAME par le nom de votre service (par exemple, mixed-protocol-lb).

    Le résultat affiche l'adresse IP de l'équilibreur de charge et les règles de transfert. Vérifiez les détails suivants dans le résultat :

    • Le champ status.loadBalancer.ingress.ip est renseigné.
    • Pour les clusters des versions 1.34.1-gke.2190000 à 1.36.2-gke.1498000, vérifiez que les annotations suivantes de votre équilibreur de charge externe sont présentes :
      • service.kubernetes.io/tcp-forwarding-rule
      • service.kubernetes.io/udp-forwarding-rule
    • Pour les clusters créés sur des versions ultérieures à 1.36.2-gke.1498000, vérifiez que les annotations suivantes de votre équilibreur de charge sont présentes, en fonction de votre configuration :
      • Pour IPv4 : service.kubernetes.io/l3-forwarding-rule
      • Pour IPv6 : service.kubernetes.io/l3-forwarding-rule-ipv6
      • Pour la double pile : les deux annotations.
    • La section Events ne contient aucun message d'erreur.

Mettre à jour l'équilibreur de charge à protocole mixte

Vous pouvez mettre à jour les ports d'un équilibreur de charge à protocole mixte en modifiant le fichier manifeste du service. Pour modifier le service, exécutez la commande suivante :

kubectl edit service SERVICE_NAME

Remplacez SERVICE_NAME par le nom de votre service.

Mettre à jour les ports

Pour mettre à jour les ports d'un équilibreur de charge à protocole mixte, modifiez la section ports du fichier manifeste du service. Vous pouvez ajouter, supprimer ou modifier des ports.

L'exemple suivant ajoute un port UDP pour la diffusion en streaming et un port TCP pour les métadonnées du serveur de jeu :

apiVersion: v1
kind: Service
metadata:
  name: mixed-protocol-lb
spec:
  loadBalancerClass: "networking.gke.io/l4-regional-external"  # for internal LB, use: "networking.gke.io/l4-regional-internal"
  type: LoadBalancer
  selector:
    app: mixed-app
  ports:
  - name: tcp-port
    protocol: TCP
    port: 8080
  - name: streaming
    protocol: UDP
    port: 10100
  - name: gameserver-metadata
    protocol: TCP
    port: 10400
  - name: https
    protocol: TCP
    port: 443

Mettre à jour un équilibreur de charge à protocole unique vers un protocole mixte

Pour remplacer un équilibreur de charge à protocole unique par un équilibreur de charge à protocole mixte, modifiez le service afin d'inclure des ports pour les protocoles TCP et UDP.

L'exemple suivant ajoute un port UDP pour le DNS à un équilibreur de charge existant réservé à TCP :

apiVersion: v1
kind: Service
metadata:
  name: already-existing-single-protocol-lb
spec:
  loadBalancerClass: "networking.gke.io/l4-regional-external" # for internal LB, use: "networking.gke.io/l4-regional-internal"
  type: LoadBalancer
  selector:
    app: mixed-app
  ports:
  - name: http
    protocol: TCP
    port: 80
  - name: https
    protocol: TCP
    port: 443
  - name: dns
    protocol: UDP
    port: 53

Mettre à jour un équilibreur de charge à protocole mixte vers un protocole unique

Pour remplacer un équilibreur de charge à protocole mixte par un équilibreur de charge à protocole unique, supprimez tous les ports de l'un des protocoles.

L'exemple suivant supprime le port UDP pour le DNS, ce qui convertit l'équilibreur de charge en TCP uniquement :

apiVersion: v1
kind: Service
metadata:
  name: already-existing-mixed-protocol-lb
spec:
  loadBalancerClass: "networking.gke.io/l4-regional-external" # for internal LB, use: "networking.gke.io/l4-regional-internal"
  type: LoadBalancer
  selector:
    app: mixed-app
  ports:
  - name: http
    protocol: TCP
    port: 80
  - name: https
    protocol: TCP
    port: 443

Supprimer le LoadBalancer à protocole mixte

Pour supprimer le service LoadBalancer à protocole mixte, exécutez la commande suivante :

kubectl delete service SERVICE_NAME

Remplacez SERVICE_NAME par le nom de votre service (par exemple, mixed-protocol-external-lb).

GKE supprime automatiquement toutes les ressources d'équilibreur de charge créées pour le service.

Dépannage

Cette section explique comment résoudre les problèmes courants liés aux services LoadBalancer à protocole mixte.

Rechercher les événements d'erreur

La première étape du dépannage consiste à vérifier les événements associés à votre service.

  1. Obtenez les détails de votre service :

    kubectl describe service SERVICE_NAME
    

    Remplacez SERVICE_NAME par le nom de votre service.

  2. Examinez la section Events à la fin du résultat pour détecter les éventuels messages d'erreur.

Erreur : Le protocole mixte n'est pas compatible avec LoadBalancer

Si vous avez créé le service avec l'cloud.google.com/l4-rbs: "enabled" annotation, vous verrez peut-être un événement d'avertissement du contrôleur de service d'origine après avoir créé l'équilibreur de charge à protocole mixte : mixed-protocol is not supported for LoadBalancer.

Vous pouvez ignorer ce message, car le nouveau contrôleur, qui est compatible avec les protocoles mixtes, provisionne correctement l'équilibreur de charge.

La définition du port est manquante après une mise à jour

Symptôme :

Lorsque vous mettez à jour un service qui utilise le même port pour TCP et UDP (par exemple, le port 8080), l'une des définitions de port est manquante dans le service mis à jour.

Cause:

Il s'agit d'un problème connu dans Kubernetes. Lorsque vous mettez à jour un service avec plusieurs protocoles sur le même port, le calcul du correctif côté client peut fusionner incorrectement la liste des ports, ce qui entraîne la suppression de l'une des définitions de port. Ce problème affecte les clients qui utilisent l'application de correctifs côté client, tels que kubectl apply et le client Go avec des correctifs de fusion.

Solution:

La solution de contournement de ce problème dépend de votre client.

  • Pour kubectl : utilisez l'option --server-side avec kubectl apply :

    kubectl apply --server-side -f YOUR_SERVICE_MANIFEST.yaml
    

    Remplacez YOUR_SERVICE_MANIFEST par le nom de votre fichier manifeste de service.

  • Pour go-client : n'utilisez pas de correctifs de fusion. Utilisez plutôt un appel de mise à jour pour remplacer le service. Cela nécessite une requête HTTP PUT avec la spécification complète de l'objet Service.

Étape suivante