Configura Ingress para balanceadores de cargas de aplicaciones internos

Autopilot Estándar

En esta página, se muestra cómo configurar y usar Ingress para balanceadores de cargas de aplizaciones internos en Google Kubernetes Engine (GKE). Ingress proporciona compatibilidad integrada para 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 balanceadores de cargas de aplicaciones internos, consulta Características de Ingress. También puedes obtener más información sobre cómo funciona Ingress para balanceadores de cargas de aplicaciones internos en Ingress para balanceadores de cargas de aplicaciones internos.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

Requisitos

Ingress para balanceadores de cargas de aplicaciones internos 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 ser nativo de VPC.
El clúster debe tener el complemento HttpLoadBalancing habilitado. Este complemento está habilitado de forma predeterminada. No debes inhabilitarlo.
Debes usar grupos de extremos de red (NEG) como backends para tu servicio.

Implementa Ingress para balanceadores de cargas de aplicaciones internos

En los siguientes ejercicios, se muestra cómo implementar Ingress para balanceadores de cargas de aplicaciones internos:

Prepara el entorno.
Crea un clúster.
Implementa una aplicación
Implementa un Service
Implementa Ingress
Valida la implementación.
Borra los recursos de Ingress.

Prepara el entorno

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.

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

Reemplaza lo siguiente:

COMPUTE_REGION: Es una región de Compute Engine.
NETWORK_NAME: Es el nombre de la red para la subred.

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

Crea una regla de firewall

El controlador de Ingress no crea una regla de firewall para permitir conexiones desde los proxies del balanceador de cargas en la subred del proxy. Debes crear esta regla de firewall de forma manual. Sin embargo, el controlador de Ingress crea reglas de firewall a fin de permitir el ingreso para las verificaciones de estado de Google Cloud.

Crea una regla de firewall para permitir conexiones desde los proxies del balanceador de cargas 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

Reemplaza CONTAINER_PORT por el valor del puerto que escucha el Pod, como 9376.

Crear un clúster

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

gcloud

Crea un clúster en la misma red que la subred de solo proxy:

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

Reemplaza lo siguiente:

CLUSTER_NAME: Es un nombre para tu clúster.
COMPUTE_LOCATION: La ubicación del Compute Engine del clúster. Debes usar la misma ubicación que la subred de proxy que creaste en la sección anterior.

Console

Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.

Ir a Google Kubernetes Engine
Haz clic en Crear.
En la sección Autopilot, haz clic en Configurar.
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 de Compute Engine para el clúster. Debes usar la misma región que la subred de proxy que creaste en la sección anterior.
En el panel de navegación, haga clic en Herramientas de redes.
En la lista 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.
En la lista Subred del nodo, selecciona la subred de proxy que creaste
Haz clic en Crear.

Implementa una aplicación web

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

Para crear un Deployment, sigue estos pasos:

Guarda el siguiente manifiesto de muestra 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

En este manifiesto, se describe una implementación 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.

Aplica el manifiesto 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. Ingress para balanceadores de cargas de aplicaciones internos 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:

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

La anotación se agrega de forma automática mediante un MutatingWebhookConfiguration con el nombre neg-annotation.config.common-webhooks.networking.gke.io. Puedes verificar si MutatingWebhookConfiguration está presente con el siguiente comando:

kubectl get mutatingwebhookconfigurations

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

Guarda el siguiente manifiesto de muestra 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

Aplica el manifiesto 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. Ingress para balanceadores de cargas de aplicaciones internos requiere la siguiente anotación:

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

No puedes usar el campo ingressClassName para especificar un Ingress de GKE. 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, haz lo siguiente:

Guarda el siguiente manifiesto de muestra 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

Aplica el manifiesto 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

El resultado es similar a este:

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

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.
```
gcloud compute instances create l7-ilb-client \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --network=NETWORK_NAME \
    --subnet=SUBNET_NAME \
    --zone=COMPUTE_ZONE \
    --tags=allow-ssh
```
Reemplaza lo siguiente:
- SUBNET_NAME: Es el nombre de una subred en la red.
- COMPUTE_ZONE: Es una zona de Compute Engine en la región.
Para obtener más información sobre cómo crear instancias, consulta Crea e inicia una instancia de VM.
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 \
    --zone=COMPUTE_ZONE 
```
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:

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

Para implementar una aplicación en GKE y exponer la aplicación con una dirección IP privada de balanceador de cargas, consulta Ingress interno básico.

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 dirección IP estática antes de implementar el 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. Si modificas un Ingress existente para que use una dirección IP estática en lugar de una dirección IP efímera, GKE podría cambiar la dirección IP del balanceador de cargas cuando GKE vuelva a crear la regla de reenvío del balanceador de cargas.
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. El uso de HTTPS y HTTP de forma simultánea es compatible con GKE 1.25 o versiones posteriores. Para habilitar esta función, debes crear una dirección IP estática con PURPOSE=SHARED_LOADBALANCER_VIP y configurarla en la entrada. Si no se proporciona una dirección IP estática, solo se permite el tráfico HTTPS, y debes seguir la documentación para Inhabilitar HTTP.

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 para tráfico HTTPS y HTTP:

Crea el certificado regional:
```
gcloud compute ssl-certificates create CERT_NAME \
    --certificate CERT_FILE_PATH \
    --private-key KEY_FILE_PATH \
    --region COMPUTE_REGION
```
Reemplaza lo siguiente:
- CERT_NAME: Es un nombre para el certificado que elijas.
- CERT_FILE_PATH: la ruta de acceso al archivo del certificado local para crear un certificado autoadministrado. El certificado debe estar en formato PEM.
- KEY_FILE_PATH: Es la ruta a un archivo de clave privada local. La clave privada debe estar en formato PEM y debe usar encriptación RSA o ECDSA.
- COMPUTE_REGION: Es una región de Compute Engine para el certificado.
Reserva y aplica una dirección IP estática después de Direccionamiento IP estático.

Guarda el siguiente manifiesto de muestra 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

Reemplaza lo siguiente:

DOMAIN: tu dominio.
CERT_NAME: Es el nombre del certificado que creaste en la sección anterior.
SERVICE_NAME: el nombre de tu servicio.

Aplica el manifiesto 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

Agrega la anotación del NEG de forma manual

Si el GKE en el que implementas los recursos de Ingress está en un proyecto de servicio de VPC compartida, los servicios no se anotan de forma automática con la anotación cloud.google.com/neg: '{"ingress": true}' porque el MutatingWebhookConfiguration es responsable de inyectar. La anotación a los servicios no está instalada.

Debes agregar la anotación de NEG al manifiesto de los Services que se exponen a través de Ingress para balanceadores de cargas de aplicaciones internos.

Reglas de firewall de VPC

Si el clúster de GKE en el que implementas los recursos de Ingress está en un proyecto de servicio de VPC compartida 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 para permitir 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 reglas de firewall de forma manual desde el proyecto host, puedes silenciar los eventos firewallXPNError agregando 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 balanceadores de cargas de aplicaciones internos.

Anotaciones de Ingress

Anotación	Descripción
`kubernetes.io/ingress.class`	Puedes configurarlo como `"gce-internal"` para Ingress interno. Si no se especifica la clase, un recurso de Ingress se interpreta de forma predeterminada como Ingress externo. Para obtener más información, consulta Comportamiento del controlador de Ingress de GKE.
`kubernetes.io/ingress.allow-http`	Puedes permitir el tráfico HTTP entre el cliente y el balanceador de cargas HTTP(S). Los valores posibles son `true` y `false`. El valor predeterminado es `true`. 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 con balanceadores de cargas de aplicaciones externos.
`networking.gke.io/suppress-firewall-xpn-error`	En GLBC 1.4 y versiones posteriores, puedes silenciar el evento `firewallXPNError`. 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 crea un evento `firewallXPNError` cada varios minutos. Agrega la anotación `networking.gke.io/suppress-firewall-xpn-error: "true"` al recurso de entrada. El valor predeterminado es `false`. Podrás quitar esta anotación para dejar de silenciar el evento.
`kubernetes.io/ingress.regional-static-ip-name`	Puedes especificar una dirección IP estática para aprovisionar tu recurso Ingress interno. Para obtener más información, consulta Direccionamiento IP estático.

Anotaciones de Service relacionadas con Ingress

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 Configuración 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.

El resultado es similar a este:

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

El resultado es similar a este:

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

El resultado es similar a este:

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

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

El resultado es 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

¿Qué sigue?

Obtén información acerca de Ingress para balanceadores de cargas de aplicaciones externos.
Consulta una descripción general conceptual de los Services en GKE.
Aprende a crear un balanceador de cargas de red de transferencia interno en GKE.
Implementa un Ingress interno básico.