Kubernetes Gateway API v1.0: Você Deve Migrar?

Já se passou mais de um mês desde o lançamento da versão 1.0 da API Gateway do Kubernetes, marcando a graduação para o status de disponibilidade geral de algumas de suas principais APIs.

Eu escrevi sobre a API Gateway quando ela se tornou beta no ano passado, mas, um ano depois, a pergunta ainda permanece. Você deve migrar da API Ingress para a API Gateway?

Minha resposta do ano passado foi que você não deveria. E eu tinha razões fortes para isso.

A API Gateway e suas implementações ainda estavam em sua infância. A API Ingress, por outro lado, era estável e cobria alguns casos de uso primários que poderiam funcionar para a maioria dos usuários.

Para usuários que exigiam mais capacidades, eu sugeria usar os recursos personalizados fornecidos pelos controladores Ingress, sacrificando a portabilidade (trocar entre diferentes implementações de Ingress).

Com o lançamento da versão 1.0, isso pode mudar. A API Gateway está muito mais capaz agora, e suas 20+ implementações estão evoluindo rapidamente.

Portanto, se você está começando do zero e escolhendo entre a API Ingress e a API Gateway, eu sugiro que você escolha a API Gateway se a API e a implementação que você escolher suportarem todos os recursos que você deseja.

O que há de errado com a API Ingress?

A API Ingress funciona muito bem, mas apenas para um pequeno subconjunto de casos de uso comuns. Para estender suas capacidades, as implementações de Ingress começaram a usar anotações personalizadas.

Por exemplo, se você escolher o Nginx Ingress, você usará algumas de suas dezenas de anotações que não são portáteis se você decidir mudar para outra implementação de Ingress, como o Apache APISIX.

Essas anotações específicas da implementação também são difíceis de gerenciar e vão contra o propósito de gerenciar o Ingress de uma maneira nativa do Kubernetes.

Eventualmente, as implementações de controladores Ingress começaram a desenvolver seus próprios CRDs para expor mais recursos aos usuários do Kubernetes. Esses CRDs são específicos para o controlador Ingress. Mas se você puder sacrificar a portabilidade e se manter em um único controlador Ingress, os CRDs são mais fáceis de trabalhar e oferecem mais recursos.

A API Gateway visa resolver esse problema de uma vez por todas, fornecendo a independência de fornecedor da API Ingress e a flexibilidade dos CRDs. Ela está muito bem posicionada para alcançar esse objetivo.

A longo prazo, a API Ingress não deve receber novos recursos, e todos os esforços serão feitos para convergir com a API Gateway. Portanto, adotar a API Ingress pode causar problemas quando você inadvertidamente atingir limites com suas capacidades.

Benefícios Óbvios

Expressiva, extensível e orientada a papéis são as ideias-chave que moldaram o desenvolvimento da API Gateway.

Diferente da API Ingress, a API Gateway é uma coleção de várias APIs (HTTPRoute, Gateway, GatewayClass, etc.), cada uma atendendo a diferentes papéis organizacionais.

Por exemplo, os desenvolvedores de aplicativos precisam se preocupar apenas com o recurso HTTPRoute, onde podem definir regras para rotear o tráfego. Eles podem delegar os detalhes de nível de cluster a um operador que gerencia o cluster e garante que ele atenda às necessidades dos desenvolvedores usando o recurso Gateway.

Esse design orientado a papéis da API permite que diferentes pessoas usem o cluster enquanto mantêm o controle.

A API Gateway também é muito mais capaz do que a API Ingress. Recursos que exigem anotações na API Ingress são suportados nativamente na API Gateway.

Uma Extensão Oficial

Embora a API Gateway seja uma API oficial do Kubernetes, ela é implementada como um conjunto de CRDs.

Isso não é diferente de usar recursos padrão do Kubernetes. Mas você só precisa instalar esses CRDs como uma extensão oficial.

Isso permite uma iteração rápida em comparação com o Kubernetes, que está se movendo lentamente em direção à estabilidade de longo prazo.

Ela Vai Proliferar?

Como este famoso quadrinho do XKCD frequentemente nos lembra, os padrões tendem a proliferar.

Uma versão disso foi vista nas APIs Ingress e Gateway. Geralmente acontece assim:

1. Um padrão emerge para unificar diferentes projetos/seus padrões (API Ingress do Kubernetes).
2. O padrão unificado tem limitações que os implementadores desejam superar (a API Ingress era limitada).
3. As implementações divergem do padrão devido a essas limitações (CRDs personalizados, anotações).
4. Cada implementação agora tem seu próprio padrão (CRDs, anotações não portáteis).
5. Um novo padrão emerge para unificar esses diferentes padrões (API Gateway do Kubernetes).

É razoável pensar que a API Gateway pode não ser o fim da linha aqui. Mas eu acredito que ela tem todas as chances de se tornar o padrão para roteamento no Kubernetes.

Novamente, eu tenho minhas razões fortes.

A adoção ampla é crítica para evitar a proliferação de padrões, pois há menos incentivos para as implementações trabalharem em um padrão diferente. A API Gateway já tem mais de 25 implementações.

Uma implementação pode se conformar com a API Gateway em diferentes níveis:

1. Core: Todas as implementações devem se conformar com isso.
2. Extended: Esses podem estar disponíveis apenas em algumas implementações, mas são APIs padrão.
3. Específico da implementação: Específico para implementações, mas adicionado através de pontos de extensão padrão.

Um recurso de nicho pode passar de específico da implementação para estendido e depois para core, à medida que mais implementações suportam esses recursos. Ou seja, a API permite espaço para extensões personalizadas, garantindo que siga o padrão.

O projeto Service Mesh Interface (SMI) foi uma tentativa semelhante de padronizar a configuração de malhas de serviço no Kubernetes. No entanto, o projeto recebeu pouca tração após o envolvimento inicial dos projetos de malha de serviço e lentamente desapareceu.

O SMI não suportava muitos recursos comuns que os usuários esperavam em uma malha de serviço. Ele também não se movia rápido o suficiente para suportar esses recursos. Eventualmente, as implementações de malha de serviço ficaram para trás em conformidade com o SMI (eu trabalhei de perto com o SMI sob o CNCF TAG Network em um projeto que relatava conformidade com o SMI).

Essas são razões universais, mas o projeto está sendo ressuscitado através da API Gateway. A iniciativa Gateway API for Mesh Management and Administration (GAMMA) visa estender a API Gateway para trabalhar com malhas de serviço.

O projeto SMI recentemente se fundiu com a iniciativa GAMMA, o que é excelente para a API Gateway. O Istio, sem dúvida a malha de serviço mais popular, também anunciou que a API Gateway será a API padrão para gerenciar o Istio no futuro. Tais adoções previnem a proliferação.

Guia de Migração

A documentação da API Gateway tem um guia abrangente sobre como migrar seus recursos Ingress para recursos Gateway. Em vez de repeti-lo, vamos tentar usar a ferramenta ingress2gateway para converter nossos recursos Ingress em recursos correspondentes da API Gateway.

Você pode baixar e instalar o binário para o seu sistema operacional diretamente na página de lançamentos.

Vamos pegar um recurso Ingress simples:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-route
spec:
  ingressClassName: apisix
  rules:
    - host: local.httpbin.org
      http:
        paths:
          - backend:
              service:
                name: httpbin
                port:
                  number: 80
            path: /
            pathType: Prefix

Isso roteará todo o tráfego com o endereço de host fornecido para o serviço httpbin.

Para convertê-lo para o recurso da API Gateway, podemos executar:

ingress2gateway print --input_file=ingress.yaml

Este recurso da API Gateway será como mostrado abaixo:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: httpbin-route
spec:
  hostnames:
  - local.httpbin.org
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: httpbin
      port: 80

Alternativas Viáveis

Existem outras alternativas viáveis para configurar gateways no Kubernetes.

No Apache APISIX, você pode implantá-lo no modo standalone e definir configurações de rota em um arquivo yaml. Você pode atualizar esse arquivo yaml através de fluxos de trabalho tradicionais, e isso pode ser bastante útil em cenários onde o gerenciamento da configuração do gateway via API do Kubernetes não é necessário.

CRDs personalizados específicos da implementação também são alternativas viáveis se você não planeja mudar para uma solução diferente ou se sua configuração é pequena o suficiente para migrar facilmente.

De qualquer forma, a API Gateway veio para ficar.