Configurer Ingress pour l'équilibrage de charge HTTP(S) interne

Cette page vous explique comment configurer et utiliser Ingress pour l'équilibrage de charge HTTP(S) interne dans Google Kubernetes Engine (GKE). Ingress pour l'équilibrage de charge HTTP(S) interne est compatible avec l'équilibrage de charge interne via le contrôleur d'entrée GKE.

Pour en savoir plus sur les fonctionnalités compatibles avec Ingress pour l'équilibrage de charge HTTP(S) interne, consultez la section Fonctionnalités Ingress. Pour en savoir plus sur le fonctionnement d'Ingress pour l'équilibrage de charge HTTP(S) interne, consultez la page Ingress pour l'équilibrage de charge HTTP(S) interne.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Assurez-vous d'avoir activé l'API Google Kubernetes Engine.
  • Activer l'API Google Kubernetes Engine
  • Assurez-vous d'avoir installé le SDK Cloud.
  • Configurez les paramètres de l'outil de ligne de commande gcloud par défaut pour votre projet en utilisant l'une des méthodes suivantes:
    • Utilisez gcloud init si vous souhaitez suivre les étapes de définition des paramètres par défaut du projet.
    • Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

    gcloud init

    1. Exécutez gcloud init et suivez les instructions :

      gcloud init

      Si vous utilisez SSH sur un serveur distant, utilisez l'option --console-only pour empêcher la commande d'ouvrir un navigateur :

      gcloud init --console-only
    2. Suivez les instructions pour autoriser l'outil gcloud à utiliser votre compte Google Cloud.
    3. Créez ou sélectionnez une configuration.
    4. Choisissez un projet Google Cloud.
    5. Choisissez une zone Compute Engine par défaut.
    6. Choisissez une région Compute Engine par défaut.

    gcloud config

    1. Définissez votre ID de projet par défaut :
      gcloud config set project PROJECT_ID
    2. Définissez votre région Compute Engine par défaut (par exemple, us-central1):
      gcloud config set compute/region COMPUTE_REGION
    3. Définissez votre zone Compute Engine par défaut (par exemple, us-central1-c):
      gcloud config set compute/zone COMPUTE_ZONE
    4. Mettez à jour gcloud vers la dernière version :
      gcloud components update

    En définissant des emplacements par défaut, vous pouvez éviter les erreurs dans l'outil gcloud, telles que les suivantes: One of [--zone, --region] must be supplied: Please specify location.

Exigences

Ingress pour l'équilibrage de charge HTTP(S) interne 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. Vous ne devez pas le désactiver.
  • Vous devez utiliser des groupes de points de terminaison du réseau (NEG) comme backends pour votre service.

Déployer Ingress pour l'équilibrage de charge HTTP(S) interne

Les exercices suivants vous montrent comment déployer Ingress pour l'équilibrage de charge HTTP(S) interne :

  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=INTERNAL_HTTPS_LOAD_BALANCER \
    --role=ACTIVE \
    --region=us-west1 \
    --network=lb-network \
    --range=10.129.0.0/23

Créer un cluster

Dans cette section, vous allez créer un cluster que vous pourrez utiliser avec Ingress pour l'équilibrage de charge HTTP(S) interne. Vous pouvez créer ce cluster à l'aide de l'outil de ligne de commande gcloud ou de Google Cloud Console.

gcloud

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

gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --zone=COMPUTE_REGION \
    --network=NETWORK

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom de votre cluster.
  • COMPUTE_ZONE : zone Compute Engine du nouveau cluster. Vous devez choisir une zone située dans la même région 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 Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. 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 zone Compute Engine pour votre cluster. Vous devez choisir une zone située dans la même région que le sous-réseau proxy que vous avez créé dans la section précédente.
  4. Dans le volet de navigation, sous Cluster, cliquez sur Réseau.

    1. 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.
    2. Sous Options de mise en réseau avancées, assurez-vous que les options Activer le routage du trafic VPC natif (utilisation d'une adresse IP d'alias) et Activer l'équilibrage de charge HTTP sont sélectionnées.
  5. Cliquez sur Create (Créer).

Déployer une application Web

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

Pour créer un déploiement :

  1. Copiez et enregistrez la ressource de déploiement suivante dans un fichier nommé web-deployment.yaml :

    # 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: k8s.gcr.io/serve_hostname:v1.4
            name: hostname-server
            ports:
            - containerPort: 9376
              protocol: TCP
          terminationGracePeriodSeconds: 90
    

    Ce fichier de déploiement utilise une image de conteneur 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. Après avoir créé le fichier de déploiement, appliquez la ressource 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 l'équilibrage de charge HTTP(S) interne 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 HTTP(S) 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. Copiez et enregistrez la ressource de service suivante dans un fichier nommé web-service.yaml :

    # 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: NodePort
    
  2. Après avoir créé votre fichier de service, appliquez la ressource 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 l'équilibrage de charge HTTP(S) interne nécessite l'annotation suivante :

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

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

  1. Copiez et enregistrez la ressource Ingress suivante dans un fichier nommé internal-ingress.yaml :

    # 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. Après avoir créé votre fichier Ingress, appliquez la ressource 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 HTTP(S) 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-9 \
        --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.

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'entrée. 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.
  • 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. Créez une ressource Ingress. Le fichier YAML suivant, nommé ingress-pre-shared-cert.yaml, est un exemple de la ressource Ingress que vous devez créer :

    # 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:
          - 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. Après avoir créé l'entrée, appliquez la ressource 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 l'équilibrage de charge HTTP(S) interne.

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 l'équilibrage de charge HTTP(S) interne.

Annotations Ingress

Annotation Description
kubernetes.io/ingress.class Spécifiée comme "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.
kubernetes.io/ingress.allow-http Spécifie s'il faut 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 plus d'informations, consultez la page Utiliser plusieurs certificats SSL dans l'équilibrage de charge HTTP(S).
networking.gke.io/suppress-firewall-xpn-error 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 diffusions). Dans GLBC 1.4 et ses versions ultérieures, vous pouvez désactiver l'événement firewallXPNError en ajoutant l'annotation networking.gke.io/suppress-firewall-xpn-error: "true" à la ressource d'entrée. Vous pouvez supprimer cette annotation pour réactiver l'événement. Les valeurs possibles sont true et false. La valeur par défaut est false.
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 Fonctionnalités Ingress.
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

Étape suivante