Équilibrage de charge natif en conteneurs via des NEG zonaux autonomes

Autopilot Standard

---

Cette page explique comment créer un service Kubernetes reposant sur un Groupe de points de terminaison du réseau (NEG, network endpoint group) GCE_VM_IP_PORT zonal dans un Cluster de VPC natif Google Kubernetes Engine (GKE).

Reportez-vous à la section Équilibrage de charge natif en conteneurs pour en savoir plus sur les avantages, les exigences et les limites de l'équilibrage de charge natif en conteneurs.

Présentation

Un NEG représente un groupe de points de terminaison. GKE est compatible avec les NEG autonomes de type GCE_VM_IP_PORT. Les NEG GCE_VM_IP_PORT acceptent les points de terminaison qui utilisent l'adresse IP interne principale de la VM ou une adresse IP de l'une de ses plages d'adresses IP d'alias.

Dans le contexte d'un cluster de VPC natif GKE et à l'aide de NEG autonomes, chaque point de terminaison est une adresse IP de pod et un port cible. Les adresses IP des pods proviennent de la plage d'adresses IP d'alias des pods, qui provient de la plage d'adresses IP secondaire du sous-réseau réservée aux pods du cluster.

GKE fournit un contrôleur NEG pour gérer l'appartenance aux NEG GCE_VM_IP_PORT. Vous pouvez ajouter les NEG qu'il crée en tant que backends aux services de backend pour les équilibreurs de charge que vous configurez en dehors de l'API GKE.

Le schéma suivant illustre la correspondance des objets de l'API Kubernetes avec les objets Compute Engine.

Utiliser l'entrée avec des NEG

Lorsque des groupes de points de terminaison du réseau sont utilisés avec GKE Ingress, le contrôleur d'entrée facilite la création de tous les aspects de l'équilibreur de charge. Cela inclut la création de l'adresse IP virtuelle, des règles de transfert, des vérifications d'état, des règles de pare-feu, etc.

L'objet Ingress constitue la méthode recommandée pour utiliser l'équilibrage de charge natif en conteneurs, car il comporte de nombreuses fonctionnalités qui simplifient la gestion des NEG. Les NEG autonomes constituent une autre option si les NEG gérés par un objet Ingress ne répondent pas à votre cas d'utilisation.

NEG autonomes

Lorsque des NEG sont déployés avec des équilibreurs de charge provisionnés par n'importe quelle autre méthode qu'un objet Ingress, ils sont considérés comme des NEG autonomes. Les NEG autonomes sont déployés et gérés via le contrôleur NEG. Toutefois, les règles de transfert, les vérifications d'état et les autres objets associés à l'équilibrage de charge sont déployés manuellement.

Les NEG autonomes n'entrent pas en conflit avec l'équilibrage de charge natif en conteneurs de type objet Ingress.

L'illustration suivante montre les différences de déploiement des objets d'équilibrage de charge pour chaque scénario :

Prévenir la divulgation des NEG

Pour les NEG autonomes, vous êtes responsable de la gestion des cycles de vie des NEG et des ressources qui composent l'équilibreur de charge. Vous risquez de divulguer des NEG de différentes manières :

• Lorsqu'un service GKE est supprimé, le NEG associé n'est pas récupéré en mémoire si le NEG est toujours référencé par un service de backend. Pour permettre la suppression du NEG, vous devez le déréférencer du service de backend.
• Lorsqu'un cluster est supprimé, les NEG autonomes ne sont pas supprimés.

Cas d'utilisation de NEG autonomes

Les NEG autonomes possèdent plusieurs cas d'utilisation critiques. Les NEG autonomes sont très flexibles. Ces caractéristiques diffèrent de celles de l'objet Ingress (utilisé avec ou sans NEG), qui définit un ensemble spécifique d'objets d'équilibrage de charge choisis de façon très rigoureuse pour simplifier leur utilisation.

Exemples d'utilisation des NEG autonomes :

Services hétérogènes de conteneurs et de VM

Les NEG peuvent contenir à la fois des adresses IP de VM et de conteneurs. Cela signifie qu'une adresse IP virtuelle unique peut pointer vers un backend composé à la fois de charges de travail Kubernetes et non-Kubernetes. Cela peut également servir à migrer des charges de travail existantes vers un cluster GKE.

Les NEG autonomes peuvent pointer vers des adresses IP de VM, ce qui permet de configurer manuellement des équilibreurs de charge pour qu'ils pointent vers des backends composés à la fois de VM et de conteneurs pour la même adresse IP virtuelle du service.

Contrôleurs d'objet Ingress personnalisés

Vous pouvez utiliser un contrôleur d'objet Ingress personnalisé pour configurer les équilibreurs de charge qui ciblent les NEG autonomes, ou n'utiliser aucun contrôleur.

Utiliser Traffic Director avec GKE

Vous pouvez utiliser Traffic Director avec GKE. Traffic Director utilise des NEG autonomes pour fournir un équilibrage de charge natif en conteneurs pour le maillage de services géré.

Utiliser des équilibreurs de charge réseau proxy externes avec GKE

Vous pouvez utiliser des NEG autonomes pour équilibrer la charge directement sur les conteneurs dotés de l'équilibreur de charge réseau proxy externe, qui n'est pas compatible de manière native avec Kubernetes/GKE.

Disponibilité des pods

Les portes de disponibilité sont une fonctionnalité d'extensibilité de Kubernetes. Elles permettent d'injecter des commentaires ou des signaux supplémentaires dans l'objet PodStatus pour rendre le pod disponible. Le contrôleur NEG gère une porte de disponibilité personnalisée pour s'assurer que le chemin réseau complet est fonctionnel entre l'équilibreur de charge Compute Engine et le pod. Les portes de disponibilité des pods dans GKE sont expliquées dans l'équilibrage de charge natif en conteneurs.

L'objet Ingress avec des NEG déploie et gère les vérifications d'état de Compute Engine pour le compte de l'équilibreur de charge. Toutefois, les NEG autonomes n'émettent aucune hypothèse concernant les vérifications d'état de Compute Engine, car elles sont supposées être déployées et gérées séparément. Les vérifications d'état de Compute Engine doivent toujours être configurées avec l'équilibreur de charge pour empêcher l'envoi du trafic vers les backends qui ne sont pas prêts à le recevoir. Si aucune vérification d'état n'est associée au NEG (généralement parce qu'aucune vérification d'état n'est configurée), le contrôleur NEG définit la valeur de la porte de disponibilité du pod sur "True" (Vrai) lorsque son point de terminaison correspondant est programmé dans le NEG.

Conditions requises

Votre cluster doit être VPC natif. Pour en savoir plus, consultez la page Créer un cluster de VPC natif.

Le module complémentaire HttpLoadBalancing doit être activé sur votre cluster. Le module complémentaire HttpLoadBalancing est activé par défaut sur les clusters GKE.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Activez l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez 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.

Utiliser des NEG autonomes

Les instructions suivantes vous expliquent comment utiliser des NEG autonomes avec un équilibreur de charge HTTP externe sur GKE.

Vous devez créer les objets suivants :

• Un déploiement, qui crée et gère les pods.
• Un service, qui crée un NEG.
• Un équilibreur de charge créé avec l'API Compute Engine. Ce processus est différent lorsque vous utilisez des NEG avec un objet Ingress. Dans ce cas, l'objet Ingress crée et configure un équilibreur de charge automatiquement. Avec les NEG autonomes, vous devez associer le NEG et le service de backend pour pouvoir connecter les pods à l'équilibreur de charge. L'équilibreur de charge est constitué de plusieurs composants, illustrés dans le schéma suivant :

Créer un cluster de VPC natif

Les clusters Autopilot sont par défaut des VPC natifs. Vous pouvez donc passer à l'étape Déployer une charge de travail.

Pour les clusters standards, créez un cluster de VPC natif dans la zone us-central1-a :

gcloud container clusters create neg-demo-cluster \
    --create-subnetwork="" \
    --network=default \
    --zone=us-central1-a

Créer un déploiement

Les exemples de fichiers manifestes suivants spécifient des déploiements qui exécutent trois instances d'un serveur HTTP conteneurisé. Le serveur HTTP répond aux requêtes en renvoyant le nom d'hôte du serveur d'applications, soit le nom du pod sur lequel le serveur est exécuté.

Nous vous recommandons d'utiliser des charges de travail qui font appel au retour d'informations via la disponibilité des pods.

Utiliser le retour d'informations via la disponibilité des pods

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

Utiliser un délai codé en dur

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

Enregistrez ce fichier manifeste sous le nom neg-demo-app.yaml, puis créez le déploiement en exécutant la commande suivante :

kubectl apply -f neg-demo-app.yaml

Créer un service

Le fichier manifeste suivant spécifie un service où :

• Tous les pods comportant le libellé run: neg-demo-app sont membres de ce service.
• Le service possède un champ ServicePort défini avec le port 80.
• L'annotation cloud.google.com/neg indique que le port 80 sera associé à un NEG. Le champ facultatif name indique que le NEG sera nommé NEG_NAME. Si le champ name est omis, un nom unique est généré automatiquement. Pour en savoir plus, consultez la section Nommer les NEG.
• Chaque pod membre doit avoir un conteneur qui écoute sur le port TCP 9376.

apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'
spec:
  type: ClusterIP
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376

Remplacez NEG_NAME par le nom du NEG. Le nom du NEG doit être unique dans sa région.

Enregistrez ce fichier manifeste sous le nom neg-demo-svc.yaml, puis créez le service en exécutant la commande suivante :

kubectl apply -f neg-demo-svc.yaml

Un NEG est créé quelques minutes après la création du Service.

Types de services

Bien que cet exemple utilise un service ClusterIP, les cinq types de services sont compatibles avec les NEG autonomes. Nous vous recommandons d'utiliser le type par défaut, ClusterIP.

Nommer les NEG

Dans les versions 1.18.18-gke.1200 et ultérieures de GKE, vous pouvez spécifier un nom personnalisé pour les NEG, ou GKE peut générer un nom automatiquement. Les versions précédentes de GKE n'acceptent que les noms de NEG générés automatiquement.

GKE crée un NEG dans chaque zone utilisée par le cluster. Tous les NEG utilisent le même nom.

Specifying a name

La spécification d'un nom de NEG personnalisé simplifie la configuration de l'équilibreur de charge, car vous connaissez à l'avance le nom et les zones des NEG. Les noms des NEG personnalisés doivent répondre aux exigences suivantes :

• Être uniques à la zone du cluster pour les clusters zonaux, ou uniques à la région pour les clusters régionaux.

• Ne doit pas correspondre au nom d'un NEG existant qui n'a pas été créé par le contrôleur NEG GKE.
• Ne doit contenir aucun trait de soulignement.

Remarque : En cas de conflit de noms, la création ou la synchronisation des NEG échoue. Pour connaître les étapes de dépannage, consultez la section NEG non synchronisé avec le service.

Utilisez le champ name dans l'annotation cloud.google.com/neg du service pour spécifier un nom NEG :

cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'

Remplacez NEG_NAME par le nom du NEG. Le nom du NEG doit être unique dans sa région.

Utiliser un nom généré automatiquement

Les noms des NEG générés automatiquement sont garantis uniques. Pour utiliser un nom généré automatiquement, omettez le champ name :

cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'

Le nom généré automatiquement se présente comme suit :

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

Mappage des ports sur plusieurs NEG

Un service peut écouter sur plusieurs ports. Par définition, les NEG possèdent une seule adresse IP et un seul port. Cela signifie que si vous spécifiez un objet Service avec plusieurs ports, celui-ci créera un NEG pour chaque port.

Le format de l'annotation cloud.google.com/neg est le suivant :

cloud.google.com/neg: '{
   "exposed_ports":{
      "SERVICE_PORT_1":{},
      "SERVICE_PORT_2":{},
      "SERVICE_PORT_3":{},
      ...
   }
 }'

Dans cet exemple, chaque instance de SERVICE_PORT_N est un numéro de port distinct qui fait référence aux ports de service existants du service. Pour chaque port de service répertorié, le contrôleur NEG crée un NEG dans chaque zone occupée par le cluster.

Récupérer les états des NEG

Utilisez la commande suivante pour récupérer les états des Services du cluster :

kubectl get service neg-demo-svc -o yaml

Le résultat ressemble à ce qui suit :

cloud.google.com/neg-status: '{
   "network-endpoint-groups":{
      "SERVICE_PORT_1": "NEG_NAME_1",
      "SERVICE_PORT_2": "NEG_NAME_2",
      ...
   },
   "zones":["ZONE_1", "ZONE_2", ...]
}

Dans cette sortie, chaque élément du mappage network-endpoint-groups est un port de service (tel que SERVICE_PORT_1) et le nom des NEG gérés correspondants (comme NEG_NAME_1). La liste zones contient toutes les zones (comme ZONE_1) qui contiennent un NEG.

Le résultat ressemble à ce qui suit :

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"80":"k8s1-cca197ad-default-neg-demo-app-80-4db81e02"},"zones":["ZONE_1", "ZONE_2"]}'
  labels:
    run: neg-demo-app
  name: neg-demo-app
  namespace: default
  selfLink: /api/v1/namespaces/default/services/neg-demo-app
  ...
spec:
  clusterIP: 10.0.14.252
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376
  selector:
    run: neg-demo-app
  sessionAffinity: None
status:
  loadBalancer: {}

Dans cet exemple, l'annotation indique que le port de service 80 est exposé à des NEG nommés k8s1-cca197ad-default-neg-demo-app-80-4db81e02.

Valider la création des NEG

Un NEG est créé quelques minutes après la création du Service. Si des pods correspondent au libellé spécifié dans le fichier manifeste de l'objet Service, alors le NEG créé contiendra les adresses IP des pods.

Il existe deux manières de vérifier que le NEG est créé et configuré correctement. Dans GKE 1.18.1-gke.6400 et versions ultérieures, une ressource personnalisée ServiceNetworkEndpointGroup stocke des informations sur l'état des NEG créés par le contrôleur de service. Dans les versions précédentes, vous devez directement inspecter les NEG.

Ressource ServiceNetworkEndpointGroup

Pour répertorier les NEG d'un cluster, obtenez toutes les ressources ServiceNetworkEndpointGroup :

kubectl get svcneg

Observez l'état d'un NEG en vérifiant l'état de la ressource ServiceNetworkEndpointGroup :

kubectl get svcneg NEG_NAME -o yaml

Remplacez NEG_NAME par le nom du NEG individuel que vous souhaitez inspecter.

Le résultat de cette commande inclut une section "status" susceptible de contenir des messages d'erreur. Certaines erreurs sont signalées en tant qu'événements de service. Pour plus de détails, interrogez l'objet Service :

kubectl describe service SERVICE_NAME

Remplacez SERVICE_NAME par le nom du service concerné.

Pour vérifier que le contrôleur NEG synchronise correctement le NEG, consultez le champ d'état de la ressource ServiceNetworkEndpointGroup pour une condition avec type:Synced. L'heure de la synchronisation la plus récente se trouve dans le champ status.lastSyncTime.

Les ressources ServiceNetworkEndpointGroup n'existent que dans GKE 1.18 et versions ultérieures.

Inspecter directement des NEG

Vérifiez que le NEG existe en répertoriant les NEG dans votre projet Google Cloud et en recherchant un NEG correspondant à l'objet Service que vous avez créé. Le nom du NEG s'affiche au format suivant :

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

Utilisez la commande suivante pour répertorier les NEG :

gcloud compute network-endpoint-groups list

Le résultat ressemble à ce qui suit :

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      GCE_VM_IP_PORT  3

Ce résultat indique que le SIZE du NEG est égal à 3, ce qui signifie qu'il a trois points de terminaison qui correspondent aux trois pods du déploiement.

Identifiez les points de terminaison individuels avec la commande suivante :

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME

Remplacez NEG_NAME par le nom du NEG pour lequel vous souhaitez afficher les points de terminaison individuels.

Le résultat affiche trois points de terminaison, chacun disposant de l'adresse IP et du port d'un pod :

INSTANCE                                           IP_ADDRESS  PORT
gke-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.43  9376
gke-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.44  9376
gke-cluster-3-default-pool-4cc71a15-w9nk  10.12.2.26  9376

Associer un équilibreur de charge d'application externe à des NEG autonomes

Vous pouvez utiliser les NEG en tant que backend pour un équilibreur de charge d'application externe à l'aide de l'API Compute Engine.

1. Créez une règle de pare-feu. Les équilibreurs de charge doivent pouvoir accéder aux points de terminaison du cluster pour effectuer des vérifications d'état. Cette commande crée une règle de pare-feu pour autoriser l'accès :

   gcloud compute firewall-rules create fw-allow-health-check-and-proxy \
      --network=NETWORK_NAME \
      --action=allow \
      --direction=ingress \
      --target-tags=GKE_NODE_NETWORK_TAGS \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --rules=tcp:9376
   

   Remplacez les éléments suivants :

   • NETWORK_NAME : réseau sur lequel le cluster est exécuté.
   • GKE_NODE_NETWORK_TAGS : tags réseau sur les nœuds GKE

   Si vous n'avez pas créé de tags réseau personnalisés pour vos nœuds, GKE génère automatiquement des tags pour vous. Vous pouvez consulter ces tags générés en exécutant la commande suivante :

   gcloud compute instances describe INSTANCE_NAME
   

   Remplacez INSTANCE_NAME par le nom de l'instance de VM Compute Engine hôte qui exécute le nœud GKE. Par exemple, le résultat de la section précédente affiche les noms d'instance dans la colonne INSTANCE des nœuds GKE. Pour les clusters standards, vous pouvez également exécuter la commande gcloud compute instances list afin de répertorier toutes les instances de votre projet.

2. Créez une adresse IP virtuelle globale pour l'équilibreur de charge :

   gcloud compute addresses create hostname-server-vip \
       --ip-version=IPV4 \
       --global
   

3. Créez une vérification d'état. L'équilibreur de charge s'en sert pour détecter l'activité des points de terminaison individuels au sein du NEG.

   gcloud compute health-checks create http http-basic-check \
       --use-serving-port
   

4. Créez un service de backend spécifiant qu'il s'agit d'un équilibreur de charge d'application externe global :

   gcloud compute backend-services create my-bes \
       --protocol HTTP \
       --health-checks http-basic-check \
       --global
   

5. Créez un mappage d'URL et un proxy cible pour l'équilibreur de charge. Cet exemple est très simple, car l'application serve_hostname utilisée pour ce guide comporte un seul point de terminaison, mais pas d'URL.

   gcloud compute url-maps create web-map \
       --default-service my-bes
   

   gcloud compute target-http-proxies create http-lb-proxy \
       --url-map web-map
   

6. Créez une règle de transfert. C'est ce qui va permettre de créer l'équilibreur de charge.

   gcloud compute forwarding-rules create http-forwarding-rule \
       --address=HOSTNAME_SERVER_VIP \
       --global \
       --target-http-proxy=http-lb-proxy \
       --ports=80
   

   Remplacez HOSTNAME_SERVER_VIP par l'adresse IP à utiliser pour l'équilibreur de charge. Si vous omettez --address, GKE attribue automatiquement une adresse IP éphémère. Vous pouvez également réserver une nouvelle adresse IP externe statique.

Check Point

Voici les ressources que vous avez créées jusqu'à maintenant :

• Une adresse IP virtuelle externe
• Des règles de transfert
• Des règles de pare-feu
• Le proxy HTTP cible
• Le mappage d'URL de la vérification d'état de Compute Engine
• Le service de backend
• Vérification d'état de Compute Engine

La relation entre ces ressources est illustrée dans le diagramme suivant :

Ensemble, ces ressources constituent un équilibreur de charge. À l'étape suivante, vous allez ajouter des backends à l'équilibreur de charge.

L'un des avantages des NEG autonomes présentés ici est que les cycles de vie de l'équilibreur de charge et du backend peuvent être totalement indépendants. L'équilibreur de charge peut continuer à s'exécuter après la suppression de l'application, de ses services ou du cluster GKE. Vous pouvez ajouter et supprimer des nouveaux NEG ou plusieurs NEG à partir de l'équilibreur de charge sans modifier aucun des objets de l'équilibreur de charge de l'interface.

Ajouter des backends à l'équilibreur de charge

Utilisez gcloud compute backend-services add-backend pour connecter le NEG à l'équilibreur de charge en l'ajoutant en tant que backend du service de backend my-bes :

gcloud compute backend-services add-backend my-bes \
    --global \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    --balancing-mode RATE --max-rate-per-endpoint 5

Remplacez l'élément suivant :

• NEG_NAME : nom de votre groupe de points de terminaison du réseau. Le nom peut être le nom que vous avez spécifié lors de la création du NEG ou un nom généré automatiquement. Si vous n'avez pas spécifié de nom pour le NEG, consultez les instructions suivantes pour trouver le nom généré automatiquement.
• NEG_ZONE : correspond à la zone dans laquelle se trouve le groupe de points de terminaison du réseau. Reportez-vous aux instructions suivantes pour trouver cette valeur.

Utilisez cette commande pour obtenir le nom et l'emplacement du NEG :

gcloud compute network-endpoint-groups list

Le résultat ressemble à ce qui suit :

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      GCE_VM_IP_PORT  3

Dans cet exemple de résultat, le nom du NEG est k8s1-70aa83a6-default-my-service-80-c9710a6f.

Plusieurs NEG peuvent être ajoutés au même service de backend. Les services de backend internationaux, tels que my-bes, peuvent être situés dans différentes régions, tandis que les backends des services de backend régionaux doivent être situés dans une seule région.

Vérifier le fonctionnement de l'équilibreur de charge

Remarque : Le provisionnement et la stabilisation de l'équilibreur de charge peut prendre quelques minutes.

Il existe deux façons de vérifier que l'équilibreur de charge que vous configurez fonctionne :

• Assurez-vous que la vérification d'état est correctement configurée et qu'elle signale un problème sain.
• Accéder à l'application et vérifier sa réponse

Valider les vérifications d'état

Vérifiez que le service de backend est associé à la vérification d'état et aux groupes de points de terminaison du réseau, et que les points de terminaison individuels sont opérationnels.

Utilisez cette commande pour vérifier que le service de backend est associé à la vérification d'état et à votre groupe de points de terminaison du réseau :

gcloud compute backend-services describe my-bes --global

Le résultat ressemble à ce qui suit :

backends:
- balancingMode: RATE
  capacityScaler: 1.0
  group: ... /networkEndpointGroups/k8s1-70aa83a6-default-my-service-80-c9710a6f
...
healthChecks:
- ... /healthChecks/http-basic-check
...
name: my-bes
...

Vérifiez ensuite l'état des points de terminaison individuels :

gcloud compute backend-services get-health my-bes --global

La section status: du résultat ressemble à ce qui suit :

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-w9nk
    ipAddress: 10.12.2.26
    port: 50000

Accéder à l'application

Accédez à l'application via l'adresse IP de l'équilibreur de charge pour vérifier que tout fonctionne correctement.

Remarque : La programmation complète de l'équilibreur de charge prend quelques minutes.

Commencez par obtenir l'adresse IP virtuelle de l'équilibreur de charge :

gcloud compute addresses describe hostname-server-vip --global | grep "address:"

Le résultat inclut une adresse IP. Envoyez ensuite une requête à cette adresse IP (34.98.102.37 dans cet exemple) :

curl 34.98.102.37

La réponse de l'application serve_hostname doit être neg-demo-app.

Associer un équilibreur de charge d'application interne à des NEG autonomes

Vous pouvez utiliser les NEG pour configurer un équilibreur de charge d'application interne pour vos services exécutés dans des pods GKE autonomes.

Configurer le sous-réseau proxy réservé

Le sous-réseau proxy réservé est destiné à tous les équilibreurs de charge d'application internes régionaux de la région de l'équilibreur de charge.

Important : N'essayez pas d'attribuer des adresses du sous-réseau proxy réservé à la règle de transfert ou aux backends de votre équilibreur de charge. Vous devez attribuer l'adresse IP de la règle de transfert et les adresses IP de l'instance backend depuis une ou plusieurs plages de sous-réseaux différentes du sous-réseau proxy réservé. Google Cloud réserve la plage de sous-réseaux aux proxys gérés par Google Cloud.

Console

Si vous utilisez Google Cloud Console, vous pouvez attendre et créer le sous-réseau proxy réservé ultérieurement.

gcloud

Créez le sous-réseau proxy réservé à l'aide de la commande gcloud compute networks subnets create.

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=lb-network \
    --range=10.129.0.0/23

Remplacez COMPUTE_REGION par Compute Engine pour le sous-réseau.

API

Créez le sous-réseau proxy réservé à l'aide de la commande subnetworks.insert.

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/COMPUTE_REGION",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

Remplacez les éléments suivants :

• PROJECT_ID : ID de votre projet.
• COMPUTE_REGION : Compute Engine du sous-réseau.

Configurer les règles de pare-feu

Cet exemple utilise les règles de pare-feu suivantes :

• fw-allow-ssh : règle d'entrée, applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise la connectivité SSH entrante sur le port TCP 22 à partir de n'importe quelle adresse. Vous pouvez choisir une plage d'adresses IP sources plus restrictive pour cette règle. Par exemple, vous pouvez spécifier uniquement les plages d'adresses IP du système à partir duquel vous souhaitez lancer des sessions SSH. Cet exemple utilise le tag cible allow-ssh pour identifier les VM auxquelles la règle de pare-feu s'applique.

• fw-allow-health-check : règle d'entrée, applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise tout le trafic TCP issu des systèmes de vérification d'état Google Cloud (dans 130.211.0.0/22 et 35.191.0.0/16). Cet exemple utilise le tag cible load-balanced-backend pour identifier les instances auxquelles la règle doit s'appliquer.

• fw-allow-proxies : règle d'entrée applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise le trafic TCP sur le pors 9376 à partir des proxys gérés de l'équilibreur de charge HTTP(S) interne. Cet exemple utilise le tag cible load-balanced-backend pour identifier les instances auxquelles la règle doit s'appliquer.

Sans ces règles de pare-feu, la règle d'entrée interdite par défaut bloque le trafic entrant vers les instances backend.

Console

1. Accédez à la page Stratégies de pare-feu de la console Google Cloud.

   Accéder à la page Stratégies de pare-feu

2. Cliquez de nouveau sur Créer une règle de pare-feu pour créer la règle autorisant les connexions SSH entrantes :

   • Nom : fw-allow-ssh
   • Réseau : lb-network
   • Sens du trafic : entrée
   • Action en cas de correspondance : autoriser
   • Cibles : tags cibles spécifiés
   • Tags cibles : allow-ssh
   • Filtre source : IPv4 ranges
   • Plages IPv4 sources : 0.0.0.0/0
   • Protocoles et ports :
     • Sélectionnez Protocoles et ports spécifiés.
     • Cochez la case tcp et spécifiez le port 22.

3. Cliquez sur Créer.

4. Cliquez à nouveau sur Créer une règle de pare-feu pour créer la règle autorisant les vérifications d'état Google Cloud :

   • Nom : fw-allow-health-check
   • Réseau : lb-network
   • Sens du trafic : entrée
   • Action en cas de correspondance : autoriser
   • Cibles : tags cibles spécifiés
   • Tags cibles : load-balanced-backend
   • Filtre source : IPv4 ranges
   • Plages IPv4 sources : 130.211.0.0/22 et 35.191.0.0/16
   • Protocoles et ports :
     • Sélectionnez Protocoles et ports spécifiés.
     • Cochez la case tcp et spécifiez le port 80. Nous vous recommandons de limiter cette règle aux seuls protocoles et ports qui correspondent à ceux utilisés par votre vérification de l'état. Si vous utilisez tcp:80 pour le protocole et le port, Google Cloud peut contacter vos VM via HTTP sur le port 80, mais pas via HTTPS sur le port 443.

5. Cliquez sur Créer.

6. Cliquez à nouveau sur Créer une règle de pare-feu pour créer la règle autorisant les serveurs proxy de l'équilibreur de charge à se connecter aux backends :

   • Nom : fw-allow-proxies
   • Réseau : lb-network
   • Sens du trafic : entrée
   • Action en cas de correspondance : autoriser
   • Cibles : tags cibles spécifiés
   • Tags cibles : load-balanced-backend
   • Filtre source : IPv4 ranges
   • Plages IPv4 sources : 10.129.0.0/23
   • Protocoles et ports :
     • Sélectionnez Protocoles et ports spécifiés.
     • Cochez la case tcp et spécifiez le port 9376.

7. Cliquez sur Create (Créer).

gcloud

1. Créez la règle de pare-feu fw-allow-ssh pour autoriser la connectivité SSH aux VM avec le tag réseau allow-ssh. Lorsque vous omettez source-ranges, Google Cloud interprète la règle comme désignant n'importe quelle source.

   gcloud compute firewall-rules create fw-allow-ssh \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-ssh \
       --rules=tcp:22
   

2. Créez la règle fw-allow-health-check pour autoriser les vérifications d'état Google Cloud. Cet exemple autorise tout le trafic TCP provenant des tests de vérification d'état. Toutefois, vous pouvez configurer un ensemble de ports plus restreint en fonction de vos besoins.

   gcloud compute firewall-rules create fw-allow-health-check \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=load-balanced-backend \
       --rules=tcp
   

3. Créez la règle fw-allow-proxies pour autoriser les proxys de l'équilibreur de charge HTTP(S) interne à se connecter à vos backends.

   gcloud compute firewall-rules create fw-allow-proxies \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --source-ranges=10.129.0.0/23 \
       --target-tags=load-balanced-backend \
       --rules=tcp:9376
   

API

Créez la règle de pare-feu fw-allow-ssh en envoyant une requête POST à la méthode firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

Remplacez PROJECT_ID par l'ID du projet.

Créez la règle de pare-feu fw-allow-health-check en envoyant une requête POST à la méthode firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

Créez la règle de pare-feu fw-allow-proxies pour autoriser le trafic TCP dans le sous-réseau proxy à l'aide de la méthode firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "9376"
      ]
    }
  ],
  "direction": "INGRESS"
}

Remplacez PROJECT_ID par l'ID du projet.

Configurer l'équilibreur de charge

Pour l'adresse IP de la règle de transfert, utilisez un sous-réseau backend. Si vous essayez d'utiliser le sous-réseau proxy réservé, la création de la règle de transfert échoue.

Console

Sélectionner un type d'équilibreur de charge

1. Accédez à la page Créer un équilibreur de charge dans Google Cloud Console. Accéder à la page Créer un équilibreur de charge
2. Dans la section Équilibrage de charge HTTP(S), cliquez sur Démarrer la configuration.
3. Sélectionnez Seulement entre les VM. Ce paramètre signifie que l'équilibreur de charge est interne.
4. Cliquez sur Continuer.

Préparer l'équilibreur de charge

1. Pour le nom de l'équilibreur de charge, saisissez l7-ilb-gke-map.
2. Dans le champ Région, sélectionnez la région dans laquelle vous avez créé le sous-réseau.
3. Pour le réseau, sélectionnez lb-network.

Réserver un sous-réseau proxy réservé

Remarque : Si vous avez déjà réservé un sous-réseau proxy, comme indiqué, le bouton Réserver un sous-réseau ne s'affiche pas. Vous devez donc ignorer cette section et passer directement aux étapes décrites dans la section Configurer le service de backend.

Réserver un sous-réseau proxy réservé

1. Cliquez sur Réserver un sous-réseau.
2. Dans le champ Nom, saisissez proxy-only-subnet.
3. Pour la plage d'adresses IP, saisissez 10.129.0.0/23.
4. Cliquez sur Ajouter.

Configurer le service de backend

1. Cliquez sur Configuration du backend.
2. Dans le menu Créer ou sélectionner des services de backend, sélectionnez Créer un service backend.
3. Définissez le paramètre Nom du service de backend sur l7-ilb-gke-backend-service.
4. Pour Type de backend, sélectionnez Groupes de points de terminaison du réseau.
5. Dans la carte Nouveau backend de la section Backends :
   1. Définissez le groupe de points de terminaison du réseau sur le NEG créé par GKE. Pour obtenir le nom du NEG, consultez la page Valider la création du NEG.
   2. Dans le champ Maximum RPS (Nombre maximal de RPS), spécifiez un taux maximal de 5 RPS par point de terminaison. Google Cloud dépassera ce maximum si nécessaire.
   3. Cliquez sur OK.
6. Dans la liste déroulante Health check (Vérification d'état), sélectionnez Create a health check (Créer une vérification d'état), puis spécifiez les paramètres suivants :
   1. Nom : l7-ilb-gke-basic-check
   2. Protocole : HTTP
   3. Spécification du port : port en service
   4. Cliquez sur Enregistrer et continuer.
7. Cliquez sur Create (Créer).

Configurez le mappage d'URL

1. Cliquez sur Règles de routage. Assurez-vous que le service l7-ilb-gke-backend-service est le seul service de backend pour tous les hôtes et chemins d'accès sans correspondance.

Configurer l'interface

Cliquez sur Configuration du frontend et procédez comme suit :

Pour HTTP :

1. Cliquez sur Configuration du frontend.
2. Cliquez sur Ajouter une adresse IP et un port frontend.
3. Définissez le nom sur l7-ilb-gke-forwarding-rule.
4. Définissez le protocole sur HTTP.
5. Définissez le sous-réseau sur backend-subnet.
6. Sous Adresse IP interne, sélectionnez Réserver une adresse IP statique interne.
7. Dans le panneau qui s'affiche, fournissez les informations suivantes :
   1. Nom : l7-ilb-gke-ip
   2. Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
   3. Dans la section Adresse IP personnalisée, saisissez 10.1.2.199.
   4. Cliquez sur Réserver.
8. Définissez le paramètre Port sur 80.
9. Cliquez sur OK.

Pour HTTPS :

Si vous utilisez HTTPS entre le client et l'équilibreur de charge, vous devez disposer d'une ou de plusieurs ressources de certificat SSL pour configurer le proxy. Pour en savoir plus sur la création de ressources de certificats SSL, consultez la documentation sur les certificats SSL. Les certificats gérés par Google ne sont pas compatibles avec les équilibreurs de charge HTTP(S) internes.

1. Cliquez sur Configuration de l'interface.
2. Cliquez sur Ajouter une adresse IP et un port frontend.
3. Dans le champ Nom, saisissez l7-ilb-gke-forwarding-rule.
4. Dans le champ Protocole, sélectionnez HTTPS (includes HTTP/2).
5. Définissez le sous-réseau sur backend-subnet.
6. Sous Adresse IP interne, sélectionnez Réserver une adresse IP statique interne.
7. Dans le panneau qui s'affiche, fournissez les informations suivantes :
   1. Nom : l7-ilb-gke-ip
   2. Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
   3. Dans la section Adresse IP personnalisée, saisissez 10.1.2.199.
   4. Cliquez sur Réserver.
8. Assurez-vous que le port est défini sur la valeur 443 pour autoriser le trafic HTTPS.
9. Cliquez sur la liste déroulante Certificat.
   1. Si vous possédez déjà une ressource de certificat SSL autogérée que vous souhaitez utiliser comme certificat SSL principal, sélectionnez-la dans le menu déroulant.
   2. Sinon, sélectionnez Créer un certificat.
      1. Pour le nom, indiquez l7-ilb-cert.
      2. Dans les champs appropriés, importez vos fichiers au format PEM :
         • Certificat de clé publique
         • Chaîne de certificats
         • Clé privée
      3. Cliquez sur Create (Créer).
10. Pour ajouter des ressources de certificat en plus de la ressource de certificat SSL principale, procédez comme suit :
    1. Cliquez sur Ajouter un certificat.
    2. Sélectionnez un certificat dans la liste Certificats ou cliquez sur Créer un certificat, puis suivez les instructions.
11. Cliquez sur OK.

Terminer la configuration

Cliquez sur Create (Créer).

gcloud

1. Définissez la vérification de l'état HTTP à l'aide de la commande gcloud compute health-checks create http.

   gcloud compute health-checks create http l7-ilb-gke-basic-check \
       --region=COMPUTE_REGION \
       --use-serving-port
   

2. Définissez le service de backend à l'aide de la commande gcloud compute backend-services create.

   gcloud compute backend-services create l7-ilb-gke-backend-service \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --protocol=HTTP \
       --health-checks=l7-ilb-gke-basic-check \
       --health-checks-region=COMPUTE_REGION \
       --region=COMPUTE_REGION
   

3. Définissez la variable DEPLOYMENT_NAME :

   export DEPLOYMENT_NAME=NEG_NAME
   

   Remplacez NEG_NAME par le nom du NEG.

4. Ajoutez des backends de groupe de points de terminaison du réseau au service de backend à l'aide de la commande gcloud compute backend-services add-backend.

   gcloud compute backend-services add-backend l7-ilb-gke-backend-service \
       --network-endpoint-group=$DEPLOYMENT_NAME \
       --network-endpoint-group-zone=COMPUTE_ZONE-b \
       --region=COMPUTE_REGION \
       --balancing-mode=RATE \
       --max-rate-per-endpoint=5
   

5. Créez le mappage d'URL à l'aide de la commande gcloud compute url-maps create.

   gcloud compute url-maps create l7-ilb-gke-map \
       --default-service=l7-ilb-gke-backend-service \
       --region=COMPUTE_REGION
   

6. Créez le proxy cible.

   Pour HTTP :

   Utilisez la commande gcloud compute target-http-proxies create.

   gcloud compute target-http-proxies create l7-ilb-gke-proxy \
       --url-map=l7-ilb-gke-map \
       --url-map-region=COMPUTE_REGION \
       --region=COMPUTE_REGION
   

   Pour HTTPS :

   Pour en savoir plus sur la création de ressources de certificats SSL, consultez la documentation sur les certificats SSL. Les certificats gérés par Google ne sont pas compatibles avec les équilibreurs de charge HTTP(S) internes.

   Attribuez vos chemins de fichiers à des noms de variables.

   export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
   

   export LB_PRIVATE_KEY=PATH_TO_PEM_FORMATTED_FILE
   

   Créez un certificat SSL régional à l'aide de la commande gcloud compute ssl-certificates create.

   gcloud compute ssl-certificates create

   gcloud compute ssl-certificates create l7-ilb-cert \
       --certificate=$LB_CERT \
       --private-key=$LB_PRIVATE_KEY \
       --region=COMPUTE_REGION
   

   Utilisez le certificat SSL régional pour créer le proxy cible à l'aide de la commande gcloud compute target-https-proxies create.

   gcloud compute target-https-proxies create l7-ilb-gke-proxy \
       --url-map=l7-ilb-gke-map \
       --region=COMPUTE_REGION \
       --ssl-certificates=l7-ilb-cert
   

7. Créez la règle de transfert.

   Pour les réseaux personnalisés, vous devez faire référence au sous-réseau dans la règle de transfert. Notez qu'il s'agit du sous-réseau de VM et non du sous-réseau proxy.

   Pour HTTP :

   Utilisez la commande gcloud compute forwarding-rules create avec les options appropriées.

   gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=backend-subnet \
       --address=10.1.2.199 \
       --ports=80 \
       --region=COMPUTE_REGION \
       --target-http-proxy=l7-ilb-gke-proxy \
       --target-http-proxy-region=COMPUTE_REGION
   

   Pour HTTPS :

   Utilisez la commande gcloud compute forwarding-rules create avec les options appropriées.

   gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=backend-subnet \
       --address=10.1.2.199 \
       --ports=443 \
       --region=COMPUTE_REGION \
       --target-https-proxy=l7-ilb-gke-proxy \
       --target-https-proxy-region=COMPUTE_REGION
   

API

Créez la vérification d'état en envoyant une requête POST à la méthode regionHealthChecks.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks

{
   "name": "l7-ilb-gke-basic-check",
   "type": "HTTP",
   "httpHealthCheck": {
     "portSpecification": "USE_SERVING_PORT"
   }
}

Remplacez PROJECT_ID par l'ID du projet.

Créez le service de backend régional en envoyant une requête POST à la méthode regionBackendServices.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices

{
  "name": "l7-ilb-gke-backend-service",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/networkEndpointGroups/NEG_NAME",
      "balancingMode": "RATE",
      "maxRatePerEndpoint": 5
    }
  ],
  "healthChecks": [
    "projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks/l7-ilb-gke-basic-check"
  ],
  "loadBalancingScheme": "INTERNAL_MANAGED"
}

Remplacez les éléments suivants :

• PROJECT_ID : ID du projet.
• NEG_NAME : nom du NEG.

Créez le mappage d'URL en envoyant une requête POST à la méthode regionUrlMaps.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/urlMaps

{
  "name": "l7-ilb-gke-map",
  "defaultService": "projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices/l7-ilb-gke-backend-service"
}

Remplacez PROJECT_ID par l'ID du projet.

Créez le proxy HTTP cible en envoyant une requête POST à la méthode regionTargetHttpProxies.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxy

{
  "name": "l7-ilb-gke-proxy",
  "urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-gke-map",
  "region": "COMPUTE_REGION"
}

Remplacez PROJECT_ID par l'ID du projet.

Créez la règle de transfert en envoyant une requête POST à la méthode forwardingRules.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/forwardingRules

{
  "name": "l7-ilb-gke-forwarding-rule",
  "IPAddress": "10.1.2.199",
  "IPProtocol": "TCP",
  "portRange": "80-80",
  "target": "projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxies/l7-ilb-gke-proxy",
  "loadBalancingScheme": "INTERNAL_MANAGED",
  "subnetwork": "projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks/backend-subnet",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "networkTier": "PREMIUM",
}

Remplacez PROJECT_ID par l'ID du projet.

Tests

Créez une instance de VM dans la zone pour tester la connectivité :

gcloud compute instances create l7-ilb-client \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --zone=COMPUTE_ZONE \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=l7-ilb-client,allow-ssh

Connectez-vous à l'instance cliente pour vérifier que les services HTTP(S) des backends sont accessibles via l'adresse IP de la règle de transfert de l'équilibreur de charge d'application interne, et que le trafic fait l'objet d'un équilibrage de charge entre les points de terminaison du NEG.

Connectez-vous à chaque instance de client à l'aide de SSH :

gcloud compute ssh l7-ilb-client \
    --zone=COMPUTE_ZONE-b

Vérifiez que l'adresse IP diffuse son nom d'hôte :

curl 10.1.2.199

Pour effectuer un test HTTPS, exécutez la commande suivante :

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443

L'option -k indique à curl d'ignorer l'étape de validation du certificat.

Exécutez 100 requêtes et vérifiez que leur charge est équilibrée.

Pour HTTP :

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl --silent 10.1.2.199)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Pour HTTPS :

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Mettre en œuvre des services hétérogènes (VM et conteneurs)

Les équilibreurs de charge peuvent faire office d'interfaces pour des charges de travail mixtes Kubernetes et non-Kubernetes. Cela peut se produire dans le cadre d'une migration de VM vers des conteneurs. Il peut également s'agir d'une architecture permanente bénéficiant d'un équilibreur de charge partagé. Pour ce faire, vous pouvez créer des équilibreurs de charge qui ciblent différents types de backends, y compris les NEG autonomes.

VM et conteneurs dans le même service de backend

Cet exemple montre comment créer un NEG qui pointe vers une VM existante exécutant une charge de travail, et comment ajouter ce NEG en tant que backend supplémentaire d'un backendService existant. De cette façon, un seul équilibreur de charge s'équilibre entre les VM et les conteneurs GKE.

Cet exemple étend l'exemple précédent qui utilise un équilibreur de charge HTTP externe.

Étant donné que tous les points de terminaison sont regroupés par le même backendService, les points de terminaison de VM et de conteneurs sont considérés comme faisant partie d'un même service. Cela signifie que la correspondance d'hôte ou de chemin d'accès traitera tous les backends de manière identique en fonction des règles de mappage d'URL.

Lorsque vous utilisez un NEG en tant que backend pour un service de backend, tous les autres backends de ce service doivent également être des NEG. Vous ne pouvez pas utiliser à la fois des groupes d'instances et des NEG sur le même service de backend. De plus, les conteneurs et les VM ne peuvent pas exister en tant que points de terminaison dans le même NEG. Par conséquent, ils doivent toujours être configurés avec des NEG distincts.

1. Déployez une VM sur Compute Engine à l'aide de la commande suivante :

   gcloud compute instances create vm1 \
       --zone=COMPUTE_ZONE \
       --network=NETWORK \
       --subnet=SUBNET \
       --image-project=cos-cloud \
       --image-family=cos-stable --tags=vm-neg-tag
   

   Remplacez les éléments suivants :

   • COMPUTE_ZONE : nom de la zone.
   • NETWORK : nom du réseau.
   • SUBNET : nom du sous-réseau associé au réseau

2. Déployez une application sur la VM :

   gcloud compute ssh vm1 \
       --zone=COMPUTE_ZONE \
       --command="docker run -d --rm --network=host registry.k8s.io/serve_hostname:v1.4 && sudo iptables -P INPUT ACCEPT"
   

   Cette commande déploie l'exemple d'application utilisé dans l'exemple précédent sur la VM. Pour plus de simplicité, l'application est exécutée en tant que conteneur Docker, mais ce n'est pas obligatoire. La commande iptables est requise pour autoriser l'accès du pare-feu au conteneur en cours d'exécution.

3. Vérifiez que l'application est diffusée sur le port 9376 et qu'elle s'exécute sur vm1 :

   gcloud compute ssh vm1 \
       --zone=COMPUTE_ZONE \
       --command="curl -s localhost:9376"
   

   Le serveur doit envoyer la réponse suivante : vm1.

4. Créez un NEG à utiliser avec le point de terminaison de VM. Les conteneurs et les VM peuvent les uns comme les autres servir de points de terminaison NEG, mais un seul NEG ne peut pas contenir à la fois des points de terminaison de VM et de conteneurs.

   gcloud compute network-endpoint-groups create vm-neg \
       --subnet=SUBNET \
       --zone=COMPUTE_ZONE
   

5. Associez le point de terminaison de VM au NEG :

   gcloud compute network-endpoint-groups update vm-neg \
       --zone=COMPUTE_ZONE \
       --add-endpoint="instance=vm1,ip=VM_PRIMARY_IP,port=9376"
   

   Remplacez VM_PRIMARY_IP par l'adresse IP principale de la VM.

6. Confirmez que le NEG possède le point de terminaison de VM :

   gcloud compute network-endpoint-groups list-network-endpoints vm-neg \
       --zone COMPUTE_ZONE
   

7. Associez le NEG au service de backend à l'aide de la commande qui vous a précédemment servi à ajouter un backend de conteneur :

   gcloud compute backend-services add-backend my-bes
       --global \
       --network-endpoint-group vm-neg \
       --network-endpoint-group-zone COMPUTE_ZONE \
       --balancing-mode RATE --max-rate-per-endpoint 10
   

8. Ouvrez le pare-feu pour autoriser la vérification d'état de la VM :

   gcloud compute firewall-rules create fw-allow-health-check-to-vm1 \
       --network=NETWORK \
       --action=allow \
       --direction=ingress \
       --target-tags=vm-neg-tag \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --rules=tcp:9376
   

9. Vérifiez que l'équilibreur de charge transfère le trafic à la fois vers le nouveau backend vm1 et vers le backend de conteneur existant en envoyant le trafic de test :

   for i in `seq 1 100`; do curl ${VIP};echo; done
   

   Vous devriez voir les réponses des points de terminaison du conteneur (neg-demo-app) et de la VM (vm1).

Des VM et des conteneurs pour différents services de backend

Cet exemple montre comment créer un NEG qui pointe vers une VM existante exécutant une charge de travail, et comment ajouter ce NEG en tant que backend à un nouveau backendService. Cela s'avère utile lorsque les conteneurs et les VM sont des services différents, mais doivent partager le même équilibreur de charge L7 (par exemple, lorsque les services partagent la même adresse IP ou le même nom de domaine).

Cet exemple étend l'exemple précédent, qui contient un backend de VM dans le même service de backend que le backend de conteneur. Cet exemple réutilise cette VM.

Les points de terminaison de conteneurs et de VM étant regroupés dans des services de backend distincts, ils sont considérés comme des services différents. Cela signifie que le mappage d'URL correspond aux backends et dirige le trafic vers la VM ou le conteneur en fonction du nom d'hôte.

Le schéma suivant illustre la correspondance entre une adresse IP virtuelle unique et deux noms d'hôte, correspondant eux-mêmes à un service de backend basé sur des conteneurs et un service de backend basé sur des VM.

Le schéma suivant illustre l'architecture décrite dans la section précédente :

1. Créez un service de backend pour la VM :

   gcloud compute backend-services create my-vm-bes \
      --protocol HTTP \
      --health-checks http-basic-check \
      --global
   

2. Associez le NEG de la VM (vm-neg) au service de backend :

   gcloud compute backend-services add-backend my-vm-bes \
       --global \
       --network-endpoint-group vm-neg \
       --network-endpoint-group-zone COMPUTE_ZONE \
       --balancing-mode RATE --max-rate-per-endpoint 10
   

3. Ajoutez une règle d'hôte au mappage d'URL pour diriger les requêtes de l'adresse hôte (container.example.com) vers le service de backend du conteneur :

   gcloud compute url-maps add-path-matcher web-map \
       --path-matcher-name=container-path --default-service=my-bes \
       --new-hosts=container.example.com --global
   

4. Ajoutez une autre règle d'hôte dans le mappage d'URL pour diriger les requêtes de l'adresse hôte (vm.example.com) vers le service de backend de la VM :

   gcloud compute url-maps add-path-matcher web-map \
       --path-matcher-name=vm-path --default-service=my-vm-bes \
       --new-hosts=vm.example.com --global
   

   Remarque : La programmation complète de l'équilibreur de charge prend quelques minutes.

5. Vérifiez que l'équilibreur de charge envoie le trafic vers le backend de VM en fonction du chemin demandé :

   curl -H "HOST:vm.example.com" VIRTUAL_IP
   

   Remplacez VIRTUAL_IP par l'adresse IP virtuelle.

Limites des NEG autonomes

• Les erreurs de validation des annotations sont exposées à l'utilisateur via les événements Kubernetes.
• Les limites des NEG s'appliquent également aux NEG autonomes.

• Les NEG autonomes ne fonctionnent pas avec les anciens réseaux.

• Les NEG autonomes ne peuvent être utilisés qu'avec des services réseau compatibles, parmi lesquels Traffic Director et les types d'équilibreurs de charge compatibles.

Tarification

Pour en savoir plus sur la tarification appliquée à l'équilibreur de charge, reportez-vous à la section Équilibrage de charge de la page des tarifs. Aucuns frais supplémentaires ne sont facturés pour les NEG.

Dépannage

Cette section fournit des étapes de dépannage pour les problèmes courants que vous pouvez rencontrer avec les NEG autonomes.

Aucun NEG autonome n'est configuré

Problème constaté : aucun NEG n'est créé.

Solution potentielle :

• Vérifiez les événements associés au Service et recherchez les messages d'erreur.
• Vérifiez que l'annotation du NEG autonome constitue un fichier JSON bien formé et que les ports exposés correspondent aux ports existants dans la spécification de Service.
• Vérifiez l'annotation d'état du NEG et assurez-vous que les ports de service attendus possèdent des NEG correspondants.
• Vérifiez que les NEG ont été créés dans les zones prévues, à l'aide de la commande gcloud compute network-endpoint-groups list.
• Si vous utilisez GKE version 1.18 ou ultérieure, vérifiez si la ressource svcneg du service existe. Si tel est le cas, vérifiez la condition Initialized pour obtenir des informations sur les erreurs.
• Si vous utilisez des noms de NEG personnalisés, assurez-vous que chaque nom de NEG est unique dans sa région.

Le trafic n'atteint pas les points de terminaison

Problème constaté : erreurs 502 ou connexions refusées.

Solution potentielle :

• Une fois le service configuré, les nouveaux points de terminaison sont généralement accessibles après leur association au NEG, à condition qu'ils répondent aux vérifications d'état.
• Une fois ces conditions remplies, si le trafic ne peut toujours pas atteindre les points de terminaison (ce qui génère alors une erreur de code 502 pour HTTP(S) ou occasionne des rejets de connexions pour les équilibreurs de charge TCP/SSL), vérifiez les points suivants :
  • Vérifiez que les règles de pare-feu autorisent le trafic TCP entrant vers vos points de terminaison à partir des plages d'adresses IP 130.211.0.0/22 et 35.191.0.0/16.
  • Vérifiez que vos points de terminaison sont opérationnels à l'aide de Google Cloud CLI ou en appelant l'API getHealth sur le backendService ou l'API listEndpoints du NEG avec le paramètre showHealth défini sur SHOW.

Blocage du déploiement

Problème constaté : le déploiement d'une mise à jour se bloque et le nombre d'instances répliquées à jour ne correspond pas au nombre d'instances répliquées choisi.

Solution potentielle :

Les vérifications d'état du déploiement échouent. Il est possible que l'image du conteneur soit incorrecte ou que la vérification d'état soit mal configurée. Le remplacement progressif des pods attend jusqu'à ce qu'un pod qui vient d'être lancé passe sa porte de disponibilité de pod. Cela ne se produit que si le pod répond aux vérifications d'état de l'équilibreur de charge. Si le pod ne répond pas ou si la vérification d'état est mal configurée, les conditions de la porte de disponibilité ne peuvent pas être remplies et le déploiement ne peut pas se poursuivre.

• Si vous utilisez kubectl en version 1.13 ou ultérieure, vous pouvez vérifier l'état des portes de disponibilité d'un pod à l'aide de la commande suivante :

  kubectl get my-Pod -o wide
  

  Vérifiez le contenu de la colonne READINESS GATES.

  Cette colonne n'existe pas dans les versions 1.12 et antérieures de kubectl. Un pod identifié comme étant dans l'état READY (prêt) peut néanmoins présenter une porte de disponibilité en échec. Pour le vérifier, exécutez la commande suivante :

  kubectl get my-pod -o yaml
  

  Les portes de disponibilité et leur état sont répertoriés dans le résultat.

• Vérifiez que l'image du conteneur référencée dans la spécification de déploiement de pod fonctionne correctement et qu'elle est en mesure de répondre aux vérifications d'état.

• Assurez-vous que les vérifications d'état sont correctement configurées.

Le NEG ne fait pas l'objet d'une récupération de mémoire

Problème constaté : un NEG qui aurait dû être supprimé est toujours présent.

Solution potentielle :

• Le NEG ne fait pas l'objet d'une récupération de mémoire s'il est référencé par un service de backend. Pour plus d'informations, consultez la section Prévenir la divulgation des NEG.
• Si vous utilisez la version 1.18 ou ultérieure, vous pouvez vérifier la présence d'événements dans la ressource ServiceNetworkEndpointGroup à l'aide de la procédure neg du service.
• Vérifiez si le NEG est toujours requis par un service. Consultez la ressource svcneg du service correspondant au NEG, puis vérifiez si une annotation de service existe.

Le NEG n'est pas synchronisé avec le service

Symptôme : les points de terminaison attendus (adresse IP du pod) n'existent pas dans le NEG, le NEG n'est pas synchronisé, ou erreur Failed to sync NEG_NAME (will not retry): neg name NEG_NAME is already in use, found a custom named neg with an empty description

Solution potentielle :

Si vous utilisez GKE 1.18 ou une version ultérieure, consultez la ressource svcneg pour obtenir des informations :

• Consultez la valeur status.lastSyncTime pour vérifier si le NEG a été synchronisé récemment.
• Vérifiez la condition Synced pour détecter toute erreur survenue lors de la synchronisation la plus récente.

Si vous utilisez GKE 1.19.9 ou une version ultérieure, vérifiez s'il existe un NEG dont le nom et la zone correspondent au nom et à la zone du NEG que le contrôleur de NEG GKE doit créer. Par exemple, un NEG portant le nom que le contrôleur de NEG doit utiliser a peut-être été créé à l'aide de gcloud CLI ou de la console Google Cloud dans la zone du cluster (ou de l'une des zones du cluster). Dans ce cas, vous devez supprimer le NEG existant avant que le contrôleur de NEG puisse synchroniser ses points de terminaison. La création et l'appartenance de NEG autonomes sont conçus pour être gérés par le contrôleur de NEG.

Étapes suivantes

• Présentation des groupes de points de terminaison du réseau zonaux
• Services de backend
• Créer des vérifications d'état
• Utiliser des proxys cibles
• Utiliser des règles de transfert