ALB Ingress quick start - route traffic by URL path - Container Compute Service: Central de Documentação do Alibaba Cloud

O ALB Ingress oferece gerenciamento de tráfego na camada 7, baseado no Application Load Balancer (ALB) do Alibaba Cloud, com suporte a HTTP, HTTPS e QUIC. Este tutorial demonstra como rotear o tráfego para diferentes services de backend com base no caminho da URL.

Como funciona o ALB Ingress

Conceitos principais:

ALB Ingress Controller: este componente gerencia os resources de Ingress. Ele recupera dinamicamente as alterações nos resources de Ingress e AlbConfig diretamente do API Server do cluster e atualiza as instâncias do ALB conforme necessário. Diferentemente do NGINX Ingress Controller, o ALB Ingress Controller atua como plano de controle para as instâncias do ALB. Ele administra essas instâncias, mas não processa o tráfego do usuário diretamente; em vez disso, as próprias instâncias do ALB encaminham o tráfego. O ALB Ingress Controller obtém as mudanças nos resources de Ingress por meio do API Server do cluster e aplica as atualizações nas instâncias do ALB seguindo as regras de encaminhamento definidas no Ingress.
Um AlbConfig é uma Custom Resource Definition (CRD) no nível do cluster, criada pelo ALB Ingress Controller. Cada AlbConfig contém parâmetros que definem a configuração de uma única instância do ALB. Essa instância funciona como ponto de entrada do tráfego e encaminha as requisições aos services de backend. Ela é totalmente gerenciada pelo Application Load Balancer (ALB). Ao contrário do Nginx Ingress Controller, o ALB Ingress não exige operações e manutenção (O&M) e oferece maior elasticidade.
IngressClass: define a associação entre um Ingress e um AlbConfig.
Ingress: no Kubernetes, o Ingress é um objeto de resource que estabelece as regras de acesso e roteamento de tráfego externo. O ALB Ingress Controller monitora alterações nos resources de Ingress e atualiza as instâncias do ALB para realizar o encaminhamento do tráfego.
Service: ponto de entrada estável para um conjunto de Pods com a mesma função. Outras aplicações acessam os Pods de backend por meio do IP virtual e da porta do Service, sem depender das alterações individuais de cada Pod.

A figura a seguir ilustra a relação entre uma instância do ALB e o ALB Ingress.

Limitações

Os nomes dos resources AlbConfig, namespace, ingress e service não devem começar com aliyun.

Cenário de exemplo

Este tutorial implanta quatro Pods do Nginx e configura o ALB Ingress para rotear o tráfego por caminho de URL sob o mesmo domínio.

Requisição frontend	Service de backend
`demo.domain.ingress.top/coffee`	Service `coffee`
`demo.domain.ingress.top/tea`	Service `tea`

Pré-requisitos

Você já instalou o ALB Ingress Controller.
Você criou dois vSwitches em zonas de disponibilidade diferentes dentro da VPC do seu cluster. Consulte Criar e gerenciar vSwitches.

Etapa 1: Implantar o service de backend

Usando o console

Faça login no console do 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 > Deployments.
Na página Deployments, clique em Create from YAML no canto superior direito.

Na página Create, configure os parâmetros.

Sample Template: Selecione Custom.

Template: Insira a configuração YAML para implantar dois Deployments (coffee e tea) e dois Services (coffee-svc e tea-svc).

Exemplo de YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: coffee
spec:
  replicas: 2
  selector:
    matchLabels:
      app: coffee
  template:
    metadata:
      labels:
        app: coffee
    spec:
      containers:
      - name: coffee
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: coffee
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tea
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tea
  template:
    metadata:
      labels:
        app: tea
    spec:
      containers:
      - name: tea
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: tea-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: tea
  type: ClusterIP

Clique em Create. A mensagem Created. será exibida.
Verifique se os Deployments e Services foram criados.
1. No painel de navegação à esquerda, escolha Workloads > Stateless. Os Deployments chamados coffee e tea aparecerão na lista.
2. No painel de navegação à esquerda, escolha Network > Services. Os Services chamados coffee-svc e tea-svc estarão visíveis.

Usando kubectl

Crie um arquivo chamado cafe-service.yaml com o conteúdo abaixo. Isso implantará dois Deployments (coffee e tea) e dois Services (coffee-svc e tea-svc).

Referência do arquivo de configuração YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: coffee
spec:
  replicas: 2
  selector:
    matchLabels:
      app: coffee
  template:
    metadata:
      labels:
        app: coffee
    spec:
      containers:
      - name: coffee
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: coffee
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tea
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tea
  template:
    metadata:
      labels:
        app: tea
    spec:
      containers:
      - name: tea
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: tea-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: tea
  type: ClusterIP

Execute o comando a seguir para implantar os resources.

kubectl apply -f cafe-service.yaml

Saída esperada:

deployment "coffee" created
service "coffee-svc" created
deployment "tea" created
service "tea-svc" created

Valide os Deployments e Services criados.

Verifique os Deployments.

kubectl get deployment

Saída esperada:

NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
coffee                           2/2     2            2           2m26s
tea                              2/2     2            2           2m26s

Confira os Services.

kubectl get svc

Saída esperada:

NAME                          TYPE            CLUSTER-IP       EXTERNAL-IP           PORT(S)           AGE
coffee-svc                    ClusterIP       172.16.XX.XX     <none>                80/TCP            9m38s
tea-svc                       ClusterIP       172.16.XX.XX     <none>                80/TCP            9m38s

Etapa 2: Criar um AlbConfig

Console

Faça login no console do ACS. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do cluster alvo. No painel de navegação à esquerda, escolha Workloads > Custom Resources.

Na aba CRDs, clique em Create from YAML.

Sample Template: Selecione Custom.

Template: Cole o manifesto YAML.

Exemplo de configuração YAML

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb-demo
spec:
  config:
    name: alb-test
    addressType: Internet
    zoneMappings:                          # To ensure high availability, select vSwitches in at least two different availability zones.
    - vSwitchId: vsw-uf6ccg2a9g71hx8go**** # Replace with the actual vSwitch ID (in availability zone 1).
    - vSwitchId: vsw-uf6nun9tql5t8nh15**** # Replace with the actual vSwitch ID (in availability zone 2, which must be different from the preceding one).
  listeners:
    - port: 80
      protocol: HTTP

A tabela a seguir descreve os parâmetros.

Parâmetro	Obrigatório	Descrição
`metadata.name`	Sim	Nome do AlbConfig. Nota O nome do AlbConfig deve ser exclusivo dentro do cluster para evitar conflitos.
`spec.config.name`	Não	Nome da instância do ALB.
`spec.config.addressType`	Não	Tipo de rede da instância do ALB. Valores válidos: Internet (padrão): a instância fornece services de balanceamento de carga públicos pela internet. Nota Instâncias do ALB voltadas para a Internet usam um Elastic IP Address (EIP). Há cobrança pela instância EIP, largura de banda e transferência de dados. Pay-as-you-go. Intranet: a instância fornece services de balanceamento de carga privados dentro de uma VPC.
`spec.config.zoneMappings`	Sim	IDs dos vSwitches para a instância do ALB. Para instruções sobre como criar um vSwitch, consulte Criar e gerenciar vSwitches. Nota Os vSwitches devem estar em uma zona de disponibilidade suportada pelo ALB e na mesma VPC do cluster. Consulte Regiões e zonas de disponibilidade suportadas pelo ALB. Se sua região oferecer múltiplas zonas de disponibilidade, recomenda-se selecionar vSwitches de pelo menos duas zonas diferentes para garantir alta disponibilidade.
`spec.listeners`	Não	Porta e protocolo do listener. Este exemplo usa HTTP na porta 80. O ALB Ingress requer um listener. Mantenha este padrão para evitar configurações manuais.

Clique em Create. A mensagem Created. será exibida.
Verifique a instância do ALB:
1. Faça login no console do Application Load Balancer (ALB).
2. Na barra de navegação superior, selecione a região da instância.
3. Na página Instance, confirme que a instância do ALB chamada alb-test aparece na lista de instâncias.

Kubectl

Copie o conteúdo seguinte para um arquivo chamado alb-test.yaml a fim de criar um AlbConfig.

Exemplo de configuração YAML

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb-demo
spec:
  config:
    name: alb-test
    addressType: Internet
    zoneMappings:                          # To ensure high availability, select vSwitches in at least two different availability zones.
    - vSwitchId: vsw-uf6ccg2a9g71hx8go**** # Replace with the actual vSwitch ID (in availability zone 1).
    - vSwitchId: vsw-uf6nun9tql5t8nh15**** # Replace with the actual vSwitch ID (in availability zone 2, which must be different from the preceding one).
  listeners:
    - port: 80
      protocol: HTTP

A tabela a seguir descreve os parâmetros.

Parâmetro	Obrigatório	Descrição
`metadata.name`	Sim	Nome do AlbConfig. Nota O nome do AlbConfig deve ser exclusivo dentro do cluster para evitar conflitos.
`spec.config.name`	Não	Nome da instância do ALB.
`spec.config.addressType`	Não	Tipo de rede da instância do ALB. Valores válidos: Internet (padrão): a instância fornece services de balanceamento de carga públicos pela internet. Nota Instâncias do ALB voltadas para a Internet usam um Elastic IP Address (EIP). Há cobrança pela instância EIP, largura de banda e transferência de dados. Pay-as-you-go. Intranet: a instância fornece services de balanceamento de carga privados dentro de uma VPC.
`spec.config.zoneMappings`	Sim	IDs dos vSwitches para a instância do ALB. Para instruções sobre como criar um vSwitch, consulte Criar e gerenciar vSwitches. Nota Os vSwitches devem estar em uma zona de disponibilidade suportada pelo ALB e na mesma VPC do cluster. Consulte Regiões e zonas de disponibilidade suportadas pelo ALB. Se sua região oferecer múltiplas zonas de disponibilidade, recomenda-se selecionar vSwitches de pelo menos duas zonas diferentes para garantir alta disponibilidade.
`spec.listeners`	Não	Porta e protocolo do listener. Este exemplo usa HTTP na porta 80. O ALB Ingress requer um listener. Mantenha este padrão para evitar configurações manuais.

Execute o comando a seguir para criar o AlbConfig.
```
kubectl apply -f alb-test.yaml
```
Saída esperada:
```
albconfig.alibabacloud.com/alb-demo created
```
Essa saída confirma que o AlbConfig foi criado.

Etapa 3: Criar a IngressClass

Recomenda-se criar uma IngressClass para cada AlbConfig.

Console

Faça login no console do ACS. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do cluster alvo. No painel de navegação à esquerda, escolha Workloads > Custom Resources.

Na aba CRDs, clique em Create from YAML.

Sample Template: Selecione Custom.

Template: Insira o manifesto YAML.

Exemplo de configuração YAML

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: alb
spec:
  controller: ingress.k8s.alibabacloud/alb
  parameters:
    apiGroup: alibabacloud.com
    kind: AlbConfig
    name: alb-demo

A tabela a seguir descreve os parâmetros.

Parâmetro	Obrigatório	Descrição
metadata.name	Sim	Nome da IngressClass. Nota O nome deve ser exclusivo dentro do cluster.
spec.parameters.name	Sim	Nome do AlbConfig associado.

Clique em Create. Uma mensagem de confirmação será exibida.
Verifique se a IngressClass foi criada:
1. No painel de navegação à esquerda, escolha Workloads > Custom Resources.
2. Clique na aba Resource Objects.
3. Na caixa de pesquisa API Group, insira IngressClass. A IngressClass criada aparecerá na lista.

Kubectl

Crie um arquivo chamado alb.yaml com o conteúdo a seguir.

Exemplo de configuração YAML

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: alb
spec:
  controller: ingress.k8s.alibabacloud/alb
  parameters:
    apiGroup: alibabacloud.com
    kind: AlbConfig
    name: alb-demo

A tabela a seguir descreve os parâmetros.

Parâmetro	Obrigatório	Descrição
`metadata.name`	Sim	Nome da IngressClass. Nota O nome deve ser exclusivo dentro do cluster.
`spec.parameters.name`	Sim	Nome do AlbConfig associado.

Execute o comando a seguir para criar a IngressClass.
```
kubectl apply -f alb.yaml
```
Saída esperada:
```
ingressclass.networking.k8s.io/alb created
```

Etapa 4: Criar um Ingress

Console

Faça login no console do ACS. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do cluster alvo. No painel de navegação à esquerda, escolha Network > Ingresses.

Na página Ingress, clique em Create Ingress. Na caixa de diálogo Create Ingress, configure o Ingress.

Parâmetro	Descrição	Valor de exemplo
Gateway Type	Selecione o tipo de gateway. As opções incluem ALB e MSE.	ALB Ingress
Name	Um nome personalizado para o Ingress.	cafe-ingress
IngressClass	Uma classe personalizada para o Ingress.	alb
Rules	Clique em +Add Rule para adicionar várias regras de roteamento. Domain Name: Um nome de domínio personalizado. Mappings: Configure os seguintes parâmetros. Path: O caminho da URL para acessar o service. Neste exemplo, este parâmetro é deixado vazio para usar o caminho raiz /. Rule: Suporta Prefix (Prefix-based Match), Exact (Exact Match) e ImplementationSpecific (Default Value). Service: O backend alvo, que é um Service do Kubernetes. Port: A porta exposta pelo service. Um Ingress suporta múltiplos caminhos sob o mesmo nome de domínio. Clique em +Add para adicionar um novo caminho.	Domain Name: demo.domain.ingress.top Path mapping: Path: /tea Rule: ImplementationSpecific Service: tea-svc Port: 80 Mappings: Path: /coffee Rule: ImplementationSpecific Service: coffee-svc Port: 80
TLS Settings	Ative esta opção para proteger o Ingress com um certificado TLS (HTTPS). Domain Name: Insira um nome de domínio personalizado. Secret: Selecione o Secret que contém o certificado TLS. Para criar um Secret, execute as seguintes etapas: À direita de Secret, clique em Create. Na caixa de diálogo Create Secret, defina o Name, Cert e Key e clique em OK. Na lista suspensa Secret, selecione o Secret que você criou. Clique em Add para configurar múltiplas definições de TLS. Para mais informações, consulte Configurar um certificado HTTPS para comunicação criptografada.	Mantenha as TLS Settings desativadas. Esta configuração não é necessária para este exemplo.
More	Canary Release: Ative o switch de canary release. Você pode definir regras canary com base em cabeçalhos de requisição, cookies ou pesos. Nota É possível definir regras baseadas em cabeçalho de requisição, cookie ou peso. Se você configurar vários tipos de regra, elas serão correspondidas na seguinte ordem de precedência: cabeçalho de requisição, cookie e depois peso. Based on Request Header: Divide o tráfego com base no cabeçalho da requisição. Se você configurar essa definição, as annotations `alb.ingress.kubernetes.io/canary-by-header` e `alb.ingress.kubernetes.io/canary-by-header-value` serão adicionadas. Based on Cookie: Divide o tráfego com base em um cookie. Se você configurar essa definição, a annotation `alb.ingress.kubernetes.io/canary-by-cookie` será adicionada. Based on Weight: Define a porcentagem de requisições a serem roteadas para um service específico. O valor deve ser um número inteiro de 0 a 100. Se você configurar essa definição, a annotation `alb.ingress.kubernetes.io/canary-weight` será adicionada. Protocol: Suporta services de backend que usam os protocolos HTTPS e gRPC. Configurar esta definição adiciona a annotation `alb.ingress.kubernetes.io/backend-protocol`. Rewrite Path: Reescreve o caminho da requisição antes de encaminhá-la ao service de backend. Esta definição adiciona a annotation alb.ingress.kubernetes.io/rewrite-target.	Mantenha o canary release desativado e preserve as configurações padrão de protocolo e reescrita de caminho. Essas configurações não são necessárias para este exemplo.
Custom Forwarding Rules	Ative regras de encaminhamento personalizadas para gerenciar o tráfego de entrada com controle refinado. Nota Você pode adicionar no máximo 10 entradas de condição a uma regra de encaminhamento. Na lista suspensa Add Condition, selecione uma opção: Domain Name: Corresponde ao domínio da requisição. Se você especificar vários domínios, uma requisição será correspondida se usar qualquer um dos domínios especificados. Quando você configura essa condição, a annotation `alb.ingress.kubernetes.io/conditions.host-example` é adicionada. Path: Corresponde ao caminho da requisição. Se você especificar vários caminhos, uma requisição será correspondida se usar qualquer um dos caminhos especificados. Quando você configura essa condição, a annotation `alb.ingress.kubernetes.io/conditions.path-example` é adicionada. HTTP Header: Corresponde ao cabeçalho da requisição como um par chave-valor. Por exemplo, Key é `headername` e Value é `headervalue1`. Se vários valores de cabeçalho forem configurados, a relação entre eles será OR. Quando você configura essa condição, a annotation `alb.ingress.kubernetes.io/conditions.http-header-example` é adicionada. Na lista suspensa Action, selecione uma opção: Forward To Encaminha requisições para um ou mais services de backend com base no peso. No campo Service, selecione o service alvo. No campo Port, selecione o número da porta alvo. Em seguida, especifique um peso. Nota Se você selecionar esta ação, não precisará configurar path mapping na regra. Return Fixed Response Configura o ALB para retornar uma resposta fixa ao cliente. Você pode definir o código de status da resposta, o conteúdo do corpo e o tipo de conteúdo. Conforme necessário, configure Response Status Code, Response Content Type (Optional) e Response Content (Optional). Response Body Type: text/plain: texto simples. text/css: conteúdo CSS. text/html: conteúdo HTML. application/javascript: conteúdo JavaScript. application/json: conteúdo JSON. As regras de encaminhamento personalizadas suportam condições baseadas em domínio, caminho ou cabeçalho HTTP, além de ações como encaminhamento para um service ou retorno de uma resposta fixa. Consulte Personalizar regras de encaminhamento para um ALB Ingress.	Mantenha as regras de encaminhamento personalizadas desativadas. Esta configuração não é necessária para este exemplo.
Annotations	Você pode especificar um nome e valor de annotation personalizados, ou selecionar/pesquisar uma annotation para configurar. Para mais informações sobre annotations de Ingress, consulte Annotations.	Não necessário para este exemplo.
Labels	Especifica rótulos a serem adicionados ao Ingress. Rótulos são pares chave-valor anexados a objetos para especificar atributos de identificação.	Não necessário para este exemplo.

No canto inferior esquerdo da página Create Ingress, clique em OK.
Verifique o Ingress:
1. No painel de navegação à esquerda, escolha Network > Routes. O Ingress cafe-ingress aparecerá na lista.
2. A coluna Endpoint do cafe-ingress exibirá o endereço do endpoint.

kubectl

Crie um arquivo chamado cafe-ingress.yaml e adicione o seguinte conteúdo:

Referência do arquivo de configuração YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress 
spec:
  ingressClassName: alb
  rules:
   - host: demo.domain.ingress.top
     http:
      paths:
      # Configure the context path
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      # Configure the context path
      - path: /coffee
        pathType: ImplementationSpecific
        backend:
          service:
            name: coffee-svc
            port: 
              number: 80

A tabela a seguir descreve os parâmetros.

Parâmetro	Obrigatório	Descrição
`metadata.name`	Sim	Nome do Ingress. Nota O nome deve ser exclusivo dentro do cluster para evitar conflitos.
`spec.ingressClassName`	Sim	Nome da IngressClass associada.
`spec.rules.host`	Não	O nome de domínio no cabeçalho HTTP `Host`. Defina isso como seu próprio nome de domínio. O Kubernetes compara os cabeçalhos Host recebidos com as regras do Ingress e roteia as requisições correspondentes para o service de backend especificado. Nota Nomes de domínio personalizados exigem um registro ICP válido para acesso na China continental. Consulte Processo de registro ICP. Se você não definir este parâmetro, a regra do Ingress corresponderá a todas as requisições que chegarem ao Ingress controller.
`spec.rules.http.paths.path`	Sim	URL do caminho de encaminhamento.
`spec.rules.http.paths.pathType`	Sim	Regra de correspondência de URL. Consulte Roteamento de requisições com base em caminhos de URL.
`spec.rules.http.paths.backend.service.name`	Sim	Nome do Service de backend.
`spec.rules.http.paths.backend.service.port.number`	Sim	Número da porta do Service de backend. Certifique-se de que esta porta corresponda à definição do Service.

Execute o comando a seguir para criar o Ingress com roteamento baseado em path para os services coffee e tea.
```
kubectl apply -f cafe-ingress.yaml
```
Saída esperada:
```
ingress.networking.k8s.io/cafe-ingress created
```

(Opcional) Obtenha o nome DNS do ALB atribuído ao Ingress.

kubectl get ingress

Saída esperada:

NAME           CLASS    HOSTS                         ADDRESS                                               PORTS   AGE
cafe-ingress   alb      demo.domain.ingress.top       alb-m551oo2zn63yov****.cn-hangzhou.alb.aliyuncs.com   80      50s

(Opcional) Etapa 5: Configurar a resolução de nome de domínio

Se você especificou um domínio personalizado em spec.rules.host, adicione um registro CNAME apontando-o para o nome DNS do ALB para habilitar o acesso através do seu domínio.

Faça login no console do Container Service for Kubernetes (ACK).
Clique no nome do cluster para abrir a página de gerenciamento do cluster.
No painel de navegação à esquerda, escolha Network > Routes.
Na coluna Endpoint do cafe-ingress, copie seu nome DNS.

Para adicionar um registro CNAME:

Faça login no console do Alibaba Cloud DNS.
Na página Domain Name Resolution, clique em Add Zone.
Na caixa de diálogo Add Zone, insira seu nome de domínio e clique em OK.

Importante
Você deve verificar o nome de domínio com um registro TXT.
Para o domínio alvo, clique em Settings na coluna Actions.
Na página Settings, clique em Add Record.

No painel Add Record, configure as seguintes definições para o registro CNAME e clique em OK.

Parâmetro	Descrição
Record Type	Na lista suspensa, selecione CNAME.
Hostname	O prefixo do seu nome de domínio, como `www`.
DNS Query Source	Selecione o valor padrão.
Record Value	Insira o nome DNS que você copiou da coluna Endpoint.
TTL	A duração durante a qual um registro DNS fica armazenado em cache em um servidor DNS. Use o valor padrão.

Etapa 6: Testar o encaminhamento de tráfego

Insira o domínio de teste e o caminho da URL no navegador para verificar o roteamento de tráfego.

Nota

Se você configurou um domínio personalizado, use esse domínio.
Caso não tenha configurado um domínio personalizado, utilize o nome DNS do endpoint do cafe-ingress.

Neste exemplo, o domínio é demo.domain.ingress.top:

Digite demo.domain.ingress.top/coffee no navegador. A página exibirá o service de backend coffee-svc, mostrando o nome do Servidor como o nome do Pod coffee e a URI como /coffee, o que indica que a requisição foi roteada corretamente para o service de backend coffee.
Digite demo.domain.ingress.top/tea no navegador. A página exibirá o service de backend tea-svc, mostrando a URI como /tea e o nome do Servidor começando com tea-6, o que indica que a requisição foi roteada corretamente para o Pod de backend tea.

Referências

Uso avançado do service ALB Ingress aborda verificações de integridade, redirecionamento HTTPS, lançamentos canary e portas de listener personalizadas.
Personalizar regras de encaminhamento para ALB Ingress.
Configurar um certificado HTTPS para comunicação criptografada.
Solucionar problemas do ALB Ingress e Perguntas frequentes sobre o ALB Ingress.