Um Application Load Balancer (ALB) Ingress é um objeto da API do Kubernetes que fornece balanceamento de carga na camada 7 para acesso externo aos Services em um cluster ACS. Este tópico aborda configurações avançadas de ALB Ingress, incluindo encaminhamento de requisições baseado em domínio e caminho, verificações de integridade, redirecionamentos HTTPS, canary releases, entre outros recursos.
Pré-requisitos
Antes de começar, verifique se você tem:
Um cluster ACS. Para mais informações, consulte Criar um cluster ACS.
Um objeto AlbConfig. Para mais informações, consulte Introdução ao ALB Ingress.
Referência rápida de anotações
Todas as configurações de ALB Ingress usam anotações do Kubernetes. A tabela a seguir lista as anotações abordadas neste tópico.
|
Anotação |
Tipo |
Padrão |
Versão do cluster |
Seção |
|||
|
|
|
|
|
— |
|||
|
|
string |
|
— |
||||
|
|
|
|
|
— |
|||
|
|
|
|
|
— |
|||
|
|
|
|
|
|
|
— |
|
|
|
inteiro, 1–300 |
|
— |
||||
|
|
inteiro, 1–50 |
|
— |
||||
|
|
inteiro, 2–10 |
|
— |
||||
|
|
inteiro, 2–10 |
|
— |
||||
|
|
|
|
— |
— |
|||
|
|
|
|
— |
— |
|||
|
|
|
|
— |
— |
|||
|
|
JSON |
— |
— |
||||
|
|
string |
— |
— |
||||
|
|
JSON |
— |
— |
||||
|
|
inteiro, 1–1.000 |
|
— |
||||
|
|
|
|
— |
— |
|||
|
|
string |
— |
— |
||||
|
|
string |
— |
— |
||||
|
|
string |
— |
— |
||||
|
|
inteiro, 0–100 |
— |
— |
||||
|
|
|
|
|
— |
|||
|
|
|
|
|
— |
|||
|
|
inteiro, 1–86.400 |
|
— |
||||
|
|
|
|
|
|
|
1.19+ |
|
|
|
string |
— |
1.19+ |
||||
|
|
|
|
— |
— |
|||
|
|
string |
|
— |
||||
|
|
string |
|
— |
||||
|
|
string |
|
— |
||||
|
|
string |
vazio |
— |
||||
|
|
|
|
|
— |
|||
|
|
inteiro, -1–172.800 |
|
— |
||||
|
|
|
|
— |
— |
|||
|
|
inteiro, 1–100.000 |
— |
— |
Encaminhar requisições com base em nomes de domínio
O ALB Ingress roteia requisições recebidas para Services com base no campo host das regras de Ingress. Esta seção demonstra como encaminhar requisições usando um domínio nomeado e sem domínio.
Encaminhar requisições para um domínio nomeado
-
Aplique o manifesto a seguir para criar um Deployment, um Service e um Ingress. As requisições para
demo.domain.ingress.topsão encaminhadas parademo-service.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 -
Obtenha o endereço da instância ALB executando
kubectl get inge envie uma requisição de teste. Substitua<ADDRESS>pelo nome de domínio da instância ALB.curl -H "host: demo.domain.ingress.top" <ADDRESS>/helloSaída esperada:
{"hello":"coffee"}
Encaminhar requisições sem domínio
Defina host como uma string vazia para corresponder a requisições independentemente do cabeçalho Host.
-
Aplique o seguinte manifesto de Ingress:
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 -
Obtenha o endereço da instância ALB executando
kubectl get inge envie uma requisição de teste. Substitua<ADDRESS>pelo nome de domínio da instância ALB.curl <ADDRESS>/helloSaída esperada:
{"hello":"coffee"}
Encaminhar requisições com base em caminhos de URL
Configure o campo pathType para controlar como o ALB Ingress corresponde aos caminhos de URL. Há suporte para três tipos de correspondência: Exact, ImplementationSpecific (padrão) e Prefix.
Políticas de correspondência de URL podem entrar em conflito. Quando isso ocorre, as requisições são correspondidas em ordem decrescente de prioridade da política. Para obter detalhes, consulte Defina prioridades de regras de encaminhamento .
Comportamento de correspondência de caminho
|
Modo de correspondência |
Regra |
Caminho de URL |
Corresponde? |
|
Prefix |
|
(todos os caminhos) |
Sim |
|
Prefix |
|
|
Sim |
|
Prefix |
|
|
Sim |
|
Prefix |
|
|
Não |
|
Prefix |
|
|
Sim |
|
Prefix |
|
|
Sim — a barra |
|
Prefix |
|
|
Sim — a barra |
|
Prefix |
|
|
Sim — o subcaminho é correspondido |
|
Prefix |
|
|
Sim — corresponde ao prefixo |
|
Prefix |
|
|
Sim — corresponde ao prefixo |
|
Prefix |
|
|
Sim — corresponde ao prefixo |
|
Prefix |
|
|
Não |
|
Exact ou ImplementationSpecific |
|
|
Sim |
|
Exact ou ImplementationSpecific |
|
|
Não |
|
Exact ou ImplementationSpecific |
|
|
Não |
|
Exact ou ImplementationSpecific |
|
|
Não |
Exact
As requisições devem corresponder exatamente ao caminho.
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
ImplementationSpecific
No ALB Ingress, ImplementationSpecific comporta-se de forma idêntica a Exact.
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: ImplementationSpecific
Prefix
Prefix executa uma correspondência que diferencia maiúsculas de minúsculas nos elementos do caminho delimitados por /. Definir path: / corresponde a todas as requisições recebidas.
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 verificar qualquer um dos itens acima, execute kubectl get ing para obter <ADDRESS> e depois:
curl <ADDRESS>/hello
Saída esperada:
{"hello":"coffee"}
Configure verificações de integridade
Adicione anotações de verificação de integridade a um Ingress para permitir que o ALB sonde os servidores de backend e remova automaticamente os não saudáveis da rotação.
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-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:
service:
name: tea-svc
port:
number: 80
- path: /coffee
backend:
service:
name: coffee-svc
port:
number: 80
| Anotação | Descrição |
|---|---|
alb.ingress.kubernetes.io/healthcheck-enabled | (Opcional) Ativa as verificações de integridade. Padrão: false. |
alb.ingress.kubernetes.io/healthcheck-path | (Opcional) Caminho de URL para verificações de integridade. Deve começar com / e ter entre 1 e 80 caracteres. A URL pode conter letras, dígitos, hifens (-), barras (/), pontos (.), sinais de porcentagem (%), pontos de interrogação (?), cerquilhas (#) e e comerciais (&). Também são aceitos os seguintes caracteres estendidos: _ ; ~ ! ( ) * [ ] @ $ ^ : ' , +. Padrão: /. Por padrão, a instância ALB envia requisições HTTP HEAD para a página inicial padrão da aplicação configurada em uma instância Elastic Compute Service (ECS) de backend para realizar as verificações de integridade. A instância ALB envia as requisições para o endereço IP privado da instância ECS. Caso não queira usar a página inicial padrão para as verificações, especifique um caminho de URL. |
alb.ingress.kubernetes.io/healthcheck-protocol | (Opcional) Protocolo para verificações de integridade. |
alb.ingress.kubernetes.io/healthcheck-method | (Opcional) Método HTTP para verificações de integridade. |
alb.ingress.kubernetes.io/healthcheck-httpcode | Códigos de status que indicam um backend saudável. Valores válidos: http_2xx (padrão), http_3xx, http_4xx, http_5xx. |
alb.ingress.kubernetes.io/healthcheck-timeout-seconds | Tempo limite para uma única verificação de integridade. Se o backend não responder dentro desse período, a verificação falha. Valores válidos: 1–300. Padrão: 5. Unidade: segundos. |
alb.ingress.kubernetes.io/healthcheck-interval-seconds | Intervalo entre verificações de integridade consecutivas. Valores válidos: 1–50. Padrão: 2. Unidade: segundos. |
alb.ingress.kubernetes.io/healthy-threshold-count | Número de verificações bem-sucedidas consecutivas necessárias para que um backend não saudável seja considerado saudável. Valores válidos: 2–10. Padrão: 3. |
alb.ingress.kubernetes.io/unhealthy-threshold-count | Número de verificações com falha consecutivas necessárias para que um backend saudável seja considerado não saudável. Valores válidos: 2–10. Padrão: 3. |
Redirecionar HTTP para HTTPS
Defina alb.ingress.kubernetes.io/ssl-redirect: "true" para redirecionar todas as requisições HTTP para a porta HTTPS 443.
O ALB Ingress não cria listeners diretamente. Especifique as portas e protocolos dos listeners em um objeto AlbConfig e associe os listeners aos Services no Ingress. Para obter detalhes, consulte Usar AlbConfigs para configurar listeners ALB.
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
Defina o protocolo de backend
O ALB suporta HTTPS e gRPC como protocolos de backend. Defina a anotação alb.ingress.kubernetes.io/backend-protocol como "https" ou "grpc".
Não é possível alterar o protocolo de backend após a criação do Ingress. Para mudar o protocolo, exclua o Ingress e crie-o novamente.
Para gRPC, o domínio deve possuir um certificado SSL e usar TLS. O exemplo a seguir configura um backend gRPC:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/backend-protocol: "grpc"
name: lxd-grpc-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
Usar expressões regulares
Defina alb.ingress.kubernetes.io/use-regex: "true" para ativar a correspondência por expressão regular no campo path. Use a anotação alb.ingress.kubernetes.io/conditions.<service-name> para definir condições de caminho personalizadas.
O Service nomeado na anotação deve existir no cluster e corresponder ao nome do Service no campo backend da regra.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/use-regex: "true"
alb.ingress.kubernetes.io/conditions.service-a: |
[{
"type": "Path",
"pathConfig": {
"values": [
"~*^/pathvalue1",
"/pathvalue2"
]
}
}]
name: ingress-example
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /test
pathType: Prefix
backend:
service:
name: service-a
port:
number: 88
Os padrões de expressão regular devem usar o prefixo de flag~*(por exemplo,~*^/pathvalue1). Caminhos de correspondência exata não exigem o prefixo~*.
Configure regras de reescrita
Use alb.ingress.kubernetes.io/rewrite-target em conjunto com alb.ingress.kubernetes.io/use-regex: "true" para reescrever os caminhos das requisições antes que elas cheguem ao backend.
Regras:
Variáveis no formato
${number}devem ser usadas em umpathcujopathTypesejaPrefix.Há suporte para até três variáveis de grupo de captura:
${1},${2}e${3}.O
pathdeve começar com/.Por padrão,
*e?não são permitidos no campopath. Ativeuse-regexpara usá-los.
O exemplo a seguir reescreve caminhos que correspondem a /something(/|$)(.*):
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/use-regex: "true"
alb.ingress.kubernetes.io/rewrite-target: /path/${2}
name: rewrite-ingress
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /something(/|$)(.*)
pathType: Prefix
backend:
service:
name: rewrite-svc
port:
number: 9080
A variável ${2} captura o segmento de caminho após /something/. O backend recebe os seguintes caminhos:
|
Requisição do cliente |
Backend recebe |
|
|
|
|
|
|
|
|
|
Para reescritas com múltiplos grupos, considere este exemplo: path definido como /sys/(.*)/(.*)/aaa e rewrite-target definido como /${1}/${2}. Uma requisição para /sys/ccc/bbb/aaa corresponde ao padrão — ${1} é substituído por ccc e ${2} por bbb — fazendo com que o backend receba /ccc/bbb.
Configure portas de escuta personalizadas
Defina alb.ingress.kubernetes.io/listen-ports para expor um Service em várias portas simultaneamente — por exemplo, HTTP na porta 80 e HTTPS na porta 443.
O ALB Ingress não cria listeners diretamente. Especifique as portas e protocolos dos listeners em um objeto AlbConfig e associe os listeners aos Services no Ingress. Para obter detalhes, consulte Usar AlbConfigs para configurar listeners ALB.
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
Defina prioridades de regras de encaminhamento
Por padrão, o ALB Ingress prioriza as regras de encaminhamento da seguinte forma:
Os Ingresses são classificados pela ordem lexicográfica de
namespace/name. Um valor menor indica maior prioridade.Dentro do mesmo Ingress, as regras são correspondidas de cima para baixo, na ordem em que aparecem no campo
rules.
Para substituir a classificação padrão sem renomear um Ingress, use a anotação alb.ingress.kubernetes.io/order.
As prioridades devem ser únicas dentro do mesmo listener. O valor deve ser um número inteiro de 1 a 1.000. Um valor menor indica maior prioridade. O padrão é 10 .
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
Canary releases
O ALB Ingress suporta canary releases que roteiam um subconjunto do tráfego para uma nova versão do seu Service. Três métodos de divisão de tráfego estão disponíveis: baseado em cabeçalho, baseado em cookie e baseado em peso.
Ative canary releases em um Ingress definindo alb.ingress.kubernetes.io/canary: "true" e adicione as anotações de roteamento apropriadas.
Canary rule priority: baseada em cabeçalho > baseada em cookie > baseada em peso.
Durante os testes canary, não modifique as regras originais do Ingress, pois isso pode interromper o tráfego. Após a nova versão passar pelos testes, atualize o Service de backend no Ingress original e exclua o Ingress canary.
Canary baseado em cabeçalho
canary-by-header especifica o nome do cabeçalho de requisição a ser correspondido. canary-by-header-value especifica o valor necessário para o cabeçalho e deve ser usado em conjunto com canary-by-header. Requisições em que o cabeçalho corresponde são roteadas para o Service canary; todas as outras requisições seguem para a próxima regra canary por prioridade.
No exemplo a seguir, requisições com o cabeçalho location: hz vão para o Service canary:
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
Canary baseado em cookie
canary-by-cookie divide o tráfego com base no nome de um cookie. Defina o cookie como always para rotear requisições para o Service canary, ou never para excluí-las.
Apenasalwayseneversão suportados. Valores personalizados de cookie não são aceitos.
No exemplo a seguir, requisições com o cookie demo=always vão para o Service canary:
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
Canary baseado em peso
canary-weight define a porcentagem de requisições roteadas para o Service canary. O valor deve ser um número inteiro de 0 a 100.
No exemplo a seguir, 50% das requisições vão para o Service canary:
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
Configure persistência de sessão
O ALB Ingress roteia requisições do mesmo cliente para o mesmo servidor de backend em várias conexões. Configure a persistência de sessão usando as seguintes anotações:
|
Anotação |
Descrição |
|
|
Ativa a persistência de sessão. Valores válidos: |
|
|
Método de manipulação de cookies. |
|
|
Tempo limite do cookie em segundos. Valores válidos: 1–86.400. Padrão: |
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"
alb.ingress.kubernetes.io/cookie-timeout: "1800"
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /tea2
backend:
service:
name: tea-svc
port:
number: 80
- path: /coffee2
backend:
service:
name: coffee-svc
port:
number: 80
Defina o algoritmo de balanceamento de carga
Use alb.ingress.kubernetes.io/backend-scheduler para definir o algoritmo de balanceamento de carga de um grupo de servidores de backend. A versão do cluster deve ser 1.19 ou posterior.
Quatro algoritmos são suportados:
|
Valor |
Algoritmo |
Funcionamento |
|
|
Round robin ponderado |
Distribui requisições proporcionalmente ao peso de cada servidor. |
|
|
Menos conexões ponderado |
Distribui requisições aos servidores de backend com base em seus pesos e no número de conexões existentes. Se os servidores tiverem o mesmo peso, aquele com menos conexões é selecionado. |
|
|
Hash de IP de origem |
Roteia requisições do mesmo IP de origem para o mesmo servidor de backend. |
|
|
Hash consistente baseado em URL |
Roteia requisições com o mesmo parâmetro de URL para o mesmo servidor de backend. Requer |
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"
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /tea
pathType: ImplementationSpecific
backend:
service:
name: tea-svc
port:
number: 80
Configure CORS
Defina alb.ingress.kubernetes.io/enable-cors: "true" para ativar o Cross-Origin Resource Sharing (CORS) em um ALB Ingress.
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 |
|
|
URLs permitidas para acessar recursos via navegador. Cada URL deve começar com |
|
|
|
Métodos HTTP permitidos para requisições CORS. Os valores não diferenciam maiúsculas de minúsculas. Separe múltiplos métodos com vírgulas. Exemplo: |
|
|
|
Cabeçalhos de requisição permitidos em requisições CORS. Cabeçalhos podem conter letras, dígitos, underscores e hifens. Separe múltiplos cabeçalhos com vírgulas. Exemplo: |
|
|
|
Cabeçalhos que os clientes podem acessar na resposta. Cabeçalhos podem conter letras, dígitos, underscores, hifens e asteriscos. Separe múltiplos cabeçalhos com vírgulas. Exemplo: |
vazio |
|
|
Indica se credenciais devem ser incluídas nas requisições CORS. |
|
|
|
Duração máxima de cache para resultados de requisições OPTIONS de preflight. Valores válidos: -1 a 172.800. Unidade: segundos. |
|
Ative conexões persistentes de backend
Por padrão, o ALB usa conexões de curta duração para grupos de servidores de backend — cada requisição abre e fecha uma conexão TCP. Conexões persistentes reutilizam conexões TCP existentes em várias requisições, reduzindo a sobrecarga de conexão e melhorando o throughput sob alta carga.
Defina alb.ingress.kubernetes.io/backend-keepalive: "true" para ativar esse 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
Configure limitação de QPS
Defina alb.ingress.kubernetes.io/traffic-limit-qps para limitar o número de consultas por segundo (QPS) de uma regra de encaminhamento. O valor deve ser um número inteiro de 1 a 100.000.
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