Configurer les fonctionnalités Ingress

Cette page offre une présentation complète des éléments compatibles et configurables via Kubernetes Ingress sur Google Cloud. Ingress for GKE (Google Kubernetes Engine) et Ingress for Anthos fournissent un équilibrage de charge pour les entreprises avec une intégration étroite à votre réseau VPC Google Cloud.

Comparatif des fonctionnalités

Le tableau suivant fournit une liste des fonctionnalités compatibles avec Ingress sur Google Cloud. La disponibilité de la fonctionnalité, Disponibilité générale (DG) ou Version bêta, est également indiquée.

Classe d'objet Ingress Entrée externe Entrée interne Entrée multicluster
Contrôleur d'entrée Contrôleur d'entrée hébergé par le cluster Contrôleur d'entrée hébergé par Google
Type d'équilibreur de charge Google Cloud Équilibreur de charge HTTP(S) externe Équilibreur de charge HTTP(S) interne Équilibreur de charge HTTP(S) externe
Capacité en nombre de clusters Cluster unique Cluster unique Multicluster
Champ d'application de l'équilibreur de charge Mondial Régional Mondial
Compatibilité avec les versions Toutes GKE 1.16.5+ GKE 1.14+
Environnements compatibles GKE GKE GKE
Compatibilité avec les VPC partagés DG DG DG
Annotations de service
Équilibrage de charge natif en conteneurs (NEG) DG DG DG
HTTPS de l'équilibreur de charge aux backends DG DG DG
HTTP/2 DG DG
TLS uniquement
DG
Annotations Ingress
Adresses IP statiques DG DG DG
Certificats basés sur les secrets Kubernetes DG DG DG
Certificats SSL Google autogérés DG DG DG
Certificats SSL gérés par Google DG DG
FrontendConfig
Règle SSL DG DG
Redirection HTTP vers HTTPS DG
1.17.13-gke.2600+DG
DG
BackendConfig
Délai avant expiration du service de backend DG DG DG
Cloud CDN DG DG
Délai avant expiration du drainage de connexion DG DG DG
Configuration personnalisée de la vérification d'état de l'équilibreur de charge DG DG DG
Règles de sécurité Google Cloud Armor DG
1.19.10-gke.700G
DG
Configuration de la journalisation des accès HTTP DG DG DG
Identity-Aware Proxy (IAP) DG DG DG
Affinité de session DG DG DG
En-têtes de requêtes définis par l'utilisateur DG DG

BCette fonctionnalité est disponible en version bêta à partir de la version spécifiée. Les fonctionnalités sans version répertoriée sont compatibles avec toutes les versions de GKE et d'Anthos disponibles.

GCette fonctionnalité est en disponibilité générale à partir de la version spécifiée.

Configurer les fonctionnalités Ingress

Lorsque vous créez un Ingress à l'aide du contrôleur par défaut, vous pouvez choisir le type d'équilibreur de charge (un équilibreur de charge HTTP(S) externe ou un équilibreur de charge HTTP(S) interne) à l'aide d'une annotation sur l'objet Ingress. Vous pouvez décider si GKE crée des NEG zonaux ou s'il utilise des groupes d'instances en utilisant une annotation sur chaque objet Service.

Les définitions de ressources personnalisées (CRD) FrontendConfig et BackendConfig vous permettent de personnaliser davantage l'équilibreur de charge. Ces CRD vous permettent de définir de manière hiérarchique des fonctionnalités d'équilibreur de charge supplémentaires, de façon plus structurée que les annotations. Pour utiliser Ingress (et ces CRD), vous devez activer le module complémentaire d'équilibrage de charge HTTP. L'équilibrage de charge HTTP est activé par défaut sur les clusters GKE. Vous ne devez pas le désactiver.

Les CRD FrontendConfig sont référencées dans un objet Ingress et les CRD BackendConfig sont référencées par un objet Service. Les mêmes CRD peuvent être référencées par plusieurs objets Service ou Ingress pour la cohérence de la configuration. Les CRD FrontendConfig et BackendConfig partagent le même cycle de vie que leurs ressources Ingress et Service correspondantes, et sont souvent déployées ensemble.

Le schéma suivant montre comment :

  • Une annotation sur un objet Ingress ou MultiClusterIngress fait référence à une CRD FrontendConfig. La CRD FrontendConfig fait référence à une règle SSL Google Cloud.

  • Une annotation sur un objet Service ou MultiClusterService fait référence à une CRD BackendConfig. La CRD BackendConfig contient les paramètres personnalisés pour la vérification de l'état du service de backend correspondant.

Présentation de BackendConfig et FrontendConfig
Figure : Présentation de BackendConfig et FrontendConfig

Associer FrontendConfig à votre ressource Ingress

Vous pouvez associer une FrontendConfig à une entrée ou à un MultiClusterIngress.

Entrée

Utilisez l'annotation networking.gke.io/v1beta1.FrontendConfig :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/v1beta1.FrontendConfig: "FRONTENDCONFIG_NAME"
...

Remplacez FRONTENDCONFIG_NAME par le nom de votre FrontendConfig.

Multi Cluster Ingress

Utilisez l'annotation networking.gke.io/frontend-config :

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  annotations:
    networking.gke.io/frontend-config: "FRONTENDCONFIG_NAME"
...

Remplacez FRONTENDCONFIG_NAME par le nom de votre FrontendConfig.

Associer BackendConfig à votre ressource Ingress

Un objet Service ou MultiClusterService peut utiliser l'annotation cloud.google.com/backend-config ou beta.cloud.google.com/backend-config pour spécifier le nom d'une ressource BackendConfig. Lorsqu'elle est associée à un objet Service ou MultiClusterService, la ressource BackendConfig demande à Google Cloud de créer ou de modifier les paramètres du service de backend.

Dans les exemples suivants :

Si vous utilisez GKE version 1.16-gke.3 ou ultérieure, vous devez utiliser l'annotation cloud.google.com/backend-config (même si l'annotation beta.cloud.google.com/backend-config fonctionne également). Pour les versions antérieures, vous devez utiliser l'annotation beta.cloud.google.com/backend-config.

BackendConfig identique pour tous les ports de service

Pour utiliser la même ressource BackendConfig sur tous les ports d'un objet Service ou MultiClusterService, utilisez la clé default dans l'annotation. Le contrôleur d'entrée utilise la même ressource BackendConfig chaque fois qu'il crée un service de backend d'équilibreur de charge pour référencer l'un des ports de l'objet Service.

1.16-gke.3+

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

Toutes les versions compatibles

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

BackendConfig unique par port de service

Vous pouvez spécifier une ressource BackendConfig personnalisée pour un ou plusieurs ports d'un objet Service ou MultiClusterService, à l'aide d'une clé correspondant au nom ou au numéro du port. Le contrôleur d'entrée utilise une ressource BackendConfig spécifique lorsqu'il crée un service de backend d'équilibreur de charge pour un port de service référencé.

1.16-gke.3+

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "SERVICE_REFERENCE_A":"BACKENDCONFIG_REFERENCE_A",
    "SERVICE_REFERENCE_B":"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

Toutes les versions compatibles

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {
    "SERVICE_REFERENCE_A":"BACKENDCONFIG_REFERENCE_A",
    "SERVICE_REFERENCE_B":"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

Dans GKE, l'annotation BackendConfig d'un service peut faire référence au nom du port (spec.ports[].name) ou au numéro de port (spec.ports[].port). Dans l'exemple ci-dessus, vous pouvez remplacer SERVICE_REFERENCE_A par PORT_NUMBER_1 ou PORT_NAME_1, et SERVICE_REFERENCE_B par PORT_NUMBER_2 ou PORT_NAME_2.

Lorsque vous faites référence au port du service par un numéro, vous devez utiliser la valeur port au lieu de la valeur targetPort. Le numéro de port utilisé ici ne sert qu'à lier la ressource BackendConfig. Il ne contrôle pas le port sur lequel l'équilibreur de charge envoie des tests de trafic ou de vérification de l'état :

  • Lorsque vous utilisez l'équilibrage de charge natif en conteneur, l'équilibreur de charge envoie du trafic vers un point de terminaison dans un groupe de points de terminaison du réseau (correspondant à une adresse IP de pod) sur le port de service targetPort (qui doit correspondre à un containerPort pour un pod de diffusion). Sinon, l'équilibreur de charge envoie le trafic vers l'adresse IP d'un nœud sur le nodePort du port de service référencé.

  • Lorsque vous utilisez BackendConfig pour fournir une vérification de l'état personnalisée pour l'équilibreur de charge, le numéro de port que vous utilisez pour la vérification de l'état de l'équilibreur de charge peut différer du numéro spec.ports[].port du service. Pour en savoir plus sur les numéros de port pour les vérifications d'état, consultez la section Configuration personnalisée de vérification de l'état.

Configurer les fonctionnalités Ingress via des paramètres FrontendConfig

La section suivante montre comment configurer une CRD FrontendConfig pour activer des fonctionnalités Ingress spécifiques.

Règles SSL

Les règles SSL vous permettent de spécifier un ensemble de versions et d'algorithmes de chiffrement TLS utilisés par l'équilibreur de charge pour interrompre le trafic HTTPS provenant des clients. Vous devez d'abord créer une règle SSL en dehors de GKE. Une fois créée, vous pouvez la référencer dans une CRD FrontendConfig.

Le champ sslPolicy de la CRD FrontendConfig référence le nom d'une règle SSL hébergée dans le même projet Google Cloud que le cluster GKE. Il associe la règle SSL au proxy HTTPS cible, qui a été créé pour l'équilibreur de charge HTTP(S) externe par la ressource Ingress. La même ressource FrontendConfig et la même règle SSL peuvent être référencées par plusieurs ressources Ingress. En cas de modification d'une règle SSL déjà référencée, la modification est transmise aux services GFE (Google Front End) qui alimentent votre équilibreur de charge HTTP(S) externe créé par la ressource Ingress.

Le fichier manifeste FrontendConfig suivant active une règle SSL nommée gke-ingress-ssl-policy :

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  sslPolicy: gke-ingress-ssl-policy

Redirections HTTP vers HTTPS

Un équilibreur de charge HTTP externe peut rediriger des requêtes HTTP non chiffrées vers un équilibreur de charge HTTPS qui utilise la même adresse IP. Lorsque vous créez un objet Ingress avec les redirections HTTP vers HTTPS activées, ces deux équilibreurs de charge sont créés automatiquement. Les requêtes adressées à l'adresse IP externe de l'entrée sur le port 80 sont automatiquement redirigées vers la même adresse IP externe sur le port 443. Cette fonctionnalité est basée sur les redirections HTTP vers HTTPS fournies par Cloud Load Balancing.

Pour accepter la redirection HTTP vers HTTPS, un objet Ingress doit être configuré pour diffuser à la fois le trafic HTTP et HTTPS. Si HTTP ou HTTPS est désactivé, la redirection ne fonctionnera pas.

Les redirections HTTP vers HTTPS sont configurées à l'aide du champ redirectToHttps dans une ressource personnalisée FrontendConfig. Les redirections sont activées pour l'ensemble de la ressource Ingress. Ainsi, les redirections HTTPS sont activées pour tous les services référencés par Ingress.

Le fichier manifeste FrontendConfig suivant active les redirections HTTP vers HTTPS. Définissez le champ spec.redirectToHttps.enabled sur true pour activer les redirections HTTPS. Le champ spec.responseCodeName est facultatif. Si elle est omise, une redirection 301 Moved Permanently est utilisée.

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: RESPONSE_CODE

Remplacez RESPONSE_CODE par l'un des éléments suivants :

  • MOVED_PERMANENTLY_DEFAULT pour renvoyer un code de réponse de redirection 301 (par défaut si responseCodeName n'est pas spécifié).
  • FOUND pour renvoyer un code de réponse de redirection 302.
  • SEE_OTHER pour renvoyer un code de réponse de redirection 303.
  • TEMPORARY_REDIRECT pour renvoyer un code de réponse de redirection 307.
  • PERMANENT_REDIRECT pour renvoyer un code de réponse de redirection 308.

Lorsque les redirections sont activées, le contrôleur d'entrée crée un équilibreur de charge, comme indiqué dans le schéma suivant :

Un équilibreur de charge HTTP externe de redirection unique comportant une règle de transfert, un proxy HTTP cible et un mappage d'URL avec une redirection vers un équilibreur de charge HTTPS complet avec services de backend

Pour vérifier que votre redirection fonctionne, utilisez une commande curl :

curl http://IP_ADDRESS

Remplacez IP_ADDRESS par l'adresse IP de votre ressource Ingress.

La réponse affiche le code de réponse de redirection que vous avez configuré. Par exemple, l'exemple suivant concerne une FrontendConfig incluant une redirection 301: MovedPermanently :

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://35.244.160.59/">here</A>.</BODY></HTML>

Configurer les fonctionnalités Ingress via des paramètres BackendConfig

Les sections suivantes vous expliquent comment définir la CRD BackendConfig pour activer des fonctionnalités Ingress spécifiques. Les modifications apportées à une ressource BackendConfig sont constamment rapprochées. Vous n'avez donc pas besoin de supprimer puis de recréer une ressource Ingress pour répercuter les modifications apportées à la CRD BackendConfig.

Pour en savoir plus sur les limites de la CRD BackendConfig, consultez la section Limites.

Délai avant expiration du service de backend

Vous pouvez utiliser une CRD BackendConfig pour définir un délai d'expiration du service de backend, exprimé en secondes. Si vous ne spécifiez pas de valeur, celle-ci est définie par défaut sur 30 secondes.

Le fichier manifeste BackendConfig suivant spécifie un délai d'expiration de 40 secondes :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40

Cloud CDN

Vous pouvez activer Cloud CDN à l'aide d'une CRD BackendConfig.

Le fichier manifeste BackendConfig suivant affiche tous les champs disponibles lors de l'activation de Cloud CDN :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: CDN_ENABLED
    cachePolicy:
      includeHost: INCLUDE_HOST
      includeProtocol: INCLUDE_PROTOCOL
      includeQueryString: INCLUDE_QUERY_STRING
      queryStringBlacklist: QUERY_STRING_BLACKLIST
      queryStringWhitelist: QUERY_STRING_WHITELIST

Remplacez les éléments suivants :

  • CDN_ENABLED : si la valeur est true, Cloud CDN est activé pour ce backend Ingress.
  • INCLUDE_HOST : si la valeur est true, les requêtes adressées à différents hôtes sont mises en cache séparément.
  • INCLUDE_PROTOCOL : si la valeur est true, les requêtes HTTP et HTTPS sont mises en cache séparément.
  • INCLUDE_QUERY_STRING : si la valeur est true, les paramètres de chaîne de requête sont inclus dans la clé de cache selon queryStringBlacklist ou queryStringWhitelist. Si aucun paramètre n'est défini, la chaîne de requête entière est incluse. Si la valeur est false, la chaîne de requête entière est exclue de la clé de cache.
  • QUERY_STRING_BLACKLIST : permet de spécifier un tableau de chaînes avec les noms des paramètres de chaîne de requête à exclure des clés de cache. Tous les autres paramètres sont inclus. Vous pouvez spécifier queryStringBlacklist ou queryStringWhitelist, mais pas les deux.
  • QUERY_STRING_WHITELIST : permet de spécifier un tableau de chaînes avec les noms des paramètres de chaîne de requête à inclure dans les clés de cache. Tous les autres paramètres sont exclus. Vous pouvez spécifier queryStringBlacklist ou queryStringWhitelist, mais pas les deux.

Développez la section suivante pour voir un exemple qui déploie Cloud CDN via une ressource Ingress, puis valide la mise en cache du contenu de l'application.

Délai avant expiration du drainage de connexion

Vous pouvez configurer le délai avant expiration du drainage de connexion à l'aide d'une CRD BackendConfig. Le délai avant expiration du drainage de connexion est le délai d'attente, exprimé en secondes, pour le drainage des connexions. Au cours de ce délai avant expiration spécifié, les requêtes existantes adressées au backend en cours de suppression se voient accorder un délai de grâce pour être traitées. L'équilibreur de charge n'envoie plus de nouvelles requêtes au backend en cours de suppression. Une fois le délai écoulé, toutes les connexions au backend qui subsistent encore sont fermées. La durée de ce délai peut être comprise entre 0 et 3 600 secondes. La valeur par défaut est 0, ce qui correspond à la désactivation du drainage de connexion.

Le fichier manifeste BackendConfig suivant spécifie un délai avant expiration du drainage de connexion de 60 secondes :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  connectionDraining:
    drainingTimeoutSec: 60

Configuration personnalisée de vérification de l'état

GKE configure les vérifications de l'état de l'équilibreur de charge Google Cloud de plusieurs façons lors du déploiement via une ressource Ingress. Pour en savoir plus sur la manière dont la ressource Ingress GKE déploie les vérifications de l'état, consultez la section décrivant les vérifications de l'état via une ressource Ingress.

BackendConfig vous permet de contrôler précisément les paramètres de vérification de l'état de l'équilibreur de charge.

Vous pouvez configurer plusieurs objets Service GKE faisant référence à la même CRD BackendConfig en tant que modèle réutilisable. Pour les paramètres healthCheck, une vérification de l'état unique de Google Cloud est créée pour chaque service de backend correspondant à chaque objet Service GKE.

Le fichier manifeste BackendConfig suivant affiche tous les champs disponibles lors de la configuration d'une vérification de l'état BackendConfig :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  healthCheck:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTH_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    type: PROTOCOL
    requestPath: PATH
    port: PORT

Remplacez l'élément suivant :

  • INTERVAL : spécifiez check-interval, en secondes, pour chaque vérificateur d'état. Il s'agit du temps écoulé entre le début du test d'un vérificateur et le début du test suivant. Si vous omettez ce paramètre, la valeur par défaut de Google Cloud (5 secondes) est utilisée. Pour en savoir plus sur la mise en œuvre, consultez la section Vérifications multiples et fréquence de vérification.
  • TIMEOUT : spécifiez la durée pendant laquelle Google Cloud attend une réponse à une vérification. La valeur de TIMEOUT doit être inférieure ou égale à celle de INTERVAL. Cette valeur est exprimée en secondes. Chaque vérificateur requiert un code de réponse HTTP 200 (OK) avant la fin du délai avant expiration du vérificateur.
  • HEALTH_THRESHOLD et UNHEALTHY_THRESHOLD : spécifiez le nombre de tentatives de connexion séquentielles qui doivent réussir ou échouer pour au moins un vérificateur, afin de faire passer l'état de opérationnel à non opérationnel, ou vice versa. Si vous omettez l'un de ces paramètres, Google Cloud utilise la valeur par défaut de 2.
  • PROTOCOL : spécifiez un protocole utilisé par les systèmes de vérification pour la vérification de l'état. La CRD BackendConfig n'accepte que la création de vérifications de l'état à l'aide des protocoles HTTP, HTTPS ou HTTP2. Pour plus d'informations, consultez la section Critères de réussite pour HTTP, HTTPS et HTTP/2. Vous ne pouvez pas omettre ce paramètre.
  • PATH : pour les vérifications de l'état HTTP, HTTPS ou HTTP2, spécifiez le chemin request-path auquel le système de vérification doit se connecter. Si vous omettez ce paramètre, Google Cloud utilise la valeur par défaut de /.

    • PORT : une ressource BackendConfig n'accepte que la spécification du port de vérification de l'état de l'équilibreur de charge à l'aide d'un numéro de port. Si vous omettez ce paramètre, Google Cloud utilise la valeur par défaut de 80.

    • Lorsque vous utilisez l'équilibrage de charge natif en conteneur, vous devez sélectionner un port correspondant à un containerPort de pod de diffusion (que containerPort soit référencé par un targetPort du service ou non). Étant donné que l'équilibreur de charge envoie directement des vérifications à l'adresse IP du pod, vous n'êtes pas limité aux containerPort référencés par le targetPort d'un service. Les systèmes de vérification de l'état se connectent à l'adresse IP d'un pod de diffusion sur le port que vous spécifiez.

    • Pour les backends de groupes d'instances, vous devez sélectionner un port correspondant à un nodePort exposé par le service. Les systèmes de test de vérification d'état se connectent ensuite à chaque nœud sur ce port.

Règles de sécurité Google Cloud Armor

Les règles de sécurité Google Cloud Armor vous aident à protéger vos applications à équilibrage de charge contre les attaques Web. Après avoir configuré une règle de sécurité Google Cloud Armor, vous pouvez la référencer à l'aide d'une CRD BackendConfig.

Ajoutez le nom de votre règle de sécurité à la CRD BackendConfig. Le fichier manifeste BackendConfig suivant spécifie une règle de sécurité nommée example-security-policy :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

Journalisation des accès HTTP

L'objet Ingress peut journaliser toutes les requêtes HTTP des clients dans Cloud Logging. Vous pouvez activer et désactiver la journalisation des accès à l'aide de la CRD BackendConfig et définir le taux d'échantillonnage des journaux d'accès.

Pour configurer la journalisation des accès, utilisez le champ logging dans votre CRD BackendConfig. Si logging est omis, la journalisation d'accès adopte le comportement par défaut. Cela dépend de la version de GKE.

Vous pouvez configurer les champs suivants :

  • enable : si la valeur est true, la journalisation des accès est activée pour cette entrée et les journaux sont disponibles dans Cloud Logging. Sinon, la journalisation des accès est désactivée pour cette ressource Ingress.
  • sampleRate : spécifiez une valeur comprise entre 0,0 et 1,0 ; où 0,0 signifie qu'aucun paquet n'est enregistré et 1,0 signifie que 100 % des paquets sont enregistrés. Ce champ n'est pertinent que si enable est défini sur true. sampleRate est un champ facultatif, mais s'il est configuré, enable: true doit également être défini. Sinon, il est interprété comme enable: false.

Le fichier manifeste BackendConfig suivant active la journalisation des accès et définit le taux d'échantillonnage sur 50 % des requêtes HTTP pour une ressource Ingress donnée :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

Identity-Aware Proxy

Afin de configurer la CRD BackendConfig pour Identity-Aware Proxy (IAP), vous devez spécifier les valeurs enabled et secretName dans le bloc iap de votre CRD BackendConfig. Pour ce faire, assurez-vous que vous disposez de l'autorisation compute.backendServices.update.

Le fichier manifeste BackendConfig suivant active Identity-Aware Proxy :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

Pour obtenir des instructions complètes, consultez la page Activer IAP pour GKE dans la documentation IAP.

Affinité de session

Vous pouvez utiliser une CRD BackendConfig pour définir l'affinité de session sur l'adresse IP du client ou sur le cookie généré.

Affinité basée sur les adresses IP client

Pour utiliser une CRD BackendConfig afin de définir l'affinité basée sur les adresses IP client, définissez affinityType sur "CLIENT_IP", comme dans l'exemple suivant :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "CLIENT_IP"

Pour utiliser une CRD BackendConfig afin de définir l'affinité basée sur les cookies générés, définissez affinityType sur GENERATED_COOKIE dans votre fichier manifeste BackendConfig. Vous pouvez également utiliser affinityCookieTtlSec pour définir la période pendant laquelle le cookie reste actif.

Le fichier manifeste suivant définit le type d'affinité sur les cookies générés et donne aux cookies une valeur TTL de 50 secondes :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 50

En-têtes de requêtes définis par l'utilisateur

Vous pouvez configurer les en-têtes de requêtes définis par l'utilisateur à l'aide d'une CRD BackendConfig. L'équilibreur de charge ajoute les en-têtes que vous spécifiez aux requêtes qu'il transfère aux backends.

Pour activer les en-têtes de requêtes définis par l'utilisateur, vous devez spécifier une liste d'en-têtes dans la propriété customRequestHeaders de la ressource BackendConfig. Spécifiez chaque en-tête en tant que chaîne header-name:header-value.

Le fichier manifeste BackendConfig suivant ajoute trois en-têtes de requête :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customRequestHeaders:
    headers:
    - "X-Client-Region:{client_region}"
    - "X-Client-City:{client_city}"
    - "X-Client-CityLatLong:{client_city_lat_long}"

Exercice : Définir des délais avant expiration sur une ressource Ingress à l'aide d'un service de backend

L'exercice suivant montre les étapes requises pour configurer les délais avant expiration et le drainage de connexion sur une ressource Ingress associée à une ressource BackendConfig.

Pour configurer les propriétés backend d'un objet Ingress, procédez comme suit :

  1. Créez un objet Deployment.
  2. Créez une CRD BackendConfig.
  3. Créez un objet Service et associez l'un de ses ports à la CRD BackendConfig.
  4. Créez un objet Ingress et associez-le à la paire (Service, Port).
  5. Validez les propriétés du service de backend.
  6. Effectuez un nettoyage.

Créer un déploiement

Avant de créer une CRD BackendConfig et un objet Service, vous devez créer un objet Deployment.

L'exemple de fichier manifeste suivant correspond à un objet Deployment nommé my-deployment.yaml :

# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 2
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Créez l'objet Deployment en exécutant la commande suivante :

kubectl apply -f my-deployment.yaml

Créer une CRD BackendConfig

Utilisez votre CRD BackendConfig pour spécifier les fonctionnalités Ingress que vous souhaitez utiliser.

Ce fichier manifeste BackendConfig, nommé my-backendconfig.yaml, spécifie :

  • un délai avant expiration de 40 secondes ;
  • Un délai avant expiration du drainage de connexion de 60 secondes
# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60

Pour obtenir la liste complète des fonctionnalités que vous pouvez définir à l'aide d'une CRD BackendConfig, consultez la section BackendConfig du tableau des fonctionnalités.

Créez une CRD BackendConfig en exécutant la commande suivante :

kubectl apply -f my-backendconfig.yaml

Créer un objet Service

La CRD BackendConfig correspond à une seule combinaison Service-Port, même si un Service possède plusieurs ports. Chaque port peut être associé à une seule CRD BackendConfig. Si un port d'un objet Service est référencé par une ressource Ingress, et si ce port est associé à une CRD BackendConfig, le service de backend d'équilibrage de charge HTTP(S) participe à sa configuration depuis la CRD BackendConfig.

Voici un exemple de fichier manifeste de service nommé my-service.yaml :

# my-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    purpose: bsc-config-demo
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080

L'annotation cloud.google.com/backend-config spécifie un mappage entre les ports et les objets BackendConfig. Dans le fichier my-service.yaml :

  • Tous les pods comportant le libellé purpose: bsc-config-demo sont membres du service.
  • Le port TCP 80 de l'objet Service est associé à une CRD BackendConfig nommée my-backendconfig. Ceci est spécifié par le champ cloud.google.com/backend-config.
  • Une requête envoyée au port 80 de l'objet Service est transmise à l'un des pods membres sur le port TCP 8080.

Pour créer l'objet Service, exécutez la commande suivante :

kubectl apply -f my-service.yaml

Créer une ressource Ingress

Voici le fichier manifeste d'une ressource Ingress nommé my-ingress.yaml.. Dans cet exemple, les requêtes entrantes sont acheminées vers le port 80 de l'objet Service nommé my-service.

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

Pour créer la ressource Ingress, exécutez la commande suivante :

kubectl apply -f my-ingress.yaml

Attendez quelques minutes que le contrôleur d'entrée configure un équilibrage de charge HTTP(S) et un service de backend associé. Une fois cette opération terminée, vous avez configuré votre ressource Ingress pour qu'elle utilise un délai avant expiration de 40 secondes et un délai avant expiration du drainage de connexion de 60 secondes.

Valider les propriétés du service de backend

Vous pouvez vérifier que les paramètres appropriés de l'équilibreur de charge ont été appliqués via votre CRD BackendConfig. Pour ce faire, identifiez le service de backend déployé par la ressource Ingress et examinez ses paramètres pour vérifier qu'ils correspondent aux fichiers manifestes de l'objet Deployment.

Commencez par décrire la ressource my-ingress et filtrez en fonction de l'annotation qui répertorie les services de backend associés à la ressource Ingress. Exemple :

kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends

Le résultat doit être semblable à ceci :

ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}

La sortie fournit des informations sur vos services de backend. Par exemple, cette annotation contient deux services de backend :

  • "k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY" fournit des informations sur le service de backend associé au service Kubernetes my-service.
    • k8s1-27fde173 est un hachage utilisé pour décrire le cluster.
    • default est l'espace de noms Kubernetes.
    • HEALTHY indique que le backend est opérationnel.
  • "k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY" fournit des informations sur le service de backend associé au backend par défaut (serveur 404).
    • k8s1-27fde173 est un hachage utilisé pour décrire le cluster.
    • kube-system correspond à l'espace de noms.
    • default-http-backend est le nom du service Kubernetes.
    • 80 est le port de l'hôte.
    • HEALTHY indique que le backend est opérationnel.

Inspectez ensuite le service de backend associé à my-service à l'aide de gcloud. Définissez un filtrage sur "drainingTimeoutSec" et "timeoutSec" pour vérifier qu'ils ont été définis dans le plan de contrôle de l'équilibreur de charge Google Cloud. Exemple :

# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500

# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"

Sortie :

  drainingTimeoutSec: 60
  timeoutSec: 40

La présence de drainingTimeoutSec et de timeoutSec dans la sortie confirme que leurs valeurs ont été correctement définies via la CRD BackendConfig.

Effectuer un nettoyage

Pour éviter que des frais supplémentaires ne soient facturés sur votre compte, supprimez les objets Kubernetes que vous avez créés pour cet exercice :

kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment

Limites de BackendConfig

Les CRD BackendConfig présentent les limites suivantes :

  • Une seule paire (Service, Port) ne peut consommer qu'une seule CRD BackendConfig, même si plusieurs objets Ingress font référence à la paire (Service, Port). Cela signifie que tous les objets Ingress qui font référence à la même paire (Service, Port) doivent utiliser la même configuration pour Google Cloud Armor, Cloud IAP et Cloud CDN.

  • Cloud IAP et Cloud CDN ne peuvent pas être activés pour le même service de backend d'équilibrage de charge HTTP(S). Cela signifie que vous ne pouvez pas configurer Cloud IAP et Cloud CDN dans le même objet BackendConfig.

  • Vous devez utiliser kubectl 1.7 ou une version ultérieure pour pouvoir interagir avec la CRD BackendConfig.

Supprimer la configuration spécifiée dans une CRD FrontendConfig ou BackendConfig

Pour révoquer une fonctionnalité Ingress, vous devez explicitement désactiver sa configuration dans la CRD FrontendConfig ou BackendConfig. Le contrôleur d'entrée ne rapproche que les configurations spécifiées dans ces CRD.

Pour effacer ou désactiver une configuration précédemment activée, définissez la valeur du champ sur une chaîne vide ("") ou sur une valeur booléenne de false, en fonction du type de champ.

Le fichier manifeste BackendConfig suivant désactive une règle de sécurité Google Cloud Armor et Cloud CDN :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: false
  securityPolicy:
    name: ""

Supprimer une CRD FrontendConfig ou BackendConfig

FrontendConfig

Pour supprimer une CRD FrontendConfig, procédez comme suit :

  1. Supprimez le nom de la CRD FrontendConfig de l'annotation networking.gke.io/v1beta1.FrontendConfig dans le fichier manifeste Ingress.

  2. Appliquez le fichier manifeste Ingress modifié à votre cluster, en utilisant par exemple la commande kubectl apply.

  3. Supprimez la CRD FrontendConfig, en utilisant par exemple la commande kubectl delete frontendconfig config my-frontendconfig.

BackendConfig

Pour supprimer une CRD BackendConfig, procédez comme suit :

  1. Supprimez le nom de la CRD BackendConfig de l'annotation cloud.google.com/backend-config dans le fichier manifeste Service.

  2. Appliquez le fichier manifeste Service modifié à votre cluster, en utilisant par exemple la commande kubectl apply.

  3. Supprimez la CRD BackendConfig, en utilisant par exemple la commande kubectl delete backendconfig my-backendconfig.

Dépannage

BackendConfig introuvable

Cette erreur se produit lorsqu'une CRD BackendConfig est spécifiée pour un port d'objet Service dans l'annotation Service, mais que la ressource BackendConfig réelle est introuvable. Cela peut se produire si vous n'avez pas créé la ressource BackendConfig, si vous l'avez créée dans le mauvais espace de noms ou si vous avez mal orthographié la référence dans l'annotation Service.

Pour évaluer un événement Kubernetes, exécutez la commande suivante :

kubectl get event

Le type de sortie suivant indique que votre CRD BackendConfig est introuvable :

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists

Règle de sécurité introuvable

Une fois l'objet Ingress créé, si la stratégie de sécurité n'est pas correctement associée au service d'équilibrage de charge, évaluez l'événement Kubernetes pour voir s'il existe une erreur de configuration. Si votre CRD BackendConfig spécifie une règle inexistante, un événement d'avertissement est émis régulièrement. Pour résoudre ce problème, assurez-vous de spécifier la règle de sécurité correcte, par nom, dans votre CRD BackendConfig.

Pour évaluer un événement Kubernetes, exécutez la commande suivante :

kubectl get event

Le type de sortie suivant indique que votre règle de sécurité est introuvable :

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy "my-policy" does not exist.

Problèmes connus

Impossible d'activer les redirections HTTPS avec le schéma de nommage des entrées V1

Vous ne pouvez pas activer les redirections HTTPS sur les ressources GKE Ingress créées sur GKE 1.16.8-gke.12 et versions antérieures. Vous devez recréer l'objet Ingress avant de pouvoir activer les redirections HTTPS, sans quoi un événement d'erreur sera créé et l'entrée ne sera pas synchronisée.

Le message d'événement d'erreur qui s'affiche ressemblera à ce qui suit :

Error syncing to GCP: error running load balancer syncing routine: loadbalancer lb-name does not exist: ensureRedirectUrlMap() = error: cannot enable HTTPS Redirects with the V1 Ingress naming scheme. Please recreate your ingress to use the newest naming scheme.

Champs des règles de sécurité Google Cloud Armor supprimés de BackendConfig

Il existe un problème connu lorsque la mise à jour d'une ressource BackendConfig à l'aide de l'API v1beta1 supprime des règles de sécurité Google Cloud Armor actives de son service. Ce problème affecte les versions GKE suivantes :

  • 1.18.19-gke.1400 et versions ultérieures
  • 1.19.10-gke.700 et versions ultérieures
  • 1.20.6-gke.700 à 1.20.9-gke.900

Si vous ne configurez pas Google Cloud Armor sur vos ressources Ingress via une ressource BackendConfig, ce problème n'affecte pas vos clusters.

Pour les clusters GKE qui configurent Google Cloud Armor via une ressource BackendConfig, il est fortement recommandé de ne mettre à jour les ressources BackendConfig qu'avec l'API v1. L'application d'une configuration BackendConfig à votre cluster à l'aide de ressources BackendConfig v1beta1 entraîne la suppression de vos règles de sécurité Google Cloud Armor du service auquel elles font référence.

Pour atténuer ce problème, effectuez des mises à jour de votre BackendConfig uniquement à l'aide de l'API BackendConfig v1. La ressource BackendConfig v1 accepte les mêmes champs que v1beta1 mais n'apporte aucune modification destructive, de sorte que le champ d'API peut être mis à jour de manière transparente. Remplacez les champs apiVersion de tous les fichiers manifestes BackendConfig actifs avec la valeur cloud.google.com/v1 et n'utilisez pas cloud.google.com/v1beta1. L'exemple de fichier manifeste suivant décrit une ressource BackendConfig qui utilise l'API v1 :

  apiVersion: cloud.google.com/v1
  kind: BackendConfig
  metadata:
    name: my-backend-config
  spec:
    securityPolicy:
      name: "ca-how-to-security-policy"

Si vous avez des systèmes ou des outils CI/CD qui mettent régulièrement à jour les ressources BackendConfig, assurez-vous d'utiliser le groupe d'API cloud.google.com/v1 dans ces systèmes.

Si votre CRD BackendConfig a déjà été mise à jour avec l'API v1beta1, votre stratégie de sécurité Google Cloud Armor a peut-être été supprimée. Vous pouvez déterminer si cela s'est produit en exécutant la commande suivante :

kubectl get backendconfigs -A -o json | jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'

Si la réponse renvoie des résultats, votre cluster est affecté par le problème. Le résultat de cette commande renvoie la liste des ressources BackendConfig (<namespace>/<name>) affectées par le problème. Si le résultat est vide, cela signifie que votre BackendConfig n'a pas été mise à jour à l'aide de l'API v1beta1 depuis l'apparition du problème. Toute mise à jour ultérieure de votre BackendConfig ne doit utiliser que la version v1.

Si votre stratégie de sécurité Google Cloud Armor a été supprimée, vous pouvez déterminer quand elle a été supprimée à l'aide de la requête Logging suivante :

resource.type="gce_backend_service"
protoPayload.methodName="v1.compute.backendServices.setSecurityPolicy"
protoPayload.authenticationInfo.principalEmail:"container-engine-robot.iam.gserviceaccount.com"
protoPayload.response.status = "RUNNING"
NOT protoPayload.authorizationInfo.permission:"compute.securityPolicies.use"

Si l'un de vos clusters a été affecté, cela peut être corrigé en transmettant une mise à jour de votre ressource BackendConfig qui utilise l'API v1.

Ce problème est en cours de correction dans toutes les versions de GKE concernées. Il est actuellement résolu dans les versions de GKE suivantes :

  • 1.19.14-gke.300 et versions ultérieures
  • 1.20.9-gke.900 et versions ultérieures
  • 1.21.1-gke.2700 et versions ultérieures

Étape suivante