Advanced ALB Ingress configurations for ACK serverless clusters - Container Service for Kubernetes

Requisitos previos

Antes de empezar, asegúrese de contar con lo siguiente:

Un ACK serverless cluster con una Virtual Private Cloud (VPC) y NAT Gateway para tener acceso a Internet.
kubectl está conectado al clúster.
Un AlbConfig is created.

Referencia rápida de anotaciones

Las funciones de ALB Ingress se configuran mediante anotaciones en el campo metadata.annotations. La siguiente tabla enumera las anotaciones compatibles por categoría.

Categoría	Anotación	Descripción
Comprobación de estado	`alb.ingress.kubernetes.io/healthcheck-enabled`	Habilitar o deshabilitar comprobaciones de estado
	`alb.ingress.kubernetes.io/healthcheck-path`	Ruta de comprobación de estado
	`alb.ingress.kubernetes.io/healthcheck-protocol`	Protocolo: `HTTP`, `HTTPS`, `TCP`, `GRPC`
	`alb.ingress.kubernetes.io/healthcheck-httpversion`	Versión HTTP: `HTTP1.0`, `HTTP1.1`
	`alb.ingress.kubernetes.io/healthcheck-method`	Método: `HEAD`, `POST`, `GET`
	`alb.ingress.kubernetes.io/healthcheck-code`	Código de estado esperado (tiene prioridad sobre `healthcheck-httpcode`)
	`alb.ingress.kubernetes.io/healthcheck-httpcode`	Código de estado HTTP esperado (clústeres anteriores a la versión 1.19)
	`alb.ingress.kubernetes.io/healthcheck-timeout-seconds`	Tiempo de espera en segundos (1–300)
	`alb.ingress.kubernetes.io/healthcheck-interval-seconds`	Intervalo de comprobación en segundos (1–50)
	`alb.ingress.kubernetes.io/healthy-threshold-count`	Éxitos consecutivos para marcar como saludable (2–10)
	`alb.ingress.kubernetes.io/unhealthy-threshold-count`	Fallos consecutivos para marcar como no saludable (2–10)
	`alb.ingress.kubernetes.io/healthcheck-connect-port`	Puerto para comprobaciones de estado (0 = puerto del backend)
TLS / HTTPS	`alb.ingress.kubernetes.io/ssl-redirect`	Redirigir el puerto HTTP 80 al puerto HTTPS 443
Protocolo del backend	`alb.ingress.kubernetes.io/backend-protocol`	Protocolo del backend: `https`, `grpc`
Coincidencia de rutas	`alb.ingress.kubernetes.io/use-regex`	Habilitar expresiones regulares en reglas de ruta
Reescritura	`alb.ingress.kubernetes.io/rewrite-target`	Reescribir la ruta de la solicitud antes de reenviarla
Puertos de escucha	`alb.ingress.kubernetes.io/listen-ports`	Puertos de escucha personalizados, por ejemplo, `[{"HTTP": 80},{"HTTPS": 443}]`
Prioridad de reenvío	`alb.ingress.kubernetes.io/order`	Prioridad de regla de reenvío (1–1000; menor valor = mayor prioridad)
Versión canary	`alb.ingress.kubernetes.io/canary`	Habilitar enrutamiento canary
	`alb.ingress.kubernetes.io/canary-by-header`	Enrutar por nombre de encabezado de solicitud
	`alb.ingress.kubernetes.io/canary-by-header-value`	Enrutar por valor exacto de encabezado
	`alb.ingress.kubernetes.io/canary-by-cookie`	Enrutar por nombre de cookie (`always` o `never`)
	`alb.ingress.kubernetes.io/canary-weight`	Porcentaje de tráfico para enrutar a canary (0–100)
Persistencia de sesión	`alb.ingress.kubernetes.io/sticky-session`	Habilitar persistencia de sesión
	`alb.ingress.kubernetes.io/sticky-session-type`	Modo de cookie: `Insert` o `Server`
	`alb.ingress.kubernetes.io/cookie-timeout`	Tiempo de espera de cookie en segundos (1–86400)
	`alb.ingress.kubernetes.io/cookie`	Nombre de cookie personalizado (obligatorio cuando el tipo es `Server`)
Algoritmo de balanceo de carga	`alb.ingress.kubernetes.io/backend-scheduler`	Algoritmo: `wrr`, `wlc`, `sch`, `uch`
	`alb.ingress.kubernetes.io/backend-scheduler-uch-value`	Nombre del parámetro URL para hash `uch`
CORS	`alb.ingress.kubernetes.io/enable-cors`	Habilitar Cross-Origin Resource Sharing (CORS)
	`alb.ingress.kubernetes.io/cors-allow-origin`	Orígenes permitidos
	`alb.ingress.kubernetes.io/cors-allow-methods`	Métodos HTTP permitidos
	`alb.ingress.kubernetes.io/cors-allow-headers`	Encabezados de solicitud permitidos
	`alb.ingress.kubernetes.io/cors-expose-headers`	Encabezados expuestos al navegador
	`alb.ingress.kubernetes.io/cors-allow-credentials`	Indica si se permiten credenciales
	`alb.ingress.kubernetes.io/cors-max-age`	Duración de caché preflight en segundos (−1–172800)
Conexiones del backend	`alb.ingress.kubernetes.io/backend-keepalive`	Habilitar conexiones persistentes al backend
Limitación de tasa	`alb.ingress.kubernetes.io/traffic-limit-qps`	Límite de QPS por regla de reenvío (1–100,000)
Inicio lento	`alb.ingress.kubernetes.io/slow-start-enabled`	Habilitar inicio lento para nuevos pods
	`alb.ingress.kubernetes.io/slow-start-duration`	Duración de rampa en segundos (30–900)
Drenado de conexiones	`alb.ingress.kubernetes.io/connection-drain-enabled`	Habilitar drenado de conexiones
	`alb.ingress.kubernetes.io/connection-drain-timeout`	Tiempo de espera de drenado en segundos (0–900)

Reenviar solicitudes según nombres de dominio

Cree un Ingress para reenviar solicitudes por nombre de dominio. ALB Ingress admite nombres de dominio estándar y vacíos.

Reenviar solicitudes según un nombre de dominio estándar

El siguiente ejemplo establece la ruta de enrutamiento en /hello. Las solicitudes a demo.domain.ingress.top/hello se reenvían al Service del backend.

Despliegue la siguiente plantilla para crear un Service, un Deployment y un Ingress. Las solicitudes se reenvían al Service a través del nombre de dominio definido en el Ingress.

Expandir para ver el YAML de ejemplo

Para clústeres de la versión 1.19 y posteriores

apiVersion: v1
kind: Service
metadata:
  name: demo-service
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: demo.domain.ingress.top
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port:
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

Para clústeres anteriores a la versión 1.19

apiVersion: v1
kind: Service
metadata:
  name: demo-service
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: demo.domain.ingress.top
      http:
        paths:
          - backend:
              serviceName: demo-service
              servicePort: 80
            path: /hello
            pathType: ImplementationSpecific

Pruebe el enrutamiento. Reemplace ADDRESS con el nombre de dominio de la instancia ALB (ejecute kubectl get ing para obtenerlo).
```
curl -H "host: demo.domain.ingress.top" <ADDRESS>/hello
```
Salida esperada:
```
{"hello":"coffee"}
```

Reenviar solicitudes según un nombre de dominio vacío

Cuando el campo host está vacío, el Ingress coincide con todas las solicitudes sin importar el dominio. El siguiente ejemplo enruta las solicitudes a <ADDRESS>/hello hacia el Service del backend.

Despliegue la siguiente plantilla para crear un Ingress.

Expandir para ver el YAML de ejemplo

Para clústeres de la versión 1.19 y posteriores

apiVersion: v1
kind: Service
metadata:
  name: demo-service
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: ""
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port:
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

Para clústeres anteriores a la versión 1.19

apiVersion: v1
kind: Service
metadata:
  name: demo-service
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: ""
      http:
        paths:
          - backend:
              serviceName: demo-service
              servicePort: 80
            path: /hello
            pathType: ImplementationSpecific

Pruebe el enrutamiento. Reemplace ADDRESS con el nombre de dominio de la instancia ALB.
```
curl <ADDRESS>/hello
```
Salida esperada:
```
{"hello":"coffee"}
```

Reenviar solicitudes según rutas URL

ALB Ingress reenvía solicitudes según rutas URL mediante el campo pathType. Se admiten tres tipos de coincidencia:

`pathType`	Comportamiento
`Prefix`	Coincide con el prefijo de ruta segmento por segmento, distingue mayúsculas y minúsculas
`Exact`	Solo coincidencia exacta
`ImplementationSpecific`	El controlador de ALB Ingress lo maneja como coincidencia exacta (Exact). Si no se establece `path`, ALB usa `/` como valor predeterminado

Importante

Si pathType se establece en Exact o Prefix, path debe ser una ruta absoluta no vacía. De lo contrario, la creación del Ingress falla con un error de validación. Cuando varias reglas de coincidencia de URL entran en conflicto, ALB las evalúa según la prioridad de regla de reenvío.

Referencia de coincidencia de rutas

Rutas simples (/, /foo, /foo/)

Tipo de coincidencia	Ruta de regla	Ruta de solicitud	¿Coincide?
Prefix	`/`	`/` (coincide con todas)	Sí
Prefix	`/foo`	`/foo`	Sí
Prefix	`/foo`	`/foo/`	Sí
Prefix	`/foo/`	`/foo`	Sí
Prefix	`/foo/`	`/foo/`	Sí
Prefix	`/aaa`	`/ccc`	No — el prefijo no coincide
Exact o ImplementationSpecific	`/foo`	`/foo`	Sí
Exact o ImplementationSpecific	`/foo`	`/bar`	No
Exact o ImplementationSpecific	`/foo`	`/foo/`	No
Exact o ImplementationSpecific	`/foo/`	`/foo`	No

Rutas jerárquicas (/aaa/bb, /aaa/bbb, /aaa/bbb/)

Tipo de coincidencia	Ruta de regla	Ruta de solicitud	¿Coincide?
Prefix	`/aaa/bb`	`/aaa/bbb`	No
Prefix	`/aaa/bbb`	`/aaa/bbb`	Sí
Prefix	`/aaa/bbb/`	`/aaa/bbb`	Sí — se ignora la barra final en la regla
Prefix	`/aaa/bbb`	`/aaa/bbb/`	Sí — coincide con la barra final en la solicitud
Prefix	`/aaa/bbb`	`/aaa/bbb/ccc`	Sí — coincide con la subruta

Múltiples rutas de regla

Tipo de coincidencia	Rutas de regla	Ruta de solicitud	¿Coincide?
Prefix	`/`, `/aaa`	`/aaa/ccc`	Sí — coincide con el prefijo `/`
Prefix	`/aaa`, `/`	`/aaa/ccc`	Sí — coincide con el prefijo `/aaa`
Prefix	`/aaa`, `/`	`/ccc`	Sí — coincide con el prefijo `/`
Prefix	`/aaa`, `/bbb`	`/ccc`	No — el prefijo no coincide

Coincidencia de prefijo (Prefix)

La coincidencia de prefijo compara segmentos de ruta separados por / y distingue mayúsculas de minúsculas. El siguiente ejemplo establece la ruta de regla en /, que coincide con todas las rutas, incluida /hello.

Despliegue la siguiente plantilla para crear un Ingress.

Expandir para ver el YAML de ejemplo

Para clústeres de la versión 1.19 y posteriores

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-path-prefix
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /
          backend:
            service:
              name: demo-service
              port:
                number: 80
          pathType: Prefix

Para clústeres anteriores a la versión 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo-path-prefix
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /
          backend:
            serviceName: demo-service
            servicePort: 80
          pathType: Prefix

Pruebe el enrutamiento. Reemplace ADDRESS con el nombre de dominio de la instancia ALB.
```
curl <ADDRESS>/hello
```
Salida esperada:
```
{"hello":"coffee"}
```

Coincidencia exacta (Exact o ImplementationSpecific)

El siguiente ejemplo establece la ruta de regla en /hello. Solo coincide exactamente con la ruta /hello.

Despliegue la siguiente plantilla para crear un Ingress.

Expandir para ver el YAML de ejemplo

Para clústeres de la versión 1.19 y posteriores

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-path
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /hello
          backend:
            service:
              name: demo-service
              port:
                number: 80
          pathType: Exact

Para clústeres anteriores a la versión 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo-path
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /hello
          backend:
            serviceName: demo-service
            servicePort: 80
          pathType: Exact

Pruebe el enrutamiento. Reemplace ADDRESS con el nombre de dominio de la instancia ALB.
```
curl <ADDRESS>/hello
```
Salida esperada:
```
{"hello":"coffee"}
```

Redirigir HTTP a HTTPS

Agregue la anotación alb.ingress.kubernetes.io/ssl-redirect: "true" para redirigir solicitudes HTTP al puerto HTTPS 443.

Importante

Esta anotación solo aplica a reglas de reenvío HTTP en el puerto de escucha 80. Esta función solo opera con las anotaciones RemoveHeader, InsertHeader y CORS entre dominios. Antes de agregar esta anotación, configure an HTTPS listener on port 443 en AlbConfig.

Clústeres que ejecutan Kubernetes 1.19 o posterior

apiVersion: v1
kind: Service
metadata:
  name: demo-service-ssl
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo-ssl
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-ssl
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-ssl
  template:
    metadata:
      labels:
        app: demo-ssl
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo-ssl
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/ssl-redirect: "true"
  name: demo-ssl
  namespace: default
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - ssl.alb.ingress.top
  rules:
    - host: ssl.alb.ingress.top
      http:
        paths:
          - backend:
              service:
                name: demo-service-ssl
                port:
                  number: 80
            path: /
            pathType: Prefix

Clústeres que ejecutan versiones de Kubernetes anteriores a la 1.19

apiVersion: v1
kind: Service
metadata:
  name: demo-service-ssl
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo-ssl
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-ssl
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-ssl
  template:
    metadata:
      labels:
        app: demo-ssl
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo-ssl
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/ssl-redirect: "true"
  name: demo-ssl
  namespace: default
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - ssl.alb.ingress.top
  rules:
    - host: ssl.alb.ingress.top
      http:
        paths:
          - backend:
              serviceName: demo-service-ssl
              servicePort: 80
            path: /
            pathType: Prefix

Configurar comprobaciones de estado

Configure las comprobaciones de estado para el grupo de servidores del backend con las siguientes anotaciones.

Expandir para ver el YAML completo de ejemplo

Agregue las siguientes anotaciones para habilitar y configurar las comprobaciones de estado del grupo de servidores del backend.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/healthcheck-enabled: "true"
    alb.ingress.kubernetes.io/healthcheck-path: "/"
    alb.ingress.kubernetes.io/healthcheck-protocol: "HTTP"
    alb.ingress.kubernetes.io/healthcheck-httpversion: "HTTP1.1"
    alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
    alb.ingress.kubernetes.io/healthcheck-code: "http_2xx"
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: "2"
    alb.ingress.kubernetes.io/healthy-threshold-count: "3"
    alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
spec:
  ...

Para clústeres de la versión 1.19 y posteriores

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/healthcheck-enabled: "true"
    alb.ingress.kubernetes.io/healthcheck-path: "/"
    alb.ingress.kubernetes.io/healthcheck-protocol: "HTTP"
    alb.ingress.kubernetes.io/healthcheck-httpversion: "HTTP1.1"
    alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
    alb.ingress.kubernetes.io/healthcheck-code: "http_2xx"
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: "2"
    alb.ingress.kubernetes.io/healthy-threshold-count: "3"
    alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: ImplementationSpecific
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

Para clústeres anteriores a la versión 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/healthcheck-enabled: "true"
    alb.ingress.kubernetes.io/healthcheck-path: "/"
    alb.ingress.kubernetes.io/healthcheck-protocol: "HTTP"
    alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
    alb.ingress.kubernetes.io/healthcheck-httpcode: "http_2xx"
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: "2"
    alb.ingress.kubernetes.io/healthy-threshold-count: "3"
    alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /tea
        backend:
          serviceName: tea-svc
          servicePort: 80
      - path: /coffee
        backend:
          serviceName: coffee-svc
          servicePort: 80

Referencia de anotaciones:

Anotación	Descripción	Valor predeterminado
`alb.ingress.kubernetes.io/healthcheck-enabled`	Habilitar comprobaciones de estado: `true` o `false`	`false`
`alb.ingress.kubernetes.io/healthcheck-path`	Ruta de comprobación de estado	`/`
`alb.ingress.kubernetes.io/healthcheck-protocol`	Protocolo: `HTTP`, `HTTPS`, `TCP` o `GRPC`. HTTP/HTTPS usan HEAD o GET; TCP usa SYN; gRPC usa POST o GET	`HTTP`
`alb.ingress.kubernetes.io/healthcheck-httpversion`	Versión HTTP: `HTTP1.0` o `HTTP1.1`. Aplica a protocolos `HTTP` y `HTTPS`	`HTTP1.1`
`alb.ingress.kubernetes.io/healthcheck-method`	Método de solicitud: `HEAD`, `POST` o `GET`. Use `POST` o `GET` cuando el protocolo sea `GRPC`	`HEAD`
`alb.ingress.kubernetes.io/healthcheck-code`	Códigos de estado esperados. Tiene prioridad sobre `healthcheck-httpcode`. Para HTTP/HTTPS: `http_2xx`, `http_3xx`, `http_4xx`, `http_5xx` (separados por comas). Para gRPC: rangos enteros en [0, 99] (hasta 20 rangos, separados por comas)	HTTP/HTTPS: `http_2xx`; gRPC: `0`
`alb.ingress.kubernetes.io/healthcheck-httpcode`	Códigos de estado esperados para clústeres anteriores a la versión 1.19. Opciones: `http_2xx`, `http_3xx`, `http_4xx`, `http_5xx` (separados por comas)	`http_2xx`
`alb.ingress.kubernetes.io/healthcheck-timeout-seconds`	Tiempo de espera en segundos. Rango: [1, 300]	`5`
`alb.ingress.kubernetes.io/healthcheck-interval-seconds`	Intervalo de comprobación en segundos. Rango: [1, 50]	`2`
`alb.ingress.kubernetes.io/healthy-threshold-count`	Éxitos consecutivos necesarios para marcar un servidor del backend como saludable. Rango: [2, 10]	`3`
`alb.ingress.kubernetes.io/unhealthy-threshold-count`	Fallos consecutivos necesarios para marcar un servidor del backend como no saludable. Rango: [2, 10]	`3`
`alb.ingress.kubernetes.io/healthcheck-connect-port`	Puerto de comprobación de estado. `0` usa el puerto del servidor del backend	`0`

Usar HTTPS y gRPC como protocolos del backend

Agregue la anotación alb.ingress.kubernetes.io/backend-protocol para usar HTTPS o gRPC como protocolo del backend.

Una vez creado un Ingress, no se puede cambiar el protocolo del backend. Para cambiar de protocolo, elimine el Ingress y cree uno nuevo.

Importante

Al reenviar tráfico gRPC a través de un Ingress, configure un certificado TLS para el nombre de dominio y utilice TLS para la comunicación.

Expandir para ver el YAML completo de ejemplo

Para clústeres de la versión 1.19 y posteriores

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-protocol: "grpc"
  name: demo-alb-ingress
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: grpc-demo-svc
            port:
              number: 9080

Para clústeres anteriores a la versión 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-protocol: "grpc"
  name: demo-alb-ingress
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
    - host: demo.alb.ingress.top
      http:
        paths:
          - backend:
              serviceName: grpc-demo-svc
              servicePort: 9080
            path: /
            pathType: Prefix

Anotación	Valores	Descripción
`alb.ingress.kubernetes.io/backend-protocol`	`https`	El Service del backend usa HTTPS
	`grpc`	El Service del backend usa gRPC. Requiere configuración TLS en el nombre de dominio

Configurar expresiones regulares

Use la anotación alb.ingress.kubernetes.io/use-regex: "true" para habilitar la coincidencia de expresiones regulares en las reglas de ruta. Esta anotación solo aplica a reglas de ruta con pathType: Prefix.

Anotación	Descripción
`alb.ingress.kubernetes.io/use-regex: "true"`	Habilita expresiones regulares en reglas de ruta
`alb.ingress.kubernetes.io/conditions.<YOUR-SVC-NAME>`	Configura condiciones de reenvío personalizadas. Reemplace `<YOUR-SVC-NAME>` con el nombre real del Service, que debe coincidir con `backend.service.name`

Reglas de coincidencia de expresiones regulares:

Objetivo	Prefijo	Ejemplo de regla	Ruta del cliente	¿Coincide?	Notas
Nombre de dominio	Comienza con `~`	`~test.example.com`	`test.EXAMPLE.com`	Sí	Los nombres de dominio admiten coincidencias sin distinción entre mayúsculas y minúsculas
Ruta	Comienza con `~`	`~/api`	`/API`	Sí	Coincidencia sin distinción entre mayúsculas y minúsculas
Ruta	Comienza con `~*`	`~*/api`	`/Api`	No	Coincidencia con distinción entre mayúsculas y minúsculas

Expandir para ver el YAML completo de ejemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/use-regex: "true"  # Enables regular expression matching
   alb.ingress.kubernetes.io/conditions.<YOUR-SVC-NAME>: | # Replace <YOUR-SVC-NAME> with the Service name — must match backend.service.name
     [{
       "type": "Path",
       "pathConfig": {
           "values": [
              "~*/pathvalue1", # ~* = case-sensitive regex; ~ = case-insensitive regex
              "/pathvalue2"    # No prefix needed for exact match
           ]
       }
      }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test-path-for-alb
        pathType: Prefix
        backend:
          service:
            name: <YOUR-SVC-NAME> # Must match the service name in the annotation above
            port:
              number: 88

Configurar reescrituras

ALB Ingress reescribe la ruta de la solicitud antes de reenviarla. Dos anotaciones controlan el comportamiento de reescritura:

alb.ingress.kubernetes.io/rewrite-target: /<path>/${number} — habilita la reescritura y establece la ruta destino. Use el formato ${number} para hacer referencia a un grupo de captura de la ruta original (hasta tres grupos: ${1}, ${2}, ${3}). pathType debe ser Prefix.
alb.ingress.kubernetes.io/use-regex — especifica si se usan expresiones regulares en la ruta. Se habilita automáticamente cuando se configura rewrite-target. Establezca en "false" para deshabilitar; tenga en cuenta que no se pueden crear rutas con caracteres especiales (%#;!()[]^,"\") cuando la expresión regular está deshabilitada.

Escenario 1: Eliminar un prefijo

La ruta path: /something(/|$)(.*) utiliza tres grupos de captura:

/something — coincide con el prefijo a eliminar
(/|$) — primer grupo: coincide con / o el final de la ruta
(.*) — segundo grupo: captura todo lo que sigue a /something/, referenciado como ${2} en el destino de reescritura

El destino de reescritura / + ${2} elimina el prefijo /something:

Ruta original	¿Coincide?	Ruta reescrita
`/something`	Sí (el segundo grupo está vacío)	`/`
`/something/`	Sí (el segundo grupo está vacío)	`/`
`/something/new`	Sí (segundo grupo: `new`)	`/new`
`/something-new/item`	No	503

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true"
    alb.ingress.kubernetes.io/rewrite-target: /${2}
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /something(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080

Escenario 2: Captura y reorganización de varios segmentos

La ruta /items/(.*)/(.*)/(.*) captura tres segmentos. El destino de reescritura /${2}?code=${3} reestructura la URL mediante el segundo y tercer grupo de captura.

Este patrón requiere exactamente cuatro segmentos de ruta. Los clientes deben usar un formato de ruta fijo.

Ruta original	¿Coincide?	Ruta reescrita
`/items/electronics/computers/554`	Sí (grupo 2: `computers`, grupo 3: `554`)	`/computers?code=554`
`/items/produce/fruits/12`	Sí (grupo 2: `fruits`, grupo 3: `12`)	`/fruits?code=12`
`/items/headphones/5`	No	503
`/drinks/41`	No	503

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true"
    alb.ingress.kubernetes.io/rewrite-target: /${2}?code=${3}
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /items/(.*)/(.*)/(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080

Escenario 3: Reescritura de varias rutas a una sola ruta

En el siguiente ejemplo, tanto /app-a como /app-b se enrutan hacia /app-c al definir dos reglas de ruta con el mismo destino de reescritura /${2} → /app-c/${2}.

Ruta original	¿Coincide?	Ruta reescrita
`/app-a/item1`	Sí (grupo 2: `item1`)	`/app-c/item1`
`/app-a/item2`	Sí (grupo 2: `item2`)	`/app-c/item2`
`/app-a` o `/app-a/`	Sí (el grupo 2 está vacío)	`/app-c/`
`/drinks/41`	No	503

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true"
    alb.ingress.kubernetes.io/rewrite-target: /app-c/${2}
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /app-a(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080
      - path: /app-b(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080

Escenario 4: Reescritura de un nombre de dominio

La anotación rewrite-target modifica únicamente la ruta. Para reescribir otras partes de la URL, como el nombre de dominio o los parámetros de consulta, utilice reglas de reenvío personalizadas

.

Verificación local de las reglas de reescritura

Utilice sed para probar las coincidencias de expresiones regulares de ruta y previsualizar los resultados reescritos antes del despliegue.

El siguiente ejemplo prueba la expresión regular de ruta /items/(.*)/(.*)/(.*) y la regla de reescritura /${2}?code=${3} del Escenario 2.

Guarde las rutas de prueba en path2.txt:

/items/electronics/computers/554
/items/produce/fruits/12
/items/headphones/5
/drinks/41

Simule la reescritura con sed. Escape / como \/ en la expresión regular de la ruta y use \2 en lugar de ${2} para los grupos de captura:

sed -E 's#\/items\/(.*)\/(.*)\/(.*)#Matched: [&]  --->  Rewritten: [/\2?code=\3]#' path2.txt

Salida esperada: las dos primeras rutas coinciden con la regla de reescritura; las dos últimas no:

Matched: [/items/electronics/computers/554]  --->  Rewritten: [/computers?code=554]
Matched: [/items/produce/fruits/12]  --->  Rewritten: [/fruits?code=12]
/items/headphones/5
/drinks/41

Configuración de puertos de listener personalizados

Utilice la anotación alb.ingress.kubernetes.io/listen-ports para exponer un Service en varios puertos, por ejemplo HTTP 80 y HTTPS 443.

Importante

ALB no crea listeners desde un Ingress. Primero cree los puertos y protocolos de listener requeridos en AlbConfig y luego asócielos con el Ingress.

Expand to view the full sample YAML

Para clústeres de la versión 1.19 y posteriores

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Para clústeres anteriores a la versión 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
  name: cafe-ingress
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
    - host: demo.alb.ingress.top
      http:
        paths:
          - backend:
              serviceName: tea-svc
              servicePort: 80
            path: /tea
            pathType: ImplementationSpecific

Anotación	Descripción
`alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'`	Configura el Service para escuchar tanto en el puerto 80 como en el puerto 443

Configuración de la prioridad de las reglas de reenvío

De forma predeterminada, ALB ordena las reglas de reenvío según el siguiente criterio:

Entre distintos Ingress: se ordenan lexicográficamente por namespace/name. Los valores menores tienen mayor prioridad. Primero se compara el namespace y luego el nombre.
Dentro del mismo Ingress: se ordenan según su posición en el campo rules. Las reglas que aparecen primero tienen mayor prioridad.
```
rules:
  - host: www.example.com   # Higher priority
    http: ...
  - host: www.test.com      # Lower priority
    http: ...
```

Para anular el orden predeterminado sin cambiar el nombre del Ingress, utilice la anotación alb.ingress.kubernetes.io/order.

Importante

Las prioridades dentro del mismo listener deben ser únicas.

Expand to view the full sample YAML

Para clústeres de la versión 1.19 y posteriores

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
   alb.ingress.kubernetes.io/order: "2"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Para clústeres anteriores a la versión 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "2"
  name: cafe-ingress
spec:
  ingressClassName: alb
  rules:
    - host: demo.alb.ingress.top
      http:
        paths:
          - backend:
              serviceName: tea-svc
              servicePort: 80
            path: /tea
            pathType: ImplementationSpecific

Anotación	Rango	Valor predeterminado	Descripción
`alb.ingress.kubernetes.io/order`	[1, 1000]	10	Prioridad de la regla de reenvío. Los valores más bajos indican mayor prioridad

Implementación de versiones canary mediante anotaciones

ALB admite versiones canary basadas en encabezados de solicitud, cookies y pesos de tráfico. Cree un Ingress canary independiente junto con el Ingress de producción.

Canary routing priority: Header > Cookie > Weight (de mayor a menor prioridad).

Importante

No elimine el Ingress de producción durante la versión canary. Una vez validada la versión canary, actualice el Service de backend en el Ingress de producción para que apunte a la nueva versión y después elimine el Ingress canary.

Consulte Implementación de versiones graduales mediante ALB Ingress.

Enrutamiento por encabezado

Utilice canary-by-header y canary-by-header-value en conjunto para dirigir al Service canary las solicitudes que coincidan con un valor de encabezado específico. Las solicitudes que no coincidan pasarán a la siguiente regla canary (cookie o peso).

Expand to view the full sample YAML

Para clústeres de la versión 1.19 y posteriores

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "1"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-by-header: "location"
    alb.ingress.kubernetes.io/canary-by-header-value: "hz"
  name: demo-canary
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-hello
                port:
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

Para clústeres anteriores a la versión 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "1"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-by-header: "location"
    alb.ingress.kubernetes.io/canary-by-header-value: "hz"
  name: demo-canary
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              serviceName: demo-service-hello
              servicePort: 80
            path: /hello
            pathType: ImplementationSpecific

Con esta configuración, las solicitudes con location: hz se dirigen al Service canary. Todas las demás solicitudes pasan a la siguiente regla canary.

Anotación	Descripción
`alb.ingress.kubernetes.io/canary-by-header`	Nombre del encabezado de solicitud que se debe evaluar
`alb.ingress.kubernetes.io/canary-by-header-value`	Valor exacto del encabezado que debe coincidir. Ambas anotaciones deben configurarse en conjunto

Enrutamiento por cookie

Utilice canary-by-cookie para enrutar solicitudes según el nombre de una cookie. Establezca el valor de la cookie en always para dirigir siempre al Service canary, o en never para excluirlo siempre.

Expand to view the full sample YAML

Para clústeres de la versión 1.19 y posteriores

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "2"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-by-cookie: "demo"
  name: demo-canary-cookie
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-hello
                port:
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

Para clústeres anteriores a la versión 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "2"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-by-cookie: "demo"
  name: demo-canary-cookie
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              serviceName: demo-service-hello
              servicePort: 80
            path: /hello
            pathType: ImplementationSpecific

Con esta configuración, las solicitudes con Cookie: demo=always se dirigen al Service canary. Las solicitudes con Cookie: demo=never omiten por completo el Service canary.

Anotación	Valores	Descripción
`alb.ingress.kubernetes.io/canary-by-cookie`	`always`	Todas las solicitudes se dirigen al Service canary
	`never`	Ninguna solicitud se dirige al Service canary

El enrutamiento canary basado en cookies solo admite always y never. No se admiten valores de cookie personalizados.

Enrutamiento por peso

Utilice canary-weight para enviar un porcentaje del tráfico al Service canary. El siguiente ejemplo dirige el 50 % del tráfico al entorno canary:

Expand to view the full sample YAML

Para clústeres de la versión 1.19 y posteriores

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "3"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-weight: "50"
  name: demo-canary-weight
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-hello
                port:
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

Para clústeres anteriores a la versión 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "3"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-weight: "50"
  name: demo-canary-weight
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              serviceName: demo-service-hello
              servicePort: 80
            path: /hello
            pathType: ImplementationSpecific

Anotación	Rango	Descripción
`alb.ingress.kubernetes.io/canary-weight`	0–100	Porcentaje de solicitudes dirigidas al Service canary

Implementación de persistencia de sesión mediante anotaciones

ALB Ingress admite persistencia de sesión basada en cookies. Agregue las siguientes anotaciones para habilitar y configurar esta función.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress-v3
  annotations:
    alb.ingress.kubernetes.io/sticky-session: "true"
    alb.ingress.kubernetes.io/sticky-session-type: "Insert"   # Use "Server" for custom cookies
    alb.ingress.kubernetes.io/cookie-timeout: "1800"
    alb.ingress.kubernetes.io/cookie: "test"
spec:
  ...

Expand to view the full sample YAML

Para clústeres de la versión 1.19 y posteriores

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress-v3
  annotations:
    alb.ingress.kubernetes.io/sticky-session: "true"
    alb.ingress.kubernetes.io/sticky-session-type: "Insert"   # Use "Server" for custom cookies
    alb.ingress.kubernetes.io/cookie-timeout: "1800"
    alb.ingress.kubernetes.io/cookie: "test"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - backend:
          service:
            name: tea-svc
            port:
              number: 80
        path: /tea2
        pathType: ImplementationSpecific
      - backend:
          service:
            name: coffee-svc
            port:
              number: 80
        path: /coffee2
        pathType: ImplementationSpecific

Para clústeres anteriores a la versión 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress-v3
  annotations:
    alb.ingress.kubernetes.io/sticky-session: "true"
    alb.ingress.kubernetes.io/sticky-session-type: "Insert"  # Use "Server" for custom cookies
    alb.ingress.kubernetes.io/cookie-timeout: "1800"
    alb.ingress.kubernetes.io/cookie: "test"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /tea2
        pathType: ImplementationSpecific
        backend:
          serviceName: tea-svc
          servicePort: 80
      - path: /coffee2
        pathType: ImplementationSpecific
        backend:
          serviceName: coffee-svc
          servicePort: 80

Anotación	Descripción	Valor predeterminado
`alb.ingress.kubernetes.io/sticky-session`	Habilita la persistencia de sesión: `true` o `false`	`false`
`alb.ingress.kubernetes.io/sticky-session-type`	Modo de gestión de cookies. `Insert`: ALB inserta una cookie `SERVERID` para dirigir las solicitudes posteriores al mismo backend. `Server`: ALB reescribe una cookie personalizada para el enrutamiento. Requiere que `StickySessionEnabled` esté establecido en `true` en el grupo de servidores. Consulte Creación de un grupo de servidores	`Insert`
`alb.ingress.kubernetes.io/cookie-timeout`	Tiempo de expiración de la cookie en segundos. Rango: [1, 86400]. Aplica cuando `sticky-session-type` es `Insert`	`1000`
`alb.ingress.kubernetes.io/cookie`	Nombre de cookie personalizado. Es obligatorio y no puede estar vacío cuando `sticky-session-type` es `Server`	`""`

Especificación de un algoritmo de balanceo de carga

Utilice la anotación alb.ingress.kubernetes.io/backend-scheduler para establecer el algoritmo de balanceo de carga de un grupo de servidores de backend.

Expand to view the full sample YAML

Para clústeres de la versión 1.19 y posteriores

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-scheduler: "uch"
    alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # Required only for uch
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Para clústeres anteriores a la versión 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-scheduler: "uch"
    alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # Required only for uch
  name: cafe-ingress
spec:
  ingressClassName: alb
  rules:
    - host: demo.alb.ingress.top
      http:
        paths:
          - backend:
              serviceName: tea-svc
              servicePort: 80
            path: /tea
            pathType: ImplementationSpecific

Valor	Algoritmo	Descripción
`wrr`	Round-robin ponderado	Los servidores de backend con pesos mayores reciben más solicitudes. Algoritmo predeterminado
`wlc`	Menor número de conexiones ponderado	Dirige la solicitud al servidor con menos conexiones activas, ponderado según el peso del servidor
`sch`	Hash consistente por IP de origen	Dirige las solicitudes de la misma IP de cliente al mismo servidor de backend
`uch`	Hash consistente por parámetro de URL	Enruta según el hash de un parámetro de URL. Defina el nombre del parámetro con `alb.ingress.kubernetes.io/backend-scheduler-uch-value`

Configuración del uso compartido de recursos de origen cruzado

Agregue anotaciones CORS para permitir que los navegadores realicen solicitudes de origen cruzado al Service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  annotations:
    alb.ingress.kubernetes.io/enable-cors: "true"
    alb.ingress.kubernetes.io/cors-expose-headers: ""
    alb.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
    alb.ingress.kubernetes.io/cors-allow-credentials: "true"
    alb.ingress.kubernetes.io/cors-max-age: "600"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: cloud-nodeport
            port:
              number: 80

Anotación	Descripción	Valor predeterminado
`alb.ingress.kubernetes.io/cors-allow-origin`	Orígenes permitidos. Deben comenzar con `http://` o `https://`, seguidos de un dominio válido o un dominio comodín de nivel superior. Separe varios orígenes con comas. Ejemplo: `"https://example.com:4443, http://aliyundoc.com, https://example.org:1199"`	`*`
`alb.ingress.kubernetes.io/cors-allow-methods`	Métodos de origen cruzado permitidos. No distingue entre mayúsculas y minúsculas. Separe varios métodos con comas. Ejemplo: `"PUT, GET, POST, OPTIONS"`	`GET, PUT, POST, DELETE, PATCH, OPTIONS`
`alb.ingress.kubernetes.io/cors-allow-headers`	Encabezados de solicitud permitidos. Los encabezados pueden contener letras, dígitos, guiones bajos (`_`) y guiones (`-`). Separe varios encabezados con comas. Ejemplo: `"X-Forwarded-For, X-app123-XPTO"`	`DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization`
`alb.ingress.kubernetes.io/cors-expose-headers`	Encabezados expuestos al navegador. Pueden contener letras, dígitos, guiones bajos (`_`), guiones (`-`) y asteriscos (``). Separe varios encabezados con comas. Ejemplo: `", X-CustomResponseHeader"`	Vacío
`alb.ingress.kubernetes.io/cors-allow-credentials`	Indica si se permiten credenciales en solicitudes de origen cruzado. Ejemplo: `"false"`	`true`
`alb.ingress.kubernetes.io/cors-max-age`	Duración máxima de caché en segundos para respuestas preflight OPTIONS. Rango: [−1, 172800]	`172800`

Habilitación de conexiones persistentes al backend

Las conexiones persistentes al backend reutilizan las conexiones TCP hacia los servidores de backend, lo que reduce la sobrecarga de abrir y cerrar conexiones por cada solicitud.

Agregue la anotación alb.ingress.kubernetes.io/backend-keepalive: "true" para habilitar esta función:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-keepalive: "true"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: cloud-nodeport
            port:
              number: 80

Configuración de límites de tasa de QPS

Agregue la anotación alb.ingress.kubernetes.io/traffic-limit-qps para establecer la limitación de QPS a nivel de regla de reenvío:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/traffic-limit-qps: "50"
spec:
  ingressClassName: alb
  rules:
   - host: demo.alb.ingress.top
     http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: ImplementationSpecific
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

Anotación	Rango	Descripción
`alb.ingress.kubernetes.io/traffic-limit-qps`	[1, 100,000]	QPS máximo para la regla de reenvío

Configuración del inicio lento para nuevos pods

El inicio lento incrementa gradualmente el tráfico hacia los nuevos pods durante un período configurado, lo que evita picos transitorios de CPU o memoria provocados por la llegada repentina de todo el tráfico a un pod frío.

Anotación	Descripción	Valor predeterminado
`alb.ingress.kubernetes.io/slow-start-enabled`	Habilita el inicio lento: `true` o `false`	`false`
`alb.ingress.kubernetes.io/slow-start-duration`	Duración del incremento progresivo en segundos. Duraciones más largas ralentizan el aumento del tráfico. Rango: [30, 900]	`30`

Expand to view the full sample YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/slow-start-enabled: "true"
    alb.ingress.kubernetes.io/slow-start-duration: "100"
  name: alb-ingress
spec:
  ingressClassName: alb
  rules:
  - host: alb.ingress.alibaba.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Configuración del drenado de conexiones

Cuando un pod entra en estado Terminating, ALB lo elimina del grupo de servidores de backend. Sin el drenado de conexiones, las solicitudes en curso sobre conexiones existentes podrían fallar.

El drenado de conexiones mantiene abiertas las conexiones activas durante un período configurado, lo que permite completar las solicitudes en curso antes de que el pod quede fuera de línea.

Importante

Antes de que finalice el tiempo de espera del drenado, ALB no garantiza que el pod permanezca en buen estado. Configure spec.terminationGracePeriodSeconds en el pod o utilice un hook preStop para controlar la disponibilidad del pod durante el estado Terminating.

Consulte Desconexión fluida del servicio mediante el drenado de conexiones de ALB.

Anotación	Descripción	Valor predeterminado
`alb.ingress.kubernetes.io/connection-drain-enabled`	Habilita el drenado de conexiones: `true` o `false`	`false`
`alb.ingress.kubernetes.io/connection-drain-timeout`	Tiempo máximo en segundos que ALB espera antes de cerrar las conexiones después de que un pod se elimina o falla una comprobación de salud. Rango: [0, 900]	`300`

Expand to view the full sample YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/connection-drain-enabled: "true"
    alb.ingress.kubernetes.io/connection-drain-timeout: "199"
  name: alb-ingress
spec:
  ingressClassName: alb
  rules:
  - host: alb.ingress.alibaba.com
    http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: