O APIG Ingress gerencia o acesso externo aos services do cluster com balanceamento de carga na camada 7. Adicione annotations aos seus resources de Ingress para configurar roteamento avançado de tráfego, limitação de taxa e recursos de segurança.
Os exemplos neste tópico usam os prefixos de annotationnginx.ingress.kubernetes.ioehigress.ingress.kubernetes.io. O prefixo aplicável a cada annotation está indicado no índice de annotations abaixo.
Índice de annotations
Clique em no nome de uma annotation para ir diretamente à sua descrição.
|
Annotation |
Tipo |
Escopo |
Recurso |
|
|
string ( |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
integer (0–100) |
Rota |
|
|
|
integer |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
boolean |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
boolean |
Rota |
|
|
|
integer (segundos) |
Rota |
|
|
|
boolean |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Domínio |
|
|
|
boolean |
Rota |
|
|
|
boolean |
Rota |
|
|
|
URL |
Rota |
|
|
|
integer |
Rota |
|
|
|
URL |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
integer |
Rota |
|
|
|
integer (segundos) |
Rota |
|
|
|
string |
Rota |
|
|
|
CIDR/IP |
Rota |
|
|
|
CIDR/IP |
Rota |
|
|
|
CIDR/IP |
Domínio |
|
|
|
CIDR/IP |
Domínio |
|
|
|
integer |
Rota |
|
|
|
integer |
Rota |
|
|
|
integer |
Rota |
|
|
|
integer (RPS) |
Rota |
|
|
|
integer |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
URL |
Rota |
|
|
|
integer |
Rota |
|
|
|
integer |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
URL |
Rota |
|
|
|
string ( |
Rota |
|
|
|
integer (0–100) |
Rota |
|
|
|
string ( |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
integer (segundos) |
Rota |
|
|
|
string ( |
Rota |
|
|
|
string ( |
Rota |
|
|
|
string |
Rota |
|
|
|
string |
Rota |
|
|
|
integer (segundos) |
Rota |
|
|
|
integer (segundos) |
Rota |
|
|
|
integer |
Rota |
|
|
|
integer |
Rota |
|
|
|
integer |
Rota |
|
|
|
string |
Domínio |
|
|
|
string |
Domínio |
|
|
|
string |
Domínio |
|
|
|
string ( |
Rota |
|
|
|
string |
Rota |
|
|
|
boolean |
Rota |
Canary release
O canary release permite direcionar tráfego para uma nova versão do service sem remover a versão atual de produção. Ative o recurso com nginx.ingress.kubernetes.io/canary: "true" e adicione uma ou mais annotations de direcionamento para controlar a distribuição do tráfego.
Quando vários métodos de direcionamento são configurados no mesmo Ingress, as regras são avaliadas na seguinte ordem de prioridade:
Cookie > Header > Parâmetro de query > Peso
Canary release baseado em header
|
Annotation |
Descrição |
|
|
Roteia o tráfego com base no nome de um header de requisição. Defina o valor do header como |
|
|
Quando combinado com |
Exemplo 1: Roteie requisições com o header apig: always para o service canary
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "apig"
name: demo-canary
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service-canary
port:
number: 80
path: /hello
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "apig"
name: demo-canary
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Exemplo 2: Roteie para múltiplas versões canary pelo valor do header (apig: v1 → v1, apig: v2 → v2)
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "apig"
nginx.ingress.kubernetes.io/canary-by-header-value: "v1"
name: demo-canary-v1
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service-canary-v1
port:
number: 80
path: /hello
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "apig"
nginx.ingress.kubernetes.io/canary-by-header-value: "v2"
name: demo-canary-v2
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service-canary-v2
port:
number: 80
path: /hello
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "apig"
nginx.ingress.kubernetes.io/canary-by-header-value: "v1"
name: demo-canary-v1
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary-v1
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "apig"
nginx.ingress.kubernetes.io/canary-by-header-value: "v2"
name: demo-canary-v2
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary-v2
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Canary release baseado em parâmetro de query
|
Annotation |
Descrição |
|
|
Roteia o tráfego com base no nome de um parâmetro de query da URL. Defina o valor do parâmetro como |
|
|
Quando combinado com |
É possível combinar regras baseadas em header e em parâmetro de query. Quando ambas estão configuradas, a requisição é roteada para o service canary somente se as duas condições forem atendidas.
Exemplo 1: Roteie requisições com o parâmetro de query canary=gray na URL para o service canary
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
higress.ingress.kubernetes.io/canary-by-query: "canary"
higress.ingress.kubernetes.io/canary-by-query-value: "gray"
name: demo-canary
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service-canary
port:
number: 80
path: /hello
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
higress.ingress.kubernetes.io/canary-by-query: "canary"
higress.ingress.kubernetes.io/canary-by-query-value: "gray"
name: demo-canary
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Exemplo 2: Roteie para o canary apenas quando canary=gray estiver na URL e x-user-id: test estiver no header
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
higress.ingress.kubernetes.io/canary-by-query: "canary"
higress.ingress.kubernetes.io/canary-by-query-value: "gray"
nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
nginx.ingress.kubernetes.io/canary-by-header-value: "test"
name: demo-canary
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service-canary
port:
number: 80
path: /hello
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
higress.ingress.kubernetes.io/canary-by-query: "canary"
higress.ingress.kubernetes.io/canary-by-query-value: "gray"
nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
nginx.ingress.kubernetes.io/canary-by-header-value: "test"
name: demo-canary
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Canary release baseado em cookie
Use nginx.ingress.kubernetes.io/canary-by-cookie para dividir o tráfego com base em um cookie. Defina o valor do cookie como always para rotear requisições para o service canary; todas as demais requisições vão para o service de produção.
O canary release baseado em cookie não aceita valores personalizados. O valor do cookie deve ser always.
Exemplo: Roteie requisições com o cookie demo=always para o service canary
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-cookie: "demo"
name: demo-canary
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service-canary
port:
number: 80
path: /hello
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-cookie: "demo"
name: demo-canary
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Canary release baseado em peso
|
Annotation |
Descrição |
Padrão |
|
|
Percentual de requisições roteadas para a versão canary. Integer de 0 a 100. |
— |
|
|
Peso total entre todas as versões. |
|
Exemplo: Divida o tráfego entre três versões — canary v1 com 30%, canary v2 com 20% e produção com 50%
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "30"
name: demo-canary-v1
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service-canary-v1
port:
number: 80
path: /hello
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "20"
name: demo-canary-v2
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service-canary-v2
port:
number: 80
path: /hello
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "30"
name: demo-canary-v1
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary-v1
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "20"
name: demo-canary-v2
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary-v2
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Subconjunto de service
Os subconjuntos de service permitem rotear o tráfego para Pods específicos dentro de um Service. Esse recurso é útil quando um único Service é sustentado por vários Deployments executando diferentes versões de código.
Convenção de rótulos de Pod para APIG Ingress
Defina higress.ingress.kubernetes.io/service-subset para especificar qual grupo de Pods recebe as requisições. Por padrão, o APIG Ingress mapeia o valor do subconjunto para rótulos de Pod com o prefixo opensergo.io/canary:
Valor
""oubase: roteia para Pods com o rótuloopensergo.io/canary: ""ou para Pods que não possuem nenhum rótulo com o prefixoopensergo.io/canary.Qualquer outra string (por exemplo,
gray): roteia para Pods com o rótuloopensergo.io/canary-gray: gray.
Exemplo: Roteie requisições com x-user-id: test para o Deployment gray do go-httpbin
Primeiro, aplique o Service e os Deployments:
# Kubernetes Service
apiVersion: v1
kind: Service
metadata:
name: go-httpbin
namespace: default
spec:
ports:
- port: 8080
protocol: TCP
selector:
app: go-httpbin
---
# Base Deployment — no opensergo.io/canary label
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-httpbin-base
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: go-httpbin
template:
metadata:
labels:
app: go-httpbin
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/apig/go-httpbin
args:
- "--version=base"
imagePullPolicy: Always
name: go-httpbin
---
# Gray Deployment — has label opensergo.io/canary-gray: gray
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-httpbin-gray
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: go-httpbin
template:
metadata:
labels:
app: go-httpbin
opensergo.io/canary-gray: gray
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/apig/go-httpbin
args:
- "--version=gray"
imagePullPolicy: Always
name: go-httpbinEm seguida, configure os resources de Ingress:
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
nginx.ingress.kubernetes.io/canary-by-header-value: "test"
# Forward to Pods with label opensergo.io/canary-gray: gray
higress.ingress.kubernetes.io/service-subset: gray
name: demo-canary
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: go-httpbin
port:
number: 8080
path: /test
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
# Forward to Pods with no opensergo.io/canary-prefixed label
higress.ingress.kubernetes.io/service-subset: ""
name: demo
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: go-httpbin
port:
number: 8080
path: /test
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
nginx.ingress.kubernetes.io/canary-by-header-value: "test"
# Forward to Pods with label opensergo.io/canary-gray: gray
higress.ingress.kubernetes.io/service-subset: gray
name: demo-canary
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /test
backend:
serviceName: go-httpbin
servicePort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
# Forward to Pods with no opensergo.io/canary-prefixed label
higress.ingress.kubernetes.io/service-subset: ""
name: demo
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /test
backend:
serviceName: go-httpbin
servicePort: 8080Uso de rótulos personalizados
Para direcionar Pods por qualquer rótulo arbitrário — fora da convenção opensergo.io/canary — defina tanto higress.ingress.kubernetes.io/service-subset quanto higress.ingress.kubernetes.io/subset-labels.
Quandosubset-labelsestá configurado, o subconjunto deixa de ser mapeado para rótulos com o prefixoopensergo.io/canary.
Exemplo: Roteie requisições com x-user-id: test para Pods com o rótulo version: gray
Primeiro, aplique os Deployments (o rótulo version: gray foi adicionado ao template de Pod do Deployment gray):
# go-httpbin Kubernetes Service
apiVersion: v1
kind: Service
metadata:
name: go-httpbin
namespace: default
spec:
ports:
- port: 8080
protocol: TCP
selector:
app: go-httpbin
---
# Base Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-httpbin-base
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: go-httpbin
template:
metadata:
labels:
app: go-httpbin
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/apig/go-httpbin
args:
- "--version=base"
imagePullPolicy: Always
name: go-httpbin
---
# Gray Deployment — uses the custom label version: gray
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-httpbin-gray
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: go-httpbin
template:
metadata:
labels:
app: go-httpbin
version: gray
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/apig/go-httpbin
args:
- "--version=gray"
imagePullPolicy: Always
name: go-httpbinEm seguida, configure os resources de Ingress:
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
nginx.ingress.kubernetes.io/canary-by-header-value: "test"
# Forward to Pods with label version: gray
higress.ingress.kubernetes.io/service-subset: gray
higress.ingress.kubernetes.io/subset-labels: version gray
name: demo-canary
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: go-httpbin
port:
number: 8080
path: /test
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/service-subset: ""
name: demo
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: go-httpbin
port:
number: 8080
path: /test
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
nginx.ingress.kubernetes.io/canary-by-header-value: "test"
# Forward to Pods with label version: gray
higress.ingress.kubernetes.io/service-subset: gray
higress.ingress.kubernetes.io/subset-labels: version gray
name: demo-canary
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /test
backend:
serviceName: go-httpbin
servicePort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/service-subset: ""
name: demo
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /test
backend:
serviceName: go-httpbin
servicePort: 8080CORS
O compartilhamento de recursos de origem cruzada (CORS) controla quais domínios externos podem fazer requisições ao seu service.
|
Annotation |
Descrição |
Padrão |
|
|
Ativa ou desativa o CORS. |
— |
|
|
Origens de terceiros permitidas. Separado por vírgulas; aceita o curinga |
|
|
|
Métodos HTTP permitidos. Separado por vírgulas; aceita o curinga |
|
|
|
Headers de requisição permitidos. Separado por vírgulas; aceita o curinga |
|
|
|
Headers de resposta que o navegador pode acessar. Separado por vírgulas. |
— |
|
|
Indica se credenciais são permitidas nas requisições CORS. |
|
|
|
Tempo de cache das respostas de preflight, em segundos. |
|
Exemplo: Permita example.com, autorize apenas GET e POST, restrinja ao header X-Foo-Bar e não permita credenciais
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/enable-cors: "true"
nginx.ingress.kubernetes.io/cors-allow-origin: "example.com"
nginx.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
nginx.ingress.kubernetes.io/cors-allow-headers: "X-Foo-Bar"
nginx.ingress.kubernetes.io/cors-allow-credentials: "false"
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/enable-cors: "true"
nginx.ingress.kubernetes.io/cors-allow-origin: "example.com"
nginx.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
nginx.ingress.kubernetes.io/cors-allow-headers: "X-Foo-Bar"
nginx.ingress.kubernetes.io/cors-allow-credentials: "false"
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Correspondência por expressão regular
Os Ingresses padrão do Kubernetes aceitam apenas correspondência de caminho do tipo Exact e Prefix. O APIG Ingress também oferece suporte a correspondência por expressão regular. Ative esse recurso com nginx.ingress.kubernetes.io/use-regex: "true" e use um padrão regex como valor do caminho.
Exemplo: Encaminhe qualquer requisição que corresponda a /app/... ou /test/... para o service demo
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/use-regex: "true"
name: regex-match
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo
port:
number: 8080
path: /(app|test)/(.*)
pathType: PrefixClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/use-regex: "true"
name: regex-match
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /(app|test)/(.*)
backend:
serviceName: demo
servicePort: 8080Reescrita de caminho e host
A reescrita modifica o caminho ou o host de uma requisição antes que o APIG Ingress a encaminhe para o service de backend.
|
Annotation |
Descrição |
|
|
Caminho de destino após a reescrita. Aceita grupos de captura. |
|
|
Valor do header Host enviado ao service de backend. |
Reescrita de caminho
Todos os exemplos abaixo utilizam nginx.ingress.kubernetes.io/rewrite-target para modificar o caminho da requisição.
Exemplo 1: Reescreva example.com/test para example.com/dev antes do encaminhamento
Clusters com Kubernetes 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: "/dev"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters anteriores ao Kubernetes 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: "/dev"
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /test
pathType: Exact
backend:
serviceName: demo-service
servicePort: 80Exemplo 2: Remova o prefixo /v1 — reescreva example.com/v1/xxx para example.com/xxx
Clusters com Kubernetes 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: "/$1"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /v1/(.*)
pathType: PrefixClusters anteriores ao Kubernetes 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: "/$1"
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /v1/(.*)
pathType: Prefix
backend:
serviceName: demo-service
servicePort: 80Exemplo 3: Substitua o prefixo /v1 por /v2 — reescreva example.com/v1/xxx para example.com/v2/xxx
Clusters com Kubernetes 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: "/v2/$1"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /v1/(.*)
pathType: PrefixClusters anteriores ao Kubernetes 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: "/v2/$1"
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /v1/(.*)
pathType: Prefix
backend:
serviceName: demo-service
servicePort: 80Reescrita de host
Exemplo: Reescreva o host de example.com para test.com antes do encaminhamento
Clusters com Kubernetes 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-vhost: "test.com"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters anteriores ao Kubernetes 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-vhost: "test.com"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Redirecionamento
Redirecionamento de HTTP para HTTPS
|
Annotation |
Descrição |
|
|
Redireciona requisições HTTP para HTTPS. |
|
|
Redireciona requisições HTTP para HTTPS. |
O APIG Ingress trata ssl-redirect e force-ssl-redirect de forma idêntica — ambos forçam o redirecionamento de HTTP para HTTPS.
Exemplo: Redirecione http://example.com/test para https://example.com/test
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters anteriores à versão 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Redirecionamento permanente
|
Annotation |
Descrição |
Padrão |
|
|
URL de destino para um redirecionamento permanente. Deve incluir o esquema ( |
— |
|
|
Código de status HTTP para o redirecionamento. |
|
Exemplo: Redirecione permanentemente http://example.com/test para http://example.com/app
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/permanent-redirect: "http://example.com/app"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters anteriores à versão 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/permanent-redirect: "http://example.com/app"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Redirecionamento temporário
Use nginx.ingress.kubernetes.io/temporal-redirect para definir a URL de destino de um redirecionamento temporário. A URL deve incluir o esquema (http:// ou https://).
Exemplo: Redirecione temporariamente http://example.com/test para http://example.com/app
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/temporal-redirect: "http://example.com/app"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters anteriores à versão 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/temporal-redirect: "http://example.com/app"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Controle de headers
O controle de headers permite adicionar, atualizar ou remover headers HTTP enquanto o APIG Ingress encaminha requisições para os services de backend e devolve respostas aos clientes.
Controle de headers de requisição
As três annotations compartilham a mesma sintaxe para múltiplos headers: um único header usa um par chave-valor; vários headers usam o bloco escalar YAML | com um par chave-valor por linha.
|
Annotation |
Descrição |
|
|
Adiciona um header à requisição encaminhada. Se o header já existir, o valor é anexado. |
|
|
Atualiza um header na requisição encaminhada. Se o header já existir, o valor é sobrescrito. |
|
|
Remove um header da requisição encaminhada. Separe vários nomes de headers com vírgulas. |
Exemplo 1: Adicione os headers foo: bar e test: true a todas as requisições para example.com/test
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/request-header-control-add: |
foo bar
test true
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/request-header-control-add: |
foo bar
test true
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Exemplo 2: Combine controle de headers com canary releases para marcar o tráfego por estágio de deployment
Quando apig: v1 está presente no header da requisição, o APIG Ingress roteia para o canary e adiciona stage: gray. Todas as outras requisições vão para a versão base e recebem stage: production.
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "apig"
nginx.ingress.kubernetes.io/canary-by-header-value: "v1"
higress.ingress.kubernetes.io/request-header-control-add: "stage gray"
name: demo-canary-v1
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service-canary-v1
port:
number: 80
path: /hello
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/request-header-control-add: "stage production"
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "apig"
nginx.ingress.kubernetes.io/canary-by-header-value: "v1"
higress.ingress.kubernetes.io/request-header-control-add: "stage gray"
name: demo-canary-v1
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary-v1
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/request-header-control-add: "stage production"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Controle de headers de resposta
|
Annotation |
Descrição |
|
|
Adiciona um header à resposta antes do encaminhamento ao cliente. Se o header já existir, o valor é anexado. |
|
|
Atualiza um header na resposta antes do encaminhamento ao cliente. Se o header já existir, o valor é sobrescrito. |
|
|
Remove um header da resposta antes do encaminhamento ao cliente. Separe vários nomes de headers com vírgulas. |
Exemplo: Remova o header req-cost-time das respostas para example.com/test
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/response-header-control-remove: "req-cost-time"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/response-header-control-remove: "req-cost-time"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Retry
O APIG Ingress tenta novamente requisições com falha automaticamente no nível da rota. Configure o número máximo de tentativas, o timeout e as condições que acionam uma nova tentativa.
|
Annotation |
Descrição |
Padrão |
|
|
Número máximo de tentativas. |
|
|
|
Timeout para tentativas, em segundos. |
Sem timeout |
|
|
Lista de condições para nova tentativa, separada por vírgulas. |
|
Condições válidas para nova tentativa:
|
Condição |
Descrição |
|
|
Falha no estabelecimento da conexão ou retorno de código de status 5xx. |
|
|
Timeout no estabelecimento da conexão ou retorno de código de status 5xx. |
|
|
Erro na requisição ou retorno de código de status 5xx. |
|
|
Tenta novamente em um código de status HTTP específico (por exemplo, |
|
|
Habilita tentativas para requisições não idempotentes (POST, PATCH). Por padrão, essas requisições não sofrem nova tentativa. |
|
|
Desativa totalmente as tentativas. |
Exemplo: Tente até 2 vezes em 5 segundos, apenas em HTTP 502, e tente novamente também requisições não idempotentes
Clusters com Kubernetes 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "2"
nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: "5"
nginx.ingress.kubernetes.io/proxy-next-upstream: "http_502,non_idempotent"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "2"
nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: "5"
nginx.ingress.kubernetes.io/proxy-next-upstream: "http_502,non_idempotent"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Controle de acesso por IP
O APIG Ingress oferece suporte a listas de permissões e listas de bloqueios de endereços IP tanto no nível da rota quanto no nível do domínio. As regras no nível da rota têm precedência sobre as regras no nível do domínio.
Controle de acesso por IP no nível da rota
|
Annotation |
Descrição |
|
|
Lista de permissões para uma rota específica. Aceita endereços IP e blocos CIDR, separados por vírgulas. |
|
|
Lista de bloqueios para uma rota específica. Aceita endereços IP e blocos CIDR, separados por vírgulas. |
Exemplo 1: Permita acesso a example.com/test apenas de 1.1.X.X
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/whitelist-source-range: 1.1.X.X
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/whitelist-source-range: 1.1.X.X
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Exemplo 2: Bloqueie acesso a example.com/test de 2.2.2.2
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/blacklist-source-range: 2.2.2.2
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/blacklist-source-range: 2.2.2.2
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Controle de acesso por IP no nível do domínio
|
Annotation |
Descrição |
|
|
Lista de permissões aplicada a todas as rotas sob um domínio. Listas de permissões no nível da rota têm precedência. Aceita endereços IP e blocos CIDR, separados por vírgulas. |
|
|
Lista de bloqueios aplicada a todas as rotas sob um domínio. Listas de bloqueios no nível da rota têm precedência. Aceita endereços IP e blocos CIDR, separados por vírgulas. |
Exemplo 1: Permita acesso a todas as rotas sob example.com de 1.1.X.X e 2.2.2.2
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: Exact
- backend:
service:
name: app-service
port:
number: 80
path: /app
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80
- path: /app
backend:
serviceName: app-service
servicePort: 80Exemplo 2: Combine listas de permissões no nível do domínio e da rota — restrinja /order a 3.3.X.X enquanto permite 1.1.X.X e 2.2.2.2 em todas as outras rotas
Clusters com versão 1,19 e posterior
# Domain-level allowlist for /test and /app
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2
name: demo-domain
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: Exact
- backend:
service:
name: app-service
port:
number: 80
path: /app
pathType: Exact
---
# Route-level allowlist overrides domain-level for /order
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/whitelist-source-range: 3.3.X.X
name: demo-route
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /order
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2
name: demo-domain
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80
- path: /app
backend:
serviceName: app-service
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/whitelist-source-range: 3.3.X.X
name: demo-route
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /order
backend:
serviceName: demo-service
servicePort: 80Limitação de taxa por gateway
A limitação de taxa por gateway restringe a taxa de requisições de uma rota específica em cada instância do Cloud-native API Gateway. O limite se aplica por réplica do gateway, e não em todo o cluster.
Os limites de taxa se aplicam por réplica do gateway. Se você executar várias réplicas ou usar um Horizontal Pod Autoscaler (HPA), o limite efetivo em todo o cluster será o valor configurado multiplicado pelo número de réplicas. Para um limite global que não seja afetado pela contagem de réplicas, use o controle global de limitação de taxa.
|
Annotation |
Descrição |
Padrão |
|
|
Máximo de requisições por minuto (RPM) por instância do gateway. Quando o limite é excedido, o corpo da resposta é |
— |
|
|
Máximo de requisições por segundo (RPS) por instância do gateway. Quando o limite é excedido, o corpo da resposta é |
— |
|
|
Multiplicador do limite de pico. O limite de pico equivale ao valor de RPM ou RPS multiplicado por este número. |
|
O código de status da resposta quando a limitação é acionada depende da versão do seu gateway:
Versão do gateway anterior a 1.2.23: HTTP 503
Versão do gateway 1.2.23 ou posterior: HTTP 429
Exemplo 1: Limite example.com/test a 100 RPM com limite de pico de 200 (multiplicador 2)
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/route-limit-rpm: "100"
higress.ingress.kubernetes.io/route-limit-burst-multiplier: "2"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/route-limit-rpm: "100"
higress.ingress.kubernetes.io/route-limit-burst-multiplier: "2"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Exemplo 2: Limite example.com/test a 10 RPS com o limite de pico padrão (multiplicador 5, pico = 50)
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/route-limit-rps: "10"
# Default burst multiplier is 5; burst limit = 50
# higress.ingress.kubernetes.io/route-limit-burst-multiplier: "5"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/route-limit-rps: "10"
# Default burst multiplier is 5; burst limit = 50
# higress.ingress.kubernetes.io/route-limit-burst-multiplier: "5"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Controle global de limitação de taxa
Este recurso requer a versão 1.2.25 ou posterior do gateway APIG Ingress.
O controle global de limitação de taxa integra-se ao Sentinel para impor um limite de RPS em todo o cluster para uma rota específica. Quando o limite é excedido, a resposta padrão é HTTP 429 com o corpo sentinel rate limited. É possível substituir esse comportamento por uma resposta personalizada ou um redirecionamento — mas não ambos simultaneamente.
Resposta personalizada
|
Annotation |
Descrição |
Padrão |
|
|
RPS máximo para a rota em todo o cluster de gateways. |
— |
|
|
Código de status HTTP quando a limitação é acionada. |
|
|
|
Formato do corpo da resposta: |
|
|
|
Conteúdo do corpo da resposta quando a limitação é acionada. |
|
Exemplo 1: Limite example.com/test a 100 RPS com a resposta de limitação padrão
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/rate-limit: "100"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/rate-limit: "100"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Exemplo 2: Limite example.com/test a 100 RPS; retorne HTTP 503 com o corpo server is overload quando limitado
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/rate-limit: "100"
higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-code: "503"
higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-body: "server is overload"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/rate-limit: "100"
higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-code: "503"
higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-body: "server is overload"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Redirecionamento
Use higress.ingress.kubernetes.io/rate-limit-fallback-redirect-url para redirecionar clientes a uma URL alternativa quando a limitação for acionada.
Exemplo: Limite example.com/test a 100 RPS; redirecione para example.com/fallback quando limitado
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/rate-limit: "100"
higress.ingress.kubernetes.io/rate-limit-fallback-redirect-url: "example.com/fallback"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/rate-limit: "100"
higress.ingress.kubernetes.io/rate-limit-fallback-redirect-url: "example.com/fallback"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Controle global de concorrência
Este recurso requer a versão 1.2.25 ou posterior do gateway APIG Ingress.
O controle global de concorrência integra-se ao Sentinel para impor um limite de requisições simultâneas em todo o cluster para uma rota específica. Quando o limite é excedido, a resposta padrão é HTTP 429 com o corpo sentinel rate limited. É possível substituir esse comportamento por uma resposta personalizada ou um redirecionamento — mas não ambos simultaneamente.
Resposta personalizada
|
Annotation |
Descrição |
Padrão |
|
|
Máximo de requisições simultâneas para a rota em todo o cluster de gateways. |
— |
|
|
Código de status HTTP quando o controle de concorrência é acionado. |
|
|
|
Formato do corpo da resposta: |
|
|
|
Conteúdo do corpo da resposta quando o controle de concorrência é acionado. |
|
Exemplo 1: Limite requisições simultâneas para example.com/test a 1.000 com a resposta padrão
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/concurrency-limit: "1000"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/concurrency-limit: "1000"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Exemplo 2: Limite requisições simultâneas a 1.000; retorne HTTP 503 com o corpo server is overloaded quando o limite for atingido
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/concurrency-limit: "1000"
higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-code: "503"
higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-body: "server is overload"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/concurrency-limit: "1000"
higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-code: "503"
higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-body: "server is overload"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Redirecionamento
Use higress.ingress.kubernetes.io/concurrency-limit-fallback-redirect-url para redirecionar clientes a uma URL alternativa quando o controle de concorrência for acionado.
Exemplo: Limite requisições simultâneas a 1.000; redirecione para example.com/fallback quando o limite for atingido
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/concurrency-limit: "1000"
higress.ingress.kubernetes.io/concurrency-limit-fallback-redirect-url: "example.com/fallback"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/concurrency-limit: "1000"
higress.ingress.kubernetes.io/concurrency-limit-fallback-redirect-url: "example.com/fallback"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Espelhamento de tráfego
O espelhamento de tráfego copia o tráfego de requisições em tempo real para um service sombra sem afetar o fluxo original da requisição. Utilize esse recurso para auditoria operacional, testes de tráfego ou validação de novas versões de services em modo sombra.
|
Annotation |
Descrição |
Padrão |
|
|
Service de destino para o tráfego espelhado. Formato: |
— |
|
|
Percentual de tráfego a ser espelhado. Valores válidos: 0–100. |
|
Quando o tráfego espelhado é encaminhado ao service de destino, o APIG Ingress acrescenta automaticamente -shadow ao header Host. Por exemplo, example.com torna-se example.com-shadow. Se o service de destino utilizar o header Host para roteamento ou logs, leve essa reescrita em consideração na configuração do seu service.
Exemplo 1: Espelhe todo o tráfego de example.com/test para test/app:8080
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/mirror-target-service: test/app:8080
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com versões anteriores a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/mirror-target-service: test/app:8080
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Exemplo 2: Espelhe 10% do tráfego de example.com/test para test/app:8080
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/mirror-target-service: test/app:8080
higress.ingress.kubernetes.io/mirror-percentage: "10"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com versões anteriores a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/mirror-target-service: test/app:8080
higress.ingress.kubernetes.io/mirror-percentage: "10"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Protocolos de service de backend
Por padrão, o APIG Ingress encaminha requisições aos services de backend via HTTP. Use a annotation nginx.ingress.kubernetes.io/backend-protocol para alternar para HTTPS ou gRPC.
Se o nome da porta em um resource de Kubernetes Service estiver definido comogrpcouhttp2, o APIG Ingress usará automaticamente gRPC ou HTTP/2 para esse backend — sem necessidade da annotation. Isso difere do NGINX Ingress, que exige a annotation em todos os casos.
Exemplo 1: Encaminhe requisições para um backend HTTPS
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /
pathType: ExactClusters com versões do Kubernetes anteriores a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Exemplo 2: Encaminhe requisições para um backend gRPC
Dois métodos: annotation (explícito) ou nome da porta do Service (convenção sobre configuração).
Método 1 — annotation:
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com versões do Kubernetes anteriores a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Método 2 — Nome da porta do Service (grpc):
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /order
pathType: Exact
---
apiVersion: v1
kind: Service
metadata:
name: demo-service
spec:
ports:
- name: grpc # APIG Ingress detects this and automatically uses gRPC
port: 80
protocol: TCP
selector:
app: demo-serviceClusters com versões do Kubernetes anteriores a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80
---
apiVersion: v1
kind: Service
metadata:
name: demo-service
spec:
ports:
- name: grpc
port: 80
protocol: TCP
selector:
app: demo-serviceAlgoritmos de balanceamento de carga para services de backend
Os algoritmos de balanceamento de carga determinam como o gateway seleciona os nós de backend ao encaminhar requisições.
Algoritmos comuns de balanceamento de carga
Use nginx.ingress.kubernetes.io/load-balance para definir o algoritmo.
|
Valor |
Descrição |
|
|
Distribui requisições entre os nós de backend em rodízio. Este é o padrão. |
|
|
Roteia cada requisição para o nó com o menor número de conexões ativas. |
|
|
Seleciona um nó de backend aleatoriamente. |
O APIG Ingress não oferece suporte ao algoritmo de média móvel ponderada exponencialmente (EWMA). Se o EWMA for configurado, o sistema reverte para round_robin.
Exemplo: Use least connections para o backend demo-service
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/load-balance: "least_conn"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /order
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/load-balance: "least_conn"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Algoritmos de balanceamento de carga baseados em hashing consistente
O hashing consistente garante que requisições com a mesma chave sejam sempre roteadas para o mesmo nó de backend. Esse recurso é útil para aplicações sensíveis a sessão ou localidade de cache. Defina a chave de hash usando nginx.ingress.kubernetes.io/upstream-hash-by.
Tipos de chave de hash suportados:
|
Chave de hash |
Configuração |
Descrição |
|
URI da requisição |
|
Inclui parâmetros de caminho. |
|
Host |
|
O header host da requisição. |
|
IP do cliente |
|
O endereço IP do cliente. |
|
Header da requisição |
|
O valor de um header específico da requisição. |
|
Parâmetro de query |
|
O valor de um parâmetro de query específico da URL. |
Exemplo 1: Roteie todas as requisições do mesmo IP de cliente para o mesmo nó de backend
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Exemplo 2: Roteie requisições com o mesmo valor de header X-Stage para o mesmo nó de backend
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$http_x-stage"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$http_x-stage"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Exemplo 3: Roteie requisições com o mesmo valor de parâmetro de query X-Stage para o mesmo nó de backend
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_x-stage"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_x-stage"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Warmup (inicialização gradual)
O warmup aumenta gradualmente o tráfego para um nó de backend recém-iniciado durante uma janela de tempo especificada. Isso dá ao nó tempo para inicializar caches e compilar código JIT antes de lidar com o pico de tráfego.
Use higress.ingress.kubernetes.io/warmup para definir a janela de warmup em segundos. O warmup vem desativado por padrão.
O warmup só é compatível com os algoritmos de balanceamento de cargaround_robineleast_conn.
Exemplo: Faça o warmup do demo-service durante uma janela de 30 segundos
Clusters com Kubernetes 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/warmup: "30"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/warmup: "30"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Afinidade por cookie (persistência de sessão)
A afinidade por cookie roteia todas as requisições do mesmo cliente para o mesmo nó de backend. O APIG Ingress gera um cookie de afinidade na primeira requisição; as requisições subsequentes carregam o cookie e são roteadas para o mesmo nó.
|
Annotation |
Descrição |
Padrão |
|
|
Tipo de afinidade. O único valor válido é |
— |
|
|
Modo de afinidade: |
|
|
|
Nome do cookie usado como chave de hash. |
|
|
|
Caminho do cookie gerado. Deve corresponder ao caminho do Ingress. |
|
|
|
Tempo de expiração do cookie gerado, em segundos. Tem precedência sobre |
Nível de sessão |
|
|
Tempo de expiração do cookie gerado, em segundos. |
Nível de sessão |
Exemplo 1: Ative a afinidade por cookie com configurações padrão (nome do cookie INGRESSCOOKIE, caminho /, vida útil no nível da sessão)
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/affinity: "cookie"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/affinity: "cookie"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Exemplo 2: Ative a afinidade por cookie com nome de cookie personalizado test, caminho / e expiração de 10 segundos
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "test"
nginx.ingress.kubernetes.io/session-cookie-max-age: "10"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "test"
nginx.ingress.kubernetes.io/session-cookie-max-age: "10"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Pool de conexões
Os pools de conexões limitam quantas conexões uma instância do gateway abre para um service de backend, evitando sobrecarga sob alto tráfego.
|
Annotation |
Descrição |
|
|
Total máximo de conexões TCP entre a instância do gateway e o service de backend. |
|
|
Máximo de conexões TCP entre a instância do gateway e um único Pod de backend. |
|
|
Máximo de requisições HTTP por conexão TCP entre a instância do gateway e o service de backend. |
Exemplo: Limite o gateway a 10 conexões totais e 2 conexões por Pod para o demo-service
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/connection-policy-tcp-max-connection: "10"
higress.ingress.kubernetes.io/connection-policy-tcp-max-connection-per-endpoint: "2"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters anteriores à versão 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/connection-policy-tcp-max-connection: "10"
higress.ingress.kubernetes.io/connection-policy-tcp-max-connection-per-endpoint: "2"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Versões de TLS e suítes de criptografia
Por padrão, o APIG Ingress aceita conexões TLS do TLS 1.0 ao TLS 1.3, usando as seguintes suítes de criptografia:
ECDHE-ECDSA-AES128-GCM-SHA256ECDHE-RSA-AES128-GCM-SHA256ECDHE-ECDSA-AES128-SHAECDHE-RSA-AES128-SHAAES128-GCM-SHA256AES128-SHAECDHE-ECDSA-AES256-GCM-SHA384ECDHE-RSA-AES256-GCM-SHA384ECDHE-ECDSA-AES256-SHAECDHE-RSA-AES256-SHAAES256-GCM-SHA384AES256-SHA
Use as annotations a seguir para restringir o intervalo de versões de TLS ou as suítes de criptografia para um domínio específico:
|
Annotation |
Descrição |
Padrão |
|
|
Versão mínima do TLS. Valores válidos: |
|
|
|
Versão máxima do TLS. Valores válidos: |
|
|
|
Suítes de criptografia permitidas, separadas por vírgulas. Aplica-se apenas a handshakes TLS 1.0–1.2. |
— |
Exemplo: Restrinja example.com apenas ao TLS 1.2
Clusters com versão 1,19 e posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/tls-min-protocol-version: "TLSv1.2"
higress.ingress.kubernetes.io/tls-max-protocol-version: "TLSv1.2"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com versão anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/tls-min-protocol-version: "TLSv1.2"
higress.ingress.kubernetes.io/tls-max-protocol-version: "TLSv1.2"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Autenticação mTLS com services de backend
O TLS unidirecional (via nginx.ingress.kubernetes.io/backend-protocol: "HTTPS", descrito em Protocolos de service de backend) verifica apenas o certificado do backend. Para verificação mútua, configure o mTLS — o backend também verifica um certificado de cliente apresentado pelo gateway.
Use estas annotations para configurar o certificado de cliente que o gateway apresenta:
|
Annotation |
Descrição |
|
|
Certificado de cliente usado pelo gateway para se autenticar perante o service de backend. Formato: |
|
|
Valor de Server Name Indication (SNI) usado durante o handshake TLS. |
|
|
Ativa ou desativa o SNI durante o handshake TLS. |
Exemplo: Configure mTLS entre o gateway e o demo-service usando o certificado default/gateway-cert
Clusters com Kubernetes 1,19 ou posterior
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
nginx.ingress.kubernetes.io/proxy-ssl-secret: "default/gateway-cert"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactClusters com Kubernetes anterior a 1,19
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
nginx.ingress.kubernetes.io/proxy-ssl-secret: "default/gateway-cert"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80