À propos du routage et de la sécurité GKE Ingress

Autopilot Standard

Cette page décrit les principales fonctionnalités et l'architecture réseau d'entrée GKE, en particulier la sécurisation des connexions entre le client et l'équilibreur de charge, et jusqu'aux pods d'application, la gestion du routage complexe sur plusieurs services de backend et la compréhension de l'orchestration des vérifications de l'état de l'équilibreur de charge dans un cluster.

Cette page s'appuie sur les concepts de base décrits dans la présentation d'Ingress GKE. Pour obtenir des instructions détaillées et des exemples d'implémentation à l'aide de ressources personnalisées telles que FrontendConfig et BackendConfig, consultez Configurer les fonctionnalités Ingress pour les applications GKE.

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.

Sécuriser l'entrée avec HTTPS

GKE Ingress sécurise le trafic entre le client et l'équilibreur de charge d'application, ainsi qu'entre l'équilibreur de charge et les pods d'application.

Configurer TLS entre le client et l'équilibreur de charge

Un équilibreur de charge HTTP(S) joue le rôle de proxy entre vos clients et votre application. Si vous souhaitez accepter les requêtes HTTPS émanant de vos clients, l'équilibreur de charge doit disposer d'un certificat lui permettant de leur prouver son identité. L'équilibreur de charge doit également disposer d'une clé privée pour mener à bien la négociation HTTPS.

Lorsque l'équilibreur de charge accepte une requête HTTPS d'un client, le trafic entre le client et l'équilibreur de charge est chiffré via TLS. Cependant, l'équilibreur de charge interrompt ce chiffrement TLS et transfère la requête sans chiffrement à l'application. Pour en savoir plus, consultez Configurer le chiffrement entre l'équilibreur de charge et votre application.

Méthodes pour fournir des certificats SSL

Remarque : Pour utiliser les certificats gérés par Certificate Manager, nous vous recommandons d'utiliser l'API Gateway. GKE Ingress n'est pas compatible avec les certificats gérés par Certificate Manager.

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

• Certificats gérés par Google : il s'agit de certificats de validation de domaine (DV) que Google provisionne, renouvelle et gère pour vos noms de domaine. Ces certificats ne représentent pas votre identité personnelle ni celle de votre organisation. Les certificats gérés par Google acceptent jusqu'à 100 domaines ne comportant pas de caractères génériques. Pour en savoir plus, consultez Utiliser des certificats gérés par Google.

• 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 répertoriez ensuite la ressource de certificat dans une annotation sur une Ingress afin de créer un équilibreur de charge HTTP(S) qui utilise le certificat. Pour en savoir plus, consultez Utiliser des certificats prépartagés.

• Certificats autogérés utilisant les secrets Kubernetes : vous pouvez provisionner votre propre certificat SSL et créer un secret pour le conserver. Vous pouvez ensuite faire référence au secret dans le champ tls d'un fichier manifeste Ingress pour créer un équilibreur de charge HTTP(S). Pour en savoir plus, consultez Utiliser les secrets Kubernetes.

Diffuser du trafic HTTPS avec plusieurs certificats

Vous pouvez configurer l'équilibreur de charge d'application pour qu'il présente jusqu'à 15 certificats TLS à un client. L'utilisation de plusieurs certificats est essentielle lorsque vous devez diffuser du contenu à partir de plusieurs noms d'hôte, chacun nécessitant un certificat différent (par exemple, des certificats distincts pour your-store.example et your-experimental-store.example). Vous spécifiez ces plusieurs certificats dans votre fichier manifeste Ingress.

Sélection et priorité des certificats

Pour déterminer le certificat à présenter au client, l'équilibreur de charge utilise l'indication du nom du serveur (SNI).

• Si le client utilise SNI ou un nom de domaine qui correspond au nom commun (CN) de l'un des certificats disponibles, l'équilibreur de charge utilise le certificat dont le nom commun correspond le mieux au nom d'hôte demandé par le client.

• Si le client ne prend pas en charge SNI ou si le nom de domaine demandé ne correspond pas au CN d'un certificat disponible, l'équilibreur de charge utilise par défaut le premier certificat listé dans le fichier manifeste Ingress. L'équilibreur de charge choisit ce certificat en fonction des règles suivantes :

  • Pour les secrets répertoriés dans le bloc tls, le certificat principal est le premier secret du bloc tls.
  • Pour les certificats prépartagés dans l'annotation pre-shared-cert, le certificat principal est le premier certificat listé dans l'annotation.
  • pour les certificats gérés par Google dans l'annotation managed-certificates : tous les certificats gérés sont triés par ordre alphabétique. Le certificat principal est celui qui apparaît en premier dans cette liste alphabétique. Pour définir un certificat spécifique comme certificat principal, vous devez nommer vos objets ManagedCertificate en conséquence afin de contrôler l'ordre de tri. Par exemple, pour définir my-default-cert comme principal au lieu de another-cert, vous pouvez les nommer 0-my-default-cert et 1-another-cert.

Lorsque l'équilibreur de charge présente plusieurs certificats via différentes méthodes GKE, les certificats prépartagés sont prioritaires sur les secrets listés dans le bloc tls de l'entrée.

Le diagramme suivant représente l'envoi de trafic vers différents backends par l'équilibreur de charge, en fonction du nom de domaine utilisé dans la requête :

Bonnes pratiques concernant la rotation des certificats

Voici quelques bonnes pratiques à suivre si vous souhaitez faire tourner le contenu de votre certificat secret ou prépartagé :

• Créez un certificat secret ou prépartagé avec un autre nom, contenant les nouvelles données de certificat. Mettez à jour votre Ingress pour utiliser la nouvelle ressource de certificat.
• Si cela ne vous dérange pas de perturber le trafic, vous pouvez supprimer l'ancienne ressource de l'Ingress, provisionner une nouvelle ressource avec le même nom, mais avec un contenu différent, puis la réassocier à l&#Ingress;entrée.

Pour éviter de devoir gérer vous-même la rotation des certificats, utilisez des certificats SSL gérés par Google.

Appliquer le trafic HTTPS uniquement

Si vous souhaitez que tout le trafic entre le client et l'équilibreur de charge HTTP(S) utilise le protocole HTTPS, vous pouvez désactiver HTTP en incluant l'annotation kubernetes.io/ingress.allow-http dans le fichier manifeste d'entrée et en définissant la valeur sur "false". Pour en savoir plus, consultez Désactiver HTTP.

Attention : La désactivation de HTTP n'est pas compatible avec l'entrée multicluster.

Configurer le chiffrement entre l'équilibreur de charge et votre application

Cette section explique comment sécuriser la connexion entre l'équilibreur de charge et les pods d'application.

Activer le protocole de backend HTTPS ou HTTP/2

L'équilibreur de charge d'application externe agit comme un proxy entre vos clients et votre application GKE. Bien que les clients puissent se connecter à l'équilibreur de charge à l'aide du protocole HTTPS (pour le chiffrement) et de divers protocoles (HTTP/1.1 ou HTTP/2), la connexion entre l'équilibreur de charge et vos pods de backend est définie par défaut sur HTTP/1.1 non chiffré.

Si votre application est capable de gérer des configurations plus avancées, vous pouvez mettre à jour manuellement l'équilibreur de charge d'application externe pour qu'il utilise :

• HTTP/2 : pour optimiser les performances si vos pods sont compatibles.
• HTTPS (TLS) : pour appliquer le chiffrement de bout en bout du trafic entre le proxy de l'équilibreur de charge et vos pods.

Vous contrôlez à la fois le protocole (HTTP ou HTTPS) et la version HTTP (HTTP/1.1 ou HTTP/2) utilisés pour la connexion au backend à l'aide de l'annotation cloud.google.com/app-protocols dans le fichier manifeste de votre service Kubernetes. Ce fichier manifeste de service doit inclure 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.

Adresses IP statiques pour les équilibreurs de charge HTTPS

Lorsque vous créez un objet Ingress pour un équilibreur de charge d'application externe, vous obtenez une adresse IP externe stable que les clients peuvent utiliser pour accéder à vos services et, par la suite, à vos conteneurs en cours d'exécution. Cette adresse IP est stable dans le sens où elle dure toute la vie de l'objet Entrée. Si vous supprimez votre entrée pour en créer une autre à partir du même fichier manifeste, il n'est pas garanti que vous obteniez la même adresse IP externe.

Si vous souhaitez conserver une adresse IP permanente identique lors de la suppression de votre objet Ingress et de la création d'un nouvel objet, vous devez réserver une adresse IP externe statique globale. Incluez ensuite dans le manifeste de votre entrée une annotation donnant le nom de cette adresse IP statique réservée. Si vous modifiez un Ingress existant pour utiliser une adresse IP statique au lieu d'une adresse IP éphémère, GKE peut modifier l'adresse IP de l'équilibreur de charge lorsque GKE recrée la règle de transfert de l'équilibreur de charge.

Routage du trafic

GKE Ingress utilise des mappages d'URL pour définir la manière dont les requêtes entrantes sont acheminées vers des services de backend spécifiques. Vous pouvez configurer des règles de routage basées sur des noms d'hôte, des chemins d'URL ou une combinaison des deux pour gérer le trafic de plusieurs applications via un seul équilibreur de charge.

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.

Si vous souhaitez configurer GKE Ingress avec plusieurs backends pour le même hôte, vous devez disposer d'une seule règle avec un seul hôte et plusieurs chemins d'accès. Sinon, le contrôleur GKE Ingress ne provisionne qu'un seul service de backend.

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:
  - host: your-store.example
    http:
      paths:
      - path: /products
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Remarque : Pour pouvoir utiliser l'objet Ingress, vous devez activer le module complémentaire d'équilibreur de charge d'application externe. Les équilibreurs de charge d'application externes sont activés par défaut sur les clusters GKE. Vous ne devez pas les désactiver.

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/products, 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

Notez les points suivants dans le fichier manifeste précédent :

• Le champ spec.type dépend de la méthode d'équilibrage de charge que vous utilisez :

  • Si vous utilisez l'équilibrage de charge natif en conteneurs, utilisez type: ClusterIP.
  • Si vous utilisez des groupes d'instances, utilisez type: NodePort.

• Le champ selector indique que tous les pods comportant les libellés app: products et department: sales sont membres 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

Notez les points suivants dans le fichier manifeste précédent :

• 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é.

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 de l'étatGoogle Cloud . Cette vérification de l'état est différente d'une vérification d'activité ou d'aptitude Kubernetes, car elle est mise en œuvre en dehors du cluster.

Les vérifications d'état de l'équilibreur de charge sont spécifiées par service de backend. Bien qu'il soit possible d'utiliser la même vérification d'état pour tous les services de backend de l'équilibreur de charge, la référence de la vérification d'état n'est pas spécifiée pour l'équilibreur de charge dans son ensemble (au niveau de l'objet Ingress proprement dit).

GKE crée des vérifications de l'état selon l'une des méthodes suivantes :

• CRD BackendConfig : définition de ressource personnalisée (CRD, Custom Resource Definition) qui vous permet de contrôler précisément la façon dont vos services interagissent avec l'équilibreur de charge. Les CRD BackendConfig vous permettent de spécifier des paramètres personnalisés pour la vérification de l'état associée au service de backend correspondant. Ces paramètres personnalisés offrent davantage de flexibilité et de contrôle sur les vérifications de l'état pour l'équilibreur de charge d'application classique et l'équilibreur de charge d'application interne créés par un objet Ingress.
• Vérification d'aptitude : contrôle de diagnostic qui détermine si un conteneur dans un pod est prêt à diffuser du trafic. Le contrôleur GKE Ingress crée la vérification de l'état de l'état pour le service de backend du service en fonction de la vérification d'aptitude utilisée par les pods actifs de ce service. Vous pouvez déduire les paramètres de vérification de l'état (chemin d'accès, port et protocole, par exemple) de la définition de la vérification d'aptitude.
• Valeurs par défaut : paramètres utilisés lorsque vous ne configurez pas de CRD BackendConfig ou ne définissez pas d'attributs pour la vérification d'aptitude.

Bonne pratique :

Utilisez un CRD BackendConfig pour contrôler au mieux les paramètres de vérification de l'état de l'état de l'équilibreur de charge.

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.

Remarque : Le champ containerPort doit être défini dans les spécifications du pod et le champ targetPort doit être défini dans les spécifications du service pour la vérification de l'état afin de déduire les paramètres définis lors de la vérification d'aptitude. Si elles ne sont pas définies, la vérification de l'état du service de backend utilise par défaut le chemin d'accès "/", même si les paramètres sont définis lors de la vérification d'aptitude.

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 l'équilibrage de charge natif en conteneurs : 15 secondes Pour les groupes d'instances : 60 secondes	Si présent dans la spec du pod actif : Pour l'équilibrage de charge natif en conteneurs : 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 l'équilibrage de charge natif en conteneurs : 2 Pour les groupes d'instances : 10	Identique à la valeur par défaut : pour l'équilibrage de charge natif en conteneurs : 2 Pour les groupes d'instances : 10
Spécification du port	Pour l'équilibrage de charge natif en conteneurs : 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 l'équilibrage de charge natif en conteneurs : l'adresse IP du pod Pour les groupes d'instances : l'adresse IP du nœud	Identique à la valeur par défaut : Pour l'équilibrage de charge natif en conteneurs : l'adresse IP du pod Pour les groupes d'instances : l'adresse IP du nœud

Remarque : Une vérification d'aptitude Kubernetes valide accepte la définition de plusieurs en-têtes HTTP dans readinessProbe.httpGet. Si readinessProbe.httpGet.httpHeaders spécifie davantage que l'en-tête Host, les paramètres de vérification d'état de l'équilibreur de charge sont définis sur les valeurs par défaut au lieu des valeurs déduites de la vérification d'aptitude. Cette limitation existe, car les vérifications d'état acceptent uniquement la définition de l'en-tête Host.

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 regroupé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.

Avertissement : Lorsque les paramètres de vérification d'état d'un service de backend sont déduits de la vérification d'aptitude d'un pod de diffusion, GKE ne maintient pas la synchronisation entre la vérification d'aptitude et la vérification d'état :

• Si vous modifiez la vérification d'aptitude des pods actifs d'un service référencé par un objet Ingress après la création par GKE de l'équilibreur de charge d'application externe ou interne pour cet objet Ingress, les modifications que vous apportez à la vérification d'aptitude ne seront pas copiées dans la vérification d'état pour le service de backend correspondant sur l'équilibreur de charge.
• À l'inverse, si vous modifiez la vérification d'état utilisée par le service de backend d'un équilibreur de charge créé dans le cadre d'un objet Ingress, GKE ne met pas à jour les vérifications d'aptitude, et n'annule aucune des modifications que vous apportez à la vérification d'état.

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.

Disponibilité des pods

Une fois les vérifications de l'état de l'équilibreur de charge configurées à l'aide de l'une des méthodes précédentes, le contrôleur d'entrée GKE utilise l'état de santé des points de terminaison de backend pour déterminer l'aptitude des pods, ce qui est essentiel pour gérer les mises à jour progressives et la stabilité globale du trafic.

Pour les pods concernés, le contrôleur d'entrée correspondant gère une porte de disponibilité de type cloud.google.com/load-balancer-neg-ready. Le contrôleur d'entrée envoie des demandes de vérification de l'état de l'équilibreur de charge incluant des demandes relatives à l'état de tous les points de terminaison appartenant au NEG. Lorsque l'état de l'équilibreur de charge indique que le point de terminaison correspondant à un pod particulier est opérationnel, le contrôleur d'entrée définit la valeur de la porte de disponibilité de ce pod sur True. Le kubelet exécuté sur chaque nœud calcule alors la disponibilité réelle du pod en tenant compte à la fois de cette valeur de porte de disponibilité et de la valeur de vérification de la préparation du pod, si celle-ci est définie.

Les portes de disponibilité des pods sont automatiquement activées lorsque vous utilisez l'équilibrage de charge natif en conteneurs via Ingress.

Les portes de disponibilité contrôlent la vitesse d'une mise à jour progressive. Lorsque vous lancez une mise à jour progressive, la création de chaque nouveau pod par GKE conduit à l'ajout d'un point de terminaison associé dans un NEG. Lorsque le point de terminaison est sain du point de vue de l'équilibreur de charge, le contrôleur d'Ingress définit la porte de disponibilité sur True. Un pod nouvellement créé doit a minima passer sa porte de disponibilité avant que GKE ne supprime un ancien pod. Cela garantit que le point de terminaison correspondant au pod a déjà réussi la vérification d'état réalisée par l'équilibreur de charge et que la capacité de backend est maintenue.

Si la porte de disponibilité d'un pod n'indique jamais que le pod est prêt, par exemple en raison d'une image de conteneur incorrecte ou d'une vérification d'état mal configurée au niveau de l'équilibreur de charge, l'équilibreur de charge ne dirige aucun trafic vers le nouveau pod. Si un tel échec se produit lors du déploiement d'une mise à jour, le déploiement est bloqué après la tentative de création d'un nouveau pod car la porte de disponibilité de ce pod n'atteint jamais la valeur True. Pour plus d'informations sur la détection et la résolution d'une telle situation, consultez la section de dépannage.

Sans l'équilibrage de charge natif en conteneurs et sans portes de préparation, GKE ne peut pas détecter si les points de terminaison d'un équilibreur de charge sont opérationnels avant d'identifier les pods comme étant prêts. Dans les versions précédentes de Kubernetes, vous contrôliez la vitesse de suppression et de remplacement des pods en spécifiant un délai (minReadySeconds dans les spécifications de déploiement).

GKE définit la valeur de cloud.google.com/load-balancer-neg-ready pour un pod sur True si l'une des conditions suivantes est remplie :

• Aucune des adresses IP du pod n'est un point de terminaison dans un NEG GCE_VM_IP_PORT géré par le plan de contrôle GKE.
• Une ou plusieurs des adresses IP du pod sont des points de terminaison dans un NEG GCE_VM_IP_PORT géré par le plan de contrôle GKE. Le NEG est associé à un service de backend. La vérification de l'état de l'équilibreur de charge pour le service de backend est concluante.
• Une ou plusieurs des adresses IP du pod sont des points de terminaison dans un NEG GCE_VM_IP_PORT géré par le plan de contrôle GKE. Le NEG est associé à un service de backend. La vérification de l'état de l'équilibreur de charge pour le service de backend se termine par un dépassement de délai.
• Une ou plusieurs des adresses IP du pod sont des points de terminaison dans un ou plusieurs NEG GCE_VM_IP_PORT. Aucun des NEG n'est associé à un service de backend. Aucune donnée de vérification d'état de l'équilibreur de charge n'est disponible.

Compatibilité avec WebSocket

Avec les équilibreurs de charge d'application externes, le protocole WebSocket fonctionne sans aucune configuration.

Si vous comptez utiliser le protocole WebSocket, il peut être opportun de spécifier un délai avant expiration supérieur à la valeur par défaut de 30 secondes. Pour le trafic WebSocket envoyé via un équilibreur de charge d'application externeGoogle Cloud , le délai avant expiration du service de backend est interprété comme la durée maximale pendant laquelle une connexion WebSocket peut rester ouverte, qu'elle soit inactive ou non.

Pour définir la valeur de délai avant expiration d'un service de backend, consultez Délai avant expiration de réponse du service de backend.

Scénarios de mise en réseau avancés

GKE Ingress est compatible avec les configurations réseau avancées, comme le partage de ressources réseau entre plusieurs projets et l'utilisation de contrôleurs Ingress personnalisés.

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 :

• Proxys Google Front End (GFE) et systèmes de vérification de l'état utilisés par les équilibreurs de charge d'application externes pour Ingress externe. Pour en savoir plus, consultez la présentation des équilibreurs de charge d'application externes.

• Systèmes de vérification de l'état pour les équilibreurs de charge d'application internes utilisés par Ingress interne.

  Remarque : Que vous utilisiez ou non un VPC partagé, si votre cluster utilise un objet Ingress interne, vous devez créer manuellement des règles de pare-feu autorisant le trafic entrant afin d'autoriser le trafic provenant dusous-réseau proxy réservé dans le réseau VPC et la région du cluster. Il est nécessaire de créer manuellement ces règles, car le contrôleur GKE Ingress ne peut pas créer de règles de pare-feu d'entrée permettant d'autoriser le trafic pour le sous-réseau proxy réservé d'un équilibreur de charge d'application interne. Pour en savoir plus, consultez la section Environnement de mise en réseau requis dans Ingress pour les équilibreurs de charge d'application internes.

  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. Lorsque vous déployez une ressource Ingress dans un VPC partagé, l'événement de ressource Ingress fournit la règle de pare-feu spécifique nécessaire 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'étatGoogle Cloud .

   Remarque : Les différents types de ressources Ingress nécessitent des règles différentes. GKE peut afficher un avertissement de règle de pare-feu, même si vous disposez de vos propres règles de pare-feu d'entrée personnalisées pour autoriser le trafic. Dans ce cas, vous pouvez ignorer l'avertissement.

Remarque : Pour les objets Ingress multicluster, cette étape de provisionnement manuelle est la seule méthode possible pour installer des règles de pare-feu dans un projet hôte. Il n'est pas possible de modifier les autorisations de compte de service pour le provisionnement automatique.

Accorder au contrôleur d'entrée 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, compute.firewalls.delete et compute.subnetworks.list. 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:[e-mail] \
  --role=roles/compute.securityAdmin

Remplacez l'élément suivant :

• HOST_PROJECT_ID : ID de projet du projet hôte du VPC partagé.
• SERVICE_PROJECT_NUMBER : numéro de projet du projet de service contenant votre cluster.

Utiliser un contrôleur d'entrée personnalisé

Vous pouvez exécuter un contrôleur d'Ingress personnalisé en désactivant le module complémentaire HttpLoadBalancing. Cela empêche le contrôleur GKE Ingress de traiter les ressources Ingress.

Si vous souhaitez exécuter un contrôleur d'entrée personnalisé avec le module complémentaire HttpLoadBalancing activé, par exemple pour utiliser des fonctionnalités telles que sous-paramètre et Private Service Connect, vous pouvez utiliser l'une des approches suivantes:

• Dans le fichier manifeste d'entrée, définissez l'annotation kubernetes.io/ingress.class. Cette configuration est compatible avec les clusters exécutant toutes les versions de GKE.
• Configurez le champ ingressClassName.
• Configurer une classe Ingress par défaut

Vous devez vous assurer que spec.ingressClassName n'est pas accidentellement écrasé par un processus. Une opération de mise à jour qui transforme une valeur valide spec.IngressClassName en une chaîne vide ("") oblige le contrôleur GKE Ingress à traiter la ressource Ingress.

Configurer le champ ingressClassName

Vous pouvez utiliser un contrôleur d'entrée personnalisé en définissant le champ ingressClassName dans le fichier manifeste d'entrée. Le fichier manifeste suivant décrit une entrée spécifiant le contrôleur d'entrée cilium:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: cafe-ingress
spec:
 ingressClassName: cilium
 tls:
 - hosts:
   - cafe.example.com
   secretName: cafe-secret
 rules:
 - host: cafe.example.com

Remarque : Si un objet Ingress contient une valeur vide spec.ingressClassName ou si spec.ingressClassName n'est pas présente, et l'entrée ne comporte pas l'annotation kubernetes.io/ingress.class, le contrôleur d'entrée GKE traite l'objet Ingress.

Configurer une classe Ingress par défaut

Vous pouvez configurer une classe Ingress par défaut pour toutes les ressources Ingress d'un cluster en créant une ressource IngressClass avec l'annotation ingressclass.kubernetes.io/is-default-class définie sur true:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: gce
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/ingress-gce

Remarque : Le contrôleur d'admission renseigne le champ spec.ingressClassName pour les nouvelles ressources Ingress du cluster, mais ne modifie pas les ressources Ingress existantes.

Résumé du 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 d'entrée GKE traite ou non une entrée dépend de la valeur de l'annotation kubernetes.io/ingress.class et du champ ingressClassName dans le fichier manifeste d'entrée. Pour en savoir plus, consultez la page Comportement du contrôleur GKE Ingress.

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.