Esta página foi traduzida pela API Cloud Translation.

Migre o Ingress para a API Gateway

Autopilot Padrão

Esta página mostra como migrar a gestão de tráfego no Google Kubernetes Engine (GKE) da API Ingress para a API Gateway. A API Gateway oferece uma solução totalmente gerida para processar o tráfego da sua aplicação. Google Cloud

Para minimizar o tempo de inatividade e mitigar o risco, a abordagem mais eficaz para migrar para a API Gateway é executar as configurações da API Ingress existente e da nova API Gateway em simultâneo. Este método permite testar exaustivamente a nova configuração da gateway num ambiente em direto sem afetar os seus serviços atuais. Depois de validar a nova configuração do gateway, pode fazer uma mudança rápida de DNS para redirecionar o tráfego para a API Gateway e ajudar a garantir uma transição suave e de baixo risco.

A um nível elevado, a estratégia de migração envolve as seguintes fases:

Configure o novo equilibrador de carga.
Defina regras para processar o tráfego recebido.
Implemente a nova configuração e teste o fluxo de tráfego para o novo endereço IP do gateway.
Mude o tráfego de produção para a API Gateway.
Limpe os recursos de entrada restantes.

Configure o novo equilibrador de carga

Nesta fase, implementa um recurso do Gateway do Kubernetes para equilibrar a carga do tráfego para o seu cluster do GKE. Quando implementa um recurso Gateway, o GKE configura um equilibrador de carga de aplicações da camada 7 para expor o tráfego HTTP(S) a aplicações que são executadas no cluster. Implementa um recurso de gateway para cada cluster ou para cada equilibrador de carga de que precisa.

No exemplo seguinte, configura um balanceador de carga de aplicações externo global. Para criar um gateway, guarde o seguinte manifesto como gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http-gateway
spec:
  gatewayClassName: gke-l7-global-external-managed # GKE's managed external Application Load Balancer
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same # Only allow HTTPRoutes from the same namespace

O manifesto anterior descreve um Gateway que inclui os seguintes campos:

gatewayClassName: gke-l7-global-external-managed: especifica a GatewayClass para este Gateway. Esta classe Gateway usa um Application Load Balancer externo global.
protocol: HTTP e port: 80: especificam que o gateway expõe a porta 80 para tráfego HTTP.

Defina regras de tráfego para o tráfego recebido

Os recursos de trajeto definem regras específicas do protocolo para mapear o tráfego de um gateway para serviços de back-end.

Nesta fase, traduz o manifesto do Ingress num recurso HTTPRoute. Para converter o manifesto do Ingress, siga os passos na ferramenta ingress2gateway.

Este exemplo pressupõe que tem o seguinte recurso Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

Depois de converter o manifesto com a ferramenta ingress2gateway, o resultado é o manifesto HTTPRoute traduzido.

Guarde o seguinte manifesto de exemplo como httproute.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cafe-route
spec:
  # This route attaches to our new Gateway
  parentRefs:
  - name: external-http-gateway
  # The hostname is the same as before
  hostnames:
  - "cafe.example.com"
  # The routing rules are now more explicit
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
    backendRefs:
    - name: tea-svc
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee-svc
      port: 80

Tenha em atenção que o campo rules no manifesto HTTPRoute corresponde diretamente às regras de encaminhamento definidas no manifesto Ingress original.

Implemente e teste a nova configuração

Nesta fase, aplica os manifestos Gateway e HTTPRoute que criou nas duas fases anteriores e testa se o tráfego flui para o novo endereço IP do Gateway.

Aplique os manifestos Gateway e HTTPRoute:

kubectl apply -f gateway.yaml
kubectl apply -f httproute.yaml

Obtenha o endereço IP do gateway. A atribuição do endereço IP pode demorar alguns minutos:
```
kubectl get gateway external-http-gateway -o=jsonpath="{.status.addresses[0].value}" --watch
```
O resultado é o endereço IP externo do gateway, por exemplo, 203.0.113.90.
Teste o novo endereço IP do gateway. Use o seguinte comando curl para enviar um pedido para o endereço IP e especificar o nome de anfitrião cafe.example.com. Por exemplo:
```
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/tea
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/coffee
```
Substitua 203.0.113.90 pelo endereço IP externo que obteve no passo anterior. O resultado confirma que o novo endereço IP do gateway encaminha corretamente o tráfego para cafe.example.com sem realizar uma pesquisa de DNS.

Direcione o tráfego para o novo endereço IP do gateway

Nesta fase, transfere o tráfego em direto da entrada anterior para o novo gateway atualizando os registos de DNS para direcionarem para o novo endereço IP do gateway. Os passos exatos para atualizar os registos de DNS variam consoante o seu fornecedor de DNS.

Por exemplo, se configurou cafe.example.com no Ingress, localizaria o registo A para cafe.example.com junto do seu fornecedor de DNS e alteraria o valor do endereço IP do Ingress antigo para 203.0.113.90, que é o novo endereço IP do Gateway.

Depois de atualizar o registo DNS, o tráfego começa a mudar do Ingress para o Gateway, mas a mudança não ocorre imediatamente para todos os clientes. Os resolutores de DNS que têm o registo anterior em cache aguardam que o valor de tempo de vida (TTL) do registo expire antes de consultarem novamente o registo e receberem o endereço IP atualizado. Por este motivo, deve continuar a executar o Ingress existente e o novo Gateway em simultâneo até verificar que o tráfego para o Ingress cessou, o que indica que a propagação de DNS está concluída e os clientes já não estão a ser direcionados para o endereço IP antigo. Pode verificar isto monitorizando o tráfego no equilibrador de carga ou no controlador de entrada. Para mais informações, consulte o artigo Verificar a propagação do DNS.

Se usar o Cloud DNS, pode usar ponderações de destino para mudar gradualmente o tráfego do endereço IP antigo para o novo endereço IP. Para mais informações, consulte o artigo Configure políticas de encaminhamento de DNS e verificações de estado.

Limpe os recursos de entrada restantes

Depois de confirmar que o novo Gateway é executado com êxito, limpe os recursos Ingress antigos.

Elimine o recurso Ingress:
```
kubectl delete ingress cafe-ingress
```
Desinstale o comando ingress-nginx. Por exemplo, se usou o Helm para instalar o controlador, execute o seguinte comando:
```
helm uninstall ingress-nginx -n ingress-nginx
```

Comparação de funcionalidades entre o Ingress NGINX e o GKE Gateway

A API Gateway oferece uma forma mais padronizada de configurar a entrada e tem paridade de funcionalidades para as funcionalidades mais comuns, como o encaminhamento, os cabeçalhos e a divisão do tráfego.

A tabela seguinte compara as anotações usadas para funcionalidades comuns no controlador Ingress e na API Gateway.

Funcionalidade	Anotação na entrada	Anotação no GKE Gateway	Paridade
Reescritas de URLs	`nginx.ingress.kubernetes.io/rewrite-target`	`HTTPRoute` com um filtro `urlRewrite`.	Paridade parcial. O GKE Gateway só suporta substituições de prefixos.
Manipulação de cabeçalhos	`nginx.ingress.kubernetes.io/proxy-set-headers` ou `add-headers`	`HTTPRoute` com um modificador `requestHeaderModifier` ou um filtro `responseHeaderModifier`.	Paridade total.
Encaminhamento baseado no caminho	`spec.rules.http.paths` no objeto Ingress.	`rules.matches.path` no objeto HTTPRoute.	Paridade total.
Encaminhamento com base no anfitrião	`spec.rules.host` no objeto Ingress.	`hostnames` no objeto HTTPRoute.	Paridade total.
Divisão de tráfego	`nginx.ingress.kubernetes.io/canary` anotações.	`HTTPRoute` com `backendRefs` ponderado.	Paridade total. Além disso, pode dividir o tráfego com um controlo detalhado.
Autenticação	`nginx.ingress.kubernetes.io/auth-url` para autenticação externa.	Identity-Aware Proxy (IAP): `BackendPolicy` CRD. Outro: requer uma abordagem mais personalizada, possivelmente com uma malha de serviços ou filtros personalizados.	Paridade parcial. O Identity-Aware Proxy é a forma recomendada de proteger o gateway e está configurado no back-end.

O que se segue?

Saiba como proteger o seu gateway.
Leia como funciona a gestão do tráfego de gateways.