Customize ALB Ingress forwarding rules using console or annotations - Container Service for Kubernetes

ALB Ingress amplía la funcionalidad nativa de Kubernetes Ingress con reglas de reenvío personalizadas. Esto permite especificar condiciones como el encabezado de solicitud, la cadena de consulta, el método de solicitud, la cookie y la IP de origen, además de definir acciones de reenvío personalizadas como respuesta fija, redirección o duplicación de tráfico. Algunas de estas reglas se pueden configurar desde la consola.

Funcionamiento

Las reglas de reenvío personalizadas de ALB constan de condiciones y acciones de reenvío que proporcionan un control detallado del tráfico tanto para solicitudes como para respuestas:

Condición de reenvío: Se configura mediante la anotación alb.ingress.kubernetes.io/conditions.<service_name>. Esta condición se asocia a un Service de backend por nombre y se aplica a todas las rutas del Ingress que dirigen tráfico a dicho Service. Solo el tráfico que cumple la condición activa la acción correspondiente. La condición puede coincidir con tráfico en ambas direcciones: solicitud y respuesta.
Acción de reenvío: Se configura mediante la anotación alb.ingress.kubernetes.io/actions.<service_name>. Define el comportamiento específico de una instancia de ALB al procesar una solicitud o respuesta, como reenviar tráfico o emitir una redirección.
Dirección de la regla: Utilice la anotación alb.ingress.kubernetes.io/rule-direction.<service_name> para especificar si una regla de reenvío personalizada se aplica a la dirección de solicitud o de respuesta:
- Dirección de solicitud: Una solicitud del cliente se reenvía a través del ALB Ingress hacia un Service de backend.
- Dirección de respuesta: Una respuesta del Service de backend se reenvía a través del ALB Ingress de vuelta al cliente.
- Cuando se configuran una condición y una acción de reenvío para la misma dirección, la acción se activa solo para el tráfico que cumple la condición de reenvío.

Importante

Dado que la anotación alb.ingress.kubernetes.io/rule-direction.<service_name> se aplica a todas las configuraciones dentro del recurso Ingress actual, configure las reglas de reenvío para las direcciones de solicitud y respuesta en recursos Ingress separados. Para ver un ejemplo de configuración, consulte Scenario 7: Modify response headers based on ResponseHeader.

Requisitos previos

Instalar el componente

Install the ALB Ingress Controller, o asegúrese de que la versión instalada sea la v2.5.0 o posterior.

Crear un Service de ejemplo

Copie el siguiente ejemplo en un archivo llamado echoserver.yaml y ejecute kubectl apply -f echoserver.yaml para crear un Deployment y un Service de ejemplo. Este ejemplo utiliza una imagen de echoserver que devuelve las solicitudes recibidas. Puede usar esta configuración para comprobar sus reglas de reenvío personalizadas de ALB.

Importante

Las imágenes de ejemplo utilizadas en este tema son imágenes públicas. Su clúster o nodos deben tener acceso a la red pública para extraerlas:

Enable Internet access for an existing ACK cluster (recomendado): Cree una puerta de enlace NAT pública para la virtual private cloud (VPC) que aloja el clúster. Todos los recursos del clúster obtendrán acceso público.
Asigne static public IP addresses a los nodos: Los nodos con IP públicas pueden extraer imágenes públicas, pero cada nodo que ejecute cargas de trabajo debe tener asignada una IP pública.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver
  labels:
    app: echoserver
spec:
  replicas: 2
  selector:
    matchLabels:
      app: echoserver
  template:
    metadata:
      labels:
        app: echoserver
    spec:
      containers:
      - name: echoserver
        image: openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/demo:1.10.2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: echoserver
  labels:
    app: echoserver
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: echoserver

Configurar condiciones de reenvío

Importante

Después de crear un Ingress y establecer condiciones de reenvío basadas en ruta en la consola de ACK, este agrega automáticamente dos reglas de reenvío con la ruta /created-by-<ALB-ID> al Ingress para cumplir con los requisitos de formato.

Escenario 1: Reenvío por IP de origen y encabezado de solicitud

Importante

Puede especificar un máximo de cinco IP de origen para una sola regla de reenvío personalizada.

En el siguiente ejemplo, el ALB reenvía una solicitud al servicio de backend solo si la IP de origen, el encabezado de solicitud y la ruta coinciden con las condiciones especificadas.

Cree sourceip-header.yaml y copie el siguiente ejemplo en él; luego ejecute kubectl apply -f sourceip-header.yaml para crear el Ingress.

IP del cliente: Coincide con 192.168.0.0/16 o 10.0.0.0/8.
El encabezado de solicitud contiene headername:headervalue1 o headername:headervalue2.
Ruta: Utilice /echo.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/conditions.echoserver: | # The name echoserver must match the name of the backend Service configured in spec.rules.
     [{
       "type": "Header",
       "headerConfig": {
         "key": "headername",
         "values": [
           "headervalue1",
           "headervalue2"
         ]
       }
     },
     {
      "type": "SourceIp",
      "sourceIpConfig": {
        "values": [
          "192.168.0.0/16",
          "10.0.0.0/8"
         ]
       }
     }]
  name: sourceip-header-ingress
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /echo
        pathType: ImplementationSpecific
        backend:
          service:
            name: echoserver
            port:
              number: 80

Comprobar los resultados

Ejecute el siguiente comando para enviar una solicitud que incluya un encabezado personalizado. Reemplace ALB_ENDPOINT con el endpoint de su instancia de ALB.

Asegúrese de que la dirección IP del cliente esté en la lista SourceIp.

curl -H "headername:headervalue1" -s ALB_ENDPOINT/echo | grep -A 16 "Request Information"

Salida esperada:

Request Information:
	client_address=::ffff:10.0.2.93
	method=GET
	real path=/echo # The path that matches the forwarding condition.
	query=
	request_version=1.1
	request_scheme=http
	request_uri=http://alb-jyoefh22rkje******.******-**.alb.aliyuncsslbintl.com:8080/echo

Request Headers:
	accept=*/*
	headername=headervalue1 # The request header that matches the forwarding condition.
	host=alb-jyoefh22rkje******.******-**.alb.aliyuncsslbintl.com
	remoteip=140.205.***.***
	user-agent=curl/8.4.0
	x-forwarded-for=140.205.***.*** # The source IP that matches the forwarding condition.

Escenario 2: Reenvío por dominio, método y cookie

En el siguiente ejemplo, el ALB reenvía una solicitud al servicio de backend solo si el nombre de dominio, el método de solicitud, la cookie y la ruta coinciden con las condiciones especificadas.

Copie el siguiente ejemplo en host-method.yaml y ejecute kubectl apply -f host-method.yaml para crear un Ingress.

Nombre de dominio: Establezca demo.alb.ingress.top en spec.rules.
Método de solicitud: PUT o HEAD.
Cookie: Contiene cookiekey1=cookievalue1.
Ruta: Utilice /echo.

Las condiciones de reenvío por nombre de dominio admiten coincidencias con nombres de dominio comodín (como *.com ).

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/conditions.echoserver: | # The name echoserver must match the name of the backend Service configured in spec.rules.
     [{
       "type": "Cookie",
       "cookieConfig": {
         "values": [
           {
             "key":"cookiekey1",
             "value":"cookievalue1"
           }
        ]
       }
      },
      {
       "type": "Method",
       "methodConfig": {
         "values": [
           "PUT",
           "HEAD"
         ]
       }
      }]
  name: host-method-ingress
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /echo
        pathType: ImplementationSpecific
        backend:
          service:
            name: echoserver
            port:
              number: 80

Comprobar los resultados

Ejecute el siguiente comando para enviar una solicitud con un nombre de dominio, método y cookie específicos. Reemplace ALB_ENDPOINT con el endpoint de su instancia de ALB.

curl -H "Host:demo.alb.ingress.top" -X PUT -b "cookiekey1=cookievalue1" -s ALB_ENDPOINT/echo | grep -A 16 "Request Information"

Salida esperada:

Request Information:
	client_address=::ffff:10.0.3.249
	method=PUT # The request method that matches the forwarding condition.
	real path=/echo # The path that matches the forwarding condition.
	query=
	request_version=1.1
	request_scheme=http
	request_uri=http://demo.alb.ingress.top:8080/echo

Request Headers:
	accept=*/*
	cookie=cookiekey1=cookievalue1 # The cookie that matches the forwarding condition.
	host=demo.alb.ingress.top # The domain name that matches the forwarding condition.
	remoteip=140.205.***.***
	user-agent=curl/8.4.0
	x-forwarded-for=140.205.***.***

Escenario 3: Reenvío por cadena de consulta y encabezados

En el siguiente ejemplo, el ALB reenvía una solicitud al servicio de backend solo si la cadena de consulta, los encabezados de solicitud y la ruta coinciden con las condiciones especificadas.

Copie el siguiente ejemplo en un archivo querystring.yaml y ejecute kubectl apply -f querystring.yaml para crear un Ingress.

Cadena de consulta: Utilice querystringkey1=querystringvalue2.
Encabezado de solicitud: Contiene headerkey1:headervalue1 o headerkey1:headervalue2, y headerkey2:headervalue3 o headerkey2:headervalue4.
Ruta: Utilice /echo.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/conditions.echoserver: | # The name echoserver must match the name of the backend Service configured in spec.rules.
    [{
      "type": "QueryString",
      "queryStringConfig": {
        "values": [
          {
            "key":"querystringkey1",
            "value":"querystringvalue2"
          }
        ]
      }
    },
    {
      "type": "Header",
      "headerConfig": {
        "key":"headerkey1",
        "values": [
          "headervalue1",
          "headervalue2"
        ]
      }
    },
    {
      "type": "Header",
      "headerConfig": {
        "key":"headerkey2",
        "values": [
          "headervalue3",
          "headervalue4"
        ]
      }
    }]
  name: querystring-ingress
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /echo
        pathType: ImplementationSpecific
        backend:
          service:
            name: echoserver
            port:
              number: 80

Comprobar los resultados

Ejecute el siguiente comando para enviar una solicitud que incluya una cadena de consulta específica y encabezados de solicitud personalizados. Reemplace ALB_ENDPOINT con el endpoint de su instancia de ALB.

curl -H "headerkey1:headervalue1" -H "headerkey2:headervalue4" -s "ALB_ENDPOINT/echo?querystringkey1=querystringvalue2" | grep -A 16 "Request Information"

Salida esperada:

Request Information:
	client_address=::ffff:10.0.3.249
	method=GET
	real path=/echo?querystringkey1=querystringvalue2 # The path that matches the forwarding condition.
	query=querystringkey1=querystringvalue2 # The query string that matches the forwarding condition.
	request_version=1.1
	request_scheme=http
	request_uri=http://alb-jyoefh22rkje******.******-**.alb.aliyuncsslbintl.com/echo?querystringkey1=querystringvalue2

Request Headers:
	accept=*/*
	headerkey1=headervalue1 # The request header that matches the forwarding condition.
	headerkey2=headervalue4 # The request header that matches the forwarding condition.
	host=alb-jyoefh22rkje******.******-**.alb.aliyuncsslbintl.com
	remoteip=140.205.***.***
	user-agent=curl/8.4.0
	x-forwarded-for=140.205.***.***

Condiciones de reenvío

Importante

Para obtener información sobre la lógica que se aplica cuando se utilizan varias condiciones de reenvío en conjunto, consulte Can multiple forwarding conditions of the same type take effect at the same time?

Condición	Descripción
Nombre de dominio	Coincide con el nombre de dominio de la solicitud. El ALB reenvía al servicio de backend solo las solicitudes con un nombre de dominio coincidente. Las condiciones de reenvío admiten coincidencias con nombres de dominio comodín (por ejemplo, `.com`). `alb.ingress.kubernetes.io/conditions.service-name: \| # service-name must match the name of the backend Service configured in spec.rules. [{ "type": "Host", "hostConfig": { "values": [ "anno.example.com" ] } }]` `type`: El tipo de coincidencia de la condición de reenvío. `Host` indica una coincidencia por nombre de dominio. `hostConfig`: El nombre de dominio específico con el que se debe coincidir. Si se establecen varios nombres de dominio, la relación entre ellos es un OR lógico. Importante* Esto equivale al campo `spec.rules.host` en una configuración nativa de Ingress. Si configura ambos, se aplica una relación OR entre los dos nombres de dominio. No especifique el mismo valor para ambos. De lo contrario, se producirá el problema descrito en The param is duplicated.
Ruta	Coincide con la ruta de la solicitud. El ALB reenvía al servicio de backend solo las solicitudes con una ruta coincidente. `alb.ingress.kubernetes.io/conditions.service-name: \| # service-name must match the name of the backend Service configured in spec.rules. [{ "type": "Path", "pathConfig": { "values": [ "/pathvalue1", "/pathvalue2" ] } }]` `type`: El tipo de coincidencia para la condición de reenvío. `Path` indica una coincidencia con la ruta de la solicitud. `pathConfig`: La ruta específica con la que se debe coincidir. Si se establecen varias rutas, se evalúan con un OR lógico. Importante Esto tiene el mismo efecto que el campo `spec.rules.http.paths.path` en una configuración nativa de Ingress. Si se configuran ambos, las dos rutas tienen una relación OR. No especifique el mismo contenido para ambas rutas. De lo contrario, se producirá un error The param is duplicated.
Encabezado	Coincide con el encabezado de solicitud. El ALB reenvía al servicio de backend solo las solicitudes que contienen un encabezado específico. `alb.ingress.kubernetes.io/conditions.service-name: \| # service-name must match the name of the backend Service configured in spec.rules. [{ "type": "Header", "headerConfig": { "key": "headername", "values": [ "headervalue1", "headervalue2" ] } }]` `type`: El tipo de coincidencia de la condición de reenvío. `Header` indica una coincidencia con el encabezado de solicitud. `headerConfig`: Los pares clave-valor que debe contener el encabezado de solicitud. Si especifica varios valores, se evalúan mediante un OR lógico. Para ver un caso de uso y un ejemplo, consulte Scenario 1: Forward by source IP and request header.
Cadena de consulta	Coincide con la cadena de consulta. El ALB reenvía al servicio de backend solo las solicitudes que contienen una cadena de consulta específica. `alb.ingress.kubernetes.io/conditions.service-name: \| # service-name must match the name of the backend Service configured in spec.rules. [{ "type": "QueryString", "queryStringConfig": { "values": [ { "key":"querystringkey1", "value":"querystringvalue2" } ] } }]` `type`: El tipo de coincidencia de la condición de reenvío. `QueryString` indica una coincidencia con la cadena de consulta de la solicitud. `queryStringConfig`: Los pares clave-valor de la cadena de consulta. Si especifica varios pares clave-valor, la relación entre ellos es un OR lógico. La clave debe tener entre 1 y 100 caracteres de longitud. El valor debe tener entre 1 y 128 caracteres de longitud. Ambos admiten letras minúsculas, caracteres visibles y los caracteres comodín asterisco (*) y signo de interrogación (?). No se permiten espacios ni los siguientes caracteres: `#[]{}\\|<>&`. Para ver un caso de uso y un ejemplo, consulte Scenario 3: Forward by query string and headers.
Método de solicitud	Coincide con el método de solicitud. El ALB reenvía al servicio de backend solo las solicitudes que utilizan un método específico. `alb.ingress.kubernetes.io/conditions.service-name: \| # service-name must match the name of the backend Service configured in spec.rules. [{ "type": "Method", "methodConfig": { "values": [ "GET", "HEAD" ] } }]` `type`: El tipo de coincidencia para la condición de reenvío. `Method` especifica que la coincidencia se basa en el método de solicitud. `methodConfig`: El método de solicitud. Los métodos compatibles son GET, POST, PUT, DELETE, HEAD, OPTIONS y PATCH. Si establece varios métodos de solicitud, la relación entre ellos es OR. Para ver un caso de uso y un ejemplo, consulte Scenario 2: Forward by domain, method, and cookie.
Cookie	Coincide con la cookie y reenvía una solicitud al Service de backend solo si contiene la cookie correcta. `alb.ingress.kubernetes.io/conditions.service-name: \| # service-name must match the name of the backend Service configured in spec.rules. [{ "type": "Cookie", "cookieConfig": { "values": [ { "key":"cookiekey1", "value":"cookievalue2" } ] } }]` `type`: El tipo de coincidencia de la condición de reenvío. `Cookie` indica una coincidencia basada en una cookie. `cookieConfig`: Los pares clave-valor de la cookie. Si se establecen varias cookies, se evalúan con un OR lógico. La clave y el valor deben tener entre 1 y 100 caracteres de longitud, admiten letras minúsculas, caracteres visibles y los caracteres comodín asterisco (*) y signo de interrogación (?), pero no admiten espacios ni los caracteres `#[]{}\\|<>&`. Para ver casos de uso y ejemplos, consulte Scenario 2: Forwarding based on domain name, request method, and cookie.
IP de origen	Coincide con la IP de origen de una solicitud. Solo se reenvían al Service de backend las solicitudes provenientes de IP de origen de clientes que están en la lista. `alb.ingress.kubernetes.io/conditions.service-name: \| # service-name must match the name of the backend Service configured in spec.rules. [{ "type": "SourceIp", "sourceIpConfig": { "values": [ "192.168.0.0/16", "172.16.0.0/16" ] } }]` `type`: El tipo de coincidencia para la condición de reenvío. `SourceIp` indica una coincidencia basada en la IP de origen de la solicitud. `sourceIpConfig`: La dirección IP de la solicitud. Si especifica varias direcciones IP, se evalúan con un OR lógico. Para ver escenarios de uso y ejemplos, consulte Scenario 1: Forwarding based on SourceIp and request headers. Importante El número de SourceIps en una sola condición de reenvío está limitado a 5.
Encabezado de respuesta	Coincide con el encabezado de respuesta y realiza la acción de reenvío solo en las respuestas que contienen el encabezado especificado. Esta configuración debe usarse junto con la anotación `alb.ingress.kubernetes.io/rule-direction.<service-name>: Response`. `alb.ingress.kubernetes.io/conditions.service-name: \| # service-name must match the name of the backend Service configured in spec.rules. [{ "type": "ResponseHeader", "responseHeaderConfig": { "key": "responseHeader", "values": [ "headervalue1", "headervalue2" ] } }]` `type`: El tipo de coincidencia de la condición de reenvío. `ResponseHeader` indica una coincidencia con el encabezado de respuesta. `responseHeaderConfig`: Los pares clave-valor que se incluirán en el encabezado de respuesta. Si establece varios valores, se evalúan con un OR lógico. Para ver escenarios y ejemplos, consulte Scenario 7: Modify response headers based on ResponseHeader.
Código de estado de respuesta	Coincide con el código de estado de respuesta. Solo se puede acceder al servicio si se devuelve el código de estado correcto. Tenga en cuenta que esto debe usarse junto con la acción de reenvío de dirección de respuesta y la anotación de regla de reenvío de dirección de respuesta `alb.ingress.kubernetes.io/rule-direction.<service-name>: Response`. `alb.ingress.kubernetes.io/conditions.service-name: \| # service-name must match the name of the backend Service configured in spec.rules. [{ "type": "ResponseStatusCode", "responseStatusCodeConfig": { "values": [ "statuscode1", "statuscode2" ] } }]` `type`: El tipo de coincidencia de la condición de reenvío. `ResponseStatusCode` indica una coincidencia con el código de estado de respuesta. `responseStatusCodeConfig`: El código de estado de respuesta específico. Si establece varios códigos de estado de respuesta, la relación entre ellos es un OR lógico. Para ver un caso de uso y un ejemplo, consulte Scenario 8: Modify response headers based on the response status code.

Configurar acciones de reenvío

Escenario 1: Devolver una respuesta fija

Console

Inicie sesión en la ACK console. En el panel de navegación izquierdo, haga clic en Clusters.
En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Network > Ingresses.

En la página Ingresses, haga clic en Create Ingress y utilice los siguientes parámetros.

Parámetro	Valor
Gateway Type	ALB Ingress
Name	fixed-ingress
IngressClass	alb
Rules	Elimine los Mappings predeterminados.
Custom Forwarding Rules	Habilite Custom Forwarding Rules. Add Condition: Seleccione Path e introduzca /echo. Action: Seleccione Return Fixed Response. Response Status Code: 503 Response Content Type (Optional): text/plain Response Content (Optional): 503 error text Mantenga los valores predeterminados para los demás parámetros.

Cuando termine, haga clic en OK.

kubectl

El Ingress del siguiente ejemplo devuelve un código de estado HTTP 503 y 503 error text al recibir una solicitud.

Cree el archivo fixed-response.yaml con el siguiente ejemplo y ejecute kubectl apply -f fixed-response.yaml para crear un Ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: fixed-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.echoserver: | # The name echoserver must match the name of the backend Service that is configured in spec.rules.
      [{
          "type": "FixedResponse",
          "FixedResponseConfig": {
              "contentType": "text/plain",
              "httpCode": "503",
              "content": "503 error text"
          }
      }]
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /echo
        pathType: Prefix
        backend:
          service:
            name: echoserver
            port:
              name: use-annotation # The name of the service port must be set to use-annotation.

Comprobar los resultados

Reemplace ALB_ENDPOINT con el endpoint de su instancia de ALB y ejecute el siguiente comando:

curl -si ALB_ENDPOINT/echo | grep "HTTP/"

Salida esperada:

HTTP/1.1 503 Service Unavailable

Escenario 2: Redirigir solicitudes a un puerto HTTPS

Redirection

El siguiente ejemplo de Ingress utiliza un código de estado HTTP 301 para redirigir las solicitudes al puerto 443 de un nuevo nombre de dominio.

Si el nombre de dominio redirigido se resuelve al endpoint de la instancia de ALB, puede utilizar este método para redirigir el tráfico desde el puerto HTTP del ALB Ingress hacia el puerto HTTPS.

Cree un archivo redirect.yaml, copie el siguiente ejemplo en él y ejecute kubectl apply -f redirect.yaml para crear un Ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: redirect-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.echoserver: | # The name echoserver must match the name of the backend Service that is configured in spec.rules.
      [{
          "type": "Redirect",
          "RedirectConfig": {
              "host": "www.alibabacloud.com",
              "path": "/en",
              "port": "443",
              "protocol": "https",
              "query": "_p_lc=1",
              "httpCode": "301"
          }
      }]
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /echo
        pathType: Prefix
        backend:
          service:
            name: echoserver
            port:
              name: use-annotation # The name of the service port must be set to use-annotation.

Comprobar los resultados

Reemplace ALB_ENDPOINT con el endpoint de su instancia de ALB y ejecute el siguiente comando:

curl -LIs ALB_ENDPOINT/echo | grep "HTTP"

La salida esperada indica que la solicitud se redirige al nuevo nombre de dominio.

HTTP/1.1 301 Moved Permanently
Via: HTTP/1.1 SLB.208
HTTP/2 200

Redirection for multiple services

El siguiente ejemplo de Ingress redirige el tráfico para varios Services.

Cree un Service llamado echoserver2. Para obtener más información, consulte Create a sample Service.
Cree un archivo llamado multi-redirect.yaml y copie el siguiente ejemplo en él. Ejecute kubectl apply -f multi-redirect.yaml para crear un Ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: multi-redirect-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.echoserver: | # The name echoserver must match the name of the backend Service that is configured in spec.rules.
      [{
          "type": "Redirect",
          "RedirectConfig": {
              "host": "www.alibabacloud.com",
              "path": "/en",
              "port": "443",
              "protocol": "https",
              "query": "_p_lc=1",
              "httpCode": "301"
          }
      }]
    alb.ingress.kubernetes.io/actions.echoserver2: | # The name echoserver2 must match the name of the backend Service that is configured in spec.rules.
      [{
          "type": "Redirect",
          "RedirectConfig": {
              "host": "www.alibabacloud.com",
              "path": "/en",
              "port": "443",
              "protocol": "https",
              "query": "_p_lc=1",
              "httpCode": "301"
          }
      }]
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /echo
        pathType: Prefix
        backend:
          service:
            name: echoserver
            port:
              name: use-annotation # The name of the service port must be set to use-annotation.
      - path: /echo2
        pathType: Prefix
        backend:
          service:
            name: echoserver2
            port:
              name: use-annotation # The name of the service port must be set to use-annotation.

Comprobar los resultados

Reemplace ALB_ENDPOINT con el endpoint de su instancia de ALB y ejecute el siguiente comando:

curl -LIs ALB_ENDPOINT/echo | grep "HTTP" ;
curl -LIs ALB_ENDPOINT/echo2 | grep "HTTP"

La salida esperada indica que las solicitudes a ambos Services se redirigen al nuevo nombre de dominio.

HTTP/1.1 301 Moved Permanently
Via: HTTP/1.1 SLB.208
HTTP/2 200
HTTP/1.1 301 Moved Permanently
Via: HTTP/1.1 SLB.208
HTTP/2 200

Escenario 3: Insertar un encabezado de solicitud personalizado

El Ingress del siguiente ejemplo inserta source:alibaba en el encabezado de la solicitud cuando se recibe una petición.

Cree un archivo llamado insert-header.yaml con el siguiente contenido de ejemplo y ejecute kubectl apply -f insert-header.yaml para crear un Ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: insert-header-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.echoserver: | # The name echoserver must match the name of the backend Service that is configured in spec.rules.
      [{
          "type": "InsertHeader",
          "InsertHeaderConfig": {
              "key": "source",
              "value": "alibaba",
              "valueType": "UserDefined"
          }
      }]
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /echo
        pathType: Prefix
        backend:
          service:
            name: echoserver
            port:
              number: 80

Comprobar los resultados

Reemplace ALB_ENDPOINT con el endpoint de su instancia de ALB y ejecute el siguiente comando:

curl -s ALB_ENDPOINT/echo | grep -A 6 "Request Headers"

Salida esperada:

Request Headers:
	accept=*/*
	host=alb-jyoefh22rkjeerxmcg.us-west-1.alb.aliyuncsslbintl.com
	remoteip=140.205.***.***
	source=alibaba # Custom request header
	user-agent=curl/8.4.0
	x-forwarded-for=140.205.***.***

Escenario 4: Duplicar tráfico a un grupo de servidores

La duplicación de tráfico permite que un ALB Ingress copie las solicitudes entrantes y las envíe a otro grupo de servidores.

Inicie sesión en la Application Load Balancer (ALB) console. En el panel de navegación izquierdo, seleccione ALB > Server Group. En la página Server Group, obtenga el ID del grupo de servidores.

Cree un archivo traffic-mirror.yaml con el siguiente ejemplo y ejecute el comando kubectl apply -f traffic-mirror.yaml para crear un Ingress.

El siguiente ejemplo de Ingress duplica las solicitudes entrantes hacia el grupo de servidores sgp-2auud2fxj1r46***** .

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: traffic-mirror-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.echoserver: | # The name echoserver must match the name of the backend Service that is configured in spec.rules.
       [{
           "type": "TrafficMirror",
           "TrafficMirrorConfig": {
              "TargetType" : "ForwardGroupMirror",
              "MirrorGroupConfig": {
                  "ServerGroupTuples" : [{
                      "ServerGroupID": "sgp-2auud2fxj1r46*****"
                  }]
              }
           }
       }]
spec:
  ingressClassName: alb
  rules:
  - host: demo.domain.ingress.top
    http:
      paths:
      - path: /echo
        pathType: Prefix
        backend:
          service:
            name: echoserver
            port:
              number: 80

Escenario 5: Reenviar a varios servicios de backend

Cuando un ALB Ingress recibe una solicitud, la reenvía a varios Services de backend según pesos personalizados.

Cree un Service llamado echoserver2. Para obtener más información, consulte Create a sample Service.

Cree un recurso de Ingress.

Console

Inicie sesión en la ACK console. En el panel de navegación izquierdo, haga clic en Clusters.
En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Network > Ingresses.

En la página Ingresses, haga clic en Create Ingress y utilice los siguientes parámetros.

Parámetro	Valor
Gateway Type	ALB Ingress
Name	forward-ingress
IngressClass	alb
Rules	Elimine los Mappings predeterminados.
Custom forwarding rule	Habilite Custom Forwarding Rules. Add Condition: Domain Name: demo.alb.ingress.top Path: /echo Action: Seleccione Forward To. Service: echoserver Port: 80 Service: echoserver2 Port: 80 Mantenga los valores predeterminados para los demás parámetros.

Cuando termine, haga clic en OK.

kubectl

Cree un archivo forward.yaml con el siguiente ejemplo y ejecute kubectl apply -f forward.yaml para crear un Ingress.

El siguiente ejemplo de Ingress reenvía las solicitudes entrantes a los Services echoserver y echoserver2 con una proporción de peso de 80:20.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: forward-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.echoserver: | # The name echoserver must match the name of the backend Service that is configured in spec.rules.
       [{
           "type": "ForwardGroup",
           "ForwardConfig": {
             "ServerGroups" : [{
               "ServiceName": "echoserver",
               "Weight": 80,
               "ServicePort": 80
             },
             {
               "ServiceName": "echoserver2",
               "Weight": 20,
               "ServicePort": 80
             }]
           }
       }]
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /echo
        pathType: Prefix
        backend:
          service:
            name: echoserver
            port:
              name: use-annotation # This must be set to use-annotation.

Escenario 6: Reescribir configuraciones de solicitud

ALB Ingress le permite usar reglas de reenvío personalizadas para modificar el nombre de dominio, la ruta y los parámetros de consulta de una solicitud. A diferencia de rewrite-target annotation, esto le permite modificar el nombre de dominio. Esta función es útil para simplificar URL, realizar reescrituras transparentes para el cliente y ocultar detalles de implementación del backend.

Copie el siguiente ejemplo en un archivo llamado rewrite.yaml y ejecute el comando kubectl apply -f rewrite.yaml para crear un Ingress.

En el siguiente ejemplo, la URL del cliente https://example.com/api/echo se reescribe como https://example.org/echo .

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.echoserver: | # The name echoserver must match the name of the backend Service that is configured in spec.rules.
       [{
           "type": "Rewrite",
           "RewriteConfig": {
               "host": "example.org", 
               "path": "/echo", 
               "query": "${query}"
           }
       }]
spec:
  ingressClassName: alb
  rules:
  - host: example.com
    http:
      paths:
      - path: /api/echo
        pathType: ImplementationSpecific
        backend:
          service:
            name: echoserver
            port: 
              number: 80

Comprobar los resultados

Reemplace ALB_ENDPOINT con el endpoint de su instancia de ALB y ejecute el siguiente comando:

curl -H "Host:example.com" -s "ALB_ENDPOINT/api/echo?querystring=request" | grep -A 7 "Request Information"

Salida esperada:

Request Information:
	client_address=::ffff:10.0.2.93
	method=GET
	real path=/echo?querystring=request
	query=querystring=request
	request_version=1.1
	request_scheme=http
	request_uri=http://example.org:8080/echo?querystring=request # The domain name and path are rewritten.

Escenario 7: Modificar encabezados de respuesta según ResponseHeader

El Ingress del siguiente ejemplo modifica el encabezado de respuesta. Cuando el encabezado de respuesta contiene Content-Type: text/plain, el Ingress inserta source: alibaba en dicho encabezado.

Cree un archivo llamado response-header.yaml con el siguiente ejemplo y ejecute kubectl apply -f response-header.yaml para crear un Ingress.

Importante

Al crear una regla de reenvío para la dirección de respuesta, debe establecer la anotación alb.ingress.kubernetes.io/rule-direction.<service-name> en Response. El valor predeterminado de esta anotación es Request.
Una regla de reenvío solo para la dirección de respuesta no puede gestionar el reenvío de solicitudes. El siguiente ejemplo también configura un Ingress independiente para la dirección de solicitud.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: response-header-ingress
  annotations:
    alb.ingress.kubernetes.io/rule-direction.echoserver: Response # For response-direction rules, this must be set to Response.
    alb.ingress.kubernetes.io/conditions.echoserver: | # Used with a forwarding condition for the response direction. A custom response header is inserted only for responses that meet the forwarding condition.
     [{
         "type": "ResponseHeader",
         "responseHeaderConfig": {
            "key": "Content-Type",
            "values": [
               "text/plain"
            ]
         }
     }]
    alb.ingress.kubernetes.io/actions.echoserver: | # Inserts a custom response header.
     [{
         "type": "InsertHeader",
         "InsertHeaderConfig": {
             "key": "source",
             "value": "alibaba",
             "valueType": "UserDefined"
         }
     }]
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /echo
        pathType: ImplementationSpecific
        backend:
          service:
            name: echoserver
            port:
              name: use-annotation # This must be set to use-annotation.

---
# Ingress for the request direction
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: request-ingress
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /echo
        pathType: ImplementationSpecific
        backend:
          service:
            name: echoserver
            port:
              number: 80

Comprobar los resultados

Reemplace ALB_ENDPOINT con el endpoint de su instancia de ALB y ejecute el siguiente comando:

curl -sI ALB_ENDPOINT/echo | grep "source"

Salida esperada:

source: alibaba

Escenario 8: Modificar encabezados de respuesta por código de estado

El Ingress del siguiente ejemplo modifica el encabezado de respuesta eliminando Content-Type cuando el código de estado de la respuesta es 200 o 300.

Cree un archivo response-code.yaml, copie el siguiente ejemplo en él y ejecute kubectl apply -f response-code.yaml para crear un Ingress.

Importante

Al crear una regla de reenvío para la dirección de respuesta, debe establecer la anotación alb.ingress.kubernetes.io/rule-direction.<service-name> en Response (esta anotación se establece en Request de forma predeterminada).
Una regla de reenvío solo para la dirección de respuesta no puede gestionar el reenvío de solicitudes. El siguiente ejemplo también configura un Ingress independiente para la dirección de solicitud.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/rule-direction.echoserver: Response # For response-direction rules, this must be set to Response.
    alb.ingress.kubernetes.io/conditions.echoserver: | # Used with a forwarding condition for the response direction. The response header is removed only for responses that meet the forwarding condition.
     [{
       "type": "ResponseStatusCode",
       "responseStatusCodeConfig": {
         "values": [
             "200",
             "300"
         ]
       }
     }]
    alb.ingress.kubernetes.io/actions.echoserver: | # Removes a response header.
     [{
         "type": "RemoveHeader",
         "RemoveHeaderConfig": {
             "key": "Content-Type"
         }
     }]
  name: response-code-ingress
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /echo
        pathType: ImplementationSpecific
        backend:
          service:
            name: echoserver
            port:
              name: use-annotation # This must be set to use-annotation.
              
---
# Ingress for the request direction
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: request-ingress
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /echo
        pathType: ImplementationSpecific
        backend:
          service:
            name: echoserver
            port:
              number: 80

Comprobar los resultados

Reemplace ALB_ENDPOINT con el endpoint de su instancia de ALB y ejecute el siguiente comando:

curl -sI ALB_ENDPOINT/echo

Salida esperada:

HTTP/1.1 200 OK
Date: Thu, 29 Jan 2026 09:46:20 GMT
Connection: keep-alive
Vary: Accept-Encoding
# The Content-Type: text/plain header is removed.

Referencia de acciones de reenvío

Dirección de la solicitud

Acción de reenvío	Descripción
Respuesta fija	Devuelve una respuesta con contenido fijo al cliente. `alb.ingress.kubernetes.io/actions.service-name: \| # The service-name must match the name of the backend Service that is configured in spec.rules. [{ "type": "FixedResponse", "FixedResponseConfig": { "contentType": "text/plain", "httpCode": "503", "content": "503 error text" } }]` `type`: El tipo de acción de reenvío. `FixedResponse` indica una respuesta fija. `contentType`: El tipo de contenido del cuerpo de la respuesta. `httpCode`: El código de estado de la respuesta. Los valores compatibles son cadenas numéricas en formato `2XX`, `4XX` o `5XX`. `content`: El cuerpo de la respuesta. Importante `backend.service.port.name` debe establecerse en `use-annotation`. Para consultar un caso de uso, consulte Scenario 1: Return a fixed response.
Redirección	Redirige a los clientes a otra URL mediante un código de estado HTTP 3xx. `alb.ingress.kubernetes.io/actions.service-name: \| # The service-name must match the name of the backend Service that is configured in spec.rules. [{ "type": "Redirect", "RedirectConfig": { "host": "${host}", "path": "/test", "port": "443", "protocol": "https", "query": "querystring", "httpCode": "301" } }]` `type`: El tipo de acción de reenvío. El valor `Redirect` especifica una redirección. `host`: El nombre de dominio de destino. `path`: La ruta de destino. `port`: El puerto de destino. `protocol`: El protocolo para la redirección. `query`: La cadena de consulta para la redirección. `httpCode`: El código de estado de la redirección. Valores válidos: `301`, `302`, `303`, `307` o `308`. Importante `host`, `path`, `port`, `protocol` y `query` son parámetros especiales. Puede configurarlos para usar los valores de la solicitud original, pero como mínimo uno de ellos debe tener un valor distinto al predeterminado. Por ejemplo, en el caso del parámetro `host`, establecerlo en `${host}`, dejarlo vacío (como `"host": ""`) u omitirlo indica que se usará el valor de la solicitud original. `backend.service.port.name` debe establecerse en `use-annotation`. Para consultar un caso de uso, consulte Scenario 2: Redirect requests to an HTTPS port.
Duplicación de tráfico	Duplica las solicitudes hacia un grupo de servidores al especificar el ID del grupo de servidores. `alb.ingress.kubernetes.io/actions.service-name: \| # The service-name must match the name of the backend Service that is configured in spec.rules. [{ "type": "TrafficMirror", "TrafficMirrorConfig": { "TargetType" : "ForwardGroupMirror", "MirrorGroupConfig": { "ServerGroupTuples" : [{ "ServerGroupID": "sgp-2auud2fxj1r46***" }] } } }]` `type`: El tipo de acción de reenvío. `TrafficMirror` especifica que la función de duplicación de tráfico está configurada. `TargetType`: El tipo de destino para la duplicación. Actualmente, el único tipo compatible es `ForwardGroupMirror`, que duplica las solicitudes hacia un grupo de servidores. `ServerGroupID`: El ID del grupo de servidores de duplicación de tráfico. Importante** La acción de duplicación de tráfico puede combinarse con reenvío, inserción de encabezado de solicitud, eliminación de encabezado de solicitud y limitación de QPS. No es compatible con reescritura, respuesta fija ni redirección. Los grupos de servidores de duplicación de tráfico solo pueden asociarse mediante `ServerGroupID`. Para consultar un caso de uso, consulte Scenario 4: Mirror traffic to a server group.
Reenvío a varios grupos de servidores backend	Puede agregar varios grupos de servidores a un backend de ALB y establecer sus pesos para controlar la proporción de distribución del tráfico. Para agregar un grupo de servidores, especifique su `ServerGroupID`; también puede crear y agregar uno nuevo si especifica `ServiceName+ServicePort`. alb.ingress.kubernetes.io/actions.service-name: \| # The service-name must match the name of the backend Service that is configured in spec.rules. [{ "type": "ForwardGroup", "ForwardConfig": { "ServerGroups" : [{ "ServiceName": "tea-svc", "Weight": 30, "ServicePort": 80 }, { "ServiceName": "coffee-svc", "Weight": 20, "ServicePort": 80 }, { "ServerGroupID": "sgp-71aexb9y93ypo***", "Weight": 20 }, { "ServerGroupID": "sgp-slygpbvm2cydo*", "Weight": 30 }], "ServerGroupStickySession": { "Enabled": true, "Timeout": 80 } } }] `type`: El tipo de acción de reenvío. `ForwardGroup` especifica que las solicitudes se reenvían a varios grupos de servidores backend. `ForwardConfig`: Los parámetros específicos para los grupos de servidores de reenvío backend. Si hay varios grupos de servidores configurados, las solicitudes se distribuyen entre ellos según sus pesos. `ServerGroupID`: El ID del grupo de servidores. `ServiceName`: El nombre del servicio. `ServicePort`: El puerto del servicio. `Weight`: El peso para reenviar solicitudes a un grupo de servidores. El rango de valores es [1, 100]. `Enabled`: Especifica si se habilita la persistencia de sesiones entre grupos de servidores. `Timeout`: El tiempo de espera de persistencia de sesiones para el grupo de servidores, en segundos. Rango de valores: [1, 86400]. Importante** Una instancia de ALB estándar puede asociarse a un máximo de cinco grupos de servidores o Services. Si asocia un grupo de servidores mediante `ServerGroupID` y `ServiceName+ServicePort` al mismo tiempo, `ServerGroupID` tiene mayor prioridad. Al habilitar la persistencia de sesiones entre grupos de servidores, ALB Ingress reenvía las solicitudes de la misma sesión al mismo backend. `backend.service.port.name` debe establecerse en `use-annotation`. Es posible habilitar la persistencia de sesiones entre grupos de servidores. Asegúrese de que esta opción esté activada en todos los grupos de servidores asociados. Para consultar un caso de uso, consulte Scenario 5: Forward to multiple backend services.
Reescritura	Esta acción reescribe el nombre de dominio, la ruta y la cadena de consulta de una solicitud entrante antes de reenviarla al Service backend. `alb.ingress.kubernetes.io/actions.service-name: \| # The service-name must match the name of the backend Service that is configured in spec.rules. [{ "type": "Rewrite", "RewriteConfig": { "host": "demo.domain.ingress.top", "path": "/test", "query": "querystring" } }]` `type`: El tipo de acción de reenvío. Establezca este parámetro en `Rewrite` para habilitar la reescritura. `host`: El nombre de dominio que usa la solicitud después de la reescritura. `path`: La ruta que usa la solicitud después de la reescritura. `query`: La cadena de consulta de la solicitud reescrita. Importante La acción de reenvío de reescritura y la anotación `rewrite-target` son mutuamente excluyentes. La acción de reescritura no puede usarse junto con las acciones de respuesta fija o redirección. `host`, `path` y `query` son parámetros especiales que pueden configurarse para usar sus valores de la solicitud original, pero como mínimo uno de ellos debe tener un valor distinto al predeterminado. Por ejemplo, establecer el parámetro `host` en `${host}`, dejarlo vacío (`"host": ""`) u omitirlo por completo indica que se usará el valor de la solicitud original. Para consultar un caso de uso, consulte Scenario 6: Rewrite request configurations.
Insertar encabezado de solicitud	Inserta un encabezado en la solicitud. Si ya existe un encabezado con el mismo nombre, se sobrescribe su valor. `alb.ingress.kubernetes.io/actions.service-name: \| # The service-name must match the name of the backend Service that is configured in spec.rules. [{ "type": "InsertHeader", "InsertHeaderConfig": { "key": "key", "value": "value", "valueType": "UserDefined" } }]` `type`: El tipo de acción de reenvío. `InsertHeader` especifica que se inserta un encabezado de solicitud. `key`: El nombre del campo de encabezado que se va a insertar. `value`: El contenido del campo de encabezado que se va a insertar. `valueType`: El tipo de contenido del campo de encabezado. Para consultar un caso de uso, consulte Scenario 3: Insert a custom request header.
Eliminar encabezado de solicitud	Elimina un encabezado de solicitud. `alb.ingress.kubernetes.io/actions.service-name: \| # The service-name must match the name of the backend Service that is configured in spec.rules. [{ "type": "RemoveHeader", "RemoveHeaderConfig": { "key": "key" } }]` `type`: El tipo de acción de reenvío. Establezca el valor en `RemoveHeader` para eliminar un encabezado de solicitud. `key`: El nombre del campo de encabezado que se va a eliminar.
Limitación de QPS	Configura un límite general de tasa de solicitudes y un límite basado en la IP de origen de cada cliente. `annotations: alb.ingress.kubernetes.io/actions.service-name: \| # The service-name must match the name of the backend Service that is configured in spec.rules. [{ "type": "TrafficLimit", "TrafficLimitConfig": { "QPS": "1000", "QPSPerIp": "100" } }]` `type`: El tipo de acción de reenvío. El valor `TrafficLimit` especifica una configuración de limitación de QPS. `QPS`: El límite general de tasa de solicitudes, es decir, el número de solicitudes que pueden procesarse por segundo. El rango de valores es [1, 1,000,000]. Cuando la tasa supera el límite configurado, se rechazan las nuevas solicitudes de conexión excedentes y el cliente recibe un código de estado HTTP 503. `QPSPerIp`: Especifica el límite de tasa de solicitudes según la dirección IP de origen de cada cliente. El rango válido es [1, 1000000]. Si se establecen tanto `QPS` (limitación global) como `QPSPerIp` (limitación por IP), el valor de `QPSPerIp` debe ser menor que el de `QPS`. Cuando la tasa supera el límite establecido, se rechazan las solicitudes excedentes y el cliente recibe un código de estado HTTP 503. Importante La acción de limitación de QPS debe usarse junto con el reenvío a un grupo de servidores. Cuando el encabezado de solicitud X-Forwarded-For contiene varias direcciones IP, como `X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, ...`, la dirección más a la izquierda corresponde a la IP real del cliente. Para aplicar la limitación de QPS basada en la IP de origen del cliente, debe habilitar la función de recuperación de la IP real del cliente en la configuración del listener. Esto permite que la instancia de ALB obtenga la IP real desde el campo de encabezado X-Forwarded-For. Para obtener más información, consulte XForwardedForConfig.

Dirección de la respuesta

Acción de reenvío

Descripción

Insertar encabezado de respuesta

Inserta un encabezado en la respuesta. Si ya existe un encabezado con el mismo nombre, se sobrescribe su valor.

alb.ingress.kubernetes.io/rule-direction.service-name: Response # For response-direction rules, this must be set to Response.
alb.ingress.kubernetes.io/actions.service-name: | # The service-name must match the name of the backend Service that is configured in spec.rules.
  [{
      "type": "InsertHeader",
      "InsertHeaderConfig": {
          "key": "key",
          "value": "value",
          "valueType": "UserDefined"
      }
  }]

type: El tipo de acción de reenvío. InsertHeader especifica que se inserta un encabezado de respuesta.
key: El nombre del campo de encabezado que se va a insertar.
value: El contenido del campo de encabezado que se va a insertar.
valueType: El tipo de contenido del campo de encabezado.

Para consultar casos de uso sobre cómo modificar encabezados de respuesta, consulte Scenario 7: Modify response headers based on ResponseHeader y Scenario 8: Modify response headers by status code.

Eliminar encabezado de respuesta

Elimina un encabezado de respuesta.

alb.ingress.kubernetes.io/rule-direction.service-name: Response # For response-direction rules, this must be set to Response.
alb.ingress.kubernetes.io/actions.service-name: | # The service-name must match the name of the backend Service that is configured in spec.rules.
     [{
         "type": "RemoveHeader",
         "RemoveHeaderConfig": {
             "key": "key"
         }
     }]

type: El tipo de acción de reenvío. Establézcalo en RemoveHeader para eliminar un encabezado de respuesta.

key: El nombre del campo de encabezado que se va a eliminar.

Cuotas y límites

Una regla de reenvío para un servicio admite hasta 10 condiciones de reenvío, incluido el nombre de dominio y la ruta especificados en spec.rules.
Cada regla de reenvío admite una acción terminal —como redirección, respuesta fija o reenvío a varios grupos de servidores— que puede combinarse con una acción de limitación de tasa.
Al configurar redirecciones, respuestas fijas o reenvíos a varios grupos de servidores, backend.service.port.name debe establecerse en use-annotation.

Preguntas frecuentes

Funcionamiento de condiciones de reenvío del mismo tipo

Los distintos bloques de reglas de enrutamiento usan una operación lógica AND, mientras que los valores dentro del mismo bloque usan una operación lógica OR. Por ejemplo:

Dos bloques de reglas Header diferentes usan una operación lógica AND. La solicitud se reenvía solo si el encabezado coincide tanto con headervalue1 como con headervalue2.


alb.ingress.kubernetes.io/conditions.service-name: |
  [{
    "type": "Header",
    "headerConfig": {
      "key": "headername",
      "values": [
        "headervalue1"
      ]
     }
  },
  {
    "type": "Header",
    "headerConfig": {
      "key": "headername",
      "values": [
        "headervalue2"
      ]
     }
  }]

Los valores dentro del mismo bloque de reglas Header usan una operación lógica OR. Basta con que el encabezado coincida con headervalue1 o con headervalue2.


alb.ingress.kubernetes.io/conditions.service-name: |
  [{
    "type": "Header",
    "headerConfig": {
      "key": "headername",
      "values": [
        "headervalue1",
        "headervalue2"
      ]
     }
  }]

¿Por qué aparece el error `The param of Rules.1.RuleConditions.2.HostConfig.Values.2 is duplicated`?

Si configura una condición Host en las condiciones de reenvío y también especifica el mismo nombre de dominio en el campo host de spec.rules, la configuración del Ingress fallará. Configure el nombre de dominio en solo uno de estos lugares.

Funcionamiento

Requisitos previos

Instalar el componente

Crear un Service de ejemplo

Configurar condiciones de reenvío

Escenario 1: Reenvío por IP de origen y encabezado de solicitud

Comprobar los resultados

Escenario 2: Reenvío por dominio, método y cookie

Comprobar los resultados

Escenario 3: Reenvío por cadena de consulta y encabezados

Comprobar los resultados

Condiciones de reenvío

Configurar acciones de reenvío

Escenario 1: Devolver una respuesta fija

Console

kubectl

Comprobar los resultados

Escenario 2: Redirigir solicitudes a un puerto HTTPS

Redirection

Comprobar los resultados

Redirection for multiple services

Comprobar los resultados

Escenario 3: Insertar un encabezado de solicitud personalizado

Comprobar los resultados

Escenario 4: Duplicar tráfico a un grupo de servidores

Escenario 5: Reenviar a varios servicios de backend

Console

kubectl

Escenario 6: Reescribir configuraciones de solicitud

Comprobar los resultados

Escenario 7: Modificar encabezados de respuesta según ResponseHeader

Comprobar los resultados

Escenario 8: Modificar encabezados de respuesta por código de estado

Comprobar los resultados

Referencia de acciones de reenvío

Dirección de la solicitud

Dirección de la respuesta

Cuotas y límites

Preguntas frecuentes

Funcionamiento de condiciones de reenvío del mismo tipo

¿Por qué aparece el error The param of Rules.1.RuleConditions.2.HostConfig.Values.2 is duplicated?

¿Por qué aparece el error `The param of Rules.1.RuleConditions.2.HostConfig.Values.2 is duplicated`?