Todos os produtos
Search
Central de documentação

Container Service for Kubernetes:Expor serviços com ALB e Gateway API

Última atualização: Jul 04, 2026

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

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

  1. Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.

  2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Workloads > Custom Resources.

  3. Clique em gateway.networking.k8s.io e visualize o GatewayClass em v1.

    Confirme se existe uma instância de GatewayClass chamada alb.

Console

  1. Faça login no console ACS. No painel de navegação à esquerda, clique em Clusters.

  2. Na página Clusters, clique no nome do cluster desejado. No painel de navegação à esquerda, escolha Workloads > Custom Resources.

  3. 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

  1. Crie um arquivo chamado httpbin.yaml.

    Nota

    Por 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 campo spec.type do Service para NodePort.

    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
  2. Implante a aplicação.

    kubectl apply -f httpbin.yaml

Implantar o Gateway e as rotas

Importante

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.

  1. 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
  2. Implante o Gateway e as regras de roteamento.

    kubectl apply -f gateway.yaml
  3. Aguarde cerca de 2 minutos e verifique o status do Gateway.

    kubectl get gateway alb

    Saída esperada:

    NAME   CLASS   ADDRESS                                                  PROGRAMMED   AGE
    alb    alb     alb-0mwhq4ck6xxxxxxxxx.cn-hangzhou.alb.aliyuncsslb.com   True         2m12s
  4. Verifique o status da rota.

    kubectl describe httproute demo-route|grep Status -A 20

    Saí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
  5. Teste o acesso à aplicação.

    1. Obtenha o endereço do Gateway.

      export ALB_DOMAIN=$(kubectl get gateway alb -n default -o jsonpath='{.status.addresses[?(@.type=="Hostname")].value}')
    2. Acesse a aplicação.

      curl -H "Host: demo.ingress.top" http://${ALB_DOMAIN}/version

      Saí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.

  1. 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: 80

    Este 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ínio filter.ingress.top, o cabeçalho de requisição my-header : foo será adicionado automaticamente à requisição.

  2. Implante a regra de roteamento.

    kubectl apply -f httproute-filter.yaml
  3. Acesse a aplicação.

    curl -H "Host: filter.ingress.top" http://${ALB_DOMAIN}/header

    Saí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.

  1. Crie um arquivo chamado nginx.yaml.

    Conteúdo YAML

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: old-nginx
    spec:
      replicas: 1
      selector:
        matchLabels:
          run: old-nginx
      template:
        metadata:
          labels:
            run: old-nginx
        spec:
          containers:
          - image: registry.cn-hangzhou.aliyuncs.com/acs-sample/old-nginx
            imagePullPolicy: Always
            name: old-nginx
            ports:
            - containerPort: 80
              protocol: TCP
          restartPolicy: Always
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: old-nginx
    spec:
      type: ClusterIP 
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        run: old-nginx
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: new-nginx
    spec:
      replicas: 1
      selector:
        matchLabels:
          run: new-nginx
      template:
        metadata:
          labels:
            run: new-nginx
        spec:
          containers:
          - image: registry.cn-hangzhou.aliyuncs.com/acs-sample/new-nginx
            imagePullPolicy: Always
            name: new-nginx
            ports:
            - containerPort: 80
              protocol: TCP
          restartPolicy: Always
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: new-nginx
    spec:
      type: ClusterIP 
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        run: new-nginx

    O arquivo acima implantará duas aplicações NGINX. O serviço old-nginx retornará a string old, enquanto o serviço new-nginx retornará a string new. Os recursos implantados ficarão no namespace default.

  2. 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-nginx e o serviço new-nginx são idênticos. Portanto, ao acessar a aplicação, a proporção de tráfego entre os serviços new-nginx e old-nginx deve ser de 1:1.

  3. Implante as aplicações e a regra de roteamento.

    kubectl apply -f nginx.yaml
    kubectl apply -f httproute-weight.yaml
  4. Acesse a aplicação 10 vezes.

    for i in {1..10}; do curl -H "Host: weight.ingress.top" http://${ALB_DOMAIN}/; done

    Saída esperada:

    old
    new
    new
    old
    new
    old
    old
    new
    new
    old

    Como observado, o tráfego é dividido na proporção 1:1 entre os serviços new-nginx e old-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.

  1. 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
  2. Crie um Secret TLS.

    kubectl create secret tls ingress.top --key server.key --cert server.crt
  3. 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
  4. Aplique o arquivo gateway-tls.yaml para atualizar o Gateway. A saída abaixo indica que a atualização foi bem-sucedida:

    gateway.gateway.networking.k8s.io/alb configured
  5. 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}:443

    Saí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
    ---
    Nota

    Execute curl -H "Host: demo.ingress.top" -k https://${ALB_DOMAIN}/version para acessar a aplicação. A saída esperada é a mesma apresentada em Testar a aplicação.