Configura funciones de Ingress

En esta página, se proporciona una descripción general integral de lo que se puede configurar a través de un Ingress de Kubernetes en Google Cloud y sus compatibilidades. Ingress para Google Kubernetes Engine (GKE) y Anthos proporciona un balanceo de cargas de nivel empresarial integrado de manera estrecha a la red de VPC de Google Cloud.

Comparación de funciones

En la siguiente tabla, se proporciona una lista de las funciones compatibles de Ingress en Google Cloud.

Clase de Ingress Ingress externo Ingress interno Ingress de varios clústeres
Controlador de Ingress Ingress de GKE
(alojado en el plano de control de GKE)
Ingress de Anthos
(alojado en Google)
Tipo de balanceador de cargas de Google Cloud Balanceo de cargas de HTTP(S) externo Balanceo de cargas de HTTP(S) interno Balanceo de cargas de HTTP(S) externo
Alcance del clúster Un solo clúster Un solo clúster Varios clústeres
Alcance del balanceador de cargas Global Regional Global
Compatibilidad con las versiones Todos GKE 1.16.5 o posterior GKE 1.14 o posterior
Compatibilidad con el entorno GKE GKE GKE
Compatibilidad con VPC compartida
Anotaciones de Service
Balanceo de cargas nativo del contenedor (NEG)
HTTPS del balanceador de cargas a los backends
HTTP/2
Anotaciones de Ingress
Direcciones IP estáticas
Certificados basados en Secretos de Kubernetes
Certificados SSL autoadministrados de Google
Certificados SSL administrados por Google
FrontendConfig (versión Beta)
Política de SSL
1.17.6-gke.11B
BackendConfig
Tiempo de espera del servicio de backend
Cloud CDN
Tiempo de espera para vaciado de conexiones
Configuración de la verificación de estado del balanceador de cargas personalizado
1.17.6-gke.11B

1.17.6-gke.11B
Política de seguridad de Google Cloud Armor
Configuración del registro de acceso HTTP
1.16.10-gke.6G

1.16.10-gke.6B
Identity-Aware Proxy (IAP)
Afinidad de sesión
Encabezados de solicitud definidos por el usuario
1.15.3-gke.1G

GEsta función se admite como GA a partir de la versión especificada.

BEsta función está disponible en versión Beta a partir de la versión especificada. Las funciones sin una versión en la lista se admiten para todas las versiones de GKE y Anthos disponibles.

Configura funciones de Ingress

Cuando creas un Ingress mediante el controlador predeterminado, puedes elegir el tipo de balanceador de cargas (un balanceador de cargas de HTTP(S) externo o interno) mediante una anotación en el objeto Ingress. Puedes elegir si GKE crea NEG zonales o si usa grupos de instancias mediante una anotación en cada objeto Service.

Las definiciones de recursos personalizados (CRD) de FrontendConfig y BackendConfig te permiten personalizar aún más el balanceador de cargas. Estas CRD te permiten definir características del balanceador de cargas adicionales de manera jerárquica y de una forma más estructurada que las anotaciones. Para usar Ingress (y estas CRD), debes tener habilitado el complemento de balanceo de cargas de HTTP. Los clústeres de GKE tienen habilitado el balanceo de cargas de HTTP de forma predeterminada; no debes inhabilitarlo.

Se hace referencia a FrontendConfigs en un objeto Ingress y a BackendConfigs en un objeto Service. Varios objetos Service o Ingress pueden hacer referencia a las mismas CRD para mantener la coherencia de la configuración. Las CRD de FrontendConfig y BackendConfig tienen el mismo ciclo de vida que sus recursos de Ingress y Service correspondientes y, a menudo, se implementan juntas.

En el siguiente diagrama, se ilustra cómo:

  • Una anotación en un objeto Ingress o MultiClusterIngress hace referencia a una CRD de FrontendConfig. La CRD de FrontendConfig hace referencia a una política de SSL de Google Cloud.

  • Una anotación en un objeto Service o MultiClusterService hace referencia a una CRD de BackendConfig. La CRD de BackendConfig especifica una configuración personalizada para la verificación de estado del servicio de backend correspondiente.

Descripción general de BackendConfig y FrontendConfig
Figura: Descripción general de BackendConfig y FrontendConfig

Asocia FrontendConfig con el Ingress

Se hace referencia a una CRD de FrontendConfig mediante una anotación en un recurso de Ingress o MultiClusterIngress. Un FrontendConfig corresponde a todo el recurso de Ingress o MultiClusterIngress, como se muestra en el siguiente ejemplo:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/v1beta1.FrontendConfig: "frontendconfig"
...

Asocia un BackendConfig con el Ingress

Se hace referencia a una CRD de BackendConfig mediante una anotación en un recurso de Service o MultiClusterService. El Service o MultiClusterService usa la anotación cloud.google.com/backend-config para especificar el nombre del BackendConfig. Cuando se asocia con un Service o MultiClusterService, el BackendConfig puede determinar la configuración del servicio de backend de Google Cloud. En el siguiente ejemplo, se muestra cómo adjuntar un BackendConfig a un Service o MultiClusterService. La clave default significa que todos los puertos dentro del Service están asociados con el BackendConfig my-backendconfig cuando un Ingress hace referencia a esos puertos:

1.16-gke.3+

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

Todas las versiones compatibles

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

Si necesitas una configuración de BackendConfig única para diferentes puertos dentro del mismo Service, puedes asociar recursos BackendConfig específicos a esos puertos de forma explícita. La clave ports en el siguiente ejemplo permite la vinculación explícita de puertos:

1.16-gke.3+

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "port-1":"backendconfig-1",
    "port-2":"backendconfig-2"
    }}'
spec:
  ports:
  - name:service-name-1
    port: 8001
    protocol: TCP
    targetPort: service-port-1
  - name: service-name-2
    port: 8002
    protocol: TCP
    targetPort: service-port-2
...

Todas las versiones compatibles

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {
    "port-1":"backendconfig-1",
    "port-2":"backendconfig-2"
    }}'
spec:
  ports:
  - name: service-name-1
    port: 8001
    protocol: TCP
    targetPort: service-port-1
  - name: service-name-2
    port: 8002
    protocol: TCP
    targetPort: >service-port-2
...

port-1 puede hacer referencia a puertos dentro del Service por número y a través de service-port-1 o por nombre y a través de service-name-1 (solo compatible con GKE). Cada puerto se asigna a un servicio de backend del balanceador de cargas de Google Cloud que permite que los puertos dentro del Service tengan opciones de configuración diferentes.

Configura funciones de Ingress a través de parámetros de FrontendConfig

En la siguiente sección, se muestra cómo configurar FrontendConfig para habilitar funciones específicas de Ingress.

Políticas de SSL

Las políticas de SSL te permiten especificar un conjunto de versiones y algoritmos de cifrado de TLS que el balanceador de cargas usa para finalizar el tráfico HTTPS de clientes. Primero debes crear una política de SSL fuera de GKE. Una vez que la creaste, puedes hacer referencia a ella en una CRD de FrontendConfig.

El campo sslPolicy en el FrontendConfig hace referencia al nombre de una política de SSL en el mismo proyecto de Google Cloud que el clúster de GKE. Adjunta la política de SSL al proxy HTTPS de destino, que creó el Ingress para el balanceador de cargas de HTTP(S) externo. Varios recursos de Ingress pueden hacer referencia al mismo recurso FrontendConfig y a la misma política de SSL. Si se cambia una política de SSL a la que se hace referencia, el cambio se propaga a Google Front End (GFE) que potencia tu balanceador de cargas de HTTP(S) externo que creó el Ingress.

En el siguiente manifiesto de FrontendConfig, se habilita una política de SSL llamada gke-ingress-ssl-policy:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  sslPolicy: gke-ingress-ssl-policy

Configura funciones de Ingress a través de parámetros de BackendConfig

En las siguientes secciones, se muestra cómo configurar tu BackendConfig para habilitar funciones específicas de Ingress. Los cambios en un recurso BackendConfig se concilian de forma constante, por lo que no necesitas borrar y volver a crear el Ingress para comprobar que los cambios de BackendConfig se reflejan.

Para obtener información sobre las limitaciones de BackendConfig, consulta la sección limitaciones.

Tiempo de espera del servicio de backend

Puedes usar un BackendConfig para configurar un tiempo de espera del servicio de backend en segundos. Si no especificas un valor, el predeterminado es de 30 segundos.

En el siguiente manifiesto de BackendConfig, se especifica un tiempo de espera de 40 segundos:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40

Cloud CDN

Puedes habilitar Cloud CDN mediante un BackendConfig.

En el siguiente manifiesto de BackendConfig, se muestran todos los campos disponibles cuando habilitas Cloud CDN:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: cdnEnabled
    cachePolicy:
      includeHost: includeHost
      includeProtocol:includeProtocol
      includeQueryString: includeQueryString
      queryStringBlacklist:queryStringBlacklist
      queryStringWhitelist: queryStringWhitelist

Reemplaza los siguientes elementos:

  • cdnEnabled: Si se configura como true, Cloud CDN está habilitado para este backend de Ingress.
  • includeHost: Si se configura como true, las solicitudes a diferentes hosts se almacenan en caché por separado.
  • includeProtocol: Si se configura como true, las solicitudes HTTP y HTTPS se almacenan en caché por separado.
  • includeQueryString: Si se configura como true, los parámetros de la string de consulta se incluyen en la clave de caché según queryStringBlacklist o queryStringWhitelist. Si no se configura nada, se incluye toda la string de consulta. Si se configura como false, toda la string de consulta se excluye de la clave de caché.
  • queryStringBlacklist: Especifica un arreglo de strings con los nombres de los parámetros de la string de consulta que se excluirán de las claves de caché. Todos los demás parámetros están incluidos. Puedes especificar queryStringBlacklist o queryStringWhitelist, pero no ambos.
  • queryStringWhitelist: Especifica un arreglo de strings con los nombres de los parámetros de la string de consulta que se incluirán en las claves de caché. Todos los demás parámetros están excluidos. Puedes especificar queryStringBlacklist o queryStringWhitelist, pero no ambos.

Expande la siguiente sección para ver un ejemplo en el que se implementa Cloud CDN a través de Ingress y, luego, se valida que el contenido de la aplicación se almacene en caché.

Tiempo de espera para vaciado de conexiones

Puedes configurar el tiempo de espera del vaciado de conexiones mediante un BackendConfig. El tiempo de espera para el vaciado de conexiones es el tiempo, en segundos, en que se espera a que las conexiones se vacíen. Durante la duración especificada del tiempo de espera, las solicitudes existentes del backend que se quitó tienen tiempo para completarse. El balanceador de cargas no envía solicitudes nuevas al backend que se quitó. Una vez que transcurre el tiempo de espera, se cierran todas las conexiones restantes al backend. La duración del tiempo de espera puede ser entre 0 y 3,600 segundos. El valor predeterminado es 0, lo que también inhabilita el vaciado de conexiones.

En el siguiente manifiesto de BackendConfig, se especifica un tiempo de espera para el vaciado de conexiones de 60 segundos:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  connectionDraining:
    drainingTimeoutSec: 60

Configuración de la verificación de estado personalizada

GKE tiene diversas formas de configurar las verificaciones de estado del balanceador de cargas de Google Cloud cuando se realiza una implementación a través de Ingress. Para obtener más información sobre cómo GKE Ingress implementa las verificaciones de estado, consulta Verificaciones de estado de Ingress.

Un método es configurar verificaciones de estado de forma explícita a través de un BackendConfig. Si se configuran, estos parámetros sustituyen la configuración del sondeo del estado de preparación de Kubernetes y los valores predeterminados de la verificación de estado.

Puedes configurar varios objetos Service de GKE para hacer referencia al mismo BackendConfig como una plantilla reutilizable. En el caso de los parámetros de healthCheck, se crea una verificación de estado única de Google Cloud para cada servicio de backend correspondiente a cada Service de GKE.

En el siguiente manifiesto de BackendConfig, se muestran todos los campos disponibles cuando se configura una verificación de estado de un BackendConfig:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  healthCheck:
    checkIntervalSec: interval
    timeoutSec: timeout
    healthyThreshold: health-threshold
    unhealthyThreshold: unhealthy-threshold
    type: protocol
    requestPath: path
    port: port

Reemplaza los siguientes elementos:

  • interval: Especifica el check-interval en segundos para cada sondeador de verificación de estado. Abarca el tiempo desde el inicio de la verificación de un sondeador hasta el comienzo de la siguiente. Si omites este parámetro, se usa el valor predeterminado de 5 segundos de Google Cloud. Para obtener más información sobre la implementación, consulta Varios sondeos y frecuencia.
  • timeout: Especifica la cantidad de tiempo que Google Cloud espera una respuesta a un sondeo. El valor de timeout debe ser menor o igual que interval. Las unidades son segundos. Cada sondeo requiere que se entregue un código de respuesta HTTP 200 (OK) antes de que se agote su tiempo de espera.
  • health-threshold y unhealthy-threshold: Especifican la cantidad de intentos de conexiones secuenciales que deben tener éxito o fallar, al menos para un sondeador, a fin de cambiar el estado de bueno a malo o viceversa. Si omites uno de estos parámetros, Google Cloud usa el valor predeterminado de 2.
  • protocol: Especifica un protocolo que usan los sistemas de sondeo para la verificación de estado. El BackendConfig solo admite la creación de verificaciones de estado mediante los protocolos HTTP, HTTPS o HTTP2. Si quieres obtener más información, consulta Criterios de éxito para HTTP, HTTPS y HTTP/2. No puedes omitir este parámetro.
  • path: Para las verificaciones de estado HTTP, HTTPS o HTTP2, especifica la request-path a la que se debe conectar el sistema de sondeo. Si omites este parámetro, Google Cloud usa el valor predeterminado de /.
  • port: Especifica el puerto mediante un número de puerto. Si omites este parámetro, Google Cloud usa el valor predeterminado de 80. Cuando se usa el balanceo de cargas nativo del contenedor, los sistemas de sondeo se conectan a la dirección IP de un Pod servidor. De lo contrario, los sondeos de verificación de estado se conectan con la dirección IP del nodo en el que se ejecuta el Pod servidor.

Política de seguridad de Google Cloud Armor

Las políticas de seguridad de Google Cloud Armor te ayudan a proteger las aplicaciones con balanceo de cargas de los ataques basados en la Web. Una vez que configuraste una política de seguridad de Google Cloud Armor, puedes hacer referencia a ella mediante un BackendConfig.

Agrega el nombre de tu política de seguridad al BackendConfig. En el siguiente manifiesto de BackendConfig, se especifica una política de seguridad llamada example-security-policy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

Registro de acceso HTTP

Ingress puede registrar todas las solicitudes HTTP de los clientes en Cloud Logging. Puedes habilitar o inhabilitar el registro de acceso mediante el BackendConfig, además de configurar la tasa de muestreo del registro de acceso.

Para configurar el registro de acceso, usa el campo logging en tu BackendConfig. Si se omite logging, el registro de acceso toma el comportamiento predeterminado. Esto depende de la versión de GKE. De forma predeterminada, el registro de acceso está activado en todas las versiones anteriores a GKE 1.18, pero se expone como un campo configurable a partir de la versión 1.16.8-gke.10.

Puedes configurar los siguientes campos:

  • enable: Si se configura como true, el registro de acceso se habilitará para este Ingress, y los registros estarán disponibles en Cloud Logging. De lo contrario, se inhabilitará el registro de acceso para este Ingress.
  • sampleRate: Especifica un valor de 0.0 a 1.0, en el que 0.0 significa que no se registran paquetes y 1.0 significa que se registra el 100% de los paquetes. Este campo solo es relevante si enable se configura como true. sampleRate es un campo opcional, pero, si está configurado, se debe establecer enable: true o se interpretará como enable: false.

Con el siguiente manifiesto de BackendConfig, se habilita el registro de acceso y se establece la tasa de muestreo en el 50% de las solicitudes HTTP para un recurso Ingress determinado:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

Identity-Aware Proxy

A fin de configurar el BackendConfig para Identity-Aware Proxy (IAP), debes especificar los valores enabled y secretName en el bloque de iap en tu BackendConfig. Para especificar estos valores, asegúrate de tener el permiso compute.backendServices.update.

En el siguiente manifiesto de BackendConfig, se habilita Identity-Aware Proxy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

Si deseas obtener instrucciones completas, consulta Habilita IAP para GKE en la documentación de IAP.

Afinidad de sesión

Puedes usar un BackendConfig para establecer la afinidad de sesión como la IP de cliente o la cookie generada.

Afinidad de IP de cliente

Para usar un BackendConfig con el fin de establecer la afinidad de IP de cliente, configura affinityType como "CLIENT_IP", como se muestra en el siguiente ejemplo:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "CLIENT_IP"

Para usar un BackendConfig a fin de establecer la afinidad de cookie generada, configura affinityType como GENERATED_COOKIE en el manifiesto de BackendConfig. También puedes usar affinityCookieTtlSec para establecer el período en el que la cookie permanecerá activa.

En el siguiente manifiesto, se establece el tipo de afinidad para la cookie generada y se les otorga a las cookies un TTL de 50 segundos:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 50

Encabezados de solicitud definidos por el usuario

Puedes usar un BackendConfig para configurar los encabezados de solicitud definidos por el usuario. El balanceador de cargas agrega los encabezados que especifiques a las solicitudes que reenvía a los backends.

Para habilitar los encabezados de solicitud definidos por el usuario, especifica una lista de encabezados en una propiedad customRequestHeaders del recurso BackendConfig. Especifica cada encabezado como una string header-name:header-value.

En el siguiente manifiesto de BackendConfig, se agregan tres encabezados de solicitud:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customRequestHeaders:
    headers:
    - "X-Client-Region:{client_region}"
    - "X-Client-City:{client_city}"
    - "X-Client-CityLatLong:{client_city_lat_long}"

Ejercicio: configura tiempos de espera de Ingress mediante un servicio de backend

En el siguiente ejercicio, se muestran los pasos necesarios para configurar los tiempos de espera y el vaciado de conexiones con un Ingress mediante un recurso BackendConfig.

Para configurar las propiedades de backend de un Ingress, completa las siguientes tareas:

  1. Crea un Deployment.
  2. Crea un BackendConfig.
  3. Crea un Service y asocia uno de sus puertos al BackendConfig.
  4. Crea un Ingress y asócialo con el par (Service, puerto).
  5. Valida las propiedades del servicio de backend.
  6. Realiza una limpieza.

Crea un Deployment

Antes de crear un BackendConfig y un Service, debes crear un Deployment.

El siguiente manifiesto de ejemplo es para un Deployment llamado my-deployment.yaml:

# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 2
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: gcr.io/google-samples/hello-app:1.0

Ejecuta el siguiente comando para crear el Deployment:

kubectl apply -f my-deployment.yaml

Crea un BackendConfig

Usa el BackendConfig para especificar las funciones de Ingress que deseas usar.

En este manifiesto de BackendConfig, llamado my-backendconfig.yaml, se especifica lo siguiente:

  • Un tiempo de espera de 40 segundos
  • Un tiempo de espera de 60 segundos para vaciado de conexiones
# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60

Para obtener una lista completa de las funciones que puedes configurar mediante un BackendConfig, consulta la sección BackendConfig de la tabla de funciones.

Ejecuta el siguiente comando para crear el BackendConfig:

kubectl apply -f my-backendconfig.yaml

Crea un Service

Un BackendConfig corresponde a una sola combinación de Service y puerto, incluso si un Service tiene varios puertos. Cada puerto se puede asociar con una sola CRD de BackendConfig. Si un Ingress hace referencia a un puerto de Service, y si el puerto de Service se asocia a un BackendConfig, el servicio de backend del balanceo de cargas de HTTP(S) toma parte de su configuración del BackendConfig.

El siguiente es un ejemplo de manifiesto de Service llamado my-service.yaml:

# my-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    purpose: bsc-config-demo
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080

La anotación cloud.google.com/backend-config especifica una asignación entre puertos y objetos BackendConfig. En my-service.yaml:

  • Cualquier Pod que tenga la etiqueta purpose: bsc-config-demo es miembro del Service.
  • El puerto TCP 80 del Service está asociado a un BackendConfig denominado my-backendconfig. Esto se especifica en la anotación cloud.google.com/backend-config.
  • Una solicitud enviada al puerto 80 del Service se reenvía a uno de los Pods miembros en el puerto 8080.

Para crear el Service, ejecuta el siguiente comando:

kubectl apply -f my-service.yaml

Crea un Ingress

El siguiente es un manifiesto de Ingress llamado my-ingress.yaml.. En este ejemplo, las solicitudes entrantes se enrutan al puerto 80 del Service denominado my-service.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: my-service
          servicePort: 80

Para crear el Ingress, ejecuta el siguiente comando:

kubectl apply -f my-ingress.yaml

Espera unos minutos hasta que el controlador de Ingress configure un balanceo de cargas de HTTP(S) y un servicio de backend asociado. Una vez que se completa, configuraste tu Ingress para usar un tiempo de espera de 40 segundos y un tiempo de espera de vaciado de conexiones de 60 segundos.

Valida las propiedades del servicio de backend

Puedes validar que se aplicó la configuración correcta del balanceador de cargas a través del BackendConfig. Para hacerlo, identifica el servicio de backend que Ingress implementó e inspecciona su configuración a fin de validar que coincida con los manifiestos de Deployment.

Primero, describe el recurso my-ingress y filtra la anotación que enumera los servicios de backend asociados con el Ingress. Por ejemplo:

kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends

Deberías ver un resultado similar al siguiente:

ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}

En el resultado, se proporciona información sobre los servicios de backend. Por ejemplo, esta anotación contiene dos servicios de backend:

  • "k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY" proporciona información sobre el servicio de backend asociado con el Service de Kubernetes my-service.
    • k8s1-27fde173 es un hash que se usa para describir el clúster.
    • default es el espacio de nombres de Kubernetes.
    • HEALTHY indica que el backend está en buen estado.
  • "k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY" proporciona información sobre el servicio de backend asociado con el backend predeterminado (404-server).
    • k8s1-27fde173 es un hash que se usa para describir el clúster.
    • kube-system es el espacio de nombres.
    • default-http-backend es el nombre del servicio de Kubernetes.
    • 80 es el puerto del host.
    • HEALTHY indica que el backend está en buen estado.

A continuación, inspecciona el servicio de backend asociado con my-service mediante gcloud. Filtra "drainingTimeoutSec" y "timeoutSec" para confirmar que se configuraron en el plano de control del balanceador de cargas de Google Cloud. Por ejemplo:

# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500

# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"

Resultado:

  drainingTimeoutSec: 60
  timeoutSec: 40

Si ves drainingTimeoutSec y timeoutSec en el resultado, esto significa que los valores se configuraron de forma correcta a través del BackendConfig.

Realiza una limpieza

Si deseas evitar que se generen cargos no deseados en tu cuenta, borra los objetos de Kubernetes que creaste para este ejercicio:

kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment

Limitaciones de BackendConfig

BackendConfig tiene las siguientes limitaciones:

  • Un par (Service, puerto) puede consumir solo un BackendConfig, incluso si varios objetos Ingress hacen referencia al (Service, puerto). Esto significa que todos los objetos Ingress que hacen referencia al mismo (Service, puerto) deben usar la misma configuración para Google Cloud Armor, IAP y Cloud CDN.

  • IAP y Cloud CDN no se pueden habilitar para el mismo servicio de backend de balanceo de cargas de HTTP(S). Esto significa que no puedes configurar IAP y Cloud CDN en la misma BackendConfig.

  • Debes usar kubectl 1.7 o posterior para interactuar con BackendConfig.

Quita la configuración especificada en un FrontendConfig o un BackendConfig

Para revocar una función de Ingress, debes inhabilitar de manera explícita la configuración de funciones en la CRD de FrontendConfig o BackendConfig. El controlador de Ingress solo concilia las opciones de configuración especificadas en estas CRD.

Para borrar o inhabilitar una configuración habilitada con anterioridad, establece el valor del campo como una string vacía ("") o un valor booleano de false, según el tipo de campo.

En el siguiente manifiesto de BackendConfig, se inhabilita una política de seguridad de Google Cloud Armor y Cloud CDN:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: false
  securityPolicy:
    name: ""

Borra un FrontendConfig o un BackendConfig

FrontendConfig

Para borrar un FrontendConfig, sigue estos pasos:

  1. Quita el nombre del FrontendConfig de la anotación networking.gke.io/v1beta1.FrontendConfig en el manifiesto de Ingress.

  2. Aplica el manifiesto de Ingress modificado a tu clúster. Por ejemplo, usa kubectl apply.

  3. Borra el FrontendConfig. Por ejemplo, usa kubectl delete frontendconfig config my-frontendconfig.

BackendConfig

Para borrar un BackedConfig, sigue estos pasos:

  1. Quita el nombre del BackendConfig de la anotación cloud.google.com/backend-config en el manifiesto de Service.

  2. Aplica el manifiesto de Service modificado tu clúster. Por ejemplo, usa kubectl apply.

  3. Borra el BackendConfig. Por ejemplo, usa kubectl delete backendconfig my-backendconfig.

Soluciona problemas

No se encontró el BackendConfig

Este error ocurre cuando un BackendConfig para un puerto de Service se especifica en la anotación de Service, pero no se pudo encontrar ese recurso BackendConfig en sí. Esto puede ocurrir si no creaste el recurso BackendConfig, lo creaste en el espacio de nombres incorrecto o escribiste mal la referencia en la anotación de Service.

Para evaluar un evento de Kubernetes, ejecuta el siguiente comando:

kubectl get event

El siguiente tipo de resultado indica que no se encontró tu BackendConfig:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists

No se encontró la política de seguridad

Después de crear el objeto Ingress, si la política de seguridad no está asociada de forma correcta al servicio de balanceador de cargas, evalúa el evento de Kubernetes para ver si hay un error de configuración. Si el BackendConfig especifica una política inexistente, se emite un evento de advertencia de forma periódica. Para solucionar este problema, asegúrate de especificar la política de seguridad correcta, por nombre, en tu BackendConfig.

Para evaluar un evento de Kubernetes, ejecuta el siguiente comando:

kubectl get event

El siguiente tipo de resultado indica que no se encontró la política de seguridad:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy "my-policy" does not exist.

Próximos pasos