Fonctionnalités Ingress

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

Comparatif des fonctionnalités

Le tableau suivant fournit une liste des fonctionnalités compatibles avec Ingress sur Google Cloud.

Classe d'objet Ingress Entrée externe Entrée interne Entrée multicluster
Contrôleur d'entrée GKE Ingress
(hébergé sur le maître GKE)
Anthos Ingress
(hébergé par Google)
Type d'équilibreur de charge Google Cloud Équilibreur de charge HTTP(S) externe Équilibreur de charge HTTP(S) interne Équilibreur de charge HTTP(S) externe
Capacité en nombre de clusters Cluster unique Cluster unique Multicluster
Champ d'application de l'équilibreur de charge Mondial Régional Mondial
Compatibilité avec les versions Toutes GKE 1.16.5+ GKE 1.14+
Environnements compatibles GKE GKE GKE
Compatibilité avec les VPC partagés Compatible Incompatible Compatible
Annotations de service
Équilibrage de charge natif en conteneurs (NEG)
HTTPS de l'équilibreur de charge aux backends
HTTP/2
Annotations Ingress
Adresses IP statiques
Certificats basés sur les secrets Kubernetes
Certificats SSL Google autogérés
Certificats SSL gérés par Google
FrontendConfig (version bêta)
Règle SSL
1.17.6-gke.11B
BackendConfig
Délai avant expiration du service de backend
Cloud CDN
Délai avant expiration du drainage de connexion
Configuration personnalisée de la vérification de l'état de l'équilibreur de charge
1.17.6-gke.11B

1.17.6-gke.11B
Règles de sécurité Google Cloud Armor
Configuration de la journalisation des accès HTTP
1.16.10-gke.6G

1.16.10-gke.6B
Identity-Aware Proxy (IAP)
Affinité de session
En-têtes de requêtes définis par l'utilisateur
1.15.3-gke.1G

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

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

Configurer les fonctionnalités Ingress

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

Les définitions de ressources personnalisées (CRD) FrontendConfig et BackendConfig vous permettent de personnaliser davantage l'équilibreur de charge. Ces CRD vous permettent de définir de manière hiérarchique des fonctionnalités d'équilibreur de charge supplémentaires, de façon plus structurée que les annotations. Les CRD FrontendConfig sont référencées dans un objet Ingress et les CRD BackendConfig sont référencées par un objet Service. Les mêmes CRD peuvent être référencées par plusieurs objets Service ou Ingress pour la cohérence de la configuration. Les CRD FrontendConfig et BackendConfig partagent le même cycle de vie que leurs ressources Ingress et Service correspondantes, et sont souvent déployées ensemble.

Le schéma suivant montre comment :

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

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

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

Associer FrontendConfig à votre ressource Ingress

Une CRD FrontendConfig est référencée par une annotation sur une ressource Ingress ou MultiClusterIngress. La CRD FrontendConfig correspond à l'ensemble de la ressource Ingress/MultiClusterIngress, comme illustré dans l'exemple suivant :

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

Associer BackendConfig à votre ressource Ingress

Une CRD BackendConfig est référencée par une annotation sur une ressource Service ou MultiClusterService. Cette dernière utilise l'annotation cloud.google.com/backend-config pour spécifier le nom de la CRD BackendConfig. Lorsqu'elle est associée à une ressource Service ou MultiClusterService, la CRD BackendConfig peut déterminer les paramètres du service de backend Google Cloud. L'exemple suivant montre comment associer une CRD BackendConfig à une ressource Service ou MultiClusterService. La clé default signifie que tous les ports de la ressource Service sont associés à la CRD BackendConfig my-backendconfig lorsque ces ports sont référencés par une ressource Ingress :

1.16-gke.3+

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

Toutes les versions compatibles

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

Si vous avez besoin de paramètres BackendConfig uniques pour différents ports d'une même ressource Service, vous pouvez associer explicitement des ressources BackendConfig spécifiques à ces ports. Dans l'exemple suivant, la clé ports autorise la liaison explicite de ports :

1.16-gke.3+

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "port-1":"backendconfig-1",
    "port-2":"backendconfig-2"
    }}'
spec:
  ports:
  - name:service-name-1
    port: 8001
    protocol: TCP
    targetPort: service-port-1
  - name: service-name-2
    port: 8002
    protocol: TCP
    targetPort: service-port-2
...

Toutes les versions compatibles

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {
    "port-1":"backendconfig-1",
    "port-2":"backendconfig-2"
    }}'
spec:
  ports:
  - name: service-name-1
    port: 8001
    protocol: TCP
    targetPort: service-port-1
  - name: service-name-2
    port: 8002
    protocol: TCP
    targetPort: >service-port-2
...

port-1 peut faire référence aux ports de la ressource Service par numéro, via service-port-1, ou par nom, via service-name-1 (seulement compatible avec GKE). Chaque port correspond à un service de backend d'équilibreur de charge Google Cloud qui permet aux ports de la ressource Service d'avoir des configurations différentes.

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

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/v1beta1
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/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: cdnEnabled
    cachePolicy:
      includeHost: includeHost
      includeProtocol:includeProtocol
      includeQueryString: includeQueryString
      queryStringBlacklist:queryStringBlacklist
      queryStringWhitelist: queryStringWhitelist

Remplacez les éléments suivants :

  • cdnEnabled : si la valeur est true, Cloud CDN est activé pour ce backend Ingress.
  • includeHost : si la valeur est true, les requêtes adressées à différents hôtes sont mises en cache séparément.
  • includeProtocol : si la valeur est true, les requêtes HTTP et HTTPS sont mises en cache séparément.
  • includeQueryString : 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.
  • queryStringBlacklist : 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.
  • queryStringWhitelist : permet de spécifier un tableau de chaînes avec les noms des paramètres de chaîne de requête à inclure dans les clés de cache. Tous les autres paramètres sont exclus. Vous pouvez spécifier queryStringBlacklist ou queryStringWhitelist, mais pas les deux.

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

Délai avant expiration du drainage de connexion

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

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

apiVersion: cloud.google.com/v1beta1
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.

Une méthode consiste à configurer explicitement les vérifications de l'état via une CRD BackendConfig. Si ces paramètres sont définis, ils remplacent les paramètres de la vérification d'aptitude Kubernetes et les valeurs par défaut de la vérification de l'état.

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 les éléments suivants :

  • interval : spécifiez check-interval, en secondes, pour chaque vérificateur de l'é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 : spécifie le port à 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 conteneurs, les systèmes de vérification se connectent à l'adresse IP d'un pod de diffusion. Sinon, les vérifications de l'état se connectent à l'adresse IP du nœud sur lequel le pod de diffusion est exécuté.

Règles de sécurité Google Cloud Armor

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

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

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

Journalisation des accès HTTP

La ressource 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. La journalisation des accès est activée par défaut dans toutes les versions antérieures à GKE 1.18, mais elle est exposée en tant que champ configurable à partir de 1.16.8-gke.10.

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/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

Cloud IAP

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

Le fichier manifeste BackendConfig suivant active Identity-Aware Proxy :

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

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

Affinité de session

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

Affinité basée sur les adresses IP client

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

apiVersion: cloud.google.com/v1beta1
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/v1beta1
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/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customRequestHeaders:
    headers:
    - "X-Client-Region:{client_region}"
    - "X-Client-City:{client_city}"
    - "X-Client-CityLatLong:{client_city_lat_long}"

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

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

Pour configurer les propriétés backend d'une ressource 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 objet Deployment

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: gcr.io/google-samples/hello-app:1.0

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

kubectl apply -f my-deployment.yaml

Créer une CRD BackendConfig

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

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

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

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

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

kubectl apply -f my-backendconfig.yaml

Créer un objet Service

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

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

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

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

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

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

kubectl apply -f my-service.yaml

Créer une ressource Ingress

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

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

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

kubectl apply -f my-ingress.yaml

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

Valider les propriétés du service de backend

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

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

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

Le résultat doit être semblable à ceci :

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

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

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

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

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

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

Sortie :

  drainingTimeoutSec: 60
  timeoutSec: 40

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

Effectuer un nettoyage

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

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

Limites de BackendConfig

Les CRD BackendConfig présentent les limites suivantes :

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

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

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

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

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

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

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

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

Supprimer une CRD FrontendConfig ou BackendConfig

FrontendConfig

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

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

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

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

BackendConfig

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

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

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

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

Dépannage

BackendConfig introuvable

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

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

kubectl get event

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

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

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

Règle de sécurité introuvable

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

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

kubectl get event

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

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

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

Étapes suivantes