Configurer Ingress pour les équilibreurs de charge d'application internes

Cette page vous explique comment configurer et utiliser Ingress pour les équilibreurs de charge d'application internes dans Google Kubernetes Engine (GKE). Ingress fournit une compatibilité intégrée avec l'équilibrage de charge interne via le contrôleur GKE Ingress.

Pour en savoir plus sur les fonctionnalités compatibles avec Ingress pour les équilibreurs de charge d'application internes, consultez la section Fonctionnalités Ingress. Pour en savoir plus sur le fonctionnement d'Ingress pour les équilibreurs de charge d'application internes, consultez la section Ingress pour les équilibreurs de charge d'application internes.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Conditions requises

Ingress pour les équilibreurs de charge d'application internes présente les exigences suivantes :

  • Votre cluster doit utiliser une version de GKE ultérieure à la version 1.16.5-gke.10.
  • Votre cluster doit être VPC natif.
  • Le module complémentaire HttpLoadBalancing doit être activé sur votre cluster. Il est activé par défaut. Ne le désactivez pas.
  • Vous devez utiliser des groupes de points de terminaison du réseau (NEG) comme backends pour votre service.

Déployer Ingress pour les équilibreurs de charge d'application internes

Les exercices suivants vous montrent comment déployer Ingress pour les équilibreurs de charge d'application internes :

  1. Préparez votre environnement.
  2. Créez un cluster.
  3. Déployer une application
  4. Déployer un service
  5. Déployez Ingress.
  6. Validez le déploiement.
  7. Supprimer des ressources Ingress.

Préparer votre environnement

Avant de pouvoir déployer des ressources d'équilibreur de charge via l'API Ingress de Kubernetes, vous devez préparer votre environnement réseau afin que les proxys de l'équilibreur de charge puissent être déployés dans une région donnée.

Créez un sous-réseau proxy réservé en suivant les instructions de la section Configurer le sous-réseau proxy réservé. Par exemple, la commande suivante crée un sous-réseau proxy réservé dans la région us-west1 à l'aide du réseau lb-network :

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=us-west1 \
    --network=lb-network \
    --range=10.129.0.0/23

Créer une règle de pare-feu

Le contrôleur Ingress ne crée pas de règle de pare-feu pour autoriser les connexions à partir des proxys de l'équilibreur de charge dans le sous-réseau proxy. Vous devez créer cette règle de pare-feu manuellement. Cependant, le contrôleur Ingress crée des règles de pare-feu pour autoriser les vérifications de l'état d'Ingress via Google Cloud.

Créez une règle de pare-feu pour autoriser les connexions des proxys de l'équilibreur de charge dans le sous-réseau proxy réservé au port d'écoute du pod :

gcloud compute firewall-rules create allow-proxy-connection \
    --allow=TCP:CONTAINER_PORT \
    --source-ranges=10.129.0.0/23 \
    --network=lb-network

Remplacez CONTAINER_PORT par la valeur du port que le pod écoute, par exemple 9376.

Créer un cluster

Dans cette section, vous allez créer un cluster natif VPC que vous pourrez utiliser avec Ingress pour les équilibreurs de charge d'application internes. Vous pouvez créer ce cluster à l'aide de Google Cloud CLI ou de la console Google Cloud.

gcloud

Créez un cluster en définissant les champs suivants :

gcloud container clusters create-auto CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --network=NETWORK

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom de votre cluster.
  • COMPUTE_LOCATION : emplacement Compute Engine du cluster. Vous devez utiliser le même emplacement que le sous-réseau proxy que vous avez créé dans la section précédente.
  • NETWORK : nom du réseau dans lequel vous souhaitez créer le cluster. Ce réseau doit se trouver dans le même réseau VPC que le sous-réseau proxy que vous avez créé dans la section précédente.

Console

  1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Dans la section Autopilot, cliquez sur Configurer.

  4. Dans la section Paramètres de base du cluster, procédez comme suit :

    1. Saisissez le nom de votre cluster.
    2. Pour le type d'emplacement, sélectionnez une région Compute Engine pour votre cluster. Vous devez utiliser la même région que le sous-réseau proxy que vous avez créé dans la section précédente.

  5. Dans le volet de navigation, cliquez sur Mise en réseau.

  6. Dans la liste déroulante Réseau, sélectionnez le réseau dans lequel vous souhaitez créer le cluster. Ce réseau doit se trouver dans le même réseau VPC que le sous-réseau proxy.

  7. Dans la liste Sous-réseau de nœud, sélectionnez le sous-réseau proxy que vous avez créé.

  8. Cliquez sur Créer.

Déployer une application Web

Dans cette section, vous allez créer un déploiement.

Pour créer un déploiement :

  1. Enregistrez l'exemple de fichier manifeste suivant sous le nom web-deployment.yaml :

    apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: hostname
  name: hostname-server
spec:
  selector:
    matchLabels:
      app: hostname
  minReadySeconds: 60
  replicas: 3
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4
        name: hostname-server
        ports:
        - containerPort: 9376
          protocol: TCP
      terminationGracePeriodSeconds: 90

    Ce fichier manifeste décrit un déploiement qui écoute sur un serveur HTTPS sur le port 9376. Ce déploiement gère les pods de votre application. Chaque pod exécute un conteneur d'applications avec un serveur HTTPS qui renvoie le nom d'hôte du serveur d'applications en tant que réponse. Le nom d'hôte par défaut d'un pod correspond au nom de ce pod. Le conteneur gère également le délai de grâce.

  2. Appliquez le fichier manifeste au cluster :

    kubectl apply -f web-deployment.yaml

Déployer un service en tant que groupe de points de terminaison du réseau (NEG)

Dans cette section, vous créez une ressource Service. Le service sélectionne les conteneurs backend en fonction de leur libellé, de sorte que le contrôleur Ingress puisse les programmer en tant que points de terminaison backend. Ingress pour les équilibreurs de charge d'application internes nécessite l'utilisation de NEG en tant que backends. Cette fonctionnalité n'accepte pas les groupes d'instances en tant que backends. Étant donné que les backends NEG sont requis, l'annotation NEG suivante est obligatoire lorsque vous déployez des services exposés via un objet Ingress :

annotations:
  cloud.google.com/neg: '{"ingress": true}'

Votre service est automatiquement annoté avec cloud.google.com/neg: '{"ingress": true}' lorsque toutes les conditions suivantes sont remplies :

  • Vous utilisez des clusters de VPC natif.
  • Vous n'utilisez pas de VPC partagé.
  • Vous n'utilisez pas de règle de réseau GKE.

L'annotation est automatiquement ajoutée à l'aide d'une MutatingWebhookConfiguration nommée neg-annotation.config.common-webhooks.networking.gke.io. Vous pouvez vérifier si la MutatingWebhookConfiguration est présente à l'aide de la commande suivante :

kubectl get mutatingwebhookconfigurations

L'utilisation des NEG permet au contrôleur Ingress d'effectuer un équilibrage de charge natif en conteneurs. Le trafic est équilibré directement entre le proxy Ingress et l'adresse IP du pod, plutôt que de traverser l'adresse IP du nœud ou le réseau kube-proxy. En outre, les portes de disponibilité des pods sont mises en œuvre pour déterminer l'état des pods du point de vue de l'équilibreur de charge, et pas seulement les vérifications d'aptitude et d'activité de Kubernetes. Les portes de disponibilité des pods garantissent que le trafic n'est pas interrompu pendant les événements de cycle de vie, tels que le démarrage d'un pod, la perte d'un pod ou la perte de nœuds.

Si vous n'incluez pas d'annotation NEG, vous recevez un avertissement concernant l'objet Ingress qui vous empêche de configurer l'équilibreur de charge d'application interne. Un événement Kubernetes est également généré sur l'entrée si l'annotation NEG n'est pas incluse. Le message suivant est un exemple du message d'événement :

Message
-------
error while evaluating the ingress spec: could not find port "8080" in service "default/no-neg-svc"

Un NEG n'est créé que lorsqu'un objet Ingress référence le service. Le NEG n'apparaît dans Compute Engine que lorsque l'objet Ingress et son service référencé existent tous deux. Les NEG sont des ressources zonales et, pour les clusters multizones, un NEG est créé par service et par zone.

Pour créer un service :

  1. Enregistrez l'exemple de fichier manifeste suivant sous le nom web-service.yaml :

    apiVersion: v1
kind: Service
metadata:
  name: hostname
  namespace: default
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
spec:
  ports:
  - name: host1
    port: 80
    protocol: TCP
    targetPort: 9376
  selector:
    app: hostname
  type: ClusterIP

  2. Appliquez le fichier manifeste au cluster :

    kubectl apply -f web-service.yaml

Déployer Ingress

Dans cette section, vous allez créer une ressource Ingress qui déclenche le déploiement de l'équilibreur de charge Compute Engine via le contrôleur d'entrée. Ingress pour les équilibreurs de charge d'application internes nécessite l'annotation suivante :

annotations:
    kubernetes.io/ingress.class: "gce-internal"

Vous ne pouvez pas utiliser le champ ingressClassName pour spécifier un objet GKE Ingress. Vous devez utiliser l'annotation kubernetes.io/ingress.class. Pour en savoir plus, consultez la page Comportement du contrôleur GKE Ingress.

Pour créer une entrée, procédez comme suit :

  1. Enregistrez l'exemple de fichier manifeste suivant sous le nom internal-ingress.yaml :

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ilb-demo-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "gce-internal"
spec:
  defaultBackend:
    service:
      name: hostname
      port:
        number: 80

  2. Appliquez le fichier manifeste au cluster :

    kubectl apply -f internal-ingress.yaml

Valider un déploiement Ingress réussi

Dans cette section, vous validez si votre déploiement a réussi.

Le provisionnement complet de la ressource Ingress peut prendre plusieurs minutes. Pendant cette période, le contrôleur d'entrée crée des éléments tels que des règles de transfert, des services de backend, des mappages d'URL et des NEG.

Pour récupérer l'état de la ressource Ingress que vous avez créée dans la section précédente, exécutez la commande suivante :

kubectl get ingress ilb-demo-ingress

Le résultat ressemble à ce qui suit :

NAME               HOSTS    ADDRESS            PORTS     AGE
ilb-demo-ingress   *        10.128.0.58        80        59s

Lorsque le champ ADDRESS est renseigné, l'entrée est prête. L'utilisation d'une adresse RFC 1918 dans ce champ indique la présence d'une adresse IP interne dans le VPC.

Étant donné que l'équilibreur de charge d'application interne est un équilibreur de charge régional, l'adresse IP virtuelle (VIP) n'est accessible qu'à partir d'un client situé dans la même région et dans le même VPC. Après avoir récupéré l'adresse IP virtuelle de l'équilibreur de charge, vous pouvez utiliser des outils (par exemple, curl) pour émettre des appels HTTP GET sur l'adresse IP virtuelle depuis le VPC.

Pour émettre un appel HTTP GET, procédez comme suit :

  1. Pour accéder à l'adresse IP virtuelle d'Ingress depuis le VPC, déployez une VM dans la même région et dans le même réseau que le cluster.

    Par exemple, si vous avez suivi les étapes précédentes pour créer votre déploiement, votre service et votre entrée, et créé votre cluster sur le réseau par défaut et dans la zone us-central1-a, vous pouvez Utilisez la commande suivante :

    gcloud compute instances create l7-ilb-client-us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --network=default \
    --subnet=default \
    --zone=us-central1-a \
    --tags=allow-ssh

    Pour en savoir plus sur la création d'instances, consultez la page Créer et démarrer une instance de VM.

  2. Pour accéder à la VIP interne depuis la VM, utilisez curl :

    1. Connectez-vous en SSH à la VM que vous avez créée à l'étape précédente :

      gcloud compute ssh l7-ilb-client-us-central1-a \
   --zone=us-central1-a

    2. Utilisez curl pour accéder à l'adresse IP virtuelle de l'application interne :

      curl 10.128.0.58
hostname-server-6696cf5fc8-z4788

      La réussite de la réponse HTTP et du nom d'hôte de l'un des conteneurs backend indique que l'ensemble du chemin d'équilibrage de charge fonctionne correctement.

Supprimer des ressources Ingress

La suppression des ressources Ingress et Service entraîne également la suppression des ressources de l'équilibreur de charge Compute Engine qui leur sont associées. Pour éviter toute fuite de ressources, assurez-vous que les ressources Ingress sont détruites lorsque vous n'en avez plus besoin. Vous devez également supprimer les ressources Ingress et Service avant de supprimer des clusters, sinon les ressources d'équilibrage de charge de Compute Engine sont orphelines.

Pour supprimer un objet Ingress, procédez comme suit :

  1. Supprimez la ressource Ingress. Par exemple, pour supprimer la ressource Ingress que vous avez créée sur cette page, exécutez la commande suivante :

    kubectl delete ingress ilb-demo-ingress

    La suppression d'une ressource Ingress entraîne également la suppression des règles de transfert, des services de backend et des mappages d'URL qui lui sont associés.

  2. Supprimez le service : Par exemple, pour supprimer le service que vous avez créé sur cette page, exécutez la commande suivante :

    kubectl delete service hostname

    La suppression d'une ressource Service entraîne également la suppression des NEG qui lui sont associés.

Pour déployer une application sur GKE et l'exposer avec une adresse IP privée à équilibrage de charge, consultez la page Objet Ingress interne de base {:.external}.

Adressage IP statique

Les ressources Ingress internes sont compatibles avec l'adressage IP statique et éphémère. Si aucune adresse IP n'est spécifiée, une adresse IP disponible est automatiquement attribuée à partir du sous-réseau de nœud GKE. Cependant, la ressource Ingress ne provisionne pas les adresses IP du sous-réseau proxy réservé, car ce sous-réseau est utilisé uniquement pour la consommation du proxy interne. Ces adresses IP éphémères ne sont attribuées à l'entrée que pour le cycle de vie de la ressource Ingress interne. Si vous supprimez votre entrée pour en créer une autre à partir du même fichier manifeste, il n'est pas garanti que vous obteniez la même adresse IP externe.

Si vous souhaitez qu'une adresse IP permanente soit indépendante du cycle de vie de la ressource Entrée interne, vous devez réserver une adresse IP interne statique régionale. Vous pouvez ensuite spécifier une adresse IP statique à l'aide de l'annotation kubernetes.io/ingress.regional-static-ip-name de votre ressource d'entrée.

L'exemple suivant montre comment ajouter cette annotation :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.regional-static-ip-name: STATIC_IP_NAME
    kubernetes.io/ingress.class: "gce-internal"

Remplacez STATIC_IP_NAME par un nom d'adresse IP statique répondant aux critères suivants :

  • Créez l'adresse IP statique avant de déployer l'Ingress. Un équilibreur de charge ne se déploie pas tant que l'adresse IP statique n'existe pas, et le fait de référencer une ressource d'adresse IP inexistante ne crée pas d'adresse IP statique. Si vous modifiez un Ingress existant pour utiliser une adresse IP statique au lieu d'une adresse IP éphémère, GKE peut modifier l'adresse IP de l'équilibreur de charge lorsque GKE recrée la règle de transfert de l'équilibreur de charge.
  • L'adresse IP statique est réservée dans le projet de service pour un objet Ingress déployé dans le projet de service d'un VPC partagé.
  • Référencez la ressource d'adresse IP Google Cloud à l'aide de son nom plutôt que de son adresse IP.
  • L'adresse IP doit provenir d'un sous-réseau situé dans la même région que le cluster GKE. Vous pouvez utiliser n'importe quel sous-réseau privé disponible au sein de la région (à l'exception du sous-réseau proxy réservé). Différentes ressources Ingress peuvent également posséder des adresses provenant de différents sous-réseaux.

HTTPS entre le client et l'équilibreur de charge

Ingress pour l'équilibrage de charge interne est compatible avec la diffusion de certificats TLS aux clients. Vous pouvez diffuser des certificats TLS via des secrets Kubernetes ou via des certificats SSL régionaux prépartagés dans Google Cloud. Vous pouvez également spécifier plusieurs certificats par ressource Ingress.

Les étapes suivantes expliquent comment créer un certificat dans Google Cloud, puis le diffuser à des clients internes via une ressource Ingress.

  1. Créez le certificat régional :

    gcloud compute ssl-certificates create CERT_NAME \
    --certificate CERT_FILE_PATH \
    --private-key KEY_FILE_PATH \
    --region COMPUTE_REGION

    Remplacez les éléments suivants :

    • CERT_NAME : nom de votre certificat.
    • CERT_FILE_PATH : chemin d'accès à votre fichier de certificat local pour créer un certificat autogéré. Le certificat doit être au format PEM.
    • KEY_FILE_PATH : chemin d'accès à un fichier de clé privée local. La clé privée doit être au format PEM et doit utiliser le chiffrement RSA ou ECDSA.
    • COMPUTE_REGION : une région Compute Engine pour votre certificat.

  2. Enregistrez l'exemple de fichier manifeste suivant sous le nom ingress-pre-shared-cert.yaml :

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ilb-demo-ing
  namespace: default
  annotations:
    ingress.gcp.kubernetes.io/pre-shared-cert: "CERT_NAME"
    kubernetes.io/ingress.class: "gce-internal"
    kubernetes.io/ingress.allow-http: "false"
spec:
  rules:
  - host: DOMAIN
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: SERVICE_NAME
            port:
              number: 80

    Remplacez les éléments suivants :

    • DOMAIN : votre domaine.
    • CERT_NAME : nom du certificat que vous avez créé dans la section précédente.
    • SERVICE_NAME : nom de votre service.

  3. Appliquez le fichier manifeste au cluster :

    kubectl apply -f ingress-pre-shared-cert.yaml

HTTPS entre l'équilibreur de charge et l'application

Si votre application s'exécute dans un pod GKE et peut recevoir des requêtes HTTPS, vous pouvez configurer l'équilibreur de charge pour qu'il utilise HTTPS lorsqu'il transfère les requêtes à votre application. Pour plus d'informations, consultez la section HTTPS (TLS) entre l'équilibreur de charge et votre application.

VPC partagé

Ajouter manuellement l'annotation NEG

Si le GKE dans lequel vous déployez les ressources Ingress se trouve dans un projet de service de VPC partagé, les services ne sont pas automatiquement annotés avec l'annotation cloud.google.com/neg: '{"ingress": true}', car la MutatingWebhookConfiguration tenue d'injecter l'annotation dans les services n'est pas installée.

Vous devez ajouter l'annotation NEG au fichier manifeste des services exposés via Ingress pour les équilibreurs de charge d'application internes.

Règles de pare-feu VPC

Si le cluster GKE dans lequel vous déployez les ressources d'entrée se trouve dans un projet de service de VPC partagé et que vous souhaitez que le plan de contrôle GKE gère les ressources de pare-feu dans votre projet hôte, le compte de service GKE du projet de service doit disposer des autorisations IAM appropriées sur le projet hôte, conformément à la section Gérer les ressources de pare-feu pour les clusters avec VPC partagé. Cela permet au contrôleur d'entrée de créer des règles de pare-feu afin d'autoriser le trafic entrant pour les vérifications d'état Google Cloud.

Voici un exemple d'événement qui peut exister dans les journaux de ressources d'entrée. Cette erreur se produit lorsque le contrôleur d'entrée ne parvient pas à créer une règle de pare-feu pour autoriser le trafic entrant pour les vérifications d'état Google Cloud si les autorisations ne sont pas configurées correctement.

Firewall change required by security admin: `gcloud compute firewall-rules update <RULE_NAME> --description "GCE L7 firewall rule" --allow tcp:<PORT> --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags <TARGET_TAG> --project <HOST_PROJECT>

Si vous préférez provisionner manuellement les règles de pare-feu à partir du projet hôte, vous pouvez mettre en sourdine les événements firewallXPNError en ajoutant l'annotation networking.gke.io/suppress-firewall-xpn-error: "true" à la ressource Ingress.

Récapitulatif des annotations Ingress internes

Les tableaux suivants présentent les annotations que vous pouvez ajouter lorsque vous créez des ressources Ingress et Service pour Ingress pour les équilibreurs de charge d'application internes.

Annotations Ingress

Annotation Description
kubernetes.io/ingress.class Vous pouvez définir la valeur sur "gce-internal" pour l'entrée interne. Si la classe n'est pas spécifiée, une ressource Ingress est interprétée par défaut comme étant une entrée externe. Pour en savoir plus, consultez la page Comportement du contrôleur GKE Ingress.
kubernetes.io/ingress.allow-http Vous pouvez autoriser le trafic HTTP entre le client et l'équilibreur de charge HTTP(S). Les valeurs possibles sont true et false. La valeur par défaut est true, mais vous devez définir cette annotation sur false si vous utilisez HTTPS pour l'équilibrage de charge interne. Pour en savoir plus, consultez la section Désactiver HTTP.
ingress.gcp.kubernetes.io/pre-shared-cert Vous pouvez importer des certificats et des clés dans votre projet Google Cloud. Utilisez cette annotation pour référencer les certificats et les clés. Pour en savoir plus, consultez la section Utiliser plusieurs certificats SSL avec des équilibreurs de charge d'application externes.
networking.gke.io/suppress-firewall-xpn-error

Dans GLBC 1.4 et ses versions ultérieures, vous pouvez désactiver l'événement firewallXPNError. Pour les équilibreurs de charge d'entrée, si Kubernetes ne peut pas modifier les règles du pare-feu en raison d'autorisations insuffisantes, un événement firewallXPNError est créé régulièrement (avec un délai de quelques minutes entre les créations).

Ajoutez l'annotation networking.gke.io/suppress-firewall-xpn-error: "true" à la ressource d'entrée. La valeur par défaut est false. Vous pouvez supprimer cette annotation pour réactiver l'événement.

kubernetes.io/ingress.regional-static-ip-name Vous pouvez spécifier une adresse IP statique pour provisionner votre ressource d'entrée interne. Pour plus d'informations, consultez la section Adressage IP statique.
Annotation Description
cloud.google.com/backend-config Utilisez cette annotation pour configurer le service de backend associé à un servicePort. Pour en savoir plus, consultez la page Configuration de l'entrée.
cloud.google.com/neg Utilisez cette annotation pour indiquer que l'équilibreur de charge doit utiliser des groupes de points de terminaison du réseau. Pour plus d'informations, consultez la page Utiliser l'équilibrage de charge natif en conteneurs.

Dépannage

La compréhension et l'observation de l'état d'Ingress impliquent généralement l'inspection des ressources associées. Les types de problèmes rencontrés sont souvent les suivants : les ressources d'équilibrage de charge ne sont pas créées correctement, le trafic n'atteint pas les backends, ou encore les backends ne semblent pas opérationnels.

Voici quelques étapes de dépannage courantes :

  • Vérifiez que le trafic client provient de la même région et du même VPC que l'équilibreur de charge.
  • Vérifiez que les pods et les backends sont opérationnels.
  • Vérifiez que le chemin du trafic allant vers le VIP et pour les vérifications d'état de Compute Engine n'est pas bloqué par les règles de pare-feu.
  • Vérifiez l'absence d'erreur dans les événements de la ressource Ingress.
  • Décrivez la ressource Ingress pour consulter le mappage vers les ressources Compute Engine.
  • Vérifiez que les ressources d'équilibrage de charge de Compute Engine existent, que les configurations sont correctes et qu'aucune erreur n'est signalée.

Filtrage des événements Ingress

La requête suivante filtre les erreurs de tous les événements Ingress de votre cluster.

kubectl get events --all-namespaces --field-selector involvedObject.kind=Ingress

Vous pouvez également filtrer par objet ou par nom d'objet :

kubectl get events --field-selector involvedObject.kind=Ingress,involvedObject.name=hostname-internal-ingress

Dans l'erreur suivante, vous pouvez constater que le service référencé par l'entrée n'existe pas :

LAST SEEN   TYPE      REASON      OBJECT                              MESSAGE
0s          Warning   Translate   ingress/hostname-internal-ingress   error while evaluating the ingress spec: could not find service "default/hostname-invalid"

Inspecter les ressources de l'équilibreur de charge Compute Engine

La commande suivante affiche la sortie complète de la ressource Ingress afin que vous puissiez voir les mappages aux ressources Compute Engine créées par le contrôleur Ingress :

kubectl get ing INGRESS_FILENAME -o yaml

Remplacez INGRESS_FILENAME par le nom de fichier de votre ressource Ingress.

Le résultat ressemble à ce qui suit :

apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      ingress.kubernetes.io/backends: '{"k8s1-241a2b5c-default-hostname-80-29269aa5":"HEALTHY"}'
      ingress.kubernetes.io/forwarding-rule: k8s-fw-default-ilb-demo-ingress--241a2b5c94b353ec
      ingress.kubernetes.io/target-proxy: k8s-tp-default-ilb-demo-ingress--241a2b5c94b353ec
      ingress.kubernetes.io/url-map: k8s-um-default-ilb-demo-ingress--241a2b5c94b353ec
      kubectl.kubernetes.io/last-applied-configuration: |
       {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"gce-internal"},"name":"ilb-demo-ingress","namespace":"default"},"spec":{"defaultBackend":{"service":{"name":"hostname"},"port":{"number":80}}}}
      kubernetes.io/ingress.class: gce-internal
    creationTimestamp: "2019-10-15T02:16:18Z"
    finalizers:
    - networking.gke.io/ingress-finalizer
    generation: 1
    name: ilb-demo-ingress
    namespace: default
    resourceVersion: "1538072"
    selfLink: /apis/networking.k8s.io/v1/namespaces/default/ingresses/ilb-demo-ingress
    uid: 0ef024fe-6aea-4ee0-85f6-c2578f554975
  spec:
    defaultBackend:
      service:
        name: hostname
        port:
          number: 80
  status:
    loadBalancer:
      ingress:
      - ip: 10.128.0.127
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Les annotations ingress.kubernetes.io/backends répertorient les backends et leur état. Assurez-vous que vos backends sont répertoriés comme étant HEALTHY.

Vous pouvez interroger directement les ressources Compute Engine créées par Ingress pour comprendre leur état et leur configuration. L'exécution de ces requêtes peut également être utile pour le dépannage.

Pour répertorier toutes les règles de transfert Compute Engine, procédez comme suit :

gcloud compute forwarding-rules list

Le résultat ressemble à ce qui suit :

NAME                                                        REGION       IP_ADDRESS      IP_PROTOCOL  TARGET
k8s-fw-default-hostname-internal-ingress--42084f6a534c335b  us-central1  10.128.15.225   TCP          us-central1/targetHttpProxies/k8s-tp-default-hostname-internal-ingress--42084f6a534c335b

Pour répertorier l'état d'un service de backend, commencez par répertorier les services de backend, puis créez une copie du nom du service de backend que vous souhaitez inspecter :

gcloud compute backend-services list

Le résultat ressemble à ce qui suit :

NAME                                         BACKENDS                                                                       PROTOCOL
k8s1-42084f6a-default-hostname-80-98cbc1c1   us-central1-a/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1 HTTP

Vous pouvez maintenant utiliser le nom du service de backend pour interroger son état :

gcloud compute backend-services get-health k8s1-42084f6a-default-hostname-80-98cbc1c1 \
    --region us-central1

Le résultat ressemble à ce qui suit :

backend: https://www.googleapis.com/compute/v1/projects/user1-243723/zones/us-central1-a/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1
status:
  healthStatus:
  - healthState: HEALTHY

Étapes suivantes