Advanced ALB Ingress configurations for ACK serverless clusters - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Pré-requisitos

Antes de começar, verifique se você tem:

Um cluster ACK serverless com uma Virtual Private Cloud (VPC) e um NAT Gateway para acesso à internet.
O kubectl conectado ao cluster.
Um AlbConfig criado.

Referência rápida de anotações

Os recursos do ALB Ingress são configurados por meio de anotações no campo metadata.annotations. A tabela a seguir lista as anotações compatíveis por categoria.

Categoria	Anotação	Descrição
Verificação de integridade	`alb.ingress.kubernetes.io/healthcheck-enabled`	Ativa ou desativa verificações de integridade
	`alb.ingress.kubernetes.io/healthcheck-path`	Caminho da verificação de integridade
	`alb.ingress.kubernetes.io/healthcheck-protocol`	Protocolo: `HTTP`, `HTTPS`, `TCP`, `GRPC`
	`alb.ingress.kubernetes.io/healthcheck-httpversion`	Versão do 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 status esperado (tem precedência sobre `healthcheck-httpcode`)
	`alb.ingress.kubernetes.io/healthcheck-httpcode`	Código de status HTTP esperado (clusters anteriores à versão 1.19)
	`alb.ingress.kubernetes.io/healthcheck-timeout-seconds`	Tempo limite em segundos (1–300)
	`alb.ingress.kubernetes.io/healthcheck-interval-seconds`	Intervalo de verificação em segundos (1–50)
	`alb.ingress.kubernetes.io/healthy-threshold-count`	Sucessos consecutivos para marcar como íntegro (2–10)
	`alb.ingress.kubernetes.io/unhealthy-threshold-count`	Falhas consecutivas para marcar como não íntegro (2–10)
	`alb.ingress.kubernetes.io/healthcheck-connect-port`	Porta para verificações de integridade (0 = porta do backend)
TLS / HTTPS	`alb.ingress.kubernetes.io/ssl-redirect`	Redireciona a porta HTTP 80 para a porta HTTPS 443
Protocolo do backend	`alb.ingress.kubernetes.io/backend-protocol`	Protocolo do backend: `https`, `grpc`
Correspondência de caminho	`alb.ingress.kubernetes.io/use-regex`	Habilita expressões regulares nas regras de caminho
Reescrita	`alb.ingress.kubernetes.io/rewrite-target`	Reescreve o caminho da requisição antes do encaminhamento
Portas de listener	`alb.ingress.kubernetes.io/listen-ports`	Portas de listener personalizadas, ex.: `[{"HTTP": 80},{"HTTPS": 443}]`
Prioridade de encaminhamento	`alb.ingress.kubernetes.io/order`	Prioridade da regra de encaminhamento (1–1000; menor valor = maior prioridade)
Lançamento canário	`alb.ingress.kubernetes.io/canary`	Habilita roteamento canário
	`alb.ingress.kubernetes.io/canary-by-header`	Roteia pelo nome do cabeçalho da requisição
	`alb.ingress.kubernetes.io/canary-by-header-value`	Roteia pelo valor exato do cabeçalho
	`alb.ingress.kubernetes.io/canary-by-cookie`	Roteia pelo nome do cookie (`always` ou `never`)
	`alb.ingress.kubernetes.io/canary-weight`	Porcentagem de tráfego a ser roteada para o canário (0–100)
Persistência de sessão	`alb.ingress.kubernetes.io/sticky-session`	Habilita persistência de sessão
	`alb.ingress.kubernetes.io/sticky-session-type`	Modo de cookie: `Insert` ou `Server`
	`alb.ingress.kubernetes.io/cookie-timeout`	Tempo limite do cookie em segundos (1–86400)
	`alb.ingress.kubernetes.io/cookie`	Nome personalizado do cookie (obrigatório quando o tipo é `Server`)
Algoritmo de balanceamento de carga	`alb.ingress.kubernetes.io/backend-scheduler`	Algoritmo: `wrr`, `wlc`, `sch`, `uch`
	`alb.ingress.kubernetes.io/backend-scheduler-uch-value`	Nome do parâmetro de URL para hash `uch`
CORS	`alb.ingress.kubernetes.io/enable-cors`	Habilita Cross-Origin Resource Sharing (CORS)
	`alb.ingress.kubernetes.io/cors-allow-origin`	Origens permitidas
	`alb.ingress.kubernetes.io/cors-allow-methods`	Métodos HTTP permitidos
	`alb.ingress.kubernetes.io/cors-allow-headers`	Cabeçalhos de requisição permitidos
	`alb.ingress.kubernetes.io/cors-expose-headers`	Cabeçalhos expostos ao navegador
	`alb.ingress.kubernetes.io/cors-allow-credentials`	Permite credenciais
	`alb.ingress.kubernetes.io/cors-max-age`	Duração do cache de preflight em segundos (−1–172800)
Conexões de backend	`alb.ingress.kubernetes.io/backend-keepalive`	Habilita conexões persistentes com o backend
Limitação de taxa	`alb.ingress.kubernetes.io/traffic-limit-qps`	Limite de QPS por regra de encaminhamento (1–100.000)
Inicialização lenta	`alb.ingress.kubernetes.io/slow-start-enabled`	Habilita inicialização lenta para novos pods
	`alb.ingress.kubernetes.io/slow-start-duration`	Duração da rampa de subida em segundos (30–900)
Drenagem de conexão	`alb.ingress.kubernetes.io/connection-drain-enabled`	Habilita drenagem de conexão
	`alb.ingress.kubernetes.io/connection-drain-timeout`	Tempo limite de drenagem em segundos (0–900)

Encaminhar requisições com base em nomes de domínio

Crie um Ingress para encaminhar requisições por nome de domínio. O ALB Ingress aceita nomes de domínio padrão e vazios.

Encaminhar requisições com base em um nome de domínio padrão

O exemplo a seguir define o caminho de roteamento como /hello. As requisições para demo.domain.ingress.top/hello são encaminhadas ao Service de backend.

Implante o modelo a seguir para criar um Service, um Deployment e um Ingress. As requisições são encaminhadas ao Service através do nome de domínio no Ingress.

Expand to view the sample YAML

Para clusters da versão 1.19 e 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 clusters anteriores à versão 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

Teste o roteamento. Substitua ADDRESS pelo nome de domínio da instância ALB (use kubectl get ing para obtê-lo).
```
curl -H "host: demo.domain.ingress.top" <ADDRESS>/hello
```
Saída esperada:
```
{"hello":"coffee"}
```

Encaminhar requisições com base em um nome de domínio vazio

Quando o campo host está vazio, o Ingress corresponde a todas as requisições, independentemente do domínio. O exemplo a seguir roteia requisições para <ADDRESS>/hello ao Service de backend.

Implante o modelo a seguir para criar um Ingress.

Expand to view the sample YAML

Para clusters da versão 1.19 e 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 clusters anteriores à versão 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

Teste o roteamento. Substitua ADDRESS pelo nome de domínio da instância ALB.
```
curl <ADDRESS>/hello
```
Saída esperada:
```
{"hello":"coffee"}
```

Encaminhar requisições com base em caminhos de url

O ALB Ingress encaminha requisições com base em caminhos de url usando o campo pathType. Três tipos de correspondência são compatíveis:

`pathType`	Comportamento
`Prefix`	Corresponde ao prefixo do caminho, segmento por segmento, diferenciando maiúsculas de minúsculas
`Exact`	Apenas correspondência exata
`ImplementationSpecific`	Tratado como correspondência exata (Exact) pelo controlador ALB Ingress. Se `path` não estiver definido, o ALB usa `/` como padrão

Importante

Se pathType estiver definido como Exact ou Prefix, path deve ser um caminho absoluto não vazio. Caso contrário, a criação do Ingress falha com um erro de validação. Quando várias regras de correspondência de url entram em conflito, o ALB as avalia pela prioridade da regra de encaminhamento.

Referência de correspondência de caminho

Caminhos simples (/, /foo, /foo/)

Tipo de correspondência	Caminho da regra	Caminho da requisição	Corresponde?
Prefix	`/`	`/` (corresponde a todos)	Sim
Prefix	`/foo`	`/foo`	Sim
Prefix	`/foo`	`/foo/`	Sim
Prefix	`/foo/`	`/foo`	Sim
Prefix	`/foo/`	`/foo/`	Sim
Prefix	`/aaa`	`/ccc`	Não — o prefixo não corresponde
Exact ou ImplementationSpecific	`/foo`	`/foo`	Sim
Exact ou ImplementationSpecific	`/foo`	`/bar`	Não
Exact ou ImplementationSpecific	`/foo`	`/foo/`	Não
Exact ou ImplementationSpecific	`/foo/`	`/foo`	Não

Caminhos hierárquicos (/aaa/bb, /aaa/bbb, /aaa/bbb/)

Tipo de correspondência	Caminho da regra	Caminho da requisição	Corresponde?
Prefix	`/aaa/bb`	`/aaa/bbb`	Não
Prefix	`/aaa/bbb`	`/aaa/bbb`	Sim
Prefix	`/aaa/bbb/`	`/aaa/bbb`	Sim — a barra final na regra é ignorada
Prefix	`/aaa/bbb`	`/aaa/bbb/`	Sim — a barra final na requisição corresponde
Prefix	`/aaa/bbb`	`/aaa/bbb/ccc`	Sim — o subcaminho corresponde

Múltiplos caminhos de regra

Tipo de correspondência	Caminhos da regra	Caminho da requisição	Corresponde?
Prefix	`/`, `/aaa`	`/aaa/ccc`	Sim — corresponde ao prefixo `/`
Prefix	`/aaa`, `/`	`/aaa/ccc`	Sim — corresponde ao prefixo `/aaa`
Prefix	`/aaa`, `/`	`/ccc`	Sim — corresponde ao prefixo `/`
Prefix	`/aaa`, `/bbb`	`/ccc`	Não — o prefixo não corresponde

Correspondência de prefixo (Prefix)

A correspondência de prefixo compara segmentos de caminho separados por /, diferenciando maiúsculas de minúsculas. O exemplo a seguir define o caminho da regra como /, que corresponde a todos os caminhos, incluindo /hello.

Implante o modelo a seguir para criar um Ingress.

Expand to view the sample YAML

Para clusters da versão 1.19 e 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 clusters anteriores à versão 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

Teste o roteamento. Substitua ADDRESS pelo nome de domínio da instância ALB.
```
curl <ADDRESS>/hello
```
Saída esperada:
```
{"hello":"coffee"}
```

Correspondência exata (Exact ou ImplementationSpecific)

O exemplo a seguir define o caminho da regra como /hello. Apenas o caminho exato /hello corresponde.

Implante o modelo a seguir para criar um Ingress.

Expand to view the sample YAML

Para clusters da versão 1.19 e 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 clusters anteriores à versão 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

Teste o roteamento. Substitua ADDRESS pelo nome de domínio da instância ALB.
```
curl <ADDRESS>/hello
```
Saída esperada:
```
{"hello":"coffee"}
```

Redirecionar HTTP para HTTPS

Adicione a anotação alb.ingress.kubernetes.io/ssl-redirect: "true" para redirecionar requisições HTTP para a porta HTTPS 443.

Importante

Esta anotação aplica-se apenas a regras de encaminhamento HTTP na porta de listener 80. Este recurso funciona somente com as anotações RemoveHeader, InsertHeader e CORS entre domínios. Antes de adicionar esta anotação, configure um listener HTTPS na porta 443 no AlbConfig.

Clusters executando Kubernetes 1.19 ou 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

Clusters executando versões do Kubernetes anteriores à 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 verificações de integridade

Configure verificações de integridade para o grupo de servidores de backend com as seguintes anotações.

Expand to view the full sample YAML

Adicione as seguintes anotações para ativar e configurar verificações de integridade do grupo de servidores de 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 clusters da versão 1.19 e 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 clusters anteriores à versão 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

Referência de anotações:

Anotação	Descrição	Padrão
`alb.ingress.kubernetes.io/healthcheck-enabled`	Ativa verificações de integridade: `true` ou `false`	`false`
`alb.ingress.kubernetes.io/healthcheck-path`	Caminho da verificação de integridade	`/`
`alb.ingress.kubernetes.io/healthcheck-protocol`	Protocolo: `HTTP`, `HTTPS`, `TCP` ou `GRPC`. HTTP/HTTPS usam HEAD ou GET; TCP usa SYN; gRPC usa POST ou GET	`HTTP`
`alb.ingress.kubernetes.io/healthcheck-httpversion`	Versão do HTTP: `HTTP1.0` ou `HTTP1.1`. Aplica-se aos protocolos `HTTP` e `HTTPS`	`HTTP1.1`
`alb.ingress.kubernetes.io/healthcheck-method`	Método de requisição: `HEAD`, `POST` ou `GET`. Use `POST` ou `GET` quando o protocolo for `GRPC`	`HEAD`
`alb.ingress.kubernetes.io/healthcheck-code`	Códigos de status esperados. Tem precedência sobre `healthcheck-httpcode`. Para HTTP/HTTPS: `http_2xx`, `http_3xx`, `http_4xx`, `http_5xx` (separados por vírgula). Para gRPC: intervalos inteiros em [0, 99] (até 20 intervalos, separados por vírgula)	HTTP/HTTPS: `http_2xx`; gRPC: `0`
`alb.ingress.kubernetes.io/healthcheck-httpcode`	Códigos de status esperados para clusters anteriores à versão 1.19. Opções: `http_2xx`, `http_3xx`, `http_4xx`, `http_5xx` (separados por vírgula)	`http_2xx`
`alb.ingress.kubernetes.io/healthcheck-timeout-seconds`	Tempo limite em segundos. Intervalo: [1, 300]	`5`
`alb.ingress.kubernetes.io/healthcheck-interval-seconds`	Intervalo de verificação em segundos. Intervalo: [1, 50]	`2`
`alb.ingress.kubernetes.io/healthy-threshold-count`	Sucessos consecutivos necessários para marcar um servidor de backend como íntegro. Intervalo: [2, 10]	`3`
`alb.ingress.kubernetes.io/unhealthy-threshold-count`	Falhas consecutivas necessárias para marcar um servidor de backend como não íntegro. Intervalo: [2, 10]	`3`
`alb.ingress.kubernetes.io/healthcheck-connect-port`	Porta de verificação de integridade. `0` usa a porta do servidor de backend	`0`

Usar HTTPS e gRPC como protocolos de backend

Adicione a anotação alb.ingress.kubernetes.io/backend-protocol para usar HTTPS ou gRPC como protocolo de backend.

Após a criação de um Ingress, o protocolo de backend não pode ser alterado. Para trocar de protocolo, exclua o Ingress e crie um novo.

Importante

Ao encaminhar tráfego gRPC através de um Ingress, configure um certificado TLS para o nome de domínio e use TLS para comunicação.

Expand to view the full sample YAML

Para clusters da versão 1.19 e 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 clusters anteriores à versão 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

Anotação	Valores	Descrição
`alb.ingress.kubernetes.io/backend-protocol`	`https`	O Service de backend usa HTTPS
	`grpc`	O Service de backend usa gRPC. Requer configuração de TLS no nome de domínio

Configurar expressões regulares

Use a anotação alb.ingress.kubernetes.io/use-regex: "true" para habilitar correspondência de expressões regulares nas regras de caminho. Esta anotação aplica-se apenas a regras de caminho com pathType: Prefix.

Anotação	Descrição
`alb.ingress.kubernetes.io/use-regex: "true"`	Habilita expressões regulares nas regras de caminho
`alb.ingress.kubernetes.io/conditions.<YOUR-SVC-NAME>`	Configura condições de encaminhamento personalizadas. Substitua `<YOUR-SVC-NAME>` pelo nome real do Service, que deve corresponder a `backend.service.name`

Regras de correspondência de expressão regular:

Alvo	Prefixo	Exemplo de regra	Caminho do cliente	Corresponde?	Observações
Nome de domínio	Começa com `~`	`~test.example.com`	`test.EXAMPLE.com`	Sim	Nomes de domínio aceitam correspondência sem distinção entre maiúsculas e minúsculas
Caminho	Começa com `~`	`~/api`	`/API`	Sim	Correspondência sem distinção entre maiúsculas e minúsculas
Caminho	Começa com `~*`	`~*/api`	`/Api`	Não	Correspondência com distinção entre maiúsculas e minúsculas

Expand to view the full sample YAML

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 reescritas

O ALB Ingress reescreve o caminho da requisição antes do encaminhamento. Duas anotações controlam o comportamento de reescrita:

alb.ingress.kubernetes.io/rewrite-target: /<path>/${number} — habilita a reescrita e define o caminho de destino. Use o formato ${number} para referenciar um grupo de captura do caminho original (até três grupos: ${1}, ${2}, ${3}). pathType deve ser Prefix.
alb.ingress.kubernetes.io/use-regex — especifica se deve usar expressões regulares no caminho. Ativado automaticamente quando rewrite-target é configurado. Defina como "false" para desativar; observe que caminhos com caracteres especiais (%#;!()[]^,"\") não podem ser criados quando a regex está desativada.

Cenário 1: Remover um prefixo

O caminho path: /something(/|$)(.*) usa três grupos de captura:

/something — corresponde ao prefixo a ser removido
(/|$) — primeiro grupo: corresponde a / ou ao fim do caminho
(.*) — segundo grupo: captura tudo após /something/, referenciado como ${2} no alvo de reescrita

O alvo de reescrita / + ${2} remove o prefixo /something:

Caminho original	Corresponde?	Caminho reescrito
`/something`	Sim (segundo grupo está vazio)	`/`
`/something/`	Sim (segundo grupo está vazio)	`/`
`/something/new`	Sim (segundo grupo: `new`)	`/new`
`/something-new/item`	Não	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

Cenário 2: Capturar e reorganizar múltiplas partes

O caminho /items/(.*)/(.*)/(.*) captura três segmentos. O alvo de reescrita /${2}?code=${3} reestrutura a url usando o segundo e o terceiro grupos.

Este padrão requer exatamente quatro segmentos de caminho. Os clientes devem usar um formato de caminho fixo.

Caminho original	Corresponde?	Caminho reescrito
`/items/electronics/computers/554`	Sim (grupo 2: `computers`, grupo 3: `554`)	`/computers?code=554`
`/items/produce/fruits/12`	Sim (grupo 2: `fruits`, grupo 3: `12`)	`/fruits?code=12`
`/items/headphones/5`	Não	503
`/drinks/41`	Não	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

Cenário 3: Reescrever múltiplos caminhos para um único caminho

O exemplo a seguir roteia tanto /app-a quanto /app-b para /app-c definindo duas regras de caminho com o mesmo alvo de reescrita /${2} → /app-c/${2}.

Caminho original	Corresponde?	Caminho reescrito
`/app-a/item1`	Sim (grupo 2: `item1`)	`/app-c/item1`
`/app-a/item2`	Sim (grupo 2: `item2`)	`/app-c/item2`
`/app-a` ou `/app-a/`	Sim (grupo 2 está vazio)	`/app-c/`
`/drinks/41`	Não	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

Cenário 4: Reescrever um nome de domínio

A anotação rewrite-target altera apenas o caminho. Para reescrever outras partes da url, como o nome de domínio ou parâmetros de consulta, use regras de encaminhamento personalizadas.

Verificar regras de reescrita localmente

Use sed para testar correspondências de regex de caminho e visualizar resultados reescritos antes da implantação.

O exemplo a seguir testa a regex de caminho /items/(.*)/(.*)/(.*) e a regra de reescrita /${2}?code=${3} do Cenário 2.

Salve os caminhos de teste em path2.txt:

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

Simule a reescrita com sed. Escape / como \/ na regex de caminho e use \2 em vez de ${2} para grupos de captura:

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

Saída esperada — os dois primeiros caminhos correspondem à regra de reescrita; os dois últimos não:

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

Configurar portas de listener personalizadas

Use a anotação alb.ingress.kubernetes.io/listen-ports para expor um Service em múltiplas portas, como HTTP 80 e HTTPS 443.

Importante

O ALB não cria listeners a partir de um Ingress. Crie as portas e protocolos de listener necessários no AlbConfig primeiro e depois associe-os ao Ingress.

Expand to view the full sample YAML

Para clusters da versão 1.19 e 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 clusters anteriores à versão 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

Anotação	Descrição
`alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'`	Configura o Service para escutar tanto na porta 80 quanto na porta 443

Configurar prioridade de regra de encaminhamento

Por padrão, o ALB classifica as regras de encaminhamento na seguinte ordem:

Entre Ingresses: classificado por namespace/name lexicograficamente. Valores menores têm maior prioridade. O namespace é comparado primeiro, depois o nome.

Dentro do mesmo Ingress: classificado pela ordem no campo rules. Regras listadas anteriormente têm maior prioridade.

rules:
  - host: www.example.com   # Higher priority
    http: ...
  - host: www.test.com      # Lower priority
    http: ...

Para substituir a ordem de classificação padrão sem renomear o Ingress, use a anotação alb.ingress.kubernetes.io/order.

Importante

As prioridades dentro do mesmo listener devem ser únicas.

Expand to view the full sample YAML

Para clusters da versão 1.19 e 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 clusters anteriores à versão 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

Anotação	Intervalo	Padrão	Descrição
`alb.ingress.kubernetes.io/order`	[1, 1000]	10	Prioridade da regra de encaminhamento. Valores menores têm maior prioridade

Implementar lançamentos canário usando anotações

O ALB aceita lançamentos canário baseados em cabeçalhos de requisição, cookies e pesos de tráfego. Crie um Ingress canário separado ao lado do Ingress de produção.

Canary routing priority: Cabeçalho > Cookie > Peso (do maior para o menor).

Importante

Não exclua o Ingress de produção durante o lançamento canário. Após validar o lançamento canário, atualize o Service de backend no Ingress de produção para apontar para a nova versão e, em seguida, exclua o Ingress canário.

Consulte Implementar lançamentos graduais através do ALB Ingress.

Roteamento por cabeçalho

Use canary-by-header e canary-by-header-value juntos para rotear requisições que correspondem a um valor de cabeçalho específico para o Service canário. Requisições sem correspondência passam para a próxima regra canária (cookie ou peso).

Expand to view the full sample YAML

Para clusters da versão 1.19 e 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 clusters anteriores à versão 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

Com esta configuração, requisições com location: hz são roteadas para o Service canário. Todas as outras requisições passam para a próxima regra canária.

Anotação	Descrição
`alb.ingress.kubernetes.io/canary-by-header`	Nome do cabeçalho de requisição para correspondência
`alb.ingress.kubernetes.io/canary-by-header-value`	Valor exato do cabeçalho para correspondência. Ambas as anotações devem ser configuradas juntas

Roteamento por cookie

Use canary-by-cookie para rotear requisições com base em um nome de cookie. Defina o valor do cookie como always para sempre rotear para o Service canário, ou never para sempre excluí-lo.

Expand to view the full sample YAML

Para clusters da versão 1.19 e 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 clusters anteriores à versão 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

Com esta configuração, requisições com Cookie: demo=always são roteadas para o Service canário. Requisições com Cookie: demo=never ignoram completamente o Service canário.

Anotação	Valores	Descrição
`alb.ingress.kubernetes.io/canary-by-cookie`	`always`	Todas as requisições são roteadas para o Service canário
	`never`	Nenhuma requisição é roteada para o Service canário

O roteamento canário baseado em cookie aceita apenas always e never. Valores personalizados de cookie não são suportados.

Roteamento por peso

Use canary-weight para enviar uma porcentagem de tráfego ao Service canário. O exemplo a seguir roteia 50% do tráfego para o canário:

Expand to view the full sample YAML

Para clusters da versão 1.19 e 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 clusters anteriores à versão 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

Anotação	Intervalo	Descrição
`alb.ingress.kubernetes.io/canary-weight`	0–100	Porcentagem de requisições roteadas para o Service canário

Implementar persistência de sessão usando anotações

O ALB Ingress aceita persistência de sessão baseada em cookies. Adicione as seguintes anotações para ativar e configurar esse recurso.

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 clusters da versão 1.19 e 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 clusters anteriores à versão 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

Anotação	Descrição	Padrão
`alb.ingress.kubernetes.io/sticky-session`	Ativa persistência de sessão: `true` ou `false`	`false`
`alb.ingress.kubernetes.io/sticky-session-type`	Modo de manipulação de cookie. `Insert`: O ALB insere um cookie `SERVERID` para rotear requisições subsequentes ao mesmo backend. `Server`: O ALB reescreve um cookie personalizado para roteamento. Requer `StickySessionEnabled` definido como `true` no grupo de servidores. Consulte Criar um grupo de servidores	`Insert`
`alb.ingress.kubernetes.io/cookie-timeout`	Tempo limite do cookie em segundos. Intervalo: [1, 86400]. Aplica-se quando `sticky-session-type` é `Insert`	`1000`
`alb.ingress.kubernetes.io/cookie`	Nome personalizado do cookie. Obrigatório e não pode estar em branco quando `sticky-session-type` é `Server`	`""`

Especificar um algoritmo de balanceamento de carga

Use a anotação alb.ingress.kubernetes.io/backend-scheduler para definir o algoritmo de balanceamento de carga para um grupo de servidores de backend.

Expand to view the full sample YAML

Para clusters da versão 1.19 e 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 clusters anteriores à versão 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	Descrição
`wrr`	Round-robin ponderado	Servidores de backend com pesos maiores recebem mais requisições. Algoritmo padrão
`wlc`	Menos conexões ponderado	Roteia para o servidor com o menor número de conexões ativas, ponderado pelo peso do servidor
`sch`	Hash consistente de IP de source	Roteia requisições do mesmo IP de cliente para o mesmo servidor de backend
`uch`	Hash consistente de parâmetro de url	Roteia pelo hash do parâmetro de url. Defina o nome do parâmetro com `alb.ingress.kubernetes.io/backend-scheduler-uch-value`

Configurar compartilhamento de recursos de origem cruzada

Adicione anotações CORS para permitir que navegadores façam requisições de origem cruzada ao 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

Anotação	Descrição	Padrão
`alb.ingress.kubernetes.io/cors-allow-origin`	Origens permitidas. Deve começar com `http://` ou `https://`, seguido por um domínio válido ou domínio curinga de nível superior. Separe múltiplas origens com vírgulas. Exemplo: `"https://example.com:4443, http://aliyundoc.com, https://example.org:1199"`	`*`
`alb.ingress.kubernetes.io/cors-allow-methods`	Métodos de origem cruzada permitidos. Sem distinção entre maiúsculas e minúsculas. Separe múltiplos métodos com vírgulas. Exemplo: `"PUT, GET, POST, OPTIONS"`	`GET, PUT, POST, DELETE, PATCH, OPTIONS`
`alb.ingress.kubernetes.io/cors-allow-headers`	Cabeçalhos de requisição permitidos. Cabeçalhos podem conter letras, dígitos, sublinhados (`_`) e hífens (`-`). Separe múltiplos cabeçalhos com vírgulas. Exemplo: `"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`	Cabeçalhos expostos ao navegador. Podem conter letras, dígitos, sublinhados (`_`), hífens (`-`) e asteriscos (``). Separe múltiplos cabeçalhos com vírgulas. Exemplo: `", X-CustomResponseHeader"`	Vazio
`alb.ingress.kubernetes.io/cors-allow-credentials`	Permite credenciais em requisições de origem cruzada. Exemplo: `"false"`	`true`
`alb.ingress.kubernetes.io/cors-max-age`	Duração máxima de cache em segundos para respostas de preflight OPTIONS. Intervalo: [−1, 172800]	`172800`

Habilitar conexões persistentes de backend

Conexões persistentes de backend reutilizam conexões TCP para servidores de backend, reduzindo a sobrecarga de abrir e fechar conexões por requisição.

Adicione a anotação alb.ingress.kubernetes.io/backend-keepalive: "true" para habilitar este recurso:

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

Definir limites de taxa de QPS

Adicione a anotação alb.ingress.kubernetes.io/traffic-limit-qps para definir a limitação de QPS no nível da regra de encaminhamento:

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

Anotação	Intervalo	Descrição
`alb.ingress.kubernetes.io/traffic-limit-qps`	[1, 100.000]	QPS máximo para a regra de encaminhamento

Configurar inicialização lenta para novos pods

A inicialização lenta aumenta gradualmente o tráfego para novos pods durante uma duração configurada, evitando picos transitórios de CPU ou memória causados por tráfego total atingindo um pod frio.

Anotação	Descrição	Padrão
`alb.ingress.kubernetes.io/slow-start-enabled`	Habilita inicialização lenta: `true` ou `false`	`false`
`alb.ingress.kubernetes.io/slow-start-duration`	Duração da rampa de subida em segundos. Durações maiores desaceleram o aumento de tráfego. Intervalo: [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

Configurar drenagem de conexão

Quando um pod entra no estado Terminating, o ALB o remove do grupo de servidores de backend. Sem a drenagem de conexão, requisições em andamento nas conexões existentes podem falhar.

A drenagem de conexão mantém as conexões ativas abertas por um período configurado, permitindo que requisições em andamento sejam concluídas antes que o pod fique offline.

Importante

Antes que o tempo limite de drenagem termine, o ALB não pode garantir que o pod permaneça íntegro. Configure spec.terminationGracePeriodSeconds no pod ou use um hook preStop para controlar a disponibilidade do pod durante o estado Terminating.

Consulte Alcançar desligamento suave de negócios através da drenagem de conexão do ALB.

Anotação	Descrição	Padrão
`alb.ingress.kubernetes.io/connection-drain-enabled`	Habilita drenagem de conexão: `true` ou `false`	`false`
`alb.ingress.kubernetes.io/connection-drain-timeout`	Tempo máximo em segundos que o ALB aguarda antes de fechar conexões após um pod ser removido ou falhar em uma verificação de integridade. Intervalo: [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: