Configurar objetos Ingress para balanceadores de carga de aplicaciones internos

En esta página se muestra cómo configurar y usar Ingress para balanceadores de carga de aplicaciones internos en Google Kubernetes Engine (GKE). Ingress ofrece compatibilidad integrada con el balanceo de carga interno a través del controlador Ingress de GKE.

Para obtener más información sobre las funciones admitidas de Ingress para balanceadores de carga de aplicaciones internos, consulta las funciones de Ingress. También puedes consultar más información sobre cómo funciona Ingress para balanceadores de carga de aplicaciones internos en Ingress para balanceadores de carga de aplicaciones internos.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

Requisitos

Los objetos Ingress para balanceadores de carga de aplicaciones internos deben cumplir los siguientes requisitos:

• Tu clúster debe usar una versión de GKE posterior a la 1.16.5-gke.10.
• Tu clúster debe ser nativo de VPC.
• Tu clúster debe tener habilitado el complemento HttpLoadBalancing. Este complemento está habilitado de forma predeterminada. No debes inhabilitarla.
• Debes usar grupos de puntos finales de red (NEGs) como backends de tu servicio.

Desplegar Ingress para balanceadores de carga de aplicaciones internos

En los siguientes ejercicios se muestra cómo desplegar Ingress para balanceadores de carga de aplicaciones internos:

1. Prepara tu entorno.
2. Crea un clúster.
3. Despliega una aplicación.
4. Implementa un servicio.
5. Implementar Ingress.
6. Valida la implementación.
7. Eliminar recursos de Ingress.

Prepara tu entorno

Antes de poder desplegar recursos de balanceador de carga a través de la API Ingress de Kubernetes, debe preparar su entorno de red para que los proxies del balanceador de carga se puedan desplegar en una región determinada.

Crea una subred de solo proxy:

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

Haz los cambios siguientes:

• COMPUTE_REGION: a región de Compute Engine.
• NETWORK_NAME: el nombre de la red de la subred.

Para obtener más información, consulta cómo configurar la subred de solo proxy.

Crear una regla de cortafuegos

El controlador de entrada no crea una regla de cortafuegos para permitir las conexiones de los proxies del balanceador de carga en la subred de proxy. Debes crear esta regla de cortafuegos manualmente. Sin embargo, el controlador de entrada crea reglas de cortafuegos para permitir la entrada de comprobaciones del estado. Trusted Cloud

Crea una regla de cortafuegos para permitir las conexiones de los proxies del balanceador de carga en la subred de solo proxy al puerto de escucha del pod:

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

Sustituye CONTAINER_PORT por el valor del puerto que está escuchando el pod, como 9376.

Crear un clúster

En esta sección, crearás un clúster nativo de VPC que podrás usar con Ingress para balanceadores de carga de aplicación internos. Puedes crear este clúster con la CLI de Google Cloud o la Trusted Cloud consola.

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

Desplegar una aplicación web

En esta sección, crearás una implementación.

Para crear un despliegue, sigue estos pasos:

1. Guarda el siguiente archivo de manifiesto de ejemplo como 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
   

   Este manifiesto describe una implementación que escucha en un servidor HTTPS en el puerto 9376. Esta implementación también gestiona los pods de tu aplicación. Cada pod ejecuta un contenedor de aplicación con un servidor HTTPS que devuelve el nombre de host del servidor de aplicaciones como respuesta. El nombre de host predeterminado de un pod es el nombre del pod. El contenedor también gestiona la finalización correcta.

2. Aplica el manifiesto al clúster:

   kubectl apply -f web-deployment.yaml
   

Implementar un servicio como un grupo de endpoints de red (NEG)

En esta sección, crearás un recurso Service. El servicio selecciona los contenedores de backend por sus etiquetas para que el controlador Ingress pueda programarlos como endpoints de backend. Para usar Ingress con balanceadores de carga de aplicaciones internos, debes usar NEGs como backends. La función no admite grupos de instancias como back-ends. Como se requieren back-ends de NEG, se necesita la siguiente anotación de NEG al implementar servicios expuestos a través de Ingress:

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

Tu servicio se anota automáticamente con cloud.google.com/neg: '{"ingress": true}' cuando se cumplen todas las condiciones siguientes:

• Estás usando clústeres nativos de VPC.
• No estás usando una VPC compartida.
• No estás usando políticas de red de GKE.

La anotación se añade automáticamente con un MutatingWebhookConfiguration con el nombre neg-annotation.config.common-webhooks.networking.gke.io. Puedes comprobar si el MutatingWebhookConfiguration está presente con el siguiente comando:

kubectl get mutatingwebhookconfigurations

El uso de NEGs permite que el controlador de Ingress realice el balanceo de carga nativo de contenedores. El tráfico se balancea desde el proxy de Ingress directamente a la IP del pod, en lugar de atravesar la IP del nodo o la red de kube-proxy. Además, se implementan puertas de preparación de pods para determinar el estado de los pods desde la perspectiva del balanceador de carga y no solo las comprobaciones de preparación y actividad de Kubernetes. Los readiness gates de los pods aseguran que no se pierda tráfico durante los eventos del ciclo de vida, como el inicio, la pérdida o la pérdida de nodos de los pods.

Si no incluyes una anotación de NEG, recibirás una advertencia en el objeto Ingress que te impedirá configurar el balanceador de carga de aplicaciones interno. También se genera un evento de Kubernetes en el Ingress si no se incluye la anotación NEG. El siguiente mensaje es un ejemplo del mensaje de evento:

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

No se crea un NEG hasta que un objeto Ingress hace referencia al objeto Service. El NEG no aparece en Compute Engine hasta que existen tanto el Ingress como el servicio al que hace referencia. Los NEGs son un recurso zonal y, en el caso de los clústeres multizona, se crea uno por servicio y por zona.

Para crear un servicio, sigue estos pasos:

1. Guarda el siguiente archivo de manifiesto de ejemplo como 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. Aplica el manifiesto al clúster:

   kubectl apply -f web-service.yaml
   

Desplegar Ingress

En esta sección, crearás un recurso Ingress que activará el despliegue de un balanceador de carga de Compute Engine a través del controlador Ingress. El recurso Ingress de los balanceadores de carga de aplicaciones internos requiere la siguiente anotación:

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

No puedes usar el campo ingressClassName para especificar un GKE Ingress. Debes usar la anotación kubernetes.io/ingress.class. Para obtener más información, consulta Comportamiento del controlador de Ingress de GKE.

Para crear un Ingress, sigue estos pasos:

1. Guarda el siguiente archivo de manifiesto de ejemplo como 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. Aplica el manifiesto al clúster:

   kubectl apply -f internal-ingress.yaml
   

Validar una implementación de Ingress correcta

En esta sección, comprobarás si la implementación se ha realizado correctamente.

El recurso Ingress puede tardar varios minutos en aprovisionarse por completo. Durante este tiempo, el controlador Ingress crea elementos como reglas de reenvío, servicios de backend, mapas de URLs y NEGs.

Para obtener el estado del recurso Ingress que has creado en la sección anterior, ejecuta el siguiente comando:

kubectl get ingress ilb-demo-ingress

El resultado debería ser similar al siguiente:

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

Cuando se rellena el campo ADDRESS, el Ingress está listo. Si se usa una dirección RFC 1918 en este campo, se indica una IP interna de la VPC.

Como el balanceador de carga de aplicaciones interno es un balanceador de carga regional, solo se puede acceder a la IP virtual (VIP) desde un cliente que esté en la misma región y VPC. Después de recuperar la IP virtual del balanceador de carga, puedes usar herramientas (por ejemplo, curl) para enviar llamadas HTTP GET a la IP virtual desde dentro de la VPC.

Para hacer una llamada a HTTP GET, sigue estos pasos:

1. Para acceder a tu VIP de entrada desde dentro de la VPC, implementa una VM en la misma región y red que el clúster:

   gcloud compute instances create l7-ilb-client \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --network=NETWORK_NAME \
       --subnet=SUBNET_NAME \
       --zone=COMPUTE_ZONE \
       --tags=allow-ssh
   

   Haz los cambios siguientes:

   • SUBNET_NAME: el nombre de una subred de la red.
   • COMPUTE_ZONE: una zona de Compute Engine de la región.

   Para obtener más información sobre cómo crear instancias, consulta Crear e iniciar una instancia de VM.

2. Para acceder a la IP virtual interna desde la máquina virtual, usa curl:

   1. Accede a la VM que has creado en el paso anterior mediante SSH:

      gcloud compute ssh l7-ilb-client \
          --zone=COMPUTE_ZONE
      

   2. Usa curl para acceder al VIP de la aplicación interna:

      curl 10.128.0.58
      hostname-server-6696cf5fc8-z4788
      

      La respuesta HTTP correcta y el nombre de host de uno de los contenedores de backend indican que la ruta de balanceo de carga completa funciona correctamente.

Eliminar recursos de Ingress

Al eliminar los recursos de entrada y de servicio, también se eliminan los recursos del balanceador de carga de Compute Engine asociados a ellos. Para evitar fugas de recursos, asegúrate de que los recursos Ingress se desactiven cuando ya no los necesites. También debes eliminar los recursos de entrada y de servicio antes de eliminar los clústeres. De lo contrario, los recursos de balanceo de carga de Compute Engine quedarán huérfanos.

Para eliminar un Ingress, sigue estos pasos:

1. Elimina el Ingress. Por ejemplo, para eliminar el Ingress que has creado en esta página, ejecuta el siguiente comando:

   kubectl delete ingress ilb-demo-ingress
   

   Si eliminas el Ingress, se quitarán las reglas de reenvío, los servicios backend y los mapas de URLs asociados a este recurso de Ingress.

2. Elimina el Servicio. Por ejemplo, para eliminar el servicio que has creado en esta página, ejecuta el siguiente comando:

   kubectl delete service hostname
   

   Si eliminas el servicio, se eliminará el NEG asociado.

Para desplegar una aplicación en GKE y exponerla con una dirección IP privada balanceada, consulta Ingress interno básico.

Direccionamiento IP estático

Los recursos de entrada internos admiten tanto direcciones IP estáticas como efímeras. Si no se especifica ninguna dirección IP, se asignará automáticamente una dirección IP disponible de la subred de nodos de GKE. Sin embargo, el recurso Ingress no aprovisiona direcciones IP de la subred de solo proxy, ya que esta subred solo se usa para el consumo de proxies internos. Estas direcciones IP efímeras se asignan al Ingress solo durante el ciclo de vida del recurso Ingress interno. Si eliminas tu Ingress y creas uno nuevo a partir del mismo archivo de manifiesto, no se te garantiza que obtengas la misma dirección IP externa.

Si quieres una dirección IP permanente que sea independiente del ciclo de vida del recurso Ingress interno, debes reservar una dirección IP interna estática regional. Después, puedes especificar una dirección IP estática mediante la anotación kubernetes.io/ingress.regional-static-ip-name en tu recurso Ingress.

En el siguiente ejemplo se muestra cómo añadir esta anotación:

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"

Sustituye STATIC_IP_NAME por un nombre de IP estática que cumpla los siguientes criterios:

• Crea la dirección IP estática antes de implementar el Ingress. Un balanceador de carga no se implementa hasta que existe la IP estática, y hacer referencia a un recurso de dirección IP que no existe no crea una IP estática. Si modificas un Ingress para que use una dirección IP estática en lugar de una efímera, es posible que GKE cambie la dirección IP del balanceador de carga cuando vuelva a crear la regla de reenvío del balanceador de carga.
• La IP estática se reserva en el proyecto de servicio para un Ingress implementado en el proyecto de servicio de una VPC compartida.
• Haz referencia al recurso de Trusted Cloud by S3NS dirección IP por su nombre, en lugar de por su dirección IP.
• La dirección IP debe pertenecer a una subred de la misma región que el clúster de GKE. Puedes usar cualquier subred privada disponible en la región (excepto la subred solo proxy). Los diferentes recursos de Ingress también pueden tener direcciones de diferentes subredes.

HTTPS entre el cliente y el balanceador de carga

Ingress para el balanceo de carga interno admite el servicio de certificados TLS a los clientes. Puedes servir certificados TLS a través de secretos de Kubernetes o de certificados SSL regionales compartidos previamente en Trusted Cloud by S3NS. También puedes especificar varios certificados por recurso Ingress. En GKE 1.25 y versiones posteriores, se admite el uso simultáneo de HTTPS y HTTP. Para habilitar esta función, debes crear una dirección IP estática con PURPOSE=SHARED_LOADBALANCER_VIP y configurarla en el Ingress. Si no se proporciona una dirección IP estática, solo se permite el tráfico HTTPS y debes seguir las instrucciones de la documentación para inhabilitar HTTP.

En los siguientes pasos se explica cómo crear un certificado en Trusted Cloud by S3NS y, a continuación, servirlo a través de Ingress a clientes internos para el tráfico HTTPS y HTTP:

1. Crea el certificado regional:

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

   Haz los cambios siguientes:

   • CERT_NAME: el nombre que elijas para tu certificado.
   • CERT_FILE_PATH: la ruta al archivo de certificado local para crear un certificado autogestionado. El certificado debe estar en formato PEM.
   • KEY_FILE_PATH: la ruta a un archivo de clave privada local. La clave privada debe tener el formato PEM y usar el cifrado RSA o ECDSA.
   • COMPUTE_REGION: una región de Compute Engine para tu certificado.

2. Reserva y aplica una dirección IP estática siguiendo las instrucciones de Direcciones IP estáticas.

3. Guarda el siguiente archivo de manifiesto de ejemplo como 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.regional-static-ip-name: STATIC_IP_NAME
       kubernetes.io/ingress.class: "gce-internal"
   spec:
     rules:
     - host: DOMAIN
       http:
         paths:
         - pathType: ImplementationSpecific
           backend:
             service:
               name: SERVICE_NAME
               port:
                 number: 80
   

   Haz los cambios siguientes:

   • DOMAIN: tu dominio.
   • CERT_NAME: el nombre del certificado que has creado en la sección anterior.
   • SERVICE_NAME: el nombre de tu Servicio.

4. Aplica el manifiesto al clúster:

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

HTTPS entre el balanceador de carga y la aplicación

Si tu aplicación se ejecuta en un pod de GKE y puede recibir solicitudes HTTPS, puedes configurar el balanceador de carga para que use HTTPS cuando reenvíe solicitudes a tu aplicación. Para obtener más información, consulta HTTPS (TLS) entre el balanceador de carga y tu aplicación.

VPC compartida

Añadir manualmente la anotación NEG

Si el clúster de GKE en el que vas a desplegar los recursos de Ingress se encuentra en un proyecto de servicio de VPC compartida, los servicios no se anotarán automáticamente con la anotación cloud.google.com/neg: '{"ingress": true}' porque no está instalado el MutatingWebhookConfiguration responsable de insertar la anotación en los servicios.

Debe añadir la anotación NEG al manifiesto de los servicios que se exponen a través de Ingress para los balanceadores de carga de aplicaciones internos.

Reglas de cortafuegos de VPC

Si el clúster de GKE en el que vas a desplegar los recursos Ingress se encuentra en un proyecto de servicio de VPC compartida y quieres que el plano de control de GKE gestione los recursos de cortafuegos de tu proyecto host, debes conceder a la cuenta de servicio de GKE del proyecto de servicio los permisos de gestión de identidades y accesos adecuados en el proyecto host, tal como se indica en el artículo Gestionar recursos de cortafuegos de clústeres con VPC compartida. De esta forma, el controlador Ingress puede crear reglas de cortafuegos para permitir el tráfico de entrada de las comprobaciones de estado.Trusted Cloud

A continuación, se muestra un ejemplo de un evento que puede estar presente en los registros de recursos de entrada. Este error se produce cuando el controlador de Ingress no puede crear una regla de cortafuegos para permitir el tráfico de entrada de las comprobaciones del estado si los permisos no están configurados correctamente. Trusted Cloud

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 prefieres aprovisionar manualmente las reglas de cortafuegos desde el proyecto host, puedes silenciar los eventos firewallXPNError añadiendo la anotación networking.gke.io/suppress-firewall-xpn-error: "true" al recurso Ingress.

Resumen de las anotaciones de Ingress internas

En las siguientes tablas se muestran las anotaciones que puede añadir al crear recursos Ingress y Service para Ingress para balanceadores de carga de aplicaciones internos.

Anotaciones de Ingress

Anotaciones de servicio relacionadas con Ingress

Solución de problemas

Para entender y observar el estado de Ingress, normalmente se inspeccionan los recursos asociados. Entre los tipos de problemas que se suelen encontrar se incluyen los recursos de balanceo de carga que no se crean correctamente, el tráfico que no llega a los backends o los backends que no parecen estar en buen estado.

Estos son algunos de los pasos habituales para solucionar problemas:

• Verificar que el tráfico del cliente procede de la misma región y de la misma VPC que el balanceador de carga.
• Verificar que los pods y los back-ends están en buen estado.
• Validar la ruta del tráfico a la IP virtual y las comprobaciones del estado de Compute Engine para asegurarse de que las reglas de cortafuegos no la bloquean.
• Comprobar si hay errores en los eventos del recurso Ingress.
• Describe el recurso Ingress para ver la asignación a los recursos de Compute Engine.
• Validar que los recursos de balanceo de carga de Compute Engine existen, tienen las configuraciones correctas y no tienen errores.

Filtrar eventos de entrada

La siguiente consulta filtra los errores de todos los eventos de entrada de tu clúster:

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

También puedes filtrar por objetos o nombres de objetos:

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

En el siguiente error, puedes ver que el servicio al que hace referencia Ingress no existe:

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"

Inspeccionar recursos de balanceadores de carga de Compute Engine

El siguiente comando muestra el resultado completo del recurso Ingress para que puedas ver las asignaciones a los recursos de Compute Engine que crea el controlador Ingress:

kubectl get ing INGRESS_FILENAME -o yaml

Sustituye INGRESS_FILENAME por el nombre de archivo de tu recurso Ingress.

El resultado debería ser similar al siguiente:

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: ""

En la lista de ingress.kubernetes.io/backendsanotaciones se indican los back-ends y su estado. Asegúrate de que tus back-ends aparezcan como HEALTHY.

Los recursos de Compute Engine creados por Ingress se pueden consultar directamente para conocer su estado y configuración. Ejecutar estas consultas también puede ser útil para solucionar problemas.

Para enumerar todas las reglas de reenvío de Compute Engine, sigue estos pasos:

gcloud compute forwarding-rules list

El resultado debería ser similar al siguiente:

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

Para consultar el estado de un servicio de backend, primero debe enumerar los servicios de backend y hacer una copia del nombre del servicio de backend que quiera inspeccionar:

gcloud compute backend-services list

El resultado debería ser similar al siguiente:

NAME                                         BACKENDS                                                                       PROTOCOL
k8s1-42084f6a-default-hostname-80-98cbc1c1   REGION_NAME/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1 HTTP

Ahora puedes usar el nombre del servicio de backend para consultar su estado:

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

Sustituye COMPUTE_REGION por la región de Compute Engine del servicio de backend.

El resultado debería ser similar al siguiente:

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

Siguientes pasos

• Consulta información sobre Ingress de GKE para balanceadores de carga de aplicaciones externos.

• Consulta una descripción general conceptual de los servicios en GKE.

• Consulta cómo crear un balanceador de carga de red de paso a través interno en GKE.

• Implementa un Ingress interno básico.