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 pouvoir déployer des ressources d'équilibreur de charge via l'API d'entrée de Kubernetes, vous devez préparer votre environnement de mise en réseau afin que les proxys de l'équilibreur de charge puissent être déployés dans une région donnée. Pour savoir comment déployer le sous-réseau proxy réservé, consultez la page Configurer le réseau et les sous-réseaux. Vous n'avez pas besoin de déployer manuellement des règles de pare-feu, car le contrôleur d'entrée GKE gère cette étape. Vous devez effectuer cette étape avant de déployer Ingress pour l'équilibrage de charge HTTP(S) interne. Pour savoir pourquoi Ingress pour l'équilibrage de charge HTTP(S) interne nécessite l'utilisation d'un sous-réseau proxy réservé, consultez la page Environnement réseau requis.

Conditions requises

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 s'exécuter en mode VPC natif (adresse IP d'alias). Pour en savoir plus, consultez la page sur les clusters de VPC natif.
  • Le module complémentaire d'équilibrage de charge HTTP doit être activé sur votre cluster. Celui-ci est activé par défaut pour les clusters. Ne désactivez pas le module complémentaire.
  • 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. Créez un cluster.
  2. Déployer une application
  3. Déployer un service
  4. Déployez Ingress.
  5. Validez le déploiement.
  6. Supprimer des ressources Ingress.

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 \
    --cluster-version=VERSION_NUMBER \
    --enable-ip-alias \
    --zone=ZONE \
    --network=NETWORK
    --

Remplacez l'élément suivant :

  • CLUSTER_NAME: ajoutez un nom pour votre cluster.
  • VERSION_NUMBER: ajoutez une version ultérieure à la version 1.16.5-gke.10. Vous pouvez également utiliser l'option --release-channel pour sélectionner une version disponible avec une version par défaut ultérieure à la version 1.16.5-gke.10.
  • --enable-ip-alias active les adresses IP d'alias. Les clusters utilisant Ingress pour l'équilibrage de charge HTTP(S) interne doivent s'exécuter en mode VPC natif (adresse IP d'alias). Pour en savoir plus, consultez la page Créer un cluster de VPC natif.
  • ZONE: ajoutez une zone dans laquelle créer 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éé pour votre équilibreur de charge HTTP(S) interne dans la section Configurer le réseau et les sous-réseaux.
  • NETWORK: ajoutez le 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.

Console

  1. Accédez au menu Google Kubernetes Engine de Cloud Console.

    Accéder au menu Google Kubernetes Engine

  2. Cliquez sur le bouton Créer un cluster.

  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 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éé pour votre équilibreur de charge HTTP(S) interne dans la section Configurer le réseau et les sous-réseaux.
    3. Sous Version maître, sélectionnez une Version statique ultérieure à la version 1.16.5-gke.10.
      Vous pouvez également
      accéder à la section Version maître et sélectionner une version disponible dont la version par défaut est ultérieure à la version 1.16.5. -gke.10
  4. Dans le volet de navigation, cliquez sur Mise en 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 Enregistrer.

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 avez créé le service dans les clusters GKE 1.17.6-gke.7 et versions ultérieures.
  • 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'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'équilibrage 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/v1beta1
    kind: Ingress
    metadata:
      name: ilb-demo-ingress
      namespace: default
      annotations:
        kubernetes.io/ingress.class: "gce-internal"
    spec:
      backend:
        serviceName: hostname
        servicePort: 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

Un résultat semblable aux lignes suivantes doit s'afficher :

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-ing
    

    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/v1beta1
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.
  • 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 REGION
    

    Remplacez l'élément suivant :

    • CERT_NAME: ajoutez un nom à votre certificat.
    • CERT_FILE_PATH: ajoutez le 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: ajoutez le chemin d'accès à un fichier de clé privée locale. La clé privée doit être au format PEM et doit utiliser le chiffrement RSA ou ECDSA.
    • REGION: ajoutez une région 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/v1beta1
    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:
              serviceName: SERVICE_NAME
              servicePort: 80
    

    Remplacez l'élément suivant :

    • DOMAIN: ajouter votre domaine.
    • CERT_NAME: ajoutez le nom du certificat que vous avez créé dans la section précédente.
    • SERVICE_NAME: ajoutez le 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
    

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).
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.

Un résultat semblable à l'exemple suivant doit s'afficher:

apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1beta1
  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/v1beta1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"gce-internal"},"name":"ilb-demo-ingress","namespace":"default"},"spec":{"backend":{"serviceName":"hostname","servicePort":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/v1beta1/namespaces/default/ingresses/ilb-demo-ingress
    uid: 0ef024fe-6aea-4ee0-85f6-c2578f554975
  spec:
    backend:
      serviceName: hostname
      servicePort: 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

Exemple de résultat :

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

Exemple de résultat :

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

Exemple de résultat :

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