GKE Ingress pour les équilibreurs de charge d'application

Cette page fournit une présentation générale d'Ingress pour les équilibreurs de charge d'application externes et de son fonctionnement. Google Kubernetes Engine (GKE) fournit un contrôleur Ingress intégré et géré appelé GKE Ingress. Ce contrôleur met en œuvre les ressources Ingress en tant qu'équilibreurs de charge Google Cloud pour les charges de travail HTTP(S) dans GKE.

Présentation

Dans GKE, un objet Ingress définit des règles d'acheminement du trafic HTTP(S) vers des applications exécutées dans un cluster. Un objet Ingress est associé à un ou plusieurs objets Service, chacun étant lui-même associé à 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.

Lorsque vous créez un objet Ingress, le contrôleur GKE Ingress crée un équilibreur de charge HTTP(S) Google Cloud et le configure en fonction des informations spécifiées dans cet objet et dans les services associés.

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

Ingress pour le trafic externe et interne

Les ressources GKE Ingress sont de deux types :

Comportement du contrôleur GKE Ingress

Pour les clusters exécutant les versions 1.18 et ultérieures de GKE, 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é.

Pour les clusters exécutant des versions plus anciennes de GKE, le contrôleur GKE traite les objets Ingress qui ne comportent pas l'annotation kubernetes.io/ingress.class ou qui comportent l'annotation avec la valeur gce ou gce-internal.

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 ne pouvez pas utiliser le champ ingressClassName pour spécifier un objet GKE Ingress. Vous devez utiliser l'annotation kubernetes.io/ingress.class.

Fonctionnalités des équilibreurs de charge d'application externes

Un équilibreur de charge d'application externe, configuré par un objet Ingress, inclut les fonctionnalités suivantes :

  • Configuration flexible pour les services : un objet Ingress définit la manière dont le trafic atteint vos services et dont il est acheminé vers votre application. En outre, un objet Ingress peut fournir une adresse IP unique pour plusieurs services de votre cluster.
  • Intégration aux services réseau Google Cloud
  • Possibilité d'utiliser plusieurs certificats TLS : un objet Ingress peut spécifier l'utilisation de plusieurs certificats TLS pour l'arrêt des requêtes.

Pour obtenir la liste complète, consultez la page Configuration du trafic entrant.

É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'aide de groupes de points de terminaison du réseau (NEG).

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 certaines limitations 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 l'adresse IP du pod (qui peut 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.

Avec des NEG, le trafic est équilibré directement entre l'équilibreur de charge et l'adresse IP du pod, au lieu de transiter par l'adresse IP de la VM ou par le réseau kube-proxy. En outre, 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, et non seulement pour les vérifications d'état de Kubernetes au sein des clusters. Cela améliore la stabilité globale du trafic en permettant à l'infrastructure d'équilibrage de charge de détecter les événements de cycle de vie, tels que le démarrage d'un pod, ou la perte d'un pod ou d'une VM. Ces fonctionnalités permettent de répondre aux limitations ci-dessus, ce qui se traduit par une mise en réseau plus performante et stable.

L'équilibrage de charge natif en conteneurs est activé par défaut pour les services lorsque l'ensemble des conditions suivantes sont remplies :

  • Les services ont été créés dans des clusters GKE 1.17.6-gke.7 et versions ultérieures.
  • Des clusters de VPC natif sont utilisés.
  • Aucun VPC partagé n'est utilisé.
  • Aucune règle de réseau GKE n'est utilisée.

Dans ces conditions, les services sont annotés automatiquement avec cloud.google.com/neg: '{"ingress": true}', ce qui indique qu'un NEG doit être créé pour mettre en miroir les adresses IP des pods au sein du service. Le NEG permet aux équilibreurs de charge Compute Engine de communiquer directement avec les pods. Notez que les services existants créés avant la version GKE 1.17.6-gke.7 ne seront pas annotés automatiquement par le contrôleur de services.

Pour les clusters GKE 1.17.6-gke.7 et versions ultérieures dans lesquels l'annotation NEG est automatique, il est possible de désactiver les NEG et, si nécessaire, de forcer l'équilibreur de charge externe Compute Engine à utiliser un groupe d'instances en tant que backends. Pour ce faire, annotez explicitement les services avec cloud.google.com/neg: '{"ingress": false}'. Il n'est pas possible de désactiver les NEG disposant d'un objet Ingress pour les équilibreurs de charge d'application internes.

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. Cette annotation doit être appliquée aux services de la manière suivante :

kind: Service
...
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
...

VPC partagé

Les ressources Ingress et MultiClusterIngress sont compatibles avec le VPC partagé, mais elles nécessitent une préparation supplémentaire.

Le contrôleur Ingress s'exécute sur le plan de contrôle GKE et effectue des appels d'API vers Google Cloud en utilisant le compte de service GKE du projet du cluster. Par défaut, lorsqu'un cluster situé dans un projet de service de VPC partagé utilise un réseau VPC partagé, le contrôleur Ingress ne peut pas utiliser le compte de service GKE du projet de service pour créer et mettre à jour des règles de pare-feu autorisant les entrées dans le projet hôte.

Vous pouvez accorder au compte de service GKE du projet de service les autorisations nécessaires pour créer et gérer des règles de pare-feu VPC dans le projet hôte. L'octroi de ces autorisations permet à GKE de créer des règles de pare-feu autorisant les entrées pour les éléments suivants :

Provisionner manuellement des règles de pare-feu à partir du projet hôte

Si vos règles de sécurité n'autorisent la gestion du pare-feu qu'à partir du projet hôte, vous pouvez provisionner ces règles de pare-feu manuellement. Lors du déploiement d'une ressource Ingress dans un VPC partagé, l'événement de ressource Ingress fournit la règle de pare-feu spécifique que vous devez ajouter pour fournir un accès.

Pour provisionner manuellement une règle, procédez comme suit :

  1. Affichez l'événement de ressource Ingress :

    kubectl describe ingress INGRESS_NAME

    Remplacez INGRESS_NAME par le nom de votre ressource Ingress.

    Un résultat semblable aux lignes suivantes doit s'afficher :

    Events:
Type    Reason  Age                    From                     Message
----    ------  ----                   ----                     -------
Normal  Sync    9m34s (x237 over 38h)  loadbalancer-controller  Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`

    La règle de pare-feu obligatoire suggérée s'affiche dans la colonne Message.

  2. Copiez et appliquez les règles de pare-feu suggérées à partir du projet hôte. L'application de la règle permet d'accéder à vos pods depuis l'équilibreur de charge et les vérificateurs d'état Google Cloud.

Accorder au contrôleur d'entrée GKE l'autorisation de gérer les règles de pare-feu du projet hôte

Si vous souhaitez qu'un cluster GKE dans un projet de service crée et gère les ressources de pare-feu de votre projet hôte, le compte de service GKE du projet de service doit disposer des autorisations IAM appropriées en utilisant l'une des stratégies suivantes :

  • Attribuez au compte de service GKE du projet de service le rôle d'administrateur de sécurité Compute sur le projet hôte. L'exemple suivant illustre cette stratégie.

  • Pour une approche plus précise,créez un rôle IAM personnalisé qui n'inclut que les autorisations suivantes : compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update etcompute.firewalls.delete. Accordez au compte de service GKE du projet de service ce rôle personnalisé pour le projet hôte.

Si vous disposez de clusters dans plusieurs projets de service, vous devez choisir l'une des stratégies et la répéter pour le compte de service GKE de chaque projet de service.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
  --member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
  --role=roles/compute.securityAdmin

Remplacez l'élément suivant :

Services de backend multiples

Chaque équilibreur de charge d'application externe ou interne utilise un seul mappage d'URL, qui référence un ou plusieurs services de backend. Un service de backend correspond à chaque service référencé par l'objet Ingress.

Par exemple, l'équilibreur de charge peut être configuré pour acheminer les requêtes vers des services de backend distincts selon le chemin de l'URL. Vous pourriez ainsi acheminer les requêtes envoyées à your-store.example vers un service de backend affichant des articles au prix normal, tandis que les requêtes envoyées à your-store.example/discounted seraient acheminées vers un service de backend proposant des articles en promotion.

Vous pouvez également configurer l'équilibreur de charge pour acheminer les requêtes en fonction du nom d'hôte. Les requêtes envoyées à your-store.example pourraient être dirigées vers un service de backend donné, tandis que les demandes adressées à your-experimental-store.example seraient orientées vers un autre service de backend.

Dans un cluster GKE, la création et la configuration d'un équilibreur de charge HTTP(S) passent par la création d'un objet Entrée Kubernetes. Un objet Ingress doit être associé à un ou plusieurs objets Service, chacun étant associé à un ensemble de pods.

Voici un exemple de fichier manifeste pour un objet Ingress appelé my-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

Lorsque vous créez l'objet Ingress, le contrôleur GKE Ingress crée et configure un équilibreur de charge d'application externe ou un équilibreur de charge d'application interne en fonction des informations spécifiées dans l'objet Ingress et les services associés. De plus, l'équilibreur de charge reçoit une adresse IP stable, que vous pouvez associer à un nom de domaine.

Dans l'exemple précédent, supposons que vous ayez associé l'adresse IP de l'équilibreur de charge au nom de domaine your-store.example. Lorsqu'un client envoie une requête à your-store.example, celle-ci est acheminée vers un service Kubernetes nommé my-products sur le port 60000. Et lorsqu'un client envoie une requête à your-store.example/discounted, celle-ci est acheminée vers un service Kubernetes nommé my-discounted-products sur le port 80.

Le seul caractère générique accepté pour le champ path d'une entrée est l'astérisque (*). Le caractère * doit être placé immédiatement après une barre oblique (/) et doit être le dernier caractère du modèle. Par exemple, /*, /foo/* et /foo/bar/* sont des modèles valides, mais ce n'est pas le cas de *, /foo/bar* et /foo/*/bar.

Un modèle plus restrictif a priorité sur un modèle moins restrictif. Si vous avez à la fois /foo/* et /foo/bar/*, alors /foo/bar/bat est considéré comme correspondant à /foo/bar/*.

Pour plus d'informations sur les restrictions en matière de chemin d'accès et la correspondance de modèle, consultez la documentation relative aux mappages d'URL.

Le fichier manifeste du service my-products peut ressembler à ceci :

apiVersion: v1
kind: Service
metadata:
  name: my-products
spec:
  type: NodePort
  selector:
    app: products
    department: sales
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

Dans le fichier manifeste du service, vous devez utiliser type: NodePort, sauf si vous utilisez l'équilibrage de charge natif en conteneurs. Si vous utilisez l'équilibrage de charge natif en conteneurs, utilisez type: ClusterIP.

Dans le fichier manifeste du service, le champ selector indique que tout pod conjuguant les étiquettes app: products et department: sales est membre de ce service.

Lorsqu'une requête parvient au service sur le port 60000, elle est routée vers l'un des pods membres du port TCP 50000.

Chaque pod membre doit avoir un conteneur d'écoute sur le port TCP 50000.

Le fichier manifeste du service my-discounted-products peut ressembler à ceci :

apiVersion: v1
kind: Service
metadata:
  name: my-discounted-products
spec:
  type: NodePort
  selector:
    app: discounted-products
    department: sales
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Dans le fichier manifeste du service, le champ selector indique que tout pod conjuguant les étiquettes app: discounted-products et department: sales est membre de ce service.

Lorsqu'une requête parvient à ce service sur le port 80, elle est routée vers l'un des pods membres du port TCP 8080.

Chaque pod membre doit avoir un conteneur d'écoute sur le port TCP 8080.

Backend par défaut

Vous pouvez spécifier un backend par défaut pour votre Ingress en fournissant un champ spec.defaultBackend dans votre fichier manifeste Ingress. Toutes les requêtes qui ne correspondent pas aux chemins définis dans le champ rules seront traitées. Par exemple, dans l'Ingress suivant, toutes les requêtes qui ne correspondent pas à /discounted sont envoyées à un service nommé my-products sur le port 60001.

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

Si vous ne spécifiez pas de backend par défaut, GKE en fournit un qui renvoie 404. Il est créé en tant que service NodePort default-http-backend sur le cluster dans l'espace de noms kube-system.

La réponse HTTP 404 ressemble à ce qui suit :

response 404 (backend NotFound), service rules for the path non-existent

Pour configurer un objet GKE Ingress avec un backend par défaut client, consultez la page objet GKE Ingress avec backend par défaut personnalisé.

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.

Fournir des certificats SSL

Vous pouvez fournir des certificats SSL à un équilibreur de charge HTTP(S) à l'aide des méthodes suivantes :

Certificats gérés par Google
Les certificats SSL gérés par Google sont provisionnés, déployés, renouvelés et gérés pour vos domaines. Les certificats gérés ne sont pas compatibles avec les domaines comprenant des caractères génériques.
Certificats autogérés partagés avec Google Cloud
Vous pouvez provisionner votre propre certificat SSL et créer une ressource de certificat dans votre projet Google Cloud. Vous pouvez ensuite répertorier la ressource de certificat dans une annotation sur une entrée afin de créer un équilibreur de charge HTTP(S) qui utilise le certificat. Pour en savoir plus, consultez les instructions sur les certificats prépartagés.
Certificats autogérés en tant que ressources Secret
Vous pouvez provisionner votre propre certificat SSL et créer une ressource Secret pour le conserver. Vous pouvez ensuite faire référence au secret dans une spécification d'entrée pour créer un équilibreur de charge HTTP(S) qui utilise le certificat. Pour en savoir plus, consultez les instructions d'utilisation des certificats dans des secrets.

Vérifications d'état

Lorsque vous exposez un ou plusieurs services via un objet Ingress à l'aide du contrôleur d'entrée par défaut, GKE crée uneéquilibreur de charge d'application classique ou unéquilibreur de charge d'application interne. Ces deux équilibreurs de charge acceptent plusieurs services de backend sur un même mappage d'URL. Chacun des services de backend correspond à un service Kubernetes, et chacun doit faire référence à une vérification d'état Google Cloud. Cette vérification d'état est différente d'une vérification d'activité ou d'aptitude Kubernetes, car elle est mise en œuvre en dehors du cluster.

GKE utilise la procédure suivante pour créer une vérification d'état pour chaque service de backend correspondant à un service Kubernetes :

  • Si le service fait référence à une CRD BackendConfig contenant des informations healthCheck, GKE s'en sert pour créer la vérification d'état. Le contrôleur GKE Enterprise Ingress et le contrôleur GKE Ingress permettent tous deux de créer des vérifications d'état de cette manière.

  • Si le service ne fait pas référence à une CRD BackendConfig :

    • GKE peut déduire la totalité ou une partie des paramètres d'une vérification d'état si les pods actifs utilisent un modèle de pod avec un conteneur dont la vérification d'aptitude possède des attributs pouvant être interprétés comme des paramètres de vérification d'état. Consultez la section Paramètres d'une vérification d'aptitude pour en savoir plus sur la mise en œuvre, ainsi que la section Paramètres par défaut et paramètres déduits pour obtenir une liste des attributs pouvant être utilisés pour créer des paramètres de vérification d'état. Seul le contrôleur GKE Ingress permet de déduire les paramètres d'une vérification d'aptitude.

    • Si le modèle utilisé par les pods actifs du service ne possède pas de conteneur avec une vérification d'aptitude dont les attributs peuvent être interprétés comme des paramètres de vérification d'état, des valeurs par défaut sont utilisées pour créer la vérification d'état. Le contrôleur GKE Enterprise Ingress et le contrôleur GKE Ingress peuvent tous deux créer une vérification d'état en utilisant seulement les valeurs par défaut.

Paramètres par défaut et paramètres déduits

Les paramètres suivants sont utilisés lorsque vous ne spécifiez pas de paramètres de vérification d'état pour le service correspondant à l'aide d'une CRD BackendConfig.

Paramètre de vérification d'état Valeur par défaut Valeur déductible
Protocol (Protocole) HTTP Si présent dans l'annotation de service cloud.google.com/app-protocols
Chemin de requête / Si présent dans la spec du pod actif :
containers[].readinessProbe.httpGet.path
En-tête "hôte de la requête" Host: backend-ip-address Si présent dans la spec du pod actif :
containers[].readinessProbe.httpGet.httpHeaders
Réponse attendue HTTP 200 (OK) HTTP 200 (OK)
non modifiable
Intervalle entre deux tests
  • Pour les NEG zonaux : 15 secondes
  • Pour les groupes d'instances : 60 secondes
 Si présent dans la spec du pod actif :
  • Pour les NEG zonaux :
    containers[].readinessProbe.periodSeconds
  • Pour les groupes d'instances :
    containers[].readinessProbe.periodSeconds + 60 seconds
Délai avant expiration de la vérification 5 secondes Si présent dans la spec du pod actif :
containers[].readinessProbe.timeoutSeconds
Seuil opérationnel 1 1
Cette option ne peut pas être modifiée
Seuil de faible capacité
  • Pour les NEG zonaux : 2
  • Pour les groupes d'instances : 10
 Identique à la valeur par défaut :
  • Pour les NEG zonaux : 2
  • Pour les groupes d'instances : 10
Spécification du port
  • Pour les NEG zonaux : le port du service
  • Pour les groupes d'instances : le nodePort du service
 Les tests de vérification d'état sont envoyés au numéro de port spécifié par spec.containers[].readinessProbe.httpGet.port, à condition que toutes les conditions suivantes soient également remplies :
  • Le numéro de port de la vérification d'aptitude doit correspondre au containers[].spec.ports.containerPort du pod de diffusion.
  • L'élément containerPort du pod de diffusion doit correspondre à l'élément targetPort du service.
  • La spécification de port du backend de service d'entrée fait référence à un port valide du port spec.ports[] du service. Vous pouvez le faire de deux manières :
    • spec.rules[].http.paths[].backend.service.port.name dans l'objet Ingress correspond à l'entrée spec.ports[].name définie dans le service correspondant.
    • spec.rules[].http.paths[].backend.service.port.number dans l'objet Ingress correspond à l'entrée spec.ports[].port définie dans le service correspondant.
Adresse IP de destination
  • Pour les NEG zonaux : l'adresse IP du pod
  • Pour les groupes d'instances : l'adresse IP du nœud
 Identique à la valeur par défaut :
  • Pour les NEG zonaux : l'adresse IP du pod
  • Pour les groupes d'instances : l'adresse IP du nœud

Paramètres obtenus d'une vérification d'aptitude

Lorsque GKE crée la vérification d'état pour le backend du service, il peut copier certains paramètres à partir de la vérification d'aptitude d'un conteneur utilisée par les pods actifs de ce service. Cette option est disponible uniquement avec le contrôleur GKE Ingress.

Les attributs de vérification d'aptitude compatibles pouvant être interprétés comme des paramètres de vérification d'état sont répertoriés avec les valeurs par défaut dans la section Paramètres par défaut et paramètres déduits. Les valeurs par défaut sont utilisées pour tous les attributs non spécifiés dans la vérification d'aptitude ou si vous ne spécifiez pas de vérification d'aptitude proprement dite.

Si les pods actifs de votre service contiennent plusieurs conteneurs, ou si vous utilisez le contrôleur GKE Enterprise Ingress, vous devez utiliser une CRD BackendConfig pour définir les paramètres de vérification d'état. Pour plus d'informations, consultez la section Quand utiliser des CRD BackendConfig.

Quand utiliser des CRD BackendConfig

Dans les situations suivantes, il est préférable de définir explicitement les paramètres de vérification d'état d'un service de backend en créant une CRD BackendConfig au lieu de vous appuyer sur les paramètres des vérifications d'aptitude des pods :

  • Si vous utilisez GKE Enterprise : le contrôleur GKE Enterprise Ingress ne permet pas d'obtenir les paramètres de vérification d'état à partir des vérifications d'aptitude des pods actifs. Il ne peut créer de vérifications d'état qu'à l'aide de paramètres implicites ou définis dans une CRD BackendConfig.

  • Si vous avez plusieurs conteneurs dans les pods actifs : GKE ne permet pas de sélectionner, pour la vérification d'aptitude, un conteneur spécifique à partir duquel déduire les paramètres de vérification d'état. Étant donné que chaque conteneur peut avoir sa propre vérification d'aptitude et qu'une vérification d'aptitude n'est pas un paramètre requis pour les conteneurs, vous devez définir la vérification d'état du service de backend correspondant en faisant référence au CRD BackendConfig du service correspondant.

  • Si vous avez besoin de contrôler le port utilisé pour les vérifications d'état de l'équilibreur de charge : GKE utilise uniquement le paramètre containers[].readinessProbe.httpGet.port de la vérification d'aptitude pour la vérification d'état du service de backend lorsque ce port correspond au port du service référencé dans l'objet Ingress spec.rules[].http.paths[].backend.servicePort.

Paramètres d'une CRD BackendConfig

Vous pouvez spécifier les paramètres de vérification d'état du service de backend à l'aide du paramètre healthCheck d'une CRD BackendConfig référencée par le service correspondant. Cela vous offre davantage de flexibilité et de contrôle sur les vérifications d'état d'un équilibreur de charge d'application classique ou interne créé par un objet Ingress. Consultez la page Configuration du trafic entrant pour obtenir des informations sur la compatibilité avec les versions de GKE.

Cet exemple de CRD BackendConfig définit dans son attribut spec.healthCheck le (type de) protocole de la vérification d'état, un chemin de requête, un port et l'intervalle entre deux tests :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: http-hc-config
spec:
  healthCheck:
    checkIntervalSec: 15
    port: 15020
    type: HTTPS
    requestPath: /healthz

Pour configurer tous les champs disponibles lors de la configuration d'une vérification d'état BackendConfig, utilisez l'exemple de configuration de vérification d'état personnalisée.

Pour configurer un objet GKE Ingress avec une vérification d'état HTTP personnalisée, consultez la page objet GKE Ingress avec vérification d'état HTTP personnalisée.

Utiliser plusieurs certificats TLS

Supposons que vous souhaitiez qu'un équilibreur de charge HTTP(S) diffuse du contenu à partir de deux noms d'hôte : your-store.example et your-experimental-store-exemple. Vous souhaitez par ailleurs que cet équilibreur de charge utilise deux certificats distincts pour your-store.example et your-experimental-store-exemple.

Pour ce faire, spécifiez plusieurs certificats dans un fichier manifeste Ingress. L'équilibreur de charge choisit un certificat si le nom commun (CN) du certificat correspond au nom d'hôte utilisé dans la requête. Pour obtenir des informations détaillées sur la configuration de plusieurs certificats, consultez l'article Utiliser plusieurs certificats SSL dans l'équilibrage de charge HTTPS avec un objet Ingress.

Objet Service Kubernetes et services de backend Google Cloud

Un objet Service Kubernetes et un service de backend Google Cloud  sont deux choses différentes. Il existe une relation forte entre les deux, mais il ne s'agit pas nécessairement d'une relation un à un. Le contrôleur d'entrée GKE crée un service de backend Google Cloud pour chaque paire (service.name, service.port) spécifiée dans le fichier manifeste d'une entrée. Il est donc possible qu'un objet Service Kubernetes soit associé à plusieurs services de backend Google Cloud.

Limites

  • Dans les clusters utilisant des versions antérieures à 1.16, la longueur totale de l'espace de noms et du nom d'un objet Ingress ne doit pas dépasser 40 caractères. Si cette limite n'est pas respectée, le contrôleur GKE Ingress risque d'agir de manière anormale. Pour en savoir plus, consultez ce problème concernant les noms longs sur GitHub.

  • 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 GKE Ingress, 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 supérieurs à 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'entrée 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.

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.

Détails de mise en œuvre

  • Le contrôleur d'entrée effectue régulièrement des vérifications périodiques des autorisations du compte de service en extrayant une ressource de test à partir de votre projet Google Cloud. Vous verrez s'afficher cela comme un GET du BackendService global (non inexistant) sous le nom k8s-ingress-svc-acct-permission-check-probe. Comme cette ressource ne doit normalement pas exister, la requête GET renvoie "not found" (introuvable). Ce comportement est normal. Le contrôleur vérifie que l'appel d'API n'est pas refusé en raison de problèmes d'autorisation. Si vous créez un objet BackendService avec le même nom, le GET réussit au lieu de renvoyer "not found" (introuvable).

Modèles pour la configuration d'entrée

  • Dans la section Recettes réseau GKE, vous trouverez des modèles fournis par GKE pour de nombreux cas d'utilisation courants des objets Ingress dans la section Ingress.

Étapes suivantes