Configuration d'entrée sur Google Cloud

Cette page offre une présentation complète des éléments compatibles et configurables via Kubernetes Ingress sur 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 Google Contrôleur GKE Ingress
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 Globaux
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 autogérés DG DG DG
Certificats SSL gérés par Google DG DG
FrontendConfig
Règle SSL DG DG avec Gateway 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
En-têtes de réponse personnalisés 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 disponibles.

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

Configurer l'entrée à l'aide du contrôleur par défaut

Vous ne pouvez pas configurer manuellement les fonctionnalités de LoadBalancer à l'aide de Google Cloud SDK ou de la console Google Cloud. Vous devez utiliser les ressources Kubernetes BackendConfig ou FrontendConfig.

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 d'application externe ou un équilibreur de charge d'application interne) en utilisant 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 ne peuvent être utilisées qu'avec des entrées externes. 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

FrontendConfig ne peut être utilisé qu'avec des entrées externes.

Vous pouvez associer une FrontendConfig à un objet Ingress ou 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.

MultiClusterIngress

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

Vous pouvez utiliser l'annotation cloud.google.com/backend-config ou beta.cloud.google.com/backend-config pour spécifier le nom d'une BackendConfig.

BackendConfig identique pour tous les ports de service

Pour utiliser la même BackendConfig sur tous les ports, utilisez la clé default dans l'annotation. Le contrôleur d'entrée utilise la même 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.

Vous pouvez utiliser la clé default pour les ressources Ingress et MultiClusterIngress. 
apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

BackendConfig unique par port de service

Pour les objets Ingress et MultiClusterIngress, vous pouvez spécifier une BackendConfig personnalisée pour un ou plusieurs ports, à 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é.

GKE 1.16-gke.3 et versions ultérieures

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:
    cloud.google.com/backend-config: '{"ports": {
      PORT_NAME_1:"BACKENDCONFIG_REFERENCE_A",
      PORT_NAME_2:"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
...

Remplacez les éléments suivants :

  • BACKENDCONFIG_REFERENCE_A : nom d'une ressource BackendConfig existante.
  • BACKENDCONFIG_REFERENCE_B : nom d'une ressource BackendConfig existante.
  • SERVICE_REFERENCE_A : utilisez la valeur PORT_NUMBER_1 ou PORT_NAME_1. En effet, 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).
  • SERVICE_REFERENCE_B : utilisez la valeur PORT_NUMBER_2 ou PORT_NAME_2. En effet, 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).

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_DENYLIST
      queryStringWhitelist: QUERY_STRING_ALLOWLIST
    cacheMode: CACHE_MODE
    clientTtl: CLIENT_TTL
    defaultTtl: DEFAULT_TTL
    maxTtl: MAX_TTL
    negativeCaching: NEGATIVE_CACHING
    negativeCachingPolicy:
      code: NEGATIVE_CACHING_CODE
      ttl: NEGATIVE_CACHING_TTL
    requestCoalescing: REQ_COALESCING
    serveWhileStale: SERVE_WHILE_STALE
    signedUrlCacheMaxAgeSec: SIGNED_MAX_AGE
    signedUrlKeys:
      keyName: KEY_NAME
      keyValue: KEY_VALUE
      secretName: SECRET_NAME

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_DENYLIST : 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_ALLOWLIST : 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.

Les champs suivants ne sont compatibles qu'avec les versions 1.23.3-gke.900 et ultérieures de GKE Ingress. Ils ne sont pas compatibles avec Multi Cluster Ingress :

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.

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.

Règle de sécurité d'objet Ingress 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"

Deux sources de vérité

Bien qu'elles soient configurées via GKE, les API BackendService Compute Engine sous-jacentes peuvent toujours être utilisées pour modifier directement la règle de sécurité à appliquer. Cela crée deux sources d'informations fiables : GKE et Compute Engine. Le comportement du contrôleur d'entrée GKE en réponse au champ securityPolicy dans BackendConfig est documenté dans le tableau ci-dessous. Pour éviter les conflits et les comportements inattendus, nous vous recommandons d'utiliser le BackendConfig de GKE pour gérer la règle de sécurité à utiliser.

Champ BackendConfig Valeur Comportement
spec.securityPolicy.name CloudArmorPolicyName Le contrôleur d'entrée GKE définit la stratégie Google Cloud Armor nommée CloudArmorPolicyName sur l'équilibreur de charge. Le contrôleur d'entrée GKE écrase la règle définie précédemment.
spec.securityPolicy.name Chaîne vide ("") Le contrôleur d'entrée GKE supprime toutes les règles Google Cloud Armor configurées de l'équilibreur de charge.
spec.securityPolicy nil Le contrôleur d'entrée GKE utilise la configuration définie sur l'objet BackendService configuré via l'API Compute Engine à l'aide de la console Google Cloud, de gcloud CLI ou de Terraform.

Pour configurer un objet GKE Ingress avec la protection Google Cloud Armor, consultez la page objet Ingress compatible avec Google Cloud Armor.

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

Activer IAP avec le client OAuth géré par Google

À partir de la version 1.29.2-gke.1035000 de GKE, IAP peut être configuré pour utiliser le client OAuth géré par Google à l'aide d'un fichier BackendConfig. Pour décider d'utiliser le client OAuth Google ou un client OAuth personnalisé, consultez la section Quand utiliser une configuration OAuth personnalisée dans la documentation IAP.

Pour activer IAP avec le client OAuth géré par Google, ne fournissez pas OAuthCredentials dans le fichier BackendConfig. Pour les utilisateurs qui ont déjà configuré IAP à l'aide de OAuthCredentials, il n'existe pas de chemin de migration permettant de passer à l'utilisation du client OAuth géré par Google. Vous devez recréer le backend (supprimez le service de l'objet Ingress, puis réassociez-le). Nous vous recommandons d'effectuer cette opération pendant un intervalle de maintenance, car cela provoquera des temps d'arrêt. Dans le chemin de migration opposé, le passage du service OAuthClient géré par Google à OAuthCredentials est possible.

Le fichier manifeste BackendConfig suivant active Identity-Aware Proxy avec le client OAuth géré par Google :

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

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

Identity-Aware Proxy avec entrée interne

Pour configurer une entrée interne pour IAP, vous devez utiliser le niveau Premium. Si vous n'utilisez pas le niveau Premium, vous ne pouvez pas afficher ni créer d'équilibreurs de charge d'application internes avec Identity-Aware Proxy. Vous devez également disposer d'un abonnement BeyondCorp Enterprise pour pouvoir utiliser l'entrée interne pour IAP.

Pour configurer un objet GKE Ingress sécurisé avec l'authentification basée sur Identity-Aware Proxy, consultez la section Entrée avec IAP activée.

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}"

En-têtes de réponse personnalisés

Pour activer les en-têtes de réponse personnalisés, vous devez spécifier une liste d'en-têtes dans la propriété customResponseHeaders de la ressource BackendConfig. Spécifiez chaque en-tête en tant que chaîne header-name:header-value.

Voici un exemple de fichier manifeste BackendConfig pour ajouter un en-tête de réponse HTTP Strict Transport Security (HSTS) :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customResponseHeaders:
    headers:
    - "Strict-Transport-Security: max-age=28800; includeSubDomains"

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

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 équilibreur de charge d'application externe 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

Vous pouvez détecter les erreurs de configuration courantes à l'aide de l'outil de diagnostic Ingress. Vous devez également vous assurer que les vérifications d'état sont correctement configurées.

BackendConfig introuvable

Cette erreur se produit lorsqu'une ressource BackendConfig est spécifiée pour un port de Service dans l'annotation Service, mais que la ressource BackendConfig réelle est introuvable.

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

kubectl get event

Le résultat suivant indique que votre 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

Pour résoudre ce problème, assurez-vous que vous n'avez pas créé la ressource BackendConfig dans le mauvais espace de noms ou que sa référence n'est pas mal orthographiée dans l'annotation Service.

Règle de sécurité d'objet Ingress introuvable

Une fois l'objet Ingress créé, si la stratégie de sécurité n'est pas correctement associée au service LoadBalancer, évaluez l'événement Kubernetes pour voir s'il existe une erreur de configuration. Si votre BackendConfig spécifie une règle de sécurité qui n'existe pas, un événement d'avertissement est émis régulièrement.

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

kubectl get event

Le résultat 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.

Pour résoudre ce problème, spécifiez le nom correct de la règle de sécurité dans votre CRD BackendConfig.

Résoudre les erreurs de série 500 avec des NEG lors du scaling des charges de travail dans GKE

Symptôme :

Lorsque vous utilisez des NEG provisionnés par GKE pour l'équilibrage de charge, vous pouvez rencontrer des erreurs 502 ou 503 pour les services pendant le scaling à la baisse des charges de travail. Les erreurs 502 se produisent lorsque les pods sont arrêtés avant la fermeture des connexions existantes, tandis que les erreurs 503 se produisent lorsque le trafic est dirigé vers des pods supprimés.

Ce problème peut affecter les clusters si vous utilisez des produits d'équilibrage de charge gérés par GKE qui utilisent des NEG, y compris des ressources Gateway et Ingress, et des NEG autonomes. Si vous effectuez fréquemment le scaling de vos charges de travail, le risque que votre cluster soit affecté est plus élevé.

Diagnostic :

La suppression d'un pod dans Kubernetes sans drainer son point de terminaison et sans le supprimer du NEG entraîne d'abord des erreurs de série 500. Pour éviter les problèmes lors de l'arrêt des pods, vous devez prendre en compte l'ordre des opérations. Les images suivantes affichent des scénarios lorsque BackendService Drain Timeout n'est pas défini et que BackendService Drain Timeout est défini avec BackendConfig.

Scénario 1 : BackendService Drain Timeout n'est pas défini.

L'image suivante montre un scénario dans lequel BackendService Drain Timeout n'est pas défini.

Le délai avant expiration du drainage du service de backend n&#39;est pas défini

Scénario 2 : BackendService Drain Timeout est défini.

L'image suivante montre un scénario dans lequel BackendService Drain Timeout est défini.

Le délai avant expiration du drainage du service de backend est défini

Le moment exact où les erreurs de série 500 se produisent dépend des facteurs suivants :

  • Latence de dissociation d'API NEG : la latence de dissociation d'API NEG représente le temps nécessaire à la finalisation de l'opération de dissociation dans Google Cloud. Ce temps est influencé par divers facteurs en dehors de Kubernetes, tels que le type d'équilibreur de charge et la zone spécifique.

  • Latence de drainage : la latence de drainage représente le temps nécessaire à l'équilibreur de charge pour commencer à détourner le trafic d'une partie spécifique de votre système. Une fois le drainage initié, l'équilibreur de charge cesse d'envoyer de nouvelles requêtes au point de terminaison, mais il existe toujours un temps de latence pour déclencher le drainage (latence de drainage), ce qui peut provoquer des erreurs 503 temporaires si le pod n'existe plus.

  • Configuration de la vérification de l'état : des seuils de vérification d'état plus sensibles limitent la durée des erreurs 503, car ils peuvent signaler à l'équilibreur de charge d'arrêter d'envoyer des requêtes aux points de terminaison même si l'opération de dissociation n'est pas terminée.

  • Délai de grâce avant l'arrêt : le délai de grâce avant l'arrêt détermine la durée maximale accordée à un pod pour s'arrêter. Toutefois, un pod peut être arrêté avant la fin du délai de grâce avant l'arrêt. Si un pod prend plus de temps que ce délai, il est contraint de s'arrêter à la fin de celui-ci. Il s'agit d'un paramètre sur le pod et il doit être configuré dans la définition de la charge de travail.

Solution potentielle :

Pour éviter ces erreurs 5XX, appliquez les paramètres suivants. Les valeurs de délai avant expiration sont indicatives et il se peut que vous deviez les adapter à votre application spécifique. La section suivante vous guide tout au long du processus de personnalisation.

L'image suivante montre comment maintenir le pod actif avec preStopHook :

Le délai avant expiration du drainage du service de backend est défini

Pour éviter les erreurs de série 500, procédez comme suit :

  1. Définissez le paramètre BackendService Drain Timeout pour votre service sur 1 minute.

  2. Étendez terminationGracePeriod sur le pod.

    Définissez terminationGracePeriodSeconds sur 3,5 minutes sur le pod. Combiné aux paramètres recommandés, cela permet à vos pods de disposer d'une fenêtre de 30 à 45 secondes pour un arrêt progressif après que le point de terminaison du pod a été supprimé du NEG. Si vous avez besoin de plus de temps pour effectuer un arrêt progressif, vous pouvez prolonger le délai de grâce ou suivre les instructions mentionnées dans la section Personnaliser les délais avant expiration.

    Le fichier manifeste BackendConfig suivant spécifie un délai avant expiration du drainage de connexion de 210 secondes (3,5 minutes) :

    apiVersion: v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  terminationGracePeriodSeconds: 210
  containers:
  - name: my-app
    image: my-app-image:latest
    ports:
    - containerPort: 80

  3. Appliquez un preStopHook à tous les conteneurs.

    Appliquez un preStopHook qui garantira que le pod est actif pendant 120 secondes de plus pendant que le point de terminaison du pod est drainé dans l'équilibreur de charge et que le point de terminaison est supprimé du NEG.

    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-app
    # Container configuration details...
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 120s"]

Personnaliser les délais avant expiration

Pour garantir la continuité du pod et éviter les erreurs de série 500, le pod doit être actif jusqu'à ce que le point de terminaison soit supprimé du NEG. Pour éviter les erreurs 502 et 503, envisagez d'implémenter une combinaison de délais avant expiration et d'un preStopHook.

Pour maintenir le pod actif plus longtemps pendant le processus d'arrêt, ajoutez un preStopHook au pod. Exécutez le preStopHook avant qu'un pod ne reçoive le signal d'arrêt, de sorte que le preStopHook puisse être utilisé pour maintenir le Pod en activité jusqu'à ce que le point de terminaison correspondant soit supprimé du NEG.

Pour prolonger la durée pendant laquelle un pod reste actif pendant le processus d'arrêt, insérez un preStopHook dans la configuration du pod comme suit :

spec:
  containers:
  - name: my-app
    ...
    lifecycle:
      preStopHook:
        exec:
          command: ["/bin/sh", "-c", "sleep <latency time>"]

Vous pouvez configurer des délais avant expiration et les paramètres associés pour gérer l'arrêt progressif des pods lors du scaling à la baisse des charges de travail. Vous pouvez ajuster les délais avant expiration en fonction de cas d'utilisation spécifiques. Nous vous recommandons de commencer par des délais plus longs et de réduire la durée si nécessaire. Vous pouvez personnaliser les délais avant expiration en configurant les paramètres liés au délai d'expiration et le preStopHook de différentes manières :

Délai avant expiration du drainage du service de backend

Le paramètre Backend Service Drain Timeout n'est pas défini par défaut et n'a aucun effet. Si vous définissez le paramètre Backend Service Drain Timeout et que vous l'activez, l'équilibreur de charge arrête d'acheminer de nouvelles requêtes vers le point de terminaison et attend la fin du délai avant d'arrêter les connexions existantes.

Vous pouvez définir le paramètre Backend Service Drain Timeout à l'aide du BackendConfig avec Ingress, du GCPBackendPolicy avec Gateway, ou manuellement sur le BackendService avec les NEG autonomes. Le délai avant expiration doit être 1,5 à 2 fois plus long que le temps nécessaire au traitement d'une requête. Cela garantit que si une requête arrive juste avant le début du drainage, elle se termine avant l'expiration du délai. La définition du paramètre Backend Service Drain Timeout sur une valeur supérieure à 0 permet de limiter les erreurs 503, car aucune nouvelle requête n'est envoyée aux points de terminaison dont la suppression est planifiée. Pour que ce délai avant expiration soit effectif, vous devez l'utiliser conjointement avec le preStopHook pour vous assurer que le pod reste actif pendant le drainage. Sans cette combinaison, les requêtes existantes qui n'ont pas abouti reçoivent une erreur 502.

Durée de preStopHook

Le preStopHook doit retarder suffisamment l'arrêt du pod pour que la latence de drainage et le délai avant expiration du drainage du service de backend soient terminés, garantissant ainsi un drainage de connexion correct et la suppression des points de terminaison du NEG avant l'arrêt du pod.

Pour obtenir des résultats optimaux, assurez-vous que votre temps d'exécution de preStopHook est inférieur ou égal à la somme de Backend Service Drain Timeout et de la latence de drainage.

Cette valeur peut être calculée à l'aide de la formule suivante :

preStopHook >= Backend Service Drain Timeout + Drain Latency

Nous vous recommandons de définir la latence de drainage sur une minute. Si les erreurs 500 persistent, estimez la durée totale d'occurrence et ajoutez le double de ce temps à la latence. Ainsi, votre pod dispose de suffisamment de temps pour être drainé progressivement avant d'être supprimé du service. Vous pouvez ajuster cette valeur si le délai est trop long pour votre cas d'utilisation spécifique.

Vous pouvez également estimer le délai en examinant le code temporel de suppression du pod et le code temporel lorsque le point de terminaison a été supprimé du NEG dans Cloud Audit Logs.

Paramètre de délai de grâce avant l'arrêt

Vous devez configurer le paramètre terminationGracePeriod de façon à laisser suffisamment de temps pour que preStopHook se termine et que le pod s'arrête de manière progressive.

Par défaut, lorsqu'il n'est pas explicitement défini, le délai de terminationGracePeriod est de 30 secondes. Vous pouvez calculer le délai optimal de terminationGracePeriod à l'aide de la formule suivante :

terminationGracePeriod >= preStopHook Time + Pod shutdown time

Pour définir terminationGracePeriod dans la configuration du pod, procédez comme suit :

  spec:
    terminationGracePeriodSeconds: <terminationGracePeriod>
    containers:
    - name: my-app
      ...
    ...

NEG introuvable lors de la création d'une ressource Ingress interne

L'erreur suivante peut se produire lorsque vous créez une ressource Ingress interne dans GKE :

Error syncing: error running backend syncing routine: googleapi: Error 404: The resource 'projects/PROJECT_ID/zones/ZONE/networkEndpointGroups/NEG' was not found, notFound

Cette erreur se produit, car Ingress pour les équilibreurs de charge d'application internes nécessite des groupes de points de terminaison du réseau (NEG, Network Endpoint Group) en tant que backends.

Dans les environnements de VPC partagé ou les clusters sur lesquels des règles de réseau sont activées, ajoutez l'annotation cloud.google.com/neg: '{"ingress": true}' au fichier manifeste de service.

504 Expiration du délai imparti pour la passerelle : expiration du délai de la requête en amont

L'erreur suivante peut se produire lorsque vous accédez à un service à partir d'une ressource Ingress interne dans GKE :

HTTP/1.1 504 Gateway Timeout
content-length: 24
content-type: text/plain

upsteam request timeout

Cette erreur se produit, car le trafic envoyé aux équilibreurs de charge d'application internes est transmis par les proxys Envoy dans la plage de sous-réseau proxy réservé.

Pour autoriser le trafic provenant de la plage de sous-réseau proxy réservé, créez une règle de pare-feu sur le targetPort du service.

Erreur 400 : valeur non valide pour le champ "resource.target"

L'erreur suivante peut se produire lorsque vous accédez à un service à partir d'une ressource Ingress interne dans GKE :

Error syncing:LB_NAME does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION_NAME/targetHttpProxies/LB_NAME. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.

Pour résoudre ce problème, déployez un sous-réseau proxy réservé.

Erreur lors de la synchronisation : erreur lors de l'exécution de la routine de synchronisation de l'équilibreur de charge : l'équilibreur de charge n'existe pas.

L'une des erreurs suivantes peut se produire lorsque le plan de contrôle GKE est mis à niveau ou que vous modifiez un objet Ingress :

"Error during sync: error running load balancer syncing routine: loadbalancer
INGRESS_NAME does not exist: invalid ingress frontend configuration, please
check your usage of the 'kubernetes.io/ingress.allow-http' annotation."

ou

Error during sync: error running load balancer syncing routine: loadbalancer LOAD_BALANCER_NAME does not exist:
googleapi: Error 400: Invalid value for field 'resource.IPAddress':'INGRESS_VIP'. Specified IP address is in-use and would result in a conflict., invalid

Pour résoudre ces problèmes, procédez comme suit :

  • Ajoutez le champ hosts dans la section tls du fichier manifeste d'entrée, puis supprimez l'objet Ingress. Attendez cinq minutes que GKE supprime les ressources Ingress inutilisées. Recréez ensuite ces ressources. Pour plus d'informations, consultez la section Champ d'hôtes d'un objet Ingress.
  • Annulez les modifications que vous avez apportées sur l'objet Ingress. Ajoutez ensuite un certificat à l'aide d'une annotation ou d'un secret Kubernetes.

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: 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 à 1.18.20-gke.5099
  • 1.19.10-gke.700 à 1.19.14-gke.299
  • 1.20.6-gke.700 à 1.20.9-gke.899

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.

Mettez à niveau votre plan de contrôle GKE vers l'une des versions mises à jour suivantes, qui corrigent ce problème et permettent d'utiliser les ressources BackendConfig v1beta1 en toute sécurité :

  • 1.18.20-gke.5100 et versions ultérieures
  • 1.19.14-gke.300 et versions ultérieures
  • 1.20.9-gke.900 et versions ultérieures

Étape suivante