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.
Associer FrontendConfig à votre ressource Ingress
FrontendConfig ne peut être utilisé qu'avec des entrées externes.
Vous pouvez associer une FrontendConfig à un objet Ingress ouMultiClusterIngress
.
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.
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 valeurPORT_NUMBER_1
ouPORT_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 valeurPORT_NUMBER_2
ouPORT_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 à uncontainerPort
pour un pod de diffusion). Sinon, l'équilibreur de charge envoie le trafic vers l'adresse IP d'un nœud sur lenodePort
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 siresponseCodeName
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 :
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 esttrue
, Cloud CDN est activé pour ce backend Ingress.INCLUDE_HOST
: si la valeur esttrue
, les requêtes adressées à différents hôtes sont mises en cache séparément.INCLUDE_PROTOCOL
: si la valeur esttrue
, les requêtes HTTP et HTTPS sont mises en cache séparément.INCLUDE_QUERY_STRING
: si la valeur esttrue
, les paramètres de chaîne de requête sont inclus dans la clé de cache selonqueryStringBlacklist
ouqueryStringWhitelist
. Si aucun paramètre n'est défini, la chaîne de requête entière est incluse. Si la valeur estfalse
, 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écifierqueryStringBlacklist
ouqueryStringWhitelist
, 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écifierqueryStringBlacklist
ouqueryStringWhitelist
, 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 :
CACHE_MODE
: mode de cache.CLIENT_TTL
,DEFAULT_TTL
etMAX_TTL
: configuration de la valeur TTL. Pour en savoir plus, consultez la page Utiliser les remplacements et les paramètres TTL.NEGATIVE_CACHING
: si la valeur esttrue
, le cache négatif est activé. Pour en savoir plus, consultez la page Utiliser le cache négatif.NEGATIVE_CACHING_CODE
etNEGATIVE_CACHING_TTL
: configuration de cache négatif. Pour en savoir plus, consultez la page Utiliser le cache négatif.REQ_COALESCING
: si la valeur esttrue
, la réduction est activée. Pour en savoir plus, consultez la section Réduire le nombre de requêtes (coalescence).SERVE_WHILE_STALE
: délai, en secondes, après l'expiration de la réponse, pendant lequel Cloud CDN continue de diffuser une version obsolète. Pour plus d'informations, consultez la page Diffuser du contenu obsolète.SIGNED_MAX_AGE
: durée maximale de mise en cache des réponses, en secondes. Pour en savoir plus, consultez la section Personnaliser le délai de cache maximal (facultatif).KEY_NAME
,KEY_VALUE
etSECRET_NAME
: configuration de clé d'URL signée. Pour plus d'informations, consultez la section Créer des clés de requête signées.
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écifiezcheck-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 deTIMEOUT
doit être inférieure ou égale à celle deINTERVAL
. Cette valeur est exprimée en secondes. Chaque vérificateur requiert un code de réponseHTTP 200 (OK)
avant la fin du délai avant expiration du vérificateur.HEALTH_THRESHOLD
etUNHEALTHY_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 CRDBackendConfig
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 cheminrequest-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 de80
.Lorsque vous utilisez l'équilibrage de charge natif en conteneur, vous devez sélectionner un port correspondant à un
containerPort
de pod de diffusion (quecontainerPort
soit référencé par untargetPort
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é auxcontainerPort
référencés par letargetPort
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 esttrue
, 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 sienable
est défini surtrue
.sampleRate
est un champ facultatif, mais s'il est configuré,enable: true
doit également être défini. Sinon, il est interprété commeenable: 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"
Affinité basée sur les cookies générés
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 :
- Créez un objet Deployment.
- Créez une CRD BackendConfig.
- Créez un objet Service et associez l'un de ses ports à la CRD BackendConfig.
- Créez un objet Ingress et associez-le à la paire (Service, Port).
- Validez les propriétés du service de backend.
- 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 champcloud.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 Kubernetesmy-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 :
Supprimez le nom de la CRD FrontendConfig de l'annotation
networking.gke.io/v1beta1.FrontendConfig
dans le fichier manifeste Ingress.Appliquez le fichier manifeste Ingress modifié à votre cluster, en utilisant par exemple la commande
kubectl apply
.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 :
Supprimez le nom de la CRD BackendConfig de l'annotation
cloud.google.com/backend-config
dans le fichier manifeste Service.Appliquez le fichier manifeste Service modifié à votre cluster, en utilisant par exemple la commande
kubectl apply
.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.
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 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
:
Pour éviter les erreurs de série 500, procédez comme suit :
Définissez le paramètre
BackendService Drain Timeout
pour votre service sur 1 minute.Pour les utilisateurs d'Ingress, consultez la section Définir le délai avant expiration sur la ressource BackendConfig.
Pour les utilisateurs de Gateway, consultez la section Configurer le délai avant expiration sur la ressource GCPBackendPolicy.
Pour ceux qui gèrent leurs services de backend directement lors de l'utilisation de NEG autonomes, consultez la section Définir le délai avant expiration directement sur le service de backend.
É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
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 sectiontls
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