Créer un équilibreur de charge interne

Autopilot Standard

---

Cette page explique comment créer un équilibreur de charge réseau passthrough interne ou un équilibreur de charge interne sur Google Kubernetes Engine (GKE). Pour créer un équilibreur de charge réseau externe à stratégie directe, découvrez comment Créer un service de type LoadBalancer.

• Service LoadBalancer.
• Paramètres du service LoadBalancer
• Équilibreur de charge réseau externe à stratégie directe basé sur un service de backend.

Utiliser le sous-paramètre de l'équilibreur de charge réseau interne à stratégie directe

Les équilibreurs de charge réseau internes à stratégie directe rendent les services de votre cluster accessibles aux clients du réseau VPC de votre cluster et aux clients des réseaux connectés au réseau VPC de votre cluster. Les clients ne doivent pas nécessairement être situés dans votre cluster. Par exemple, un service LoadBalancer interne peut être accessible aux instances de machine virtuelle (VM) situées dans le réseau VPC du cluster.

Utiliser le sous-paramètre GKE

Le sous-paramètre GKE améliore l'évolutivité des services LoadBalancer internes, car il utilise des groupes de points de terminaison du réseau (NEG) GCE_VM_IP au lieu de groupes d'instances. Lorsque le sous-paramètre GKE est activé, GKE crée un NEG par zone de calcul et par service LoadBalancer interne. Les points de terminaison membres du NEG sont les adresses IP des nœuds qui possèdent au moins un des pods de diffusion du service. Pour en savoir plus sur le sous-paramètre GKE, consultez la section Regroupement de nœuds.

Conditions requises et limites

Le sous-paramètre GKE présente les exigences et limitations suivantes :

• Vous pouvez activer le sous-paramètre GKE dans les clusters nouveaux et existants dans les versions 1.18.19-gke.1400 et ultérieures de GKE. Le sous-paramètre GKE ne peut pas être désactivé une fois qu'il a été activé.

• Le sous-paramètre GKE est désactivé dans les clusters Autopilot.
• Le sous-paramètre GKE nécessite que le module complémentaire HttpLoadBalancing soit activé. Ce module complémentaire est activé par défaut. Dans les clusters Autopilot, vous ne pouvez pas désactiver ce module complémentaire requis.
• Les quotas des groupes de points de terminaison du réseau s'appliquent. Google Cloud crée un NEG GCE_VM_IP par service LoadBalancer interne par zone.
• Les quotas pour les règles de transfert, les services de backend et les vérifications d'état s'appliquent. Pour en savoir plus, consultez la page Quotas et limites.
• Le sous-paramètre GKE ne peut pas être utilisé avec l'annotation pour partager un service de backend entre plusieurs équilibreurs de charge alpha.cloud.google.com/load-balancer-backend-share.
• Vous devez disposer de la version 345.0.0 ou d'une version ultérieure de Google Cloud CLI.

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 gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
  Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Activer le sous-paramètre GKE dans un nouveau cluster Standard

Vous pouvez créer un cluster Standard avec le sous-paramètre GKE activé à l'aide de Google Cloud CLI, de la console Google Cloud ou de Terraform. Un cluster créé avec le sous-paramètre GKE activé utilise toujours le sous-paramètre GKE.

Console

1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

   Accéder à Google Kubernetes Engine

2. Cliquez sur Créer.

3. Configurez le cluster selon vos besoins.

4. Dans le volet de navigation, sous Cluster, cliquez sur Réseau.

5. Cochez la case Activer le sous-paramètre pour les équilibreurs de charge internes L4.

6. Cliquez sur Créer.

gcloud

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-l4-ilb-subsetting \
    --location=COMPUTE_LOCATION

Remplacez l'élément suivant :

• CLUSTER_NAME : nom du nouveau cluster
• VERSION : version de GKE, qui doit être 1.18.19-gke.1400 ou ultérieure. Vous pouvez également utiliser l'option --release-channel pour sélectionner une version disponible. La version disponible doit correspondre à la version 1.18.19-gke.1400 ou ultérieure par défaut.
• COMPUTE_LOCATION : emplacement Compute Engine du cluster.

Si vous souhaitez utiliser un réseau ou un sous-réseau autre que celui par défaut, exécutez la commande suivante :

  gcloud container clusters create CLUSTER_NAME \
      --cluster-version=VERSION \
      --network NETWORK_NAME \
      --subnetwork SUBNETWORK_NAME \
      --enable-l4-ilb-subsetting \
      --location=COMPUTE_LOCATION

Remplacez les éléments suivants :

• SUBNET_NAME : nom du nouveau sous-réseau. Dans les versions 1.22.4-gke.100 et ultérieures de GKE, vous pouvez spécifier un sous-réseau dans un autre projet en utilisant l'URL complète de la ressource pour ce champ. Vous pouvez obtenir l'URL complète de la ressource à l'aide de la commande gcloud compute networks subnets describe.
• NETWORK_NAME : nom du réseau VPC utilisé pour le sous-réseau.

Terraform

Pour créer un cluster standard avec le sous-paramètre GKE activé à l'aide de Terraform, reportez-vous à l'exemple suivant :

resource "google_container_cluster" "default" {
  name               = "gke-standard-regional-cluster"
  location           = "us-central1"
  initial_node_count = 1

  enable_l4_ilb_subsetting = true

  # Set `deletion_protection` to `true` will ensure that one cannot
  # accidentally delete this instance by use of Terraform.
  deletion_protection = false
}

Pour en savoir plus sur l'utilisation de Terraform, consultez la page Compatibilité de Terraform avec GKE.

Activer le sous-paramètre GKE dans un cluster Standard existant

Vous pouvez activer le sous-paramètre GKE pour un cluster Standard existant à l'aide de gcloud CLI ou de la console Google Cloud. Vous ne pouvez pas désactiver le sous-paramètre GKE après l'avoir activé.

Console

1. Dans Google Cloud Console, accédez à la page Google Kubernetes Engine.

   Accéder à Google Kubernetes Engine

2. Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.

3. Sous Mise en réseau, à côté du champ Sous-paramètre pour les équilibreurs de charge internes L4, cliquez sur Activer le sous-paramètre pour les équilibreurs de charge internes L4.

4. Cochez la case Activer le sous-paramètre pour les équilibreurs de charge internes L4.

5. Cliquez sur Save Changes (Enregistrer les modifications).

gcloud

gcloud container clusters update CLUSTER_NAME \
    --enable-l4-ilb-subsetting

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster.

L'activation du sous-paramètre GKE n'interrompt pas les services LoadBalancer internes existants. Si vous souhaitez migrer des services LoadBalancer internes existants pour utiliser des services de backend avec des NEG GCE_VM_IP en tant que backends, vous devez déployer un fichier manifeste de service de remplacement. Pour en savoir plus, consultez la section Regroupement de nœuds dans la documentation sur les concepts du service LoadBalancer.

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 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

L'exemple suivant crée un service LoadBalancer interne à l'aide du port TCP 80. GKE déploie un équilibreur de charge réseau interne à stratégie directe 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 manifeste sous le nom ilb-svc.yaml :

   apiVersion: v1
   kind: Service
   metadata:
     name: ilb-svc
     annotations:
       networking.gke.io/load-balancer-type: "Internal"
   spec:
     type: LoadBalancer
     externalTrafficPolicy: Cluster
     selector:
       app: ilb-deployment
     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.
   • Une annotation indiquant que vous avez besoin d'un service LoadBalancer interne. Pour GKE versions 1.17 et ultérieures, utilisez l'annotation networking.gke.io/load-balancer-type: "Internal" comme indiqué dans l'exemple de fichier manifeste. Pour les versions antérieures, utilisez plutôt cloud.google.com/load-balancer-type: "Internal".
   • 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 interne à stratégie directe 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 interne à stratégie directe 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.

   Pour plus d'informations, consultez la page 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
       nodePort: 30521
       port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       app: ilb-deployment
     sessionAffinity: None
     type: LoadBalancer
   status:
     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 interne à stratégie directe 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 interne à stratégie directe.
   • 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 interne à stratégie directe.

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 interne à stratégie directe

L'adresse IP de la règle de transfert de l'équilibreur de charge réseau interne à stratégie directe est 10.128.15.245 dans l'exemple inclus dans la section Créer un service LoadBalancer interne. Vous pouvez voir 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 interne à stratégie directe 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

Vous pouvez décrire 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.

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
...

Pour déterminer la liste de nœuds d'un sous-ensemble d'un service, exécutez la commande suivante :

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

Remplacez l'élément suivant :

• 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.

Pour déterminer la liste des nœuds sains pour un équilibreur de charge réseau interne à stratégie directe, utilisez la commande suivante :

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 interne à stratégie directe

Connectez-vous via SSH à une instance de VM dans le même réseau VPC et dans la même région que le cluster, puis exécutez la commande suivante :

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 interne à stratégie directe n'est accessible qu'au sein du même réseau VPC (ou 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 interne à stratégie directe. 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 console Google Cloud.

kubectl

Supprimer l'objet Deployment

Pour supprimer l'objet Deployment, exécutez la commande suivante :

kubectl delete deployment ilb-deployment

Supprimer l'objet Service

Pour supprimer l'objet Service, exécutez la commande suivante :

kubectl delete service ilb-svc

Console

Supprimer l'objet Deployment

Pour supprimer l'objet Deployment, procédez comme suit :

1. Accédez à la page Charges de travail dans la console Google Cloud.

   Accéder à la page Charges de travail

2. Sélectionnez le déploiement que vous souhaitez supprimer, puis cliquez sur Supprimer.

3. Lorsque vous êtes invité à confirmer l'opération, cochez la case Supprimer l'autoscaler horizontal de pods associé au déploiement sélectionné, puis cliquez sur Supprimer.

Supprimer l'objet Service

Pour supprimer l'objet Service, procédez comme suit :

1. Accédez à la page Services et entrées de la console Google Cloud.

   Accéder à la page Services et entrées

2. Sélectionnez le service que vous souhaitez supprimer, puis cliquez sur Supprimer.

3. Lorsque vous êtes invité à confirmer votre choix, cliquez sur Supprimer.

Adresse IP partagée

L'équilibreur de charge réseau interne à stratégie directe 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 service (ou règle de transfert) peut avoir un maximum de cinq 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 internes à stratégie directe 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, Google Cloud 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
     annotations:
       networking.gke.io/load-balancer-type: "Internal"
   spec:
     type: LoadBalancer
     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
     annotations:
       networking.gke.io/load-balancer-type: "Internal"
   spec:
     type: LoadBalancer
     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
   

Restrictions et limites

Restrictions applicables aux équilibreurs de charge réseau internes à stratégie directe

• Pour les clusters exécutant Kubernetes 1.7.4 ou version ultérieure, vous pouvez utiliser des équilibreurs de charge internes avec des sous-réseaux en mode personnalisé, en complément des sous-réseaux en mode automatique.
• Les clusters exécutant Kubernetes 1.7.X et versions ultérieures acceptent l'utilisation d'une adresse IP réservée pour l'équilibreur de charge réseau interne à stratégie directe si vous créez l'adresse IP réservée avec l'option --purpose définie sur SHARED_LOADBALANCER_VIP. Pour obtenir des instructions détaillées, consultez la page Activer l'adresse IP partagée. GKE ne conserve l'adresse IP d'un équilibreur de charge réseau interne à stratégie directe que si le service référence une adresse IP interne à cette fin. Sinon, GKE peut modifier l'adresse IP de l'équilibreur de charge (spec.loadBalancerIP) si le service est mis à jour (par exemple, si les ports sont modifiés).
• Même si l'adresse IP de l'équilibreur de charge change (voir point précédent), spec.clusterIP reste constant.

Restrictions applicables aux équilibreurs de charge UDP internes

• Les équilibreurs de charge UDP internes ne sont pas compatibles avec sessionAffinity: ClientIP.

Problèmes connus

Délai d'expiration de la connexion toutes les 10 minutes

Les services LoadBalancer internes créés avec le sous-paramètre peuvent observer des interruptions du trafic environ toutes les 10 minutes. Ce bug a été corrigé dans les versions suivantes :

• 1.18.19-gke.1700 et versions ultérieures
• 1.19.10-gke.1000 et versions ultérieures
• 1.20.6-gke.1000 et versions ultérieures

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

Lorsque vous créez un équilibreur de charge réseau interne à stratégie directe 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-paramètre GKE est activé.

Le contrôleur GKE crée des équilibreurs de charge réseau internes à stratégie directe 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.

• Obtenez plus d'informations sur l'agent de masquage d'adresses IP.

• Familiarisez-vous avec la configuration des réseaux autorisés.