Configura Ingress para balanceo de cargas HTTP(S) interno

En esta página, se muestra cómo configurar y usar Ingress para el balanceo de cargas de HTTP(S) interno en Google Kubernetes Engine (GKE). Ingress para el balanceo de cargas de HTTP(S) interno proporciona compatibilidad integrada con el balanceo de cargas interno a través del controlador de GKE Ingress.

A fin de obtener más información sobre las funciones compatibles con Ingress para el balanceo de cargas de HTTP(S) interno, consulta Características de Ingress. También puedes obtener más información sobre cómo funciona Ingress para el balanceo de cargas de HTTP(S) interno en Ingress para el balanceo de cargas de HTTP(S) interno.

Antes de comenzar

Antes de poder implementar recursos del balanceador de cargas a través de la API de Ingress de Kubernetes, debes preparar tu entorno de red para que los proxies del balanceador de cargas puedan implementarse en una región determinada. Si deseas obtener información sobre cómo implementar la subred de solo proxy, consulta Configura la red y las subredes.

Debes completar este paso antes de implementar Ingress para el balanceo de cargas de HTTP(S) interno.

Si quieres obtener más información sobre por qué Ingress para el balanceo de cargas de HTTP(S) interno requiere que uses una subred de solo proxy, consulta Entorno de red obligatorio.

Requisitos

El Ingress para el balanceo de cargas HTTP(S) interno tiene los siguientes requisitos:

  • Tu clúster debe usar una versión de GKE posterior a 1.16.5-gke.10.
  • Tu clúster debe ejecutarse en modo nativo de la VPC (IP de alias). Para obtener más información, consulta Clústeres nativos de la VPC.
  • Tu clúster debe tener habilitado el complemento de balanceo de cargas de HTTP. Los clústeres tienen el balanceo de cargas de HTTP habilitado de forma predeterminada. No inhabilites el complemento.
  • Debes usar grupos de extremo de red (NEG) como backends para tu Service.

Implementa Ingress para el balanceo de cargas de HTTP(S) interno

En los siguientes ejercicios, se muestra cómo implementar Ingress para el balanceo de cargas de HTTP(S) interno:

  1. Crea un clúster.
  2. Implementa una aplicación
  3. Implementa un Service
  4. Implementa Ingress
  5. Valida la implementación.
  6. Borra los recursos de Ingress.

Cómo crear un clúster

En esta sección, crearás un clúster que podrás usar con Ingress para el balanceo de cargas de HTTP(S) interno. Puedes crear este clúster con la herramienta de línea de comandos de gcloud o Google Cloud Console.

gcloud

Crea un clúster con los siguientes campos:

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION_NUMBER \
    --enable-ip-alias \
    --zone=ZONE \
    --network=NETWORK

Reemplaza lo siguiente:

  • CLUSTER_NAME: agrega un nombre para el clúster.
  • VERSION_NUMBER: agrega una versión posterior a 1.16.5-gke.10. También puedes usar la marca --release-channel para seleccionar un canal de versiones con una versión predeterminada posterior a 1.16.5-gke.10.
  • --enable-ip-alias activa el alias de IP. Los clústeres que usan Ingress para el balanceo de cargas de HTTP(S) interno deben ejecutarse en modo nativo de la VPC (alias de IP). Para obtener más información, consulta Crea un clúster nativo de la VPC.
  • ZONE: agrega una zona en la que deseas crear el clúster. Debes elegir una zona en la misma región que la subred de proxy que creaste para tu balanceador de cargas de HTTP(S) interno en Configura la red y las subredes.
  • NETWORK: agrega el nombre de la red en la que deseas que se cree el clúster. Esta red debe estar en la misma red de VPC que la subred de proxy.

Console

  1. Ve a la página Google Kubernetes Engine en Cloud Console.

    Ir a Google Kubernetes Engine

  2. Haz clic en Crear.

  3. En la sección Aspectos básicos del clúster, completa lo siguiente:

    1. Ingresa el nombre de tu clúster.
    2. En Tipo de ubicación, selecciona una zona para el clúster. Debes elegir una zona en la misma región que la subred de proxy que creaste para tu balanceador de cargas de HTTP(S) interno en Configura la red y las subredes.
    3. En Versión del plano de control, selecciona una versión estática posterior a 1.16.5-gke.10 o selecciona un Canal de versiones con un versión predeterminada posterior a 1.16.5-gke.10.
  4. En el panel de navegación, en Clúster, haz clic en Redes.

    1. En la lista desplegable Red, selecciona la red en la que deseas crear el clúster. Esta red debe estar en la misma red de VPC que la subred de proxy.
    2. En Opciones avanzadas de red, asegúrate de que las opciones Habilitar enrutamiento de tráfico nativo de la VPC (con alias de IP) y Habilitar balanceo de cargas HTTP estén seleccionadas.
  5. Haga clic en Crear.

Implementa una aplicación web

En esta sección, crearás un Deployment.

Para crear un Deployment, sigue estos pasos:

  1. Copia y guarda el siguiente recurso de Service en un archivo llamado 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
    

    Este Deployment utiliza una imagen de contenedor que escucha en un servidor HTTPS en el puerto 9376. Este Deployment administra los Pods para tu aplicación. Cada Pod ejecuta un contenedor de aplicaciones con un servidor HTTPS que muestra 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 controla la finalización correcta.

  2. Después de crear tu Deployment, aplica el recurso al clúster:

    kubectl apply -f web-deployment.yaml
    

Implementa un Service como un grupo de extremos de red (NEG)

En esta sección, crearás un recurso de Service. Service selecciona los contenedores de backend en función de sus etiquetas para que el controlador Ingress pueda programarlos como extremos de backend. El Ingress para el balanceo de cargas de HTTP(S) interno requiere que uses NEG como backends. La función no admite grupos de instancias como backends. Debido a que los backends de NEG son obligatorios, se requiere la siguiente anotación de NEG cuando implementas los objetos Service que se exponen a través de Ingress:

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

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

  • Creaste el Service en clústeres de GKE 1.17.6-gke.7 y versiones posteriores.
  • Estás usando clústeres nativos de la VPC.
  • No estás usando una VPC compartida
  • No estás usando una política de red de GKE

El uso de NEG permite que el controlador Ingress realice el balanceo de cargas nativo del contenedor. El tráfico tiene balanceo de cargas desde el proxy de Ingress directamente hacia la IP del pod, en lugar de desviar la red IP del nodo o las Herramientas de redes de kube-proxy. Además, las puertas de preparación de Pods se implementan para determinar el estado de los Pods desde la perspectiva del balanceador de cargas, y no solo las verificaciones de preparación y capacidad de respuesta de Kubernetes. Las puertas de preparación de Pods garantizan que el tráfico no se pierda durante los eventos del ciclo de vida, como el inicio de Pods, la pérdida de Pods o la pérdida de nodos.

Si no incluyes una anotación de NEG, recibirás una advertencia en el objeto Ingress que te evitará configurar el balanceador de cargas de HTTP(S) interno. También se genera un evento de Kubernetes en el Ingress si la anotación de NEG no está incluida. El siguiente mensaje es un ejemplo del mensaje del 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 Ingress hace referencia a un Service. El NEG no aparece en Compute Engine hasta que existan el Ingress y su Service de referencia. Los NEG son recursos zonales para clústeres multizonales; se crea uno por Service y por zona.

Para crear un Service, haz lo siguiente:

  1. Copia y guarda el siguiente recurso de Service en un archivo llamado 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. Después de crear el archivo de Service, aplica el recurso al clúster:

    kubectl apply -f  web-service.yaml
    

Implementa Ingress

En esta sección, crearás un recurso de Ingress que activa la implementación del balanceo de cargas de Compute Engine a través del controlador de Ingress. Un Ingress para el balanceo de cargas de HTTP(S) interno requiere la siguiente anotación:

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

Para crear un Ingress, haz lo siguiente:

  1. Copia y guarda el siguiente recurso de Service en un archivo llamado 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. Después de crear el archivo de Service, aplica el recurso al clúster:

    kubectl apply -f internal-ingress.yaml
    

Valida una implementación de Ingress exitosa

En esta sección, validarás si tu implementación fue exitosa.

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

Para recuperar el estado de tu recurso de Ingress que creaste en la sección anterior, ejecuta el siguiente comando:

kubectl get ingress ilb-demo-ingress

Deberías ver un resultado similar al siguiente:

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

Cuando se completa el campo ADDRESS, el Ingress está listo. El uso de una dirección RFC 1918 en este campo indica una IP interna dentro de la VPC.

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

Para emitir una llamada a HTTP GET, completa los siguientes pasos:

  1. Para llegar a la VIP de Ingress desde la VPC, implementa una VM dentro de la misma región y la red que el clúster.

    Por ejemplo, si seguiste los pasos anteriores para crear Deployment, Service e Ingress y, también, creaste el clúster en la red predeterminada y en la zona us-central1-a, podrías usar el siguiente comando:

    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
    

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

  2. Para acceder a la VIP interna desde el interior de la VM, usa curl:

    1. Establece una conexión SSH a la VM que creaste en el paso anterior:

      gcloud compute ssh l7-ilb-client-us-central1-a \
         --zone=us-central1-a
      
    2. Usa curl para acceder a la VIP de la aplicación interna:

      curl 10.128.0.58
      hostname-server-6696cf5fc8-z4788
      

      La respuesta de HTTP y el nombre de host correctos de uno de los contenedores de backend indican que la ruta del balanceo de cargas completa funciona de forma correcta.

Borra recursos de Ingress

Quitar los recursos de Ingress y Service también quita los recursos del balanceador de cargas de Compute Engine asociados a ellos. Para evitar la pérdida de recursos, asegúrate de eliminar los recursos de Ingress cuando ya no los necesites. Los recursos de Ingress y Service deben borrarse antes de que se borren los clústeres; de lo contrario, los recursos del balanceo de cargas de Compute Engine quedan huérfanos.

Para quitar un Ingress, completa los siguientes pasos:

  1. Borra el Ingress. Por ejemplo, para borrar el Ingress que creaste en esta página, ejecuta el siguiente comando:

    kubectl delete ingress ilb-demo-ingress
    

    Si borras el Ingress, se quitan las reglas de reenvío, los servicios de backend y los mapas de URL asociados con este recurso de Ingress.

  2. Borra el servicio. Por ejemplo, para borrar el Service que creaste en esta página, ejecuta el siguiente comando:

    kubectl delete service hostname
    

    Si borras el Service, se quitará el NEG asociado.

Direccionamiento IP estático

Los recursos internos de Ingress admiten direcciones IP estáticas y efímeras. Si no se especifica una dirección IP, se asignará una dirección IP disponible de forma automática desde la subred de nodos de GKE. Sin embargo, el recurso de Ingress no aprovisiona direcciones IP de la subred de solo proxy, ya que esa subred solo se usa para el consumo de proxy interno. Estas direcciones IP efímeras se asignan al Ingress solo durante el ciclo de vida del recurso interno de Ingress. Si borras tu Ingress y creas uno nuevo a partir del mismo archivo de manifiesto, no se 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 interno de Ingress, debes reservar una dirección IP interna estática regional. Luego, puedes especificar una dirección IP estática mediante la anotación kubernetes.io/ingress.regional-static-ip-name en el recurso de Ingress.

En el siguiente ejemplo, se muestra cómo agregar 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"

Reemplaza STATIC_IP_NAME con un nombre de IP estática que cumpla con los siguientes criterios:

  • Crea la IP estática antes de implementar Ingress. Un balanceador de cargas no se implementa hasta que exista la IP estática; hacer referencia a un recurso de dirección IP inexistente no crea una IP estática.
  • 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 dirección IP de Google Cloud por su nombre, en lugar de su dirección IP.
  • La dirección IP debe ser de una subred en la misma región que el clúster de GKE. Puedes usar cualquier subred privada disponible dentro de la región (excepto la subred de solo proxy). Los diferentes recursos de Ingress también pueden tener direcciones de subredes diferentes.

HTTPS entre el cliente y el balanceador de cargas

El Ingress para el balanceo de cargas interno admite la entrega de certificados TLS a los clientes. Puedes entregar certificados TLS a través de los objetos Secret de Kubernetes o mediante certificados SSL regionales compartidos de forma previa en Google Cloud. También puedes especificar varios certificados por recurso de Ingress.

En los siguientes pasos, se detalla cómo crear un certificado en Google Cloud y, luego, entregarlo a clientes internos a través de Ingress:

  1. Crea el certificado regional:

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

    Reemplaza lo siguiente:

    • CERT_NAME: agrega un nombre para el certificado.
    • CERT_FILE_PATH: agrega la ruta de acceso al archivo del certificado local para crear un certificado autoadministrado. El certificado debe estar en formato PEM.
    • KEY_FILE_PATH: agrega la ruta de acceso a un archivo de claves privadas local. La clave privada debe estar en formato PEM y debe usar encriptación RSA o ECDSA.
    • REGION: agrega una región para el certificado.
  2. Crea un Ingress. El siguiente archivo YAML, llamado ingress-pre-shared-cert.yaml, es un ejemplo del recurso de Ingress que debes crear:

    # 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
    

    Reemplaza lo siguiente:

    • DOMAIN: agrega tu dominio.
    • CERT_NAME: Agrega el nombre del certificado que creaste en la sección anterior.
    • SERVICE_NAME: agrega el nombre de tu Service.
  3. Después de crear el Ingress, aplica el recurso al clúster:

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

HTTPS entre el balanceador de cargas 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 cargas 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 cargas y la aplicación.

VPC compartida

Si el clúster de GKE en el que implementas los recursos de Ingress está en un proyecto de servicio y deseas que el plano de control de GKE administre los recursos de firewall en tu proyecto host, entonces se deben otorgar a la cuenta de servicio de GKE del proyecto de servicio los permisos de IAM adecuados en el proyecto host según Administra los recursos de firewall para clústeres con una VPC compartida. Esto permite que el controlador de Ingress cree reglas de firewall a fin de permitir el tráfico de entrada para las verificaciones de estado de Google Cloud.

El siguiente es un ejemplo de un evento que podría estar presente en los registros de recursos de Ingress. Este error se produce cuando el controlador de Ingress no puede crear una regla de firewall que permita el tráfico de entrada para las verificaciones de estado de Google Cloud si los permisos no están configurados de forma correcta.

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 de forma manual las reglas de firewall del proyecto host, puedes silenciar los eventos firewallXPNError si agregas la anotación networking.gke.io/suppress-firewall-xpn-error: "true" al recurso de Ingress.

Resumen de las anotaciones de Ingress internas

En las siguientes tablas, se muestran las anotaciones que puedes agregar cuando creas recursos de Ingress y Service para Ingress para el balanceo de cargas HTTP(S) interno.

Anotaciones de Ingress

Anotación Descripción
kubernetes.io/ingress.class Especificado como "gce-internal" para Ingress interno. Si no se especifica la clase, un recurso de Ingress se interpreta de forma predeterminada como Ingress externo.
kubernetes.io/ingress.allow-http Especifica si se debe permitir el tráfico HTTP entre el cliente y el balanceador de cargas de HTTP(S). Los valores posibles son true y false. El valor predeterminado es true, pero debes establecer esta anotación en false si usas HTTPS para el balanceo de cargas interno. Para obtener más información, consulta Inhabilita HTTP.
ingress.gcp.kubernetes.io/pre-shared-cert Puedes subir certificados y claves a tu proyecto de Google Cloud. Usa esta anotación para hacer referencia a los certificados y claves. Para obtener más información, consulta Usa varios certificados SSL en el balanceo de cargas de HTTP(S).
networking.gke.io/suppress-firewall-xpn-error En el caso de los balanceadores de cargas de Ingress, si Kubernetes no puede modificar las reglas de firewall debido a que no cuenta con los permisos suficientes, se creará un evento firewallXPNError cada algunos minutos. En GLBC 1.4 y versiones posteriores, puedes silenciar el evento firewallXPNError si agregas la anotación networking.gke.io/suppress-firewall-xpn-error: "true" al recurso de entrada. Podrás quitar esta anotación para dejar de silenciar el evento. Los valores posibles son true y false. El valor predeterminado es false.
Anotación Descripción
cloud.google.com/backend-config Usa esta anotación para configurar el servicio de backend asociado con un servicePort. Para obtener más información, consulta Funciones de Ingress.
cloud.google.com/neg Usa esta anotación para especificar que el balanceador de cargas debe usar grupos de extremos de red. Para obtener más información, consulta Usa el balanceo de cargas nativo del contenedor.

Soluciona problemas

Por lo general, comprender y observar el estado de Ingress implica inspeccionar los recursos asociados. Los tipos de problemas que se encuentran a menudo incluyen recursos de balanceo de cargas que no se crean de forma correcta, tráfico que no llega a backends o backends que no parecen estar en buen estado.

Estos son algunos pasos comunes para solucionar problemas:

  • Verificar que el tráfico del cliente se origine dentro de la misma región y la VPC que el balanceador de cargas
  • Verificar que los pods y los backends estén en buen estado
  • Validar la ruta de tráfico a la VIP y validar que las verificaciones de estado de Compute Engine garanticen que las reglas de firewall no la bloqueen
  • Verificar que no haya errores en los eventos del recurso de Ingress
  • Describir el recurso de Ingress para ver la asignación a los recursos de Compute Engine
  • Validar que los recursos de balanceo de cargas de Compute Engine existan, tengan las parámetros de configuración correctos y no tengan errores informados.

Filtra eventos de Ingress

La siguiente consulta filtra los errores de todos los eventos de Ingress en 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 Service al que hace referencia el 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"

Inspecciona los recursos del balanceador de cargas de Compute Engine

Con el siguiente comando, se muestra la salida completa del recurso de Ingress para que puedas ver las asignaciones a los recursos de Compute Engine que crea el controlador de Ingress:

kubectl get ing INGRESS_FILENAME -o yaml

Reemplaza INGRESS_FILENAME por el nombre del archivo de tu recurso Ingress.

Deberías ver un resultado 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: ""

Las anotaciones ingress.kubernetes.io/backends enumeran los backends y su estado. Asegúrate de que tus backends aparezcan como HEALTHY.

Los recursos de Compute Engine que crea Ingress se pueden consultar directamente para comprender el estado y la configuración. Ejecutar estas consultas también puede ser útil para solucionar problemas.

Para enumerar todas las reglas de reenvío de Compute Engine, haz lo siguiente:

gcloud compute forwarding-rules list

Salida de ejemplo:

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

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

gcloud compute backend-services list

Salida de ejemplo:

NAME                                         BACKENDS                                                                       PROTOCOL
k8s1-42084f6a-default-hostname-80-98cbc1c1   us-central1-a/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 us-central1

Salida de ejemplo:

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

¿Qué sigue?