Créer un équilibreur de charge interne

Autopilot Standard

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 puis 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.
  Remarque : Pour les installations de la gcloud CLI existantes, veillez à définir la propriété compute/region. Si vous utilisez principalement des clusters zonaux, définissez plutôt compute/zone. En définissant un emplacement par défaut, vous pouvez éviter les erreurs gcloud CLI de ce type : One of [--zone, --region] must be supplied: Please specify location. Vous devrez peut-être spécifier l'emplacement dans certaines commandes si celui de votre cluster diffère de l'emplacement par défaut que vous avez défini.

• 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 GKE version 1.33.1-gke.1779000 ou ultérieure, car spec.loadBalancerClass nécessite GKE version 1.33.1-gke.1779000 ou 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, le sous-paramétrage est actif, quelle que soit la valeur de l'option de sous-paramétrage 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 modifiant un cluster existant. Une fois activé, le sous-paramètre GKE ne peut plus être désactivé. Pour en savoir plus, consultez Vérifier et activer le sous-paramètre 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.

• Pour activer Cloud Logging pour un service LoadBalancer interne, votre cluster GKE doit utiliser la version 1.36.0-gke.2459000 ou une version ultérieure.

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 et ultérieure, mais avant GKE version 1.36. Vous ne pouvez pas désactiver le sous-paramètre GKE après l'avoir activé.

Pour en savoir plus sur l'importance du sous-paramètre GKE, consultez Considérations particulières pour les services LoadBalancer internes.

Pour déterminer si le sous-paramètre 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 de la manière suivante :

• Si la version du plan de contrôle est 1.36 ou ultérieure, le sous-paramétrage 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 à la version 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 GKE version 1.18.19-gke.1400 ou ultérieure, mais antérieure à GKE version 1.36, utilisez la gcloud CLI ou la console Google Cloud .

Console

1. Dans la console Google Cloud , 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 \
    --location=LOCATION
    --enable-l4-ilb-subsetting

Remplacez les éléments suivants :

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

L'activation du sous-paramètre GKE (à l'aide de la gcloud CLI, de la consoleGoogle Cloud 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.

Attention : Ne supprimez pas et ne modifiez pas les tags de finaliseur sur les ressources Service. GKE s'appuie sur ces tags pour distinguer les équilibreurs de charge sans sous-paramètre de ceux avec sous-paramètre. Si vous utilisez des gestionnaires de ressources externes ou des outils GitOps, configurez-les pour qu'ils conservent les tags de finaliseur. La suppression ou la mise à jour de ces tags peut empêcher le provisionnement de nouveaux équilibreurs de charge.

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. Cependant, la gestion des règles de pare-feu VPC est facultative et vous pouvez vous fier aux 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: PreferSameZone
        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 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 créer un service IPv6 à pile unique dans un cluster à double pile, définissez la valeur du champ spec.ipFamilyPolicy sur SingleStack et celle du champ spec.ipFamilies sur IPv6. Dans un cluster IPv6 à pile unique, il s'agit des valeurs par défaut, que vous pouvez omettre. Pour en savoir plus, consultez Services IPv4/IPv6 à double pile.

      • spec.trafficDistribution pour définir la façon 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 à la version 1.35.0-gke.1811000, utilisez plutôt la valeur PreferClose. L'affinité zonale nécessite l'activation du sous-paramètre GKE.

        Remarque : Vous pouvez également activer ou désactiver l'affinité zonale sur un service LoadBalancer interne existant à l'aide de la commande kubectl edit svc service-name. La commande kubectl edit ouvre le fichier manifeste du service de l'équilibreur de charge existant dans l'éditeur de texte configuré, où vous pouvez ajouter ou supprimer le paramètre spec.trafficDistribution et enregistrer les modifications. Le trafic peut être brièvement interrompu lorsque vous modifiez ce paramètre.

        Pour connaître les considérations importantes et une solution de contournement pour le scaling des charges de travail avec affinité zonale, consultez Procéder au scaling des charges de travail avec affinité zonale.

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

Créer un service LoadBalancer interne sur un cluster IPv6 à pile unique

Aperçu

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

Lorsque vous déployez un service LoadBalancer interne IPv6 à pile unique sur un cluster IPv6 à pile unique ou un cluster à double pile, le sous-réseau utilisé par l'équilibreur de charge dépend de l'utilisation d'un type d'accès IPv6 INTERNAL ou EXTERNAL par le sous-réseau de nœud de votre cluster. Sur un cluster double pile, vous devez définir la valeur du champ spec.ipFamilyPolicy sur SingleStack et celle du champ spec.ipFamilies sur IPv6 (sur un cluster IPv6 à pile unique, il s'agit des valeurs par défaut, que vous pouvez omettre). Pour créer un service à double pile, définissez la valeur du champ spec.ipFamilyPolicy sur RequireDualStack et listez les deux familles d'adresses dans le champ spec.ipFamilies :

• Clusters avec nœuds internes (type d'accès ULA INTERNAL) : si les nœuds de votre cluster s'exécutent sur un sous-réseau interne avec des adresses unicast locales uniques (ULA), l'équilibreur de charge interne utilise automatiquement le sous-réseau de nœuds existant. Créez votre service sans aucune annotation de sous-réseau personnalisée :

  apiVersion: v1
  kind: Service
  metadata:
    name: ilb-ipv6-svc
  spec:
    type: LoadBalancer
    loadBalancerClass: networking.gke.io/l4-regional-internal
    ipFamilyPolicy: SingleStack
    ipFamilies:
    - IPv6
    selector:
      app: my-app
    ports:
      - name: tcp-port
        protocol: TCP
        port: 80
        targetPort: 8080
  

• Clusters avec des nœuds externes (type d'accès GUA EXTERNAL) : si vos nœuds de cluster s'exécutent sur un sous-réseau externe avec des adresses unicast globales (GUA), un équilibreur de charge interne ne peut pas utiliser ce sous-réseau directement. Vous devez provisionner un sous-réseau IPv6 interne (INTERNAL) dédié et référencer le sous-réseau à l'aide de l'annotation networking.gke.io/load-balancer-subnet sur votre service :

  1. Créez un sous-réseau IPv6 interne dédié :

     gcloud compute networks subnets create SUBNET_NAME \
         --stack-type=ipv6_only \
         --ipv6-access-type=INTERNAL \
         --network=NETWORK_NAME \
         --region=COMPUTE_REGION
     

     Remplacez les éléments suivants :

     • SUBNET_NAME : nom du sous-réseau à créer.
     • NETWORK_NAME : nom du réseau VPC dans lequel vous créez ce sous-réseau.
     • COMPUTE_REGION : région Compute Engine du sous-réseau.

  2. Créez le service et référencez le nom du sous-réseau de l'étape précédente dans l'annotation networking.gke.io/load-balancer-subnet :

     apiVersion: v1
     kind: Service
     metadata:
       name: ilb-ipv6-svc
       annotations:
         networking.gke.io/load-balancer-subnet: SUBNET_NAME
     spec:
       type: LoadBalancer
       loadBalancerClass: networking.gke.io/l4-regional-internal
       ipFamilyPolicy: SingleStack
       ipFamilies:
       - IPv6
       selector:
         app: my-app
       ports:
         - name: tcp-port
           protocol: TCP
           port: 80
           targetPort: 8080
     

1. Vérifiez l'adresse IP du service attribuée :

   kubectl get svc ilb-ipv6-svc
   

   Le résultat confirme que les colonnes CLUSTER-IP et EXTERNAL-IP (une adresse ULA interne) sont renseignées :

   NAME           TYPE           CLUSTER-IP                          EXTERNAL-IP               PORT(S)        AGE
   ilb-ipv6-svc   LoadBalancer   2600:2d00:0:4:1a1e:d3b3:de4d:c549   fd20:f5d:a91f:3:0:9:0:0   80:30234/TCP   3m
   

Pour en savoir plus, consultez Services LoadBalancer IPv6.

Utiliser des adresses BYOIPv6 (Bring Your Own IPv6)

Pour configurer un service LoadBalancer interne IPv6 avec la fonctionnalité Apporter vos propres adresses IPv6 (BYOIPv6), créez un sous-réseau avec une plage d'adresses BYOIPv6 internes et référencez le sous-réseau sur votre service. La plage d'adresses IPv6 du sous-réseau doit provenir d'un sous-préfixe IPv6 régional d'un préfixe délégué public (PDP) en mode INTERNAL_IPV6_SUBNETWORK_CREATION.

Attention : GKE n'est pas compatible avec l'annotation networking.gke.io/ip-collection-v6 pour les services LoadBalancer internes. Si vous utilisez cette annotation, GKE l'ignore et émet un événement d'avertissement IPCollectionV6Error. Pour en savoir plus, consultez la section Problèmes connus.

Avant de créer le service, vérifiez que vous disposez d'un sous-préfixe IPv6 régional en mode INTERNAL_IPV6_SUBNETWORK_CREATION dans la même région que votre cluster. Pour en savoir plus, consultez Créer des sous-préfixes IPv6 et Créer des sous-réseaux avec des plages BYOIP IPv6.

1. Dans la même région et le même réseau VPC que votre cluster, créez un sous-réseau avec une plage BYOIPv6 interne à partir de votre sous-préfixe :

   gcloud compute networks subnets create BYOIP_SUBNET_NAME \
       --network=NETWORK_NAME \
       --region=REGION \
       --stack-type=IPV6_ONLY \
       --ipv6-access-type=INTERNAL \
       --ip-collection=projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME
   

   Remplacez les éléments suivants :

   • BYOIP_SUBNET_NAME : nom du nouveau sous-réseau.
   • NETWORK_NAME : nom du réseau VPC de votre cluster.
   • REGION : région de votre cluster.
   • PROJECT_ID : ID du projet contenant le sous-préfixe.
   • SUB_PREFIX_NAME : nom du sous-préfixe régional en mode INTERNAL_IPV6_SUBNETWORK_CREATION.

2. Facultatif : Réservez une plage d'adresses IPv6 /96 internes statiques à partir du sous-réseau BYOIPv6. Si vous ignorez cette étape, GKE alloue automatiquement une plage d'adresses BYOIPv6 internes éphémères à partir du sous-réseau que vous spécifiez dans l'annotation networking.gke.io/load-balancer-subnet :

   gcloud compute addresses create STATIC_IPV6_NAME \
       --region=REGION \
       --subnet=BYOIP_SUBNET_NAME \
       --ip-version=IPV6
   

   Remplacez STATIC_IPV6_NAME par le nom de la ressource d'adresse IPv6 statique.

3. Enregistrez le manifeste suivant sous le nom ilb-byoipv6-svc.yaml :

   apiVersion: v1
   kind: Service
   metadata:
     name: ilb-byoipv6-svc
     annotations:
       networking.gke.io/load-balancer-subnet: BYOIP_SUBNET_NAME
       # Optional: To use a static address, uncomment the following line
       # networking.gke.io/load-balancer-ip-addresses: STATIC_IPV6_NAME
   spec:
     type: LoadBalancer
     loadBalancerClass: networking.gke.io/l4-regional-internal
     ipFamilyPolicy: SingleStack
     ipFamilies:
     - IPv6
     selector:
       app: ilb-deployment
     ports:
     - name: tcp-port
       protocol: TCP
       port: 80
       targetPort: 8080
   

   Remplacez BYOIP_SUBNET_NAME par le nom du sous-réseau BYOIPv6 que vous avez créé. Par défaut, GKE alloue une plage d'adresses BYOIPv6 internes éphémères à partir de ce sous-réseau.

   Facultatif : si vous avez réservé une adresse BYOIPv6 interne statique à l'étape précédente, annulez la mise en commentaire de l'annotation networking.gke.io/load-balancer-ip-addresses et remplacez STATIC_IPV6_NAME par le nom de la ressource d'adresse IPv6 statique.

4. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f ilb-byoipv6-svc.yaml
   

Pour en savoir plus, consultez Utiliser vos propres adresses IPv6 (BYOIPv6).

Activer la journalisation pour les services de backend

Vous pouvez activer, désactiver et afficher les journaux d'un équilibreur de charge réseau passthrough interne. Pour activer la journalisation de vos services de backend, vous devez activer le sous-paramètre GKE.

Vous configurez Cloud Logging en créant une ressource personnalisée L4LBConfig qui spécifie vos paramètres de journalisation. La ressource L4LBConfig est associée à un service Kubernetes dans le fichier manifeste du service. Une fois le fichier manifeste appliqué, le contrôleur GKE configure la journalisation pour le service de backend. Si vous n'associez pas de ressource L4LBConfig au service, le contrôleur cesse de gérer la configuration de journalisation et laisse le service de backend dans son dernier état connu. Pour en savoir plus, consultez Comprendre le comportement de la roue libre.

Vous pouvez configurer les champs suivants :

• enabled : si la valeur est définie sur true, active la journalisation pour ce service. Les journaux sont disponibles dans Cloud Logging. Sinon, la journalisation est désactivée pour ce service.
• sampleRate : spécifie une valeur comprise entre 0 et 1,000,000 (par défaut), où 0 signifie qu'aucun paquet n'est enregistré et 1,000,000 signifie que 100 % des paquets sont enregistrés. Le champ sampleRate est facultatif et n'est pertinent que si la valeur du champ enable est définie sur true.
• optionalMode : contrôle les champs de métadonnées facultatifs inclus dans les journaux générés pour l'équilibreur de charge. Le champ accepte l'une des valeurs de chaîne suivantes :
  • EXCLUDE_ALL_OPTIONAL : paramètre par défaut si optionalMode n'est pas spécifié. Lorsque cette option est définie, aucun champ facultatif n'est inclus dans les journaux, ce qui fournit le format de journal le plus concis.
  • INCLUDE_ALL_OPTIONAL : active la journalisation pour tous les champs facultatifs disponibles, ce qui fournit les entrées de journal les plus détaillées.
  • CUSTOM : spécifie une liste personnalisée de champs facultatifs inclus dans les journaux. Avec le mode CUSTOM, vous devez également utiliser le paramètre optionalFields pour fournir une liste d'éléments séparés par une virgule des champs que vous souhaitez.
• optionalFields : chaîne de noms de champs séparés par une virgule. Définit les champs de métadonnées facultatifs exacts que vous souhaitez inclure dans les journaux générés. Ce champ n'est utilisé que lorsque optionalMode est défini sur CUSTOM. Sinon, toutes les valeurs sont ignorées.

Pour configurer Cloud Logging, créez la ressource L4LBConfig dans le même espace de noms que votre ressource Service. L'exemple de fichier manifeste L4LBConfig suivant active Cloud Logging et définit le taux d'échantillonnage sur 50 % des requêtes pour un service d'équilibreur de charge donné.

1. Enregistrez le manifeste suivant sous le nom svc-l4lb-config.yaml :

   apiVersion: networking.gke.io/v1
   kind: L4LBConfig
   metadata:
     name: svc-l4lb-config
     namespace: default
   spec:
     logging:
       enabled: true # must be included
       sampleRate: 500000
       optionalMode: "INCLUDE_ALL_OPTIONAL"
   

2. Appliquez le fichier manifeste L4LBConfig à votre cluster :

   kubectl apply -f svc-l4lb-config.yaml
   

3. Ajoutez l'annotation networking.gke.io/l4lb-config au fichier manifeste du service ilb-svc.yaml :

   apiVersion: v1
   kind: Service
   metadata:
     name: ilb-svc
     annotations:
       networking.gke.io/load-balancer-type: "Internal"
       networking.gke.io/l4lb-config: "svc-l4lb-config"
   spec:
     type: LoadBalancer
     selector:
       app: store
     ports:
       - name: tcp-port
         protocol: TCP
         port: 8080
         targetPort: 8080
   

4. Appliquez le fichier manifeste Service à votre cluster :

   kubectl apply -f ilb-svc.yaml
   

Effectuer le scaling des charges de travail avec l'affinité zonale

Étant donné que l'autoscaler horizontal de pods (AHP) effectue le scaling des pods en fonction des métriques de cluster agrégées plutôt que de la charge par zone, dissociez vos charges de travail par zone pour éviter une surcharge zonale. Au lieu d'un seul déploiement et d'un seul AHP à l'échelle du cluster, créez un déploiement et un AHP distincts pour chaque zone dans laquelle votre cluster fonctionne. Un seul service LoadBalancer interne peut acheminer le trafic vers toutes ces charges de travail zonales indépendantes simultanément.

Présentation de l'architecture

• Une charge de travail par zone : créez des déploiements distincts pour chaque zone (par exemple, zone-a, zone-b).
• Sélecteurs de nœuds : liez chaque déploiement à sa zone spécifique à l'aide du sélecteur de nœuds topology.kubernetes.io/zone.
• Un HPA par zone : associez un AHP à chaque déploiement spécifique afin que ses pods évoluent indépendamment en fonction des métriques localisées.
• Un service partagé : exposez tous ces déploiements derrière un seul service LoadBalancer interne configuré avec une affinité zonale (en utilisant le même sélecteur).

Configurer des charges de travail zonales indépendantes

L'exemple suivant montre comment implémenter cette architecture dans deux zones.

1. Créez un déploiement distinct pour chaque zone. Les déploiements partagent le même libellé app, mais ont un nodeSelector strict qui les lie à une zone spécifique.

   Enregistrez le manifeste suivant sous le nom zonal-deployments.yaml :

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app-zone-a
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: my-app
         zone: zone-a
     template:
       metadata:
         labels:
           app: my-app
           zone: zone-a
       spec:
         nodeSelector:
           topology.kubernetes.io/zone: "COMPUTE_ZONE_A"
         containers:
         - name: echoserver
           image: gcr.io/google_containers/echoserver:1.10
           ports:
           - containerPort: 8080
           resources:
             requests:
               cpu: "100m"
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app-zone-b
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: my-app
         zone: zone-b
     template:
       metadata:
         labels:
           app: my-app
           zone: zone-b
       spec:
         nodeSelector:
           topology.kubernetes.io/zone: "COMPUTE_ZONE_B"
         containers:
         - name: echoserver
           image: gcr.io/google_containers/echoserver:1.10
           ports:
           - containerPort: 8080
           resources:
             requests:
               cpu: "100m"
   

   Remplacez COMPUTE_ZONE_A et COMPUTE_ZONE_B par vos zones réelles (par exemple, us-central1-a et us-central1-b).

2. Appliquez le fichier manifeste :

   kubectl apply -f zonal-deployments.yaml
   

3. Créez un AHP indépendant pour chaque déploiement zonal.

   Enregistrez le manifeste suivant sous le nom zonal-hpas.yaml :

   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: hpa-zone-a
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: my-app-zone-a
     minReplicas: 2
     maxReplicas: 10
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 70
   ---
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: hpa-zone-b
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: my-app-zone-b
     minReplicas: 2
     maxReplicas: 10
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 70
   

4. Appliquez le fichier manifeste :

   kubectl apply -f zonal-hpas.yaml
   

5. Assurez-vous que votre service cible l'étiquette partagée (app: my-app) et que l'affinité zonale est activée.

   Enregistrez le manifeste suivant sous le nom zonal-service.yaml :

   apiVersion: v1
   kind: Service
   metadata:
     name: my-app-service-internal
   spec:
     type: LoadBalancer
     loadBalancerClass: networking.gke.io/l4-regional-internal
     trafficDistribution: PreferSameZone
     selector:
       app: my-app
     ports:
     - name: tcp-port
       protocol: TCP
       port: 8080
       targetPort: 8080
   

6. Appliquez le fichier manifeste :

   kubectl apply -f zonal-service.yaml
   

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

Cette section vous explique comment vérifier les principaux composants 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 à la version 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 la Google Cloud CLI :

  gcloud compute backend-services describe k8s2-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 à la version 1.33.3-gke.1392000.

• Déterminez la liste de 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.

• Vérifiez que Cloud Logging a été activé pour le service :

  kubectl get svc SERVICE_NAME --output yaml
  

  Remplacez les éléments suivants :

  • SERVICE_NAME : nom du service.

  Dans le résultat, assurez-vous que le champ Status.Conditions contient Type: LoggingConfigManaged et Reason: Reconciled.

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

L'équilibreur de charge réseau passthrough interne 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 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.

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

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 consoleGoogle 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 le déploiement, 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, cochez la case Supprimer l'autoscaler horizontal de pods associé au déploiement sélectionné, puis cliquez sur Supprimer.

Supprimer le service

Pour supprimer le 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 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 faire correspondre et transférer le trafic sur tous les ports. Si un service LoadBalancer interne définit plus de cinq ports, la règle de transfert sera automatiquement définie 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.
• L'adresse IP partagée n'est compatible qu'avec les adresses IPv4 internes. Vous ne pouvez pas partager une plage d'adresses IPv6 internes statiques entre plusieurs services LoadBalancer internes.

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, 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
   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-paramètre 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.

Erreur lors de l'utilisation de l'annotation networking.gke.io/ip-collection-v6 sur un service LoadBalancer interne

Lorsque vous ajoutez l'annotation networking.gke.io/ip-collection-v6 à un service LoadBalancer interne, GKE émet un événement d'avertissement IPCollectionV6Error avec le message suivant :

networking.gke.io/ip-collection-v6 is not supported for Internal LoadBalancers. To use BYOIPv6 with ILB, specify a BYOIP subnet using the "networking.gke.io/load-balancer-subnet" annotation

L'annotation networking.gke.io/ip-collection-v6 ne s'applique qu'aux services LoadBalancer externes IPv6 à pile unique. Pour utiliser des adresses BYOIPv6 avec un service LoadBalancer interne, créez un sous-réseau avec une plage d'adresses IPv6 internes à partir d'un préfixe délégué public en mode INTERNAL_IPV6_SUBNETWORK_CREATION. Spécifiez ce sous-réseau à l'aide de l'annotation networking.gke.io/load-balancer-subnet. Pour en savoir plus, consultez Utiliser vos propres adresses IPv6 (BYOIPv6).

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