GKE Ingress pour les équilibreurs de charge d'application

Autopilot Standard

Cette page fournit une présentation générale d'Ingress pour les équilibreurs de charge d'application dans Google Kubernetes Engine (GKE). Elle explique également comment le contrôleur Ingress provisionne les équilibreurs de charge d'application pour exposer les applications au trafic HTTP(S) provenant de l'intérieur ou de l'extérieur de votre réseau VPC.

Cette page sert de point d'entrée principal pour comprendre le fonctionnement d'Ingress GKE. Pour examiner plus en détail l'architecture réseau sous-jacente, les schémas de routage du trafic et les implémentations de sécurité, consultez À propos du routage et de la sécurité GKE Ingress.

Sur cette page, nous partons du principe que vous connaissez les éléments suivants :

Cette page s'adresse aux spécialistes de la mise en réseau qui conçoivent et implémentent le réseau pour leur organisation, et installent, configurent et gèrent l'équipement réseau. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenuGoogle Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Présentation

GKE fournit un contrôleur d'entrée intégré et géré appelé GKE Ingress. Lorsque vous créez une ressource Ingress dans GKE, le contrôleur configure automatiquement un équilibreur de charge HTTPS qui permet au trafic HTTP ou HTTPS d'atteindre vos services. Le contrôleur Ingress configure l'équilibreur de charge et achemine le trafic vers les applications qui s'exécutent dans votre cluster en fonction des règles spécifiées dans votre fichier manifeste Ingress et les objets Service associés.

Un objet Ingress est associé à un ou plusieurs objets Service, qui sont eux-mêmes associés à un ensemble de pods. Pour en savoir plus sur la manière dont Ingress expose les applications à l'aide des services, consultez la page Présentation de la mise en réseau de services.

Pour utiliser Ingress, vous devez activer le module complémentaire d'équilibrage de charge HTTP. Ce module complémentaire est activé par défaut sur les clusters GKE. Vous ne devez pas le désactiver.

Différence entre un service Kubernetes et un service de backend Google Cloud

L'objet Service Kubernetes et l'objet Google Cloud service de backend ont des objectifs similaires, mais distincts. Bien qu'ils soient fortement liés, la relation n'est pas toujours un à un.

Le contrôleur GKE Ingress sert d'intermédiaire entre ces deux concepts. Lorsque vous créez une ressource Ingress, le contrôleur provisionne un équilibreur de chargeGoogle Cloud . Le contrôleur crée ensuite un service de backendGoogle Cloud dédié pour chaque combinaison unique (service.name, service.port) référencée dans le fichier manifeste Ingress.

Par exemple, un fichier manifeste Ingress peut avoir le même nom de service Kubernetes, mais pointer vers un service.port différent pour deux règles host ou path distinctes. Dans ce cas, le contrôleur GKE Ingress crée deux services de backend distincts. Par conséquent, un objet Service Kubernetes peut être associé à plusieurs services de backend Google Cloud .

Ingress pour le trafic externe et interne

Il existe deux types de ressources GKE Ingress :

Ingress pour les équilibreurs de charge d'application externes déploie l'équilibreur de charge d'application classique. Cet équilibreur de charge Web est déployé à l'échelle mondiale sur le réseau périphérique de Google, sous la forme d'un pool géré et évolutif de ressources d'équilibrage des charges. Découvrez comment configurer et utiliser Ingress pour les équilibreurs de charge d'application externes.
Ingress pour les équilibreurs de charge d'application internes déploie l'équilibreur de charge d'application interne. Ces équilibreurs de charge d'application internes sont basés sur des systèmes de proxy Envoy situés en dehors de votre cluster GKE, mais au sein de votre réseau VPC. Découvrez comment configurer et utiliser Ingress pour les équilibreurs de charge d'application internes.

Important : Chaque fois que GKE crée un équilibreur de charge d'application externe ou un équilibreur de charge d'application interne via un objet Ingress, évitez de modifier la configuration de l'équilibreur de charge à l'aide de méthodes en dehors de GKE. Les modifications apportées aux paramètres des objets de l'équilibreur de charge (règles de transfert, proxys cibles, mappages d'URL, services de backend et vérifications d'état) sont écrasées lorsque de nouvelles modifications de ressources sont appliquées, lors des synchronisations périodiques ou pendant les mises à niveau du cluster. Si vous devez gérer un équilibreur de charge d'application externe ou $un équilibreur de charge d'application interne en dehors de GKE, utilisez plutôt l'équilibrage de charge natif en conteneurs pour les NEG autonomes.

Environnement de mise en réseau requis pour les équilibreurs de charge d'application externes

L'équilibreur de charge d'application externe est un système géré et distribué à l'échelle mondiale qui utilise des proxys Google Front End (GFE) déployés sur le réseau en périphérie de Google. Ces proxys ne se trouvent pas dans votre réseau VPC. Lorsqu'un client envoie une requête à l'adresse IP externe de l'équilibreur de charge, la requête est acheminée à l'aide du réseau anycast de Google vers le GFE le plus proche. Le GFE interrompt le trafic utilisateur (y compris le protocole TLS, s'il est configuré), puis le transfère vers les pods de backend de votre cluster GKE.

Pour que ce flux fonctionne, le contrôleur d'entrée GKE crée automatiquement des règles de pare-feu pour autoriser le trafic provenant des GFE et des systèmes de vérification de l'état deGoogle Cloudà atteindre vos pods. Ces règles autorisent le trafic provenant des plages d'adresses IP connues de Google (130.211.0.0/22 et 35.191.0.0/16).

Voici comment fonctionne l'équilibreur de charge d'application externe :

Un client envoie une requête à l'adresse IP et au port de la règle de transfert de l'équilibreur de charge.
La requête est acheminée vers un proxy Google Front End (GFE) sur le réseau mondial de Google. Ce proxy met fin à la connexion réseau du client.
Le proxy GFE transmet la requête au point de terminaison du pod de backend approprié dans votre cluster GKE, tel que déterminé par les services de backend et le mappage d'URL de l'équilibreur de charge.

Contrairement à l'équilibreur de charge d'application interne, il n'est pas nécessaire de configurer un sous-réseau proxy réservé dans votre réseau VPC pour un équilibreur de charge d'application externe.

Environnement de mise en réseau requis pour les équilibreurs de charge d'application internes

L'équilibreur de charge d'application interne fournit un pool de proxys pour votre réseau. Les proxys évaluent la destination de chaque requête HTTP(S) en fonction de facteurs tels que le mappage d'URL, l'affinité de session de BackendService et le mode d'équilibrage de chaque NEG backend.

L'équilibreur de charge d'application interne d'une région utilise le sous-réseau proxy réservé de cette région sur votre réseau VPC pour attribuer des adresses IP internes à chaque proxy créé par Google Cloud.

Par défaut, l'adresse IP attribuée à la règle de transfert d'un équilibreur de charge provient de la plage de sous-réseaux du nœud attribuée par GKE plutôt que du sous-réseau proxy réservé. Vous pouvez également spécifier manuellement une adresse IP pour la règle de transfert de n'importe quel sous-réseau lorsque vous créez la règle.

Le schéma suivant présente le flux de trafic pour un équilibreur de charge d'application interne, comme décrit dans le paragraphe précédent.

Voici comment fonctionne l'équilibreur de charge d'application interne :

Un client établit une connexion avec l'adresse IP et le port de la règle de transfert de l'équilibreur de charge.
Un proxy reçoit et met fin à la connexion réseau du client.
Le proxy établit une connexion au point de terminaison approprié (pod) dans un NEG, tel que déterminé par les services de backend et le mappage d'URL de l'équilibreur de charge.

Chaque proxy écoute l'adresse IP et le port spécifiés par la règle de transfert de l'équilibreur de charge correspondant. L'adresse IP source de chaque paquet envoyé depuis un proxy vers un point de terminaison est l'adresse IP interne attribuée à ce proxy à partir du sous-réseau proxy réservé.

Comportement du contrôleur GKE Ingress

Le fait que le contrôleur GKE Ingress traite ou non une entrée dépend de la valeur de l'annotation kubernetes.io/ingress.class :

Valeur `kubernetes.io/ingress.class`	Valeur `ingressClassName`	Comportement du contrôleur GKE Ingress
Non définie	Non définie	Traite le fichier manifeste Ingress et crée un équilibreur de charge d'application externe.
Non définie	Toute valeur	N'effectue aucune action. Le fichier manifeste Ingress peut être traité par un contrôleur d'entrée tiers, si un tel contrôleur a été déployé.
`gce`	N'importe quelle valeur. Ce champ est ignoré.	Traite le fichier manifeste Ingress et crée un équilibreur de charge d'application externe.
`gce-internal`	N'importe quelle valeur. Ce champ est ignoré.	Traite le fichier manifeste Ingress et crée un équilibreur de charge d'application interne.
Définissez une valeur autre que `gce` ou `gce-internal`.	Toute valeur	N'effectue aucune action. Le fichier manifeste Ingress peut être traité par un contrôleur d'entrée tiers, si un tel contrôleur a été déployé.

Abandon de l'annotation `kubernetes.io/ingress.class`

Bien que l'annotation kubernetes.io/ingress.class soit obsolète dans Kubernetes, GKE continue de l'utiliser. Vous devez utiliser cette annotation pour identifier la classe Ingress.

Lorsque vous appliquez votre configuration, un avertissement d'abandon peut s'afficher. Cet avertissement indique que l'annotation est obsolète et vous invite à utiliser le champ ingressClassName à la place. Vous pouvez ignorer cet avertissement sans risque, car GKE Ingress continue de s'appuyer exclusivement sur l'annotation kubernetes.io/ingress.class.

Mappages de ressources Ingress vers Compute Engine

Le contrôleur GKE Ingress déploie et gère les ressources de l'équilibreur de charge Compute Engine en fonction des ressources Ingress déployées dans le cluster. Le mappage des ressources Compute Engine dépend de la structure de la ressource Ingress.

Le fichier manifeste suivant décrit un objet Ingress :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Ce fichier manifeste Ingress indique à GKE de créer les ressources Compute Engine suivantes :

Une règle de transfert et une adresse IP.
Des règles de pare-feu Compute Engine autorisant le trafic associé aux vérifications d'état de l'équilibreur de charge ainsi que le trafic d'application en provenance de Google Front End ou des proxys Envoy.
Un proxy HTTP cible et un proxy HTTPS cible, si vous avez configuré TLS.
Un mappage d'URL comportant une seule règle d'hôte faisant référence à un seul outil de mise en correspondance des chemins d'accès. L'outil de mise en correspondance des chemins d'accès possède deux règles de chemin d'accès, une pour /* et une pour /discounted. Chaque règle de chemin d'accès est associée à un unique service de backend.
Des NEG qui contiennent une liste d'adresses IP des pods de chaque service en tant que points de terminaison. Ils sont créés suite aux services my-discounted-products et my-products.

Méthodes d'équilibrage de charge

GKE est compatible avec l'équilibrage de charge natif en conteneurs et les groupes d'instances.

Équilibrage de charge natif en conteneur

L'équilibrage de charge natif en conteneurs consiste à équilibrer la charge directement sur les points de terminaison des pods dans GKE. L'équilibrage de charge natif en conteneurs utilise des groupes de points de terminaison du réseau (NEG) de type GCE_VM_IP_PORT, où les points de terminaison sont les adresses IP des pods.

L'équilibrage de charge natif en conteneurs est utilisé systématiquement pour les entrées GKE internes, et est facultatif pour l'entrée externe. Le contrôleur Ingress crée l'équilibreur de charge, y compris l'adresse IP virtuelle, les règles de transfert, les vérifications d'état et les règles de pare-feu.

L'équilibrage de charge natif en conteneurs est compatible avec l'affinité de session basée sur un pod.

GKE active automatiquement l'équilibrage de charge natif en conteneurs lorsque toutes les conditions suivantes sont remplies :

Le cluster est VPC natif.
Le cluster n'utilise pas de réseau VPC partagé.
Le cluster n'utilise pas de règle de réseau GKE.
Le module complémentaire HttpLoadBalancing est activé sur le cluster. Le module complémentaire HttpLoadBalancing est activé par défaut sur les clusters GKE ; vous ne devez pas le désactiver.

Lorsque GKE active l'équilibrage de charge natif en conteneurs, les services sont automatiquement annotés avec cloud.google.com/neg: '{"ingress": true}'. Cette annotation déclenche la création d'un NEG qui reflète les adresses IP des pods, ce qui permet aux équilibreurs de charge Compute Engine de communiquer directement avec les pods.

Pour les clusters dans lesquels les NEG ne sont pas définis par défaut, il est toujours fortement recommandé d'utiliser l'équilibrage de charge natif en conteneurs, mais celui-ci doit être activé explicitement service par service.

Pour plus de flexibilité, vous pouvez également créer des NEG autonomes. Dans ce cas, vous êtes responsable de la création et de la gestion de tous les aspects de l'équilibreur de charge.

Avantages

En utilisant des NEG, l'équilibrage de charge natif en conteneurs offre une mise en réseau plus performante et stable :

Performances réseau améliorées : sans l'équilibrage de charge natif en conteneurs, le trafic est transféré vers les groupes d'instances de nœuds, puis s'appuie sur les règles iptables configurées par kube-proxy pour être acheminé vers le pod cible. Avec l'équilibrage de charge natif en conteneurs, le trafic est équilibré directement vers les pods, ce qui évite d'avoir à le router via l'adresse IP de la VM et le réseau kube-proxy sur le nœud. Ce flux élimine les sauts de réseau supplémentaires et améliore la latence et le débit.

Vérifications d'état améliorées : les portes de disponibilité des pods sont mises en œuvre pour déterminer l'état des pods du point de vue de l'équilibreur de charge, au lieu de s'appuyer uniquement sur les vérifications d'état dans le cluster. Cette fonctionnalité essentielle permet à l'équilibreur de charge de détecter les événements de cycle de vie des pods (démarrage, perte, etc.) et améliore la stabilité du trafic. Pour en savoir plus sur l'utilisation des portes de disponibilité des pods pour déterminer l'état des pods, consultez Disponibilité des pods.

Visibilité accrue : avec l'équilibrage de charge natif en conteneurs, vous bénéficiez d'une visibilité sur la latence entre l'équilibreur de charge d'application et chaque pod. Comme la latence n'est plus agrégée au niveau de l'adresse IP du nœud, il est plus facile de résoudre les problèmes de vos services au niveau du NEG.

Compatibilité avec Cloud Service Mesh : le modèle de données NEG est requis pour utiliser Cloud Service Mesh, le plan de contrôle de trafic entièrement géré de Google Cloudpour le maillage de services.

Limites des équilibreurs de charge natifs en conteneurs

Les équilibreurs de charge natifs en conteneurs via Ingress sur GKE sont soumis aux exigences suivantes :

Les équilibreurs de charge natifs en conteneurs ne sont pas compatibles avec les équilibreurs de charge réseau passthrough externes.
Vous ne devez pas modifier ni mettre à jour manuellement la configuration de l'équilibreur de charge d'application créé par GKE. Toutes les modifications que vous apportez sont remplacées par GKE.

Tarifs des équilibreurs de charge natifs en conteneurs

L'équilibreur de charge d'application provisionné par l'entrée que vous créez dans ce guide vous est facturé. Pour obtenir des informations sur les tarifs de l'équilibreur de charge, consultez la section Équilibrage de charge et règles de transfert sur la page des tarifs du VPC.

Groupes d'instances

Lorsque vous utilisez des groupes d'instances, les équilibreurs de charge Compute Engine envoient le trafic aux adresses IP des VM en tant que backends. Cela introduit les limitations suivantes lors de l'exécution dans les VM de conteneurs partageant la même interface d'hôte :

Cela occasionne deux sauts d'équilibrage de charge : un saut de l'équilibreur de charge vers le port du nœud (NodePort) de la VM, et un autre saut dans le cadre du routage kube-proxy vers les adresses IP des pods (qui peuvent résider sur une VM différente).
Les sauts supplémentaires augmentent la latence et complexifient le chemin du trafic.
L'équilibreur de charge Compute Engine n'a aucune visibilité directe sur les pods. L'équilibrage du trafic n'est alors pas optimal.
Les événements liés à l'environnement, tels que la perte d'une VM ou d'un pod, sont davantage susceptibles de causer une perte de trafic intermittente en raison du double saut.

Clusters externes et clusters basés sur le routage

Si vous utilisez des clusters basés sur le routage avec un objet Ingress externe, le contrôleur GKE Ingress ne peut pas utiliser l'équilibrage de charge natif en conteneurs à l'aide de groupes de points de terminaison du réseau (NEG) GCE_VM_IP_PORT. À la place, le contrôleur Ingress utilise des backends de groupes d'instances non gérés qui incluent tous les nœuds de tous les pools de nœuds. Si ces groupes d'instances non gérés sont également utilisés par les services LoadBalancer, cela peut entraîner des problèmes liés à la limitation des groupes d'instances à équilibrage de charge unique.

Certains objets Ingress externes créés dans des clusters de VPC natif peuvent utiliser des backends de groupe d'instances sur les services de backend de chaque équilibreur de charge d'application externe qu'ils créent. Cela n'est pas pertinent pour l'entrée interne, car les ressources Ingress internes utilisent toujours des NEG GCE_VM_IP_PORT et nécessitent des clusters de VPC natif.

Pour savoir comment résoudre les erreurs 502 avec des ressources Ingress externes, consultez la page Ingress externe génère des erreurs HTTP 502.

Limites du contrôleur GKE Ingress

GKE Ingress n'est pas compatible avec les certificats gérés par Certificate Manager. Pour utiliser des certificats gérés par Certificate Manager, utilisez l'API Gateway.
Dans les clusters utilisant des NEG, le délai de rapprochement des entrées peut être affecté par le nombre d'entrées. Par exemple, un cluster avec 20 entrées, chacun contenant 20 backends NEG distincts, peut entraîner une latence de plus de 30 minutes pour le rapprochement d'une modification d'entrée. Cela affecte particulièrement les clusters régionaux en raison du nombre croissant de NEG nécessaires.
Des quotas s'appliquent pour les mappages d'URL.
Des quotas associés aux ressources Compute Engine s'appliquent.
Si vous n'utilisez pas de NEG avec le contrôleur d'entrée GKE,les clusters GKE sont limités à 1 000 nœuds. Lorsque des services sont déployés avec des NEG, il n'existe aucune limite de nœuds GKE. Tous les services non-NEG exposés via Ingress ne fonctionnent pas correctement sur les clusters comportant plus de 1 000 nœuds.
Pour que le contrôleur GKE Ingress utilise vos vérifications de la préparation (readinessProbes) en tant que vérifications de l'état, les pods associés à une entrée doivent être définis préalablement à la création de cette entrée. En cas de scaling de vos instances dupliquées vers 0, la vérification d'état par défaut s'applique. Pour en savoir plus, consultez ce problème concernant les vérifications d'état sur GitHub.
Les modifications apportées à la vérification de la préparation (readinessProbe) d'un pod n'affectent pas l'Ingress après sa création.
Un équilibreur de charge d'application externe interrompt le protocole TLS au niveau d'emplacements distribués à l'échelle mondiale, de manière à réduire la latence entre les clients et l'équilibreur de charge. Si vous avez besoin d'exercer un contrôle géographique sur ces emplacements, vous devez plutôt faire appel à un contrôleur Ingress personnalisé exposé via un service GKE de type LoadBalancer, et interrompre le protocole TLS sur les backends situés dans les régions correspondant à vos besoins.
Il n'est pas possible de combiner plusieurs ressources Ingress dans un seul équilibreur de charge Google Cloud .
Vous devez désactiver le protocole TLS mutuel dans votre application, car il n'est pas compatible avec les équilibreurs de charge d'application externes.
Ingress ne peut exposer que les ports HTTP 80 et 443 pour son frontend.