Pensando na evolução da arquitetura do seu cluster Kubernetes, o Gateway API é um daqueles recursos que você não deve deixar de considerar. Sendo uma solução robusta e elegante, o Gateway API vem se tornando um novo padrão para o controle do roteamento dos serviços expostos pelo cluster. Dito isso, hoje iremos explorar brevemente o que é o recurso, suas diferenças para o tradicional Ingress e algumas de suas principais características.

Entendendo o recurso

Toda funcionalidade que será utilizada pelo cliente deve ser exposta de alguma forma para a internet, tornando-a acessível para o consumidor final. Se as suas aplicações são executadas em clusters Kubernetes, você com certeza já fez uso de algum dos "flavors” do Kubernetes Ingress.

O propósito do Ingress (e agora do Gateway API) é de fornecer uma forma de acesso externo às aplicações que são executadas dentro de um cluster, aplicações essas expostas internamente através de services.

Imagine que você tem dentro do seu cluster os produtos A, B e C. Esses produtos fazem parte da mesma linha de negócio, ou seja, estão todos relacionados, mesmo que façam parte de jornadas diferentes. O que você deve fazer para que as plataformas e canais utilizados pelos clientes possam acessar essas funcionalidades expostas pelas suas aplicações?

Como vemos na arquitetura acima, o Gateway API realiza a exposição das aplicações (que estão representadas “atrás” dos services) através do próprio gateway e de seu recurso auxiliar, a HTTP Route.

• Gateway API - recurso “primário”, que realiza a exposição das aplicações.

• HTTP Route - objeto que declara a rota que será exposta pelo Gateway API.

• TLS Route - parecido com o HTTP Route, porém sua exposição ocorre com o acréscimo de certificados, garantindo a criptografia in-transit na comunicação.

Essa separação das rotas que serão publicadas em um objeto próprio garante maior dinamismo e um design mais limpo e escalável para seu cluster. Se for um desejo do seu time de engenharia migrar o provedor do Gateway API (para o Cilium, por exemplo), essa separação das rotas facilitará o processo, visto que apenas o objeto principal deverá ser modificado, mantendo as rotas e suas regras intactas.

Exploraremos mais sobre algumas features interessantes do recurso nas próximas seções. Agora falaremos brevemente sobre as diferenças para o Ingress.

Qual a mudança do Ingress?

Falando do “legado”, o Ingress e seus flavors foram utilizados por muitos anos como o padrão para exposição de services no Kubernetes. As alterações e evoluções do Ingress ao Gateway API são majoritariamente funcionalidades diferentes, suporte a outros protocolos e alteração na arquitetura do componente.

Abaixo uma breve lista com algumas das principais diferenças de um recurso para outro:

• Protocolos suportados - agora podemos criar recursos que fazem uso de protocolos como gRPC, TCP, UDP e os já suportados HTTP/S.

• Modularização - como comentado anteriormente, com a nova versão, temos completa separação dos recursos, habilitando a troca do provedor e reutilização das rotas declaradas.

• Granularidade das rotas - a declaração das rotas se tornou muito mais detalhada, permitindo a construção de regras mais complexas e habilitando a criação de testes como A/B e blue green com mais facilidade.

Acima temos uma arquitetura simples sobre como o recurso funciona. Podemos notar algumas diferenças para a arquitetura do Gateway API, como mencionado anteriormente.

Coisas legais do recurso

Agora que entendemos de fato as diferenças entre um e outro, vamos nos concentrar nos recursos interessantes que a nova versão do objeto nos traz.

Acho importante reforçar o valor que a “modularização” do recurso traz para os ambientes Cloud Native. Estamos sempre buscando tornar nossas soluções escaláveis, sustentáveis no longo prazo e acima de tudo, vendor-neutral. A separação dos componentes que compõem o Gateway API facilitará na utilização de novos recursos e até na migração para outras plataformas.

TLS era algo já existente no Ingress Controller, porém agora podemos ter de maneira organizada nossas rotas que devem ser expostas de maneira segura e seus certificados, que são binded diretamente na rota. Para os times de segurança e DevOps isso trará um ganho extremo no momento de troubleshooting, visto que será possível identificar os recursos conectados com mais rapidez.

Por último, gostaria de falar sobre o modelo de criação do recurso, através de CRDs (Custom Resource Definitions). Os CRDs tornam as pipelines de execução mais limpas e organizadas, visto que são manifestos iguais aos default do Kubernetes. Criar recursos utilizando esse modelo torna a arquitetura mais modular, garantindo mais uma vez escalabilidade na sua plataforma!

O Gateway API traz uma série de benefícios para seu ambiente e sua equipe. Como qualquer outra tecnologia, não é uma bala de prata. Você deve avaliar se o serviço cumpre com os seus requisitos antes de adotá-lo em larga escala.

Espero que tenha gostado do artigo, não deixe de me contatar caso tenha alguma dúvida ou queira conversar mais sobre o recurso.

Até logo!