Este tópico explica como usar a Gateway API com um Application Load Balancer (ALB) para expor serviços do cluster ao tráfego externo.
Contexto
A Gateway API é um conjunto de recursos no Kubernetes para modelar o tráfego de rede de serviços. O objetivo é criar um modelo de rede de serviços expressivo, extensível e orientado a funções.
A Gateway API consiste em uma coleção de recursos no Kubernetes destinada à modelagem de tráfego de rede. Seu propósito é fornecer um modelo de rede de serviços expressivo, extensível e orientado a papéis.
O ALB Ingress Controller oferece suporte à Gateway API desde a versão 2.17.0. Instale o ALB Ingress Controller para expor serviços por meio de um ALB utilizando a Gateway API.
O ALB Ingress Controller fornece suporte para a Gateway API na versão 2.17.0 e posteriores. Instale o ALB Ingress Controller para utilizar a Gateway API e expor serviços através de um ALB.
Pré-requisitos
Você criou um cluster gerenciado ACK executando Kubernetes 1.24 ou posterior.
Instalou o ALB Ingress Controller versão 2.17 ou superior no cluster.
Instalou a Gateway API versão 1.1.0 ou superior no cluster.
Criou dois vSwitches compatíveis com ALB na Virtual Private Cloud (VPC) do cluster.
Pré-requisitos
Você criou um cluster ACS executando Kubernetes 1.31 ou posterior.
Instalou o ALB Ingress Controller versão 2.17 ou superior no cluster.
Instalou a Gateway API versão 1.3.0 ou superior no cluster.
Criou dois vSwitches compatíveis com ALB na Virtual Private Cloud (VPC) do cluster.
Verifique o ambiente
Se o cluster atender aos pré-requisitos, um recurso GatewayClass chamado alb será criado automaticamente. Siga os passos abaixo para confirmar essa configuração.
Console
Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em .
-
Clique em gateway.networking.k8s.io e visualize o GatewayClass em v1.
Confirme se existe uma instância de GatewayClass chamada alb.
Console
Faça login no console ACS. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do cluster desejado. No painel de navegação à esquerda, escolha Workloads > Custom Resources.
-
Clique em gateway.networking.k8s.io e visualize o GatewayClass em v1.
Confirme se existe uma instância de GatewayClass chamada alb.
kubectl
kubectl get gatewayclass
Saída esperada:
NAME CONTROLLER ACCEPTED AGE
alb gateways.alibabacloud.com/alb/v1 True 1m
Implantar uma aplicação de exemplo
-
Crie um arquivo chamado httpbin.yaml.
NotaPor padrão, o Service da aplicação neste tópico utiliza o tipo
ClusterIP. Caso o tipo de rede do seu cluster seja Flannel, altere o campospec.typedo Service paraNodePort.apiVersion: apps/v1 kind: Deployment metadata: name: go-httpbin namespace: default spec: replicas: 1 selector: matchLabels: app: go-httpbin template: metadata: labels: app: go-httpbin version: v1 spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/mse/go-httpbin args: - "--port=8090" - "--version=v1" imagePullPolicy: Always name: go-httpbin ports: - containerPort: 8090 --- apiVersion: v1 kind: Service metadata: name: go-httpbin namespace: default spec: type: ClusterIP ports: - port: 80 targetPort: 8090 protocol: TCP selector: app: go-httpbin -
Implante a aplicação.
kubectl apply -f httpbin.yaml
Implantar o Gateway e as rotas
Esta operação cria uma instância ALB na nuvem e gera custos. Uma instância ALB criada por um Gateway não é excluída automaticamente junto com o cluster. Para evitar cobranças inesperadas, exclua os recursos do Gateway no cluster antes de excluir o próprio cluster.
-
Crie um arquivo chamado gateway.yaml.
apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: alb namespace: default spec: gatewayClassName: alb listeners: - name: http protocol: HTTP port: 80 hostname: "*.ingress.top" allowedRoutes: namespaces: from: Same --- apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: demo-route spec: parentRefs: # Reference the Gateway resource. - group: gateway.networking.k8s.io kind: Gateway name: alb hostnames: - demo.ingress.top # Set the hostname to demo.ingress.top. rules: - matches: # The matching rule is a path prefix match. - path: type: PathPrefix value: / backendRefs: # The backend is a Service named go-httpbin on port 80. - kind: Service name: go-httpbin port: 80 -
Implante o Gateway e as regras de roteamento.
kubectl apply -f gateway.yaml -
Aguarde cerca de 2 minutos e verifique o status do Gateway.
kubectl get gateway albSaída esperada:
NAME CLASS ADDRESS PROGRAMMED AGE alb alb alb-0mwhq4ck6xxxxxxxxx.cn-hangzhou.alb.aliyuncsslb.com True 2m12s -
Verifique o status da rota.
kubectl describe httproute demo-route|grep Status -A 20Saída esperada:
Status: Parents: Conditions: Last Transition Time: 2025-05-23T08:21:25Z Message: Route is accepted. Observed Generation: 1 Reason: Accepted Status: True Type: Accepted Last Transition Time: 2025-05-23T08:21:25Z Message: Route is resolved. Observed Generation: 1 Reason: ResolvedRefs Status: True Type: ResolvedRefs Controller Name: gateways.alibabacloud.com/alb/v1 Parent Ref: Group: gateway.networking.k8s.io Kind: Gateway Name: alb -
Teste o acesso à aplicação.
-
Obtenha o endereço do Gateway.
export ALB_DOMAIN=$(kubectl get gateway alb -n default -o jsonpath='{.status.addresses[?(@.type=="Hostname")].value}') -
Acesse a aplicação.
curl -H "Host: demo.ingress.top" http://${ALB_DOMAIN}/versionSaída esperada:
version: v1 hostname: go-httpbin-547xxxxxf6-xxxxx
-
Casos de uso
Caso de uso 1: Modifique cabeçalhos de requisição
A HTTPRoute suporta filtros para processamento adicional durante a fase de requisição ou resposta. O exemplo a seguir utiliza um filtro para adicionar um cabeçalho às requisições enviadas ao backend.
-
Crie um arquivo chamado httproute-filter.yaml.
apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: demo-filter spec: parentRefs: # Reference the Gateway resource. - group: gateway.networking.k8s.io kind: Gateway name: alb hostnames: - filter.ingress.top # Set the hostname to filter.ingress.top. rules: - matches: # The matching rule is a path prefix match. - path: type: PathPrefix value: / filters: - type: RequestHeaderModifier # Add the request header my-header: foo. requestHeaderModifier: add: - name: my-header value: foo backendRefs: # The backend is a Service named go-httpbin on port 80. - kind: Service name: go-httpbin port: 80Este arquivo criará um recurso HTTPRoute chamado
demo-filter. Após a implantação, ao acessar a aplicação go-httpbin usando o nome de domíniofilter.ingress.top, o cabeçalho de requisiçãomy-header : fooserá adicionado automaticamente à requisição. -
Implante a regra de roteamento.
kubectl apply -f httproute-filter.yaml -
Acesse a aplicação.
curl -H "Host: filter.ingress.top" http://${ALB_DOMAIN}/headerSaída esperada:
headers: { "Accept": [ "*/*" ], "Connection": [ "close" ], "Host": [ "filter.ingress.top" ], "My-Header": [ "foo" ], "Path": [ "/header" ], "Protocol": [ "HTTP/1.1" ], "Remoteip": [ "118.xx.xx.91" ], "URL": [ "/header" ], "User-Agent": [ "curl/8.9.1" ] } query param: , hostname: go-httpbin-547xxxxxf6-xxxxx
Caso de uso 2: Dividir tráfego por peso
Ao definir pesos para múltiplos serviços de backend, é possível dividir o tráfego entre eles.
-
Crie um arquivo chamado nginx.yaml.
O arquivo acima implantará duas aplicações NGINX. O serviço
old-nginxretornará a stringold, enquanto o serviçonew-nginxretornará a stringnew. Os recursos implantados ficarão no namespacedefault. -
Crie um arquivo chamado httproute-weight.yaml.
apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: demo-weight spec: parentRefs: # Reference the Gateway resource. - group: gateway.networking.k8s.io kind: Gateway name: alb hostnames: - weight.ingress.top # Set the hostname to weight.ingress.top. rules: - matches: # The matching rule is a path prefix match. - path: type: PathPrefix value: / backendRefs: # Set backends and their corresponding weights. Weights are not percentages and do not need to sum to 100. - kind: Service name: old-nginx port: 80 weight: 100 # Set the weight of old-nginx to 100. - kind: Service name: new-nginx port: 80 weight: 100 # Set the weight of new-nginx to 100.Nesta regra de roteamento, os pesos para o serviço
old-nginxe o serviçonew-nginxsão idênticos. Portanto, ao acessar a aplicação, a proporção de tráfego entre os serviçosnew-nginxeold-nginxdeve ser de 1:1. -
Implante as aplicações e a regra de roteamento.
kubectl apply -f nginx.yaml kubectl apply -f httproute-weight.yaml -
Acesse a aplicação 10 vezes.
for i in {1..10}; do curl -H "Host: weight.ingress.top" http://${ALB_DOMAIN}/; doneSaída esperada:
old new new old new old old new new oldComo observado, o tráfego é dividido na proporção 1:1 entre os serviços
new-nginxeold-nginx.
Operações relacionadas
Configure um certificado para uma aplicação
É possível configurar um certificado TLS para sua aplicação diretamente no recurso Gateway.
-
Crie um certificado autoassinado para o nome de domínio
ingress.tap.openssl req -subj '/CN=ingress.top' -new -newkey rsa:2048 -sha256 \ -days 365 -nodes -x509 -keyout server.key -out server.crt \ -addext "subjectAltName = DNS:ingress.top" \ -addext "keyUsage = digitalSignature" \ -addext "extendedKeyUsage = serverAuth" 2> /dev/null; openssl x509 -in server.crt -subject -noout -
Crie um Secret TLS.
kubectl create secret tls ingress.top --key server.key --cert server.crt -
Crie um arquivo chamado gateway-tls.yaml para atualizar o Gateway.
apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: alb namespace: default spec: gatewayClassName: alb listeners: - name: http protocol: HTTP port: 80 hostname: "*.ingress.top" allowedRoutes: namespaces: from: Same - name: https protocol: HTTPS port: 443 hostname: "*.ingress.top" allowedRoutes: namespaces: from: Same tls: # Configure TLS. mode: Terminate certificateRefs: # Reference the created Secret. - kind: Secret name: ingress.top -
Aplique o arquivo
gateway-tls.yamlpara atualizar o Gateway. A saída abaixo indica que a atualização foi bem-sucedida:gateway.gateway.networking.k8s.io/alb configured -
Aguarde até que o status Programmed do Gateway se torne True e, em seguida, verifique a configuração do certificado.
openssl s_client -servername ingress.top -connect ${ALB_DOMAIN}:443Saída esperada:
CONNECTED(00000003) depth=0 CN = ingress.top verify error:num=18:self-signed certificate verify return:1 depth=0 CN = ingress.top verify return:1 --- Certificate chain 0 s:CN = ingress.top i:CN = ingress.top a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Jun 24 10:49:39 2025 GMT; NotAfter: Jun 24 10:49:39 2026 GMT --- Server certificate -----BEGIN CERTIFICATE----- ... ... ... -----END CERTIFICATE----- subject=CN = ingress.top issuer=CN = ingress.top --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 1506 bytes and written 410 bytes Verification error: self-signed certificate --- New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: xxxxxxxxxxxxxxxxxxxxxxxxx Session-ID-ctx: Master-Key: xxxxxxxxxxxxxxxxxxxxxxxxxxx PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: ... ... ... Start Time: 1750820008 Timeout : 7200 (sec) Verify return code: 18 (self-signed certificate) Extended master secret: yes ---NotaExecute
curl -H "Host: demo.ingress.top" -k https://${ALB_DOMAIN}/versionpara acessar a aplicação. A saída esperada é a mesma apresentada em Testar a aplicação.