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

Cette page explique comment créer un service Kubernetes reposant sur un groupe de points de terminaison du réseau zonaux (NEG).

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 groupe de points de terminaison du réseau (NEG) est un groupe de backends diffusés par un équilibreur de charge. Les NEG représentent des listes d'adresses IP gérées par un contrôleur NEG et utilisées par les équilibreurs de charge Google Cloud. Les adresses IP d'un NEG peuvent être des adresses IP primaires ou secondaires d'une VM, ce qui signifie qu'il peut s'agir d'adresses IP de pods. Cela permet l'utilisation de l'équilibrage de charge natif en conteneurs, qui envoie le trafic directement aux pods depuis un équilibreur de charge Google Cloud.

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 NEG sont utilisés avec une entrée GKE, le contrôleur d'entrée facilite la création de tous les aspects de l'équilibreur de charge L7. 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

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 l'équilibrage de charge proxy TCP avec GKE

Vous pouvez utiliser des NEG autonomes pour équilibrer la charge directement sur les conteneurs dotés de l'équilibreur de charge proxy TCP, 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

Les NEG autonomes sont disponibles dans la version GKE 1.10 ou ultérieure. Le retour d'informations via la disponibilité des pods est activé pour les NEG autonomes des versions 1.16.4 et ultérieures.

Votre cluster doit être VPC natif. Pour en savoir plus, consultez la page Créer des clusters de VPC natif à l'aide d'adresses IP d'alias.

L'équilibrage de charge HTTP doit être activé sur votre cluster. L'équilibrage de charge HTTP est activé par défaut sur les clusters GKE. Vous ne devez pas le désactiver.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Assurez-vous d'avoir activé l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Assurez-vous d'avoir installé le SDK Cloud.

Configurez les paramètres gcloud par défaut à l'aide de l'une des méthodes suivantes :

• Utilisez gcloud init pour suivre les instructions permettant de définir les paramètres par défaut.
• Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

Utiliser gcloud init

Si le message d'erreur One of [--zone, --region] must be supplied: Please specify location s'affiche, effectuez les tâches ci-dessous.

1. Exécutez gcloud init et suivez les instructions :

   gcloud init

   Si vous utilisez SSH sur un serveur distant, utilisez l'option --console-only pour empêcher la commande d'ouvrir un navigateur :

   gcloud init --console-only

2. Suivez les instructions pour autoriser gcloud à utiliser votre compte Google Cloud.
3. Créez ou sélectionnez une configuration.
4. Choisissez un projet Google Cloud.
5. Choisissez une zone Compute Engine par défaut.

Remarque : Vous pouvez remplacer ces paramètres par défaut dans les commandes gcloud à l'aide des options --project, --zone et --region.

Utiliser gcloud config

• Définissez votre ID de projet par défaut :

  gcloud config set project project-id

• Si vous utilisez des clusters zonaux, définissez votre zone de calcul par défaut :

  gcloud config set compute/zone compute-zone

• Si vous utilisez des clusters régionaux, définissez votre région de calcul par défaut :

  gcloud config set compute/region compute-region

• Mettez à jour gcloud vers la dernière version :

  gcloud components update

Remarque : Vous pouvez remplacer ces paramètres par défaut dans les commandes gcloud à l'aide des options --project, --zone et --region.

Utiliser des NEG autonomes

Les instructions ci-dessous expliquent comment utiliser des NEG autonomes avec un équilibreur de charge HTTP externe sur GKE.

Ce processus implique la création de plusieurs objets :

• 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 ci-dessous :

Créer un cluster de VPC natif

Pour utiliser l'équilibrage de charge natif en conteneurs, vous devez créer un cluster avec des adresses IP d'alias activées. Ce cluster :

• doit exécuter Google Kubernetes Engine version 1.16.4 ou ultérieure ;
• doit être un cluster de VPC natif ;
• doit avoir le module complémentaire d'équilibrage de charge HTTP activé. L'équilibrage de charge HTTP est activé par défaut sur les clusters GKE. Vous ne devez pas le désactiver.

Cette commande crée un cluster (neg-demo-cluster) dans la zone us-central1-a, avec un sous-réseau provisionné automatiquement :

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

où la version du cluster doit être 1.16.4 ou ultérieure.

Créer un déploiement

Les fichiers manifestes ci-dessous spécifient un déploiement (neg-demo-app) qui exécute 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, si cette fonctionnalité est disponible dans la version de GKE que vous exploitez. Pour plus d'informations, reportez-vous à la section Disponibilité des pods ci-dessus. Consultez la section Exigences pour connaître les versions de GKE compatibles avec l'utilisation du retour d'informations via la disponibilité des pods. Envisagez de mettre à niveau votre cluster pour pouvoir utiliser le 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: k8s.gcr.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: k8s.gcr.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 ci-dessous spécifie un service, neg-demo-svc.

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

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

Aperçu

Ce produit ou cette fonctionnalité est couvert par les Conditions des offres avant disponibilité générale des conditions d'utilisation de Google Cloud Platform. Les fonctionnalités et produits avant disponibilité générale sont susceptibles de présenter une compatibilité limitée, et les modifications apportées à ces fonctionnalités ou produits peuvent ne pas être compatibles avec d'autres versions avant disponibilité générale. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Vous pouvez spécifier le nom du NEG ou lui attribuer un nom automatiquement. La spécification de vos noms de NEG simplifie les étapes suivantes, car vous connaîtrez les noms des NEG à l'avance sans avoir à les rechercher. Toutefois, vous devez vous assurer que les noms des NEG sont uniques au sein d'une région donnée, sinon la création d'un NEG échoue. Les noms des NEG générés automatiquement sont garantis et uniques.

Vous ne pouvez spécifier des noms de NEG que dans la version 1.18.10-gke.600 et ultérieure de GKE. Les noms des NEG générés sont utilisés dans les versions antérieures.

Specifying a name

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

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":{},
      ...
   }'

Ici, les service-port-n sont des numéros de port distincts qui font 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 cette commande pour récupérer les états des Services du cluster :

kubectl get service neg-demo-svc -o yaml

Cette commande affiche l'état des NEG au format suivant :

cloud.google.com/neg-status: '{
   "network-endpoint-groups":{
      "service-port-1": "neg-name-1",
      "service-port-1": "neg-name-2",
      ...
   },
   "zones":["zone-1", "zone-2", ...]
}

où chaque élément du mappage network-endpoint-groups correspond à un port de service (service-port-1) et au nom des NEG gérés correspondants (tels que neg-name-1). La liste zones répertorie toutes les zones (telles que zone-1) qui contiennent un NEG.

L'exemple ci-dessous correspond au résultat complet de la commande :

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":["us-central1-a", "us-central1-b"]}'
  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, situés dans les zones us-central1-a et us-central1-b.

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 deviez 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 en savoir plus, vous pouvez interroger l'objet de service :

kubectl describe service service-name

Remplacez service-name par le nom du service concerné.

Pour vérifier que le contrôleur du 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 cette commande pour répertorier les NEG :

gcloud compute network-endpoint-groups list

Le résultat se présente comme suit :

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  us-central1-a  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 cette commande :

gcloud compute network-endpoint-groups list-network-endpoints \
    k8s1-70aa83a6-default-my-service-80-c9710a6f

Le résultat indique trois points de terminaison, chacun d'entre eux étant associé à l'adresse IP et au port d'un pod :

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

Associer un équilibreur de charge aux NEG autonomes

Maintenant que vous avez créé vos NEG, vous pouvez les utiliser comme backends pour les types d'équilibreurs de charge suivants :

• Un équilibreur de charge HTTP(S) externe
• Un équilibreur de charge HTTP(S) interne
• Un équilibreur de charge proxy SSL
• Un équilibreur de charge proxy TCP

Les exemples suivants décrivent deux approches :

• Associer un équilibreur de charge HTTP(S) externe à des NEG autonomes
• Associer un équilibreur de charge HTTP(S) interne à des NEG autonomes

Associer un équilibreur de charge HTTP(S) externe aux NEG autonomes

La procédure décrite ci-dessous permet de créer un équilibreur de charge HTTP externe à l'aide de l'API Compute Engine.

1. Créez des règles 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 des règles de pare-feu qui autorisent cet 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

   où gke-node-network-tags correspond aux tags réseau des nœuds GKE, et network-name au réseau sur lequel le cluster s'exécute.

   Si vous n'avez pas créé de tags réseau personnalisés pour vos nœuds, GKE en génère à votre place. Vous pouvez rechercher ces tags générés automatiquement en consultant les nœuds avec la commande suivante :

   gcloud compute instances describe node-name
   

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 HTTP(S) 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

   hostname-server-vip est l'adresse IP à utiliser pour l'équilibreur de charge. Vous pouvez réserver une nouvelle adresse IP externe statique à cette fin. Vous pouvez également omettre l'option --address pour qu'une adresse IP éphémère soit attribuée automatiquement.

Point de contrôle

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 ci-dessous :

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 objets Service 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 d'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 network-endpoint-group-name \
   --network-endpoint-group-zone network-endpoint-group-zone \
   --balancing-mode RATE --max-rate-per-endpoint 5

Remplacez l'élément suivant :

• Remplacez network-endpoint-group-name par le nom de votre groupe de points de terminaison du réseau. Il s'agit du nom que vous avez spécifié lors de la création du groupe de points de terminaison du réseau ou d'un nom généré automatiquement. Si vous n'avez pas spécifié de nom pour le NEG, consultez les instructions ci-dessous pour trouver le nom généré automatiquement.
• network-endpoint-group-zone correspond à la zone dans laquelle se trouve le groupe de points de terminaison du réseau. Reportez-vous aux instructions ci-dessous 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 se présente comme suit :

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  us-central1-a  GCE_VM_IP_PORT  3

Dans cet exemple de résultat, le nom du NEG est k8s1-70aa83a6-default-my-service-80-c9710a6f et il se trouve dans la zone us-central1-a.

Plusieurs NEG peuvent être ajoutés au même service de backend. Les backends des 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 manières de vérifier que l'équilibreur de charge que vous configurez est fonctionnel : en s'assurant que la vérification d'état est correctement configurée et génère des rapports d'état opérationnel, ou en accédant à l'application et en vérifiant 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 se présente comme 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 doit se présenter comme suit :

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-standard-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-standard-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-standard-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 HTTP(S) interne aux NEG autonomes

Cette section fournit des instructions pour configurer l'équilibrage de charge HTTP(S) 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 HTTP(S) internes de la région de l'équilibreur de charge, us-west1 dans cet exemple.

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 de backend depuis une ou plusieurs plages de sous-réseaux différentes, et non depuis celle-ci. Google Cloud réserve cette plage de sous-réseaux aux proxys gérés par Google Cloud.

console

Si vous utilisez la console GCP, vous pouvez attendre et créer le sous-réseau proxy réservé plus tard dans l'interface utilisateur de l'équilibrage de charge.

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=INTERNAL_HTTPS_LOAD_BALANCER \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

api

Créez le sous-réseau proxy réservé avec la méthode subnetworks.insert, en remplaçant project-id par votre ID de projet.

POST https://compute.googleapis.com/compute/projects/project-id/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/project-id/global/networks/lb-network",
  "region": "projects/project-id/regions/us-west1",
  "purpose": "INTERNAL_HTTPS_LOAD_BALANCER",
  "role": "ACTIVE"
}

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 les ports 80, 443 et 8000 à 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 "Règles de pare-feu" de Google Cloud Console.
   Accéder à la page "Règles 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 : IP ranges
   • Plages d'adresses IP sources : 0.0.0.0/0
   • Protocoles et ports :
     • Choisissez Protocoles et ports spécifiés.
     • Vérifiez tcp et saisissez 22 pour le numéro de port.
3. Cliquez sur Créer.
4. Cliquez une deuxième fois 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 : IP ranges
   • Plages d'adresses IP sources : 130.211.0.0/22 et 35.191.0.0/16
   • Protocoles et ports :
     • Choisissez Protocoles et ports spécifiés.
     • Vérifiez tcp et saisissez 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 une troisième fois 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 : IP ranges
   • Plages d'adresses IP sources : 10.129.0.0/23
   • Protocoles et ports :
     • Choisissez Protocoles et ports spécifiés.
     • Vérifiez tcp et saisissez 80, 443, 8000 pour les numéros de port.
7. Cliquez sur 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:80,tcp:443,tcp:8000
   

api

Créez la règle de pare-feu fw-allow-ssh en envoyant une requête POST à la méthode firewalls.insert, en remplaçant project-id par l'ID de votre projet.

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

Créez la règle de pare-feu fw-allow-health-check en envoyant une requête POST à la méthode firewalls.insert, en remplaçant project-id par l'ID de votre projet.

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 au sein du sous-réseau proxy à l'aide de la méthode firewalls.insert, en remplaçant project-id par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/{project}/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": [
        "80"
      ]
    },
  {
      "IPProtocol": "tcp",
      "ports": [
        "443"
      ]
    },
    {
      "IPProtocol": "tcp",
      "ports": [
        "8000"
      ]
    }
  ],
  "direction": "INGRESS"
}

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 Équilibrage de charge dans Google Cloud Console.
   Accéder à la page "Équilibrage 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. Pour la région, sélectionnez us-west1.
3. Pour le réseau, sélectionnez lb-network.
4. Laissez la fenêtre ouverte pour continuer.

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.

Pour l'équilibrage de charge HTTP(S) interne, réservez un sous-réseau proxy :

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. Sous 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. Saisissez 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 section Vérification d'état, sélectionnez Créer une vérification d'état avec 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 Créer.

Configurez le mappage d'URL

1. Cliquez sur Host and path rules (Règles d'hôte et de chemin d'accès). 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

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. À l'heure actuelle, les certificats gérés par Google ne sont pas compatibles avec les équilibreurs de charge HTTP(S) internes.

1. Cliquez sur Configuration du frontend.
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 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 ci-dessus.
11. Cliquez sur OK.

Terminer la configuration

1. Cliquez sur 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=us-west1 \
      --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=us-west1 \
     --region=us-west1
   

3. Définissez la variable DEPLOYMENT_NAME :

   export DEPLOYMENT_NAME=neg-name
   

   Où neg-name est le nom du groupe de points de terminaison par 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=us-west1-b \
      --region=us-west1 \
      --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=us-west1
   

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=us-west1 \
     --region=us-west1
   

   Pour HTTPS :

   Pour en savoir plus sur la création de ressources de certificats SSL, consultez la documentation sur les certificats SSL. À l'heure actuelle, 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=us-west1
   

   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=us-west1 \
     --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=us-west1 \
     --target-http-proxy=l7-ilb-gke-proxy \
     --target-http-proxy-region=us-west1
   

   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=us-west1 \
     --target-https-proxy=l7-ilb-gke-proxy \
     --target-https-proxy-region=us-west1
   

api

Créez la vérification de l'état en envoyant une requête POST à la méthode regionHealthChecks.insert, en remplaçant project-id par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/healthChecks

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

Créez le service de backend régional en générant une requête POST sur la méthode regionBackendServices.insert, en remplaçant project-id par l'ID de votre projet et neg-name par le nom du NEG créé.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/backendServices

{
  "name": "l7-ilb-gke-backend-service",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/project-id/zones/us-west1-b/networkEndpointGroups/neg-name",
      "balancingMode": "RATE",
      "maxRatePerEndpoint": 5
    }
  ],
  "healthChecks": [
    "projects/project-id/regions/us-west1/healthChecks/l7-ilb-gke-basic-check"
  ],
  "loadBalancingScheme": "INTERNAL_MANAGED"
}

Créez le mappage d'URL en envoyant une requête POST à la méthode regionUrlMaps.insert, en remplaçant project-id par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/urlMaps

{
  "name": "l7-ilb-gke-map",
  "defaultService": "projects/project-id/regions/us-west1/backendServices/l7-ilb-gke-backend-service"
}

Créez le proxy HTTP cible en envoyant une requête POST à la méthode regionTargetHttpProxies.insert, en remplaçant project-id par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/targetHttpProxy

{
  "name": "l7-ilb-gke-proxy",
  "urlMap": "projects/project-id/global/urlMaps/l7-ilb-gke-map",
  "region": "us-west1"
}

Créez la règle de transfert en envoyant une requête POST à la méthode forwardingRules.insert, en remplaçant project-id par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/forwardingRules

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

Test

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

gcloud compute instances create l7-ilb-client-us-west1-b \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --zone=us-west1-b \
    --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) sur les backends sont accessibles via l'adresse IP de la règle de transfert de l'équilibreur de charge HTTP(S) interne, et pour vérifier que le trafic fait l'objet d'un équilibrage de charge entre les points de terminaison du groupe de points de terminaison du réseau.

Connectez-vous à chaque instance de client via SSH.

gcloud compute ssh l7-ilb-client-us-west1-b \
    --zone=us-west1-b

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

curl 10.1.2.199

Pour le test HTTPS, remplacez curl par :

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 ci-dessus qui utilise un équilibreur de charge HTTP externe.

Étant donné que tous les points de terminaison sont regroupés par le même service de backend (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 hôte/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 zone --network=network \
    --subnet=subnet --image-project=cos-cloud \
    --image-family=cos-stable --tags=vm-neg-tag

2. Déployez une application sur la VM :

   gcloud compute ssh vm1 --zone=${ZONE} --command="docker run -d --rm --network=host \
    k8s.gcr.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=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=zone

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

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

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

   gcloud compute network-endpoint-groups list-network-endpoints vm-neg --zone 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 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 (backendServices) 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 ci-dessus :

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

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 sont pas compatibles 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.

Tarifs

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

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 Initialiazed pour obtenir des informations sur les erreurs.
• Si vous utilisez des noms de NEG personnalisés, assurez-vous que chaque nom 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 gcloud ou en appelant l'API getHealth sur "BackendService" ou l'API "listEndpoints" sur le NEG en veillant à ce que le paramètre "showHealth" soit 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 dupliquées à jour ne correspond pas au nombre visé.

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 n'est pas en cours de récupération si le NEG est référencé par un service de backend. Pour plus d'informations, consultez la section Prévenir les NEG inactifs.
• Si vous utilisez la version 1.18 ou ultérieure, vous pouvez rechercher des événements dans la ressource ServiceNetworkEndpointGroup à l'aide de cette procédure.
• 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

Problème constaté : les points de terminaison attendus n'existent pas, ou le NEG semble non synchronisé.

Solution potentielle :

Si vous utilisez la version 1.18 ou 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.

Étape suivante

• Concepts d'équilibrage de charge HTTP(S)
• 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