GKE Ingress pour l'équilibrage de charge HTTP(S)

Cette page fournit une présentation générale du fonctionnement de Ingress pour l'équilibrage de charge HTTP(S). 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 Entrée 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 :

Fonctionnalités de l'équilibrage de charge HTTP(S)

L'équilibrage de charge HTTP(S) configuré par un objet Ingress comprend 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 des Fonctionnalités Ingress.

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

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 les topologies de VPC partagés, mais nécessitent une préparation préalable pour fonctionner. Les contrôleurs GKE Ingress utilisent un compte de service Google Cloud pour déployer et gérer des ressources Google Cloud. Lorsqu'un cluster GKE réside dans un projet de service d'un VPC partagé, ce compte de service n'est pas autorisé à gérer les ressources réseau appartenant au projet hôte. Le contrôleur d'entrée gère activement les règles de pare-feu pour fournir un accès entre les équilibreurs de charge et les pods, ainsi qu'entre les pods et les vérificateurs d'état centralisés.

Toutefois, dans un VPC partagé, le contrôleur GKE Ingress n'a pas le droit de gérer les règles de pare-feu. Vous pouvez ajouter ces droits en provisionnant manuellement des règles de pare-feu à partir du projet hôte, ou en autorisant le contrôleur GKE Ingress à gérer les règles de pare-feu du projet hôte.

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

Une approche automatisée consiste à fournir au compte de service du contrôleur GKE Ingress les autorisations nécessaires pour mettre à jour les règles de pare-feu. Créez un rôle IAM personnalisé qui permet de gérer directement les règles de pare-feu et accordez ce rôle au compte de service GKE Ingress.

  1. Dans votre projet hôte, attribuez un rôle personnalisé avec les autorisations compute.firewalls.* et compute.networks.updatePolicy au compte de service GKE du projet de service :

    gcloud iam roles create ROLE_NAME \
       --project PROJECT_ID \
       --title ROLE_TITLE \
       --description ROLE_DESCRIPTION \
       --permissions=compute.networks.updatePolicy, compute.firewalls.*\
       --stage GA
    

    Remplacez l'élément suivant :

    • ROLE_NAME : ajoutez un nom pour le rôle.
    • PROJECT_ID : ajoutez l'ID du projet hôte.
    • ROLE_TITLE : ajoutez le titre du rôle que vous souhaitez créer.
    • ROLE_DESCRIPTION : ajoutez la description du rôle que vous souhaitez créer.
  2. Appliquez ce rôle personnalisé au compte de service GKE Ingress :

    gcloud projects add-iam-policy-binding my-project \
        --member=user:SERVICE_ACCOUNT  \
        --role=roles/gke-ingress-fw-management
    

    La valeur de SERVICE_ACCOUNT est : PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com.

    Remplacez PROJECT_NUMBER par le numéro de projet de votre projet hôte.

Services de backend multiples

Chaque équilibreur de charge HTTP(S) externe ou interne utilise un unique mappage d'URL, qui fait 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/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: my-products
          servicePort: 60000
      - path: /discounted
        backend:
          serviceName: my-discounted-products
          servicePort: 80

Lorsque vous créez l'objet Ingress, le contrôleur GKE Ingress crée et configure un équilibreur de charge HTTP(S) externe ou interne en fonction des informations spécifiées dans l'objet 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 en fournissant un champ backend dans votre fichier manifeste d'entrée. Toute requête ne correspondant pas aux chemins du champ rules est envoyée au service et au port spécifiés dans le champ backend. Par exemple, dans l'entrée suivante, toutes les requêtes qui ne correspondent pas à / ni à /discounted sont envoyées à un service nommé my-products sur le port 60001.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend:
    serviceName: my-products
    servicePort: 60001
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: my-products
          servicePort: 60000
      - path: /discounted
        backend:
          serviceName: my-discounted-products
          servicePort: 80

Si vous ne spécifiez pas de backend par défaut, GKE en fournit un qui renvoie 404.

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. La connaissance de ces mappages de ressources vous aide à planifier, concevoir et résoudre les problèmes.

Le fichier manifeste my-ingress affiché dans la section Services de backend multiples spécifie une ressource Ingress externe avec deux correspondances de chemin de l'URL qui font référence à deux services Kubernetes différents. Voici quelques-unes des ressources Compute Engine créées au nom de my-ingress :

  • 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 de pods de chaque service en tant que points de terminaison. Ils sont créés suite aux services my-discounted-products et my-products. Le schéma suivant présente les mappages de ressources Ingress vers Compute Engine.

Schéma de mappage des ressources Ingress vers Compute Engine

Fournir des certificats SSL

Il est possible de fournir des certificats SSL à un équilibreur de charge HTTP(S) de trois manières :

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 ressource équilibreur de charge HTTP(S) externe ou équilibreur de charge HTTP(S) interne Google Cloud. 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 Anthos 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 Anthos 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
Port
spécifié par numéro
  • Pour les NEG zonaux : le port du service
  • Pour les groupes d'instances : le nodePort du service
Si le paramètre backend.servicePort de l'objet Ingress fait référence au port d'un service, ce port est utilisé aux conditions suivantes :
  • la vérification d'aptitude du pod actif spécifie un port :
    spec.containers[].readinessProbe.httpGet.port ;
  • le port cible (targetPort) du service fait référence au paramètre containers[].spec.ports.containerPort du pod de diffusion.
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 Anthos 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 Anthos : le contrôleur Anthos 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 les pods actifs présentent plusieurs conteneurs ayant des vérifications d'aptitude uniques : si les pods actifs d'un service comportent plusieurs conteneurs, et que chacun d'eux possède des paramètres de vérification d'aptitude différents, vous devez définir la vérification d'état du service de backend correspondant en faisant référence à une CRD BackendConfig sur le service correspondant. Si un pod actif comporte plusieurs vérifications d'aptitude, GKE ne vous permet pas de choisir une vérification d'aptitude spécifique à partir de laquelle déduire des paramètres de vérification d'état.

  • 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 HTTP(S) Google Cloud externe ou interne créé par un objet Ingress. Consultez la page Fonctionnalités Ingress 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

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 (serviceName, servicePort) 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 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 de l'état par défaut s'applique. Pour plus d'informations, consultez ce commentaire de problème.

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

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

Étape suivante