Créer un équilibreur de charge interne

Cette page explique comment déployer un service LoadBalancer interne qui crée un équilibreur de charge réseau passthrough interne. Avant de lire cette page, assurez-vous de connaître les éléments suivants :

• À propos des services LoadBalancer
• Paramètres du service GKE LoadBalancer

Pour en savoir plus sur les équilibreurs de charge réseau passthrough internes en général, consultez la présentation de l'équilibreur de charge réseau passthrough interne.

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 la Google Cloud CLI pour cette tâche, installez et initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. 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

• Ce tutoriel utilise spec.loadBalancerClass pour créer un équilibreur de charge réseau passthrough interne avec des backends de NEG GCE_VM_IP. Ce tutoriel nécessite la version 1.33.1-gke.1779000 de GKE ou une version ultérieure, car spec.loadBalancerClass nécessite la version 1.33.1-gke.1779000 de GKE ou une version ultérieure.

• L'affinité zonale nécessite GKE version 1.33.3-gke.1392000 ou ultérieure.

• Le sous-paramètre GKE doit être activé sur votre cluster :

  • Le sous-paramètre GKE est activé par défaut dans les clusters exécutant la version 1.36 ou ultérieure. Pour ces versions, la création de sous-ensembles est active, quelle que soit la valeur du flag de sous-ensemble du cluster.

  • Dans les versions de GKE compatibles antérieures à la version 1.36, vous devez activer explicitement le sous-paramètre GKE. Vous pouvez activer le sous-paramètre GKE lorsque vous créez un cluster ou en mettant à jour un cluster existant. Une fois activé, le sous-paramètre GKE ne peut pas être désactivé. Pour en savoir plus, consultez Vérifier et activer le sous-ensemble GKE.

• Si votre cluster utilise une version antérieure à la version 1.36, le module complémentaire HttpLoadBalancing doit être activé dans votre cluster. Ce module complémentaire est activé par défaut.

Vérifier et activer le sous-paramètre GKE

Assurez-vous que le sous-paramètre GKE est activé :

• Le sous-paramètre GKE est toujours activé dans GKE 1.36 et versions ultérieures.

• Vous pouvez activer manuellement le sous-paramètre GKE dans les clusters Standard et Autopilot nouveaux et existants qui exécutent GKE version 1.18.19-gke.1400 ou ultérieure, mais avant la version 1.36 de GKE. Vous ne pouvez pas désactiver le sous-paramètre GKE après l'avoir activé.

Pour comprendre pourquoi le sous-paramètre GKE est important, consultez Considérations spéciales pour les services LoadBalancer internes.

Pour déterminer si le sous-ensemble GKE est activé, exécutez la commande suivante :

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="get(currentMasterVersion, networkConfig.enableL4ilbSubsetting)"

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster.
• LOCATION  : zone ou région du cluster.

Le résultat de la commande affiche la version du plan de contrôle du cluster, suivie de True ou False pour l'attribut networkConfig.enableL4ilbSubsetting. Interprétez le résultat comme suit :

• Si la version du plan de contrôle est 1.36 ou ultérieure, le sous-ensemble GKE est activé, que l'attribut networkConfig.enableL4ilbSubsetting soit défini sur True ou False.
• Si la version du plan de contrôle est antérieure à 1.36 :
  • True signifie que le sous-paramètre GKE est activé.
  • False signifie que le sous-paramètre GKE est désactivé.

Pour activer le sous-paramètre GKE dans un cluster qui exécute la version 1.18.19-gke.1400 ou ultérieure de GKE, mais avant la version 1.36 de GKE, utilisez la gcloud CLI ou la console Cloud de Confiance .

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION
    --enable-l4-ilb-subsetting

L'activation du sous-paramètre GKE (à l'aide de gcloud CLI, de la consoleCloud de Confiance ou en mettant à niveau votre cluster vers la version 1.36 ou ultérieure) ne modifie pas les services LoadBalancer internes existants. Si vous souhaitez migrer un service LoadBalancer interne existant pour utiliser des backends NEG GCE_VM_IP, vous devez déployer un fichier manifeste de service de remplacement.

Déployer une charge de travail

Le fichier manifeste suivant décrit un déploiement qui exécute un exemple d'image de conteneur d'application Web.

1. Enregistrez le fichier manifeste sous le nom ilb-deployment.yaml :

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: ilb-deployment
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: ilb-deployment
     template:
       metadata:
         labels:
           app: ilb-deployment
       spec:
         containers:
         - name: hello-app
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   

2. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f ilb-deployment.yaml
   

Créer un service LoadBalancer interne

1. (Facultatif) Désactivez la création automatique de règles de pare-feu VPC :

   Bien que GKE crée automatiquement des règles de pare-feu VPC pour autoriser le trafic vers votre équilibreur de charge interne, vous pouvez désactiver la création automatique de règles de pare-feu VPC et gérer vous-même les règles de pare-feu. Vous ne pouvez désactiver les règles de pare-feu VPC que si vous avez activé le sous-paramètre GKE pour votre service LoadBalancer interne. Toutefois, la gestion des règles de pare-feu VPC est facultative. Vous pouvez vous appuyer sur les règles automatiques.

   Avant de désactiver la création automatique de règles de pare-feu VPC, assurez-vous de définir des règles d'autorisation qui permettent au trafic d'atteindre votre équilibreur de charge et vos pods d'application.

   Pour en savoir plus sur la gestion des règles de pare-feu VPC, consultez Gérer la création automatique de règles de pare-feu. Pour savoir comment désactiver la création automatique de règles de pare-feu, consultez Règles de pare-feu gérées par l'utilisateur pour les services LoadBalancer GKE.

2. L'exemple suivant crée un service LoadBalancer interne à l'aide du port TCP 80. GKE déploie un équilibreur de charge réseau passthrough interne dont la règle de transfert utilise le port 80, mais transfère ensuite le trafic aux pods de backend sur le port 8080 :

   1. Enregistrez le fichier manifeste sous le nom ilb-svc.yaml :

      apiVersion: v1
      kind: Service
      metadata:
        name: ilb-svc
      spec:
        type: LoadBalancer
        # Request an internal load balancer.
        loadBalancerClass: networking.gke.io/l4-regional-internal
        # Evenly route external traffic to all endpoints.
        externalTrafficPolicy: Cluster
        # Prioritize routing traffic to endpoints that are in the same zone.
        trafficDistribution: PreferClose
        selector:
          app: ilb-deployment
        # Forward traffic from TCP port 80 to port 8080 in backend Pods.
        ports:
        - name: tcp-port
          protocol: TCP
          port: 80
          targetPort: 8080
      

      Le fichier manifeste doit contenir les éléments suivants :

      • Un nom (name) pour le service LoadBalancer interne, dans ce cas ilb-svc.
      • Le champ spec.loadBalancerClass est défini sur la valeur networking.gke.io/l4-regional-internal pour spécifier un service LoadBalancer interne, comme indiqué dans l'exemple de fichier manifeste.
      • type: LoadBalancer
      • Un champ spec: selector, afin de spécifier les pods que l'objet Service doit cibler, par exemple app: hello
      • Des informations sur les ports :
        • port représente le port de destination sur lequel la règle de transfert de l'équilibreur de charge réseau passthrough interne reçoit des paquets.
        • targetPort doit correspondre à un containerPort défini sur chaque pod de diffusion.
        • Les valeurs de port et de targetPort n'ont pas besoin d'être identiques. Les nœuds effectuent toujours la NAT de destination, en remplaçant l'adresse IP et le port de la règle de transfert de l'équilibreur de charge de destination par une adresse IP un targetPort de pod de destination. Pour en savoir plus, consultez la section Traduction d'adresse réseau de destination sur les nœuds dans la documentation sur les concepts du service LoadBalancer.

      Le fichier manifeste peut contenir les éléments suivants :

      • spec.ipFamilyPolicy et ipFamilies pour définir la façon dont GKE alloue les adresses IP au service. GKE est compatible avec les services LoadBalancer à pile unique (IPv4 seulement ou IPv6 seulement) ou à double pile. Un service LoadBalancer à double pile est mis en œuvre avec deux règles de transfert d'équilibreur de charge réseau passthrough interne distinctes : une pour le trafic IPv4 et une pour le trafic IPv6. Le service LoadBalancer à double pile GKE est disponible dans la version 1.29 ou ultérieure. Pour en savoir plus, consultez Services IPv4/IPv6 à double pile.

      • spec.trafficDistribution (preview) pour définir la manière dont GKE achemine le trafic entrant. Pour activer l'affinité zonale, définissez la valeur de ce champ sur PreferSameZone. L'affinité zonale signifie que GKE donne la priorité au routage du trafic provenant d'une zone vers les nœuds et les pods de cette même zone. Si aucun pod opérationnel n'est disponible dans cette zone, le trafic est acheminé vers une autre zone. Pour les versions de cluster antérieures à 1.35.0-gke.1811000, utilisez plutôt PreferClose. L'affinité zonale nécessite l'activation du sous-paramètre GKE.

      Pour en savoir plus, consultez Paramètres du service LoadBalancer.

   2. Appliquez le fichier manifeste à votre cluster :

      kubectl apply -f ilb-svc.yaml
      

3. Pour obtenir des informations détaillées sur l'objet Service, exécutez la commande suivante :

   kubectl get service ilb-svc --output yaml
   

   Le résultat ressemble à ce qui suit :

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       cloud.google.com/neg: '{"ingress":true}'
       cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}'
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}}
       networking.gke.io/load-balancer-type: Internal
       service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
       service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
       service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw
       service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc
       service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r
     creationTimestamp: "2022-07-22T17:26:04Z"
     finalizers:
     - gke.networking.io/l4-ilb-v2
     - service.kubernetes.io/load-balancer-cleanup
     name: ilb-svc
     namespace: default
     resourceVersion: "51666"
     uid: d7a1a865-7972-44e1-aa9e-db5be23d6567
   spec:
     allocateLoadBalancerNodePorts: true
     clusterIP: 10.88.2.141
     clusterIPs:
     - 10.88.2.141
     externalTrafficPolicy: Cluster
     internalTrafficPolicy: Cluster
     ipFamilies:
     - IPv4
     ipFamilyPolicy: SingleStack
     ports:
     - name: tcp-port
       # Kubernetes automatically allocates a port on the node during the
       # process of implementing a Service of type LoadBalancer.
       nodePort: 30521
       port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       app: ilb-deployment
     sessionAffinity: None
     trafficDistribution: PreferSameZone
     type: LoadBalancer
   status:
     # IP address of the load balancer forwarding rule.
     loadBalancer:
       ingress:
       - ip: 10.128.15.245
   

   Le résultat possède les attributs suivants :

   • L'adresse IP de la règle de transfert de l'équilibreur de charge réseau passthrough interne est incluse dans status.loadBalancer.ingress. Cette adresse IP est différente de la valeur de clusterIP. Dans cet exemple, l'adresse IP de la règle de transfert de l'équilibreur de charge est 10.128.15.245.
   • Tous les pods comportant le libellé app: ilb-deployment sont des pods de diffusion pour ce service. Il s'agit des pods qui reçoivent les paquets acheminés par l'équilibreur de charge réseau passthrough interne.
   • Les clients appellent le service à l'aide de l'adresse IP loadBalancer et du port TCP spécifié dans le champ port du fichier manifeste du service. Pour en savoir plus sur la manière dont les paquets sont acheminés une fois reçus par un nœud, consultez la section Traitement des paquets.
   • GKE a attribué un nodePort au service. Dans cet exemple, le port 30521 est attribué. Le nodePort n'est pas pertinent pour l'équilibreur de charge réseau passthrough interne.

4. Inspectez le groupe de points de terminaison du réseau du Service :

   kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
   

   Le résultat ressemble à ce qui suit :

   {"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["ZONE_NAME"]}
   

   La réponse indique que GKE a créé un groupe de points de terminaison du réseau nommé k8s2-knlc4c77-default-ilb-svc-ua5ugas0. Cette annotation est présente dans les services de type LoadBalancer qui utilisent un sous-paramètre GKE et ne figure pas dans les services qui n'utilisent pas de sous-paramètre GKE.

Vérifier les composants de l'équilibreur de charge réseau passthrough interne

Cette section vous explique comment vérifier les composants clés de votre équilibreur de charge réseau passthrough interne.

• Vérifiez que votre Service est en cours d'exécution :

  kubectl get service SERVICE_NAME --output yaml
  

  Remplacez SERVICE_NAME par le nom du fichier manifeste du service.

  Si vous avez activé l'affinité zonale, le résultat inclut le paramètre spec.trafficDistribution. La valeur de ce champ est définie sur PreferSameZone ou PreferClose si la version du cluster est antérieure à 1.35.0-gke.1811000.

• Vérifiez l'adresse IP de la règle de transfert de l'équilibreur de charge réseau passthrough interne. L'adresse IP de la règle de transfert de l'équilibreur de charge réseau passthrough interne est 10.128.15.245 dans l'exemple inclus dans la section Créer un service LoadBalancer interne. Vérifiez que cette règle de transfert est incluse dans la liste des règles de transfert du projet du cluster à l'aide de Google Cloud CLI :

  gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"
  

  La sortie inclut la règle de transfert d'équilibreur de charge réseau passthrough interne appropriée, son adresse IP et le service de backend référencé par la règle de transfert (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r dans cet exemple).

  NAME                          ... IP_ADDRESS  ... TARGET
  ...
  k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r   10.128.15.245   ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
  

• Décrivez le service de backend de l'équilibreur de charge à l'aide de Google Cloud CLI :

  gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION
  

  Remplacez COMPUTE_REGION par la région Compute Engine du service de backend.

  Si vous avez activé l'affinité zonale :

  • Le champ networkPassThroughLbTrafficPolicy.zonalAffinity.spillover doit être défini sur la valeur ZONAL_AFFINITY_SPILL_CROSS_ZONE.
  • Le champ networkPassThroughLbTrafficPolicy.zonalAffinity.spilloverRatio doit être défini sur 0 ou ne pas être inclus.

  La sortie inclut le ou les NEG GCE_VM_IP de backend pour le service (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r dans cet exemple).

  backends:
  - balancingMode: CONNECTION
    group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
  ...
  kind: compute#backendService
  loadBalancingScheme: INTERNAL
  name: aae3e263abe0911e9b32a42010a80008
  networkPassThroughLbTrafficPolicy:
    zonalAffinity:
      spillover: ZONAL_AFFINITY_SPILL_CROSS_ZONE
  protocol: TCP
  ...
  

  Si vous avez désactivé l'affinité zonale, le champ networkPassThroughLbTrafficPolicy.zonalAffinity.spillover doit être défini sur ZONAL_AFFINITY_DISABLED ou ne pas être inclus. Notez que l'affinité zonale est automatiquement désactivée si votre cluster utilise une version antérieure à 1.33.3-gke.1392000.

• Déterminez la liste des nœuds d'un sous-ensemble d'un service :

  gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
      --zone=COMPUTE_ZONE
  

  Remplacez les éléments suivants :

  • NEG_NAME : nom du groupe de points de terminaison du réseau créé par le contrôleur GKE.
  • COMPUTE_ZONE : zone de calcul du groupe de points de terminaison du réseau à utiliser.

• Déterminez la liste des nœuds sains pour un équilibreur de charge réseau passthrough interne :

  gcloud compute backend-services get-health SERVICE_NAME \
      --region=COMPUTE_REGION
  

  Remplacez les éléments suivants :

  • SERVICE_NAME : nom du service de backend. Cette valeur est identique au nom du groupe de points de terminaison du réseau créé par le contrôleur GKE.
  • COMPUTE_REGION : région de calcul du service de backend à utiliser.

Tester la connectivité à l'équilibreur de charge réseau passthrough interne

Exécutez la commande suivante dans la même région que le cluster :

curl LOAD_BALANCER_IP:80

Remplacez LOAD_BALANCER_IP par l'adresse IP de la règle de transfert de l'équilibreur de charge.

La réponse affiche le résultat de ilb-deployment :

Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n

L'équilibreur de charge réseau passthrough interne n'est accessible qu'au sein du même réseau VPC (ou d'un réseau connecté). Par défaut, l'accès mondial est désactivé pour la règle de transfert de l'équilibreur de charge. Par conséquent, les VM clientes, les tunnels Cloud VPN ou les rattachements Cloud Interconnect (VLAN) doivent être situés dans la même région que l'équilibreur de charge réseau passthrough interne. Pour accepter les clients de toutes les régions, vous pouvez activer l'accès mondial sur la règle de transfert de l'équilibreur de charge en incluant l'annotation d'accès mondial dans le fichier manifeste du service.

Supprimer le service LoadBalancer interne et les ressources de l'équilibreur de charge

Vous pouvez supprimer les objets Deployment et Service à l'aide de kubectl delete ou de la consoleCloud de Confiance .

kubectl delete deployment ilb-deployment

kubectl delete service ilb-svc

Adresse IP partagée

L'équilibreur de charge réseau passthrough interne permet le partage d'une adresse IP virtuelle entre plusieurs règles de transfert. Cela permet d'augmenter le nombre de ports simultanés sur la même adresse IP ou d'accepter le trafic UDP et TCP sur la même adresse IP. Elle autorise jusqu'à 50 ports exposés par adresse IP. Les adresses IP partagées sont compatibles de manière native sur les clusters GKE avec des services LoadBalancer internes. Lors du déploiement, le champ loadBalancerIP du service indique l'adresse IP à partager entre les services.

Limites

Une adresse IP partagée pour plusieurs équilibreurs de charge présente les limitations et les capacités suivantes :

• Chaque règle de transfert peut comporter jusqu'à cinq ports (contigus ou non contigus) ou être configurée pour correspondre au trafic sur tous les ports et le transférer. Si un service LoadBalancer interne définit plus de cinq ports, la règle de transfert sera automatiquement configurée pour correspondre à tous les ports.
• Un maximum de dix services (règles de transfert) peuvent partager une adresse IP. Cela entraîne un maximum de 50 ports par adresse IP partagée.
• Chaque règle de transfert qui partage la même adresse IP doit utiliser une combinaison unique de protocoles et de ports. Par conséquent, chaque service LoadBalancer interne doit utiliser un ensemble unique de protocoles et de ports.
• Une combinaison de services TCP uniquement et UDP uniquement est prise en charge sur la même adresse IP partagée. Cependant, vous ne pouvez pas exposer les ports TCP et UDP dans le même service.

Activer l'adresse IP partagée

Pour permettre à un service LoadBalancer interne d'utiliser une adresse IP commune, procédez comme suit :

1. Créez une adresse IP interne statique avec --purpose SHARED_LOADBALANCER_VIP. Une adresse IP doit être créée dans ce but afin d'en permettre le partage. Si vous créez l'adresse IP interne statique dans un VPC partagé, vous devez créer l'adresse IP dans le même projet de service que l'instance qui utilisera l'adresse IP, même si la valeur de l'adresse IP proviendra de la plage d'adresses IP disponibles dans un sous-réseau partagé sélectionné du réseau VPC partagé. Pour en savoir plus, reportez-vous à la section Réserver une adresse IP interne statique de la page Provisionner un VPC partagé.

2. Déployez jusqu'à dix services LoadBalancer internes à l'aide de cette adresse IP statique dans le champ loadBalancerIP. Les équilibreurs de charge réseau passthrough internes sont rapprochés par le contrôleur de service GKE et déployés à l'aide de la même adresse IP d'interface.

L'exemple suivant montre comment effectuer cette opération pour prendre en charge plusieurs ports TCP et UDP avec la même adresse IP d'équilibreur de charge interne.

1. Créez une adresse IP statique dans la même région que votre cluster GKE. Le sous-réseau doit être le même que celui utilisé par l'équilibreur de charge, qui est par défaut le même que celui utilisé par les adresses IP des nœuds du cluster GKE.

   Si votre cluster et le réseau VPC se trouvent dans le même projet :

   gcloud compute addresses create IP_ADDR_NAME \
       --project=PROJECT_ID \
       --subnet=SUBNET \
       --addresses=IP_ADDRESS \
       --region=COMPUTE_REGION \
       --purpose=SHARED_LOADBALANCER_VIP
   

   Si votre cluster se trouve dans un projet de service VPC partagé, mais utilise un réseau VPC partagé dans un projet hôte :

   gcloud compute addresses create IP_ADDR_NAME \
       --project=SERVICE_PROJECT_ID \
       --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET \
       --addresses=IP_ADDRESS \
       --region=COMPUTE_REGION \
       --purpose=SHARED_LOADBALANCER_VIP
   

   Remplacez l'élément suivant :

   • IP_ADDR_NAME : nom de l'objet d'adresse IP.
   • SERVICE_PROJECT_ID : ID du projet de service.
   • PROJECT_ID : ID de votre projet (un seul projet).
   • HOST_PROJECT_ID : ID du projet hôte de VPC partagé.
   • COMPUTE_REGION : région de calcul contenant le sous-réseau partagé.
   • IP_ADDRESS : adresse IP interne non utilisée de la plage d'adresses IP principale du sous-réseau sélectionné. Si vous ne spécifiez pas d'adresse IP, Cloud de Confiance sélectionne une adresse IP interne inutilisée dans la plage d'adresses IP principale du sous-réseau sélectionné. Pour déterminer une adresse sélectionnée automatiquement, vous devez exécuter gcloud compute addresses describe.
   • SUBNET : nom du sous-réseau partagé.

2. Enregistrez la configuration de service TCP suivante dans un fichier nommé tcp-service.yaml, puis déployez-la sur votre cluster. Remplacez IP_ADDRESS par l'adresse IP que vous avez choisie à l'étape précédente.

   apiVersion: v1
   kind: Service
   metadata:
     name: tcp-service
     namespace: default
   spec:
     type: LoadBalancer
     # Request an internal load balancer.
     loadBalancerClass: networking.gke.io/l4-regional-internal
     # Use an IP address that you create.
     loadBalancerIP: IP_ADDRESS
     selector:
       app: myapp
     ports:
     - name: 8001-to-8001
       protocol: TCP
       port: 8001
       targetPort: 8001
     - name: 8002-to-8002
       protocol: TCP
       port: 8002
       targetPort: 8002
     - name: 8003-to-8003
       protocol: TCP
       port: 8003
       targetPort: 8003
     - name: 8004-to-8004
       protocol: TCP
       port: 8004
       targetPort: 8004
     - name: 8005-to-8005
       protocol: TCP
       port: 8005
       targetPort: 8005
   

3. Appliquez la définition de service suivante à votre cluster :

   kubectl apply -f tcp-service.yaml
   

4. Enregistrez la configuration de service UDP suivante dans un fichier nommé udp-service.yaml, puis déployez-la. Elle utilise également l'IP_ADDRESS que vous avez spécifiée à l'étape précédente.

   apiVersion: v1
   kind: Service
   metadata:
     name: udp-service
     namespace: default
   spec:
     type: LoadBalancer
     # Request an internal load balancer.
     loadBalancerClass: networking.gke.io/l4-regional-internal
     # Use the same IP address that you used for the TCP Service.
     loadBalancerIP: IP_ADDRESS
     selector:
       app: my-udp-app
     ports:
     - name: 9001-to-9001
       protocol: UDP
       port: 9001
       targetPort: 9001
     - name: 9002-to-9002
       protocol: UDP
       port: 9002
       targetPort: 9002
   

5. Appliquez ce fichier à votre cluster :

   kubectl apply -f udp-service.yaml
   

6. Vérifiez que l'adresse IP virtuelle est partagée entre les règles de transfert de l'équilibreur de charge en les répertoriant et en filtrant l'adresse IP statique. Cela montre qu'il existe une règle de transfert UDP et TCP, qui écoute sur sept ports différents sur l'IP_ADDRESS partagée, qui dans cet exemple est 10.128.2.98.

   gcloud compute forwarding-rules list | grep 10.128.2.98
   ab4d8205d655f4353a5cff5b224a0dde                         us-west1   10.128.2.98     UDP          us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde
   acd6eeaa00a35419c9530caeb6540435                         us-west1   10.128.2.98     TCP          us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435
   

Problèmes connus

Erreur lors de la création de l'équilibreur de charge au niveau Standard

Lorsque vous créez un équilibreur de charge réseau passthrough interne dans un projet avec le niveau de réseau par défaut du projet défini sur Standard, le message d'erreur suivant s'affiche :

Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest

Pour résoudre ce problème dans les versions de GKE antérieures à la version 1.23.3-gke.900, configurez le niveau de réseau par défaut du projet sur Premium.

Ce problème est résolu dans les versions 1.23.3-gke.900 et ultérieures de GKE lorsque le sous-ensemble GKE est activé.

Le contrôleur GKE crée des équilibreurs de charge réseau passthrough internes dans le niveau de réseau Premium même si le niveau de réseau par défaut du projet est défini sur Standard.

Étapes suivantes

• Lisez la présentation du réseau GKE.
• Obtenez plus d'informations sur les équilibreurs de charge Compute Engine.
• Apprenez à créer un cluster de VPC natif.
• Résoudre les problèmes liés à l'équilibrage de charge dans GKE.
• Obtenez plus d'informations sur l'agent de masquage d'adresses IP.
• Familiarisez-vous avec la configuration des réseaux autorisés.