Já se passou quase um ano e meio desde que a comunidade Kubernetes anunciou oficialmente a disponibilidade geral da Gateway API — um marco que redefiniu a forma como a rede e o gerenciamento de tráfego são tratados em clusters Kubernetes. Isso foi mais do que apenas uma atualização incremental. Representou uma mudança fundamental na rede de ambientes nativos da nuvem, oferecendo uma estrutura avançada, extensível e expressiva para gerenciar a conectividade.
A Gateway API substitui os recursos limitados da Ingress API por um design orientado a funções, recursos padronizados e extensibilidade. Desde a introdução de recursos avançados de roteamento e divisão de tráfego até a viabilização da multilocação por meio de seu design orientado a funções, a Gateway API possibilita casos de uso complexos que antes eram difíceis de gerenciar. Não surpreende que essa mudança tenha impulsionado uma ampla inovação em todo o setor, à medida que fornecedores — incluindo a F5 — reconheceram seu potencial para moldar o futuro das redes no Kubernetes.
Ainda assim, a adoção de um novo padrão como esse não acontece da noite para o dia. Embora a Gateway API ofereça benefícios claros, muitas organizações continuam cautelosas. Elas avaliam cuidadosamente a complexidade da migração e as ferramentas de Ingress existentes em comparação com a configuração de roteamento padronizada, porém flexível, da Gateway API. E a decisão de adotá-la não é motivada apenas por limitações técnicas — trata-se de ponderar prós e contras. O tempo, o esforço e o risco envolvidos na transição precisam ser compensados por melhorias significativas e concretas em seus recursos de rede.
O ritmo mais lento de adoção em todo o setor reflete essa abordagem cautelosa. Embora a API Gateway seja amplamente considerada o futuro das redes no Kubernetes, muitas organizações ainda estão explorando seus recursos ou avaliando as vantagens e desvantagens antes de se comprometerem com uma adoção em larga escala. Relatos da comunidade Kubernetes indicam que os testes com a API Gateway estão aumentando de forma constante. Os primeiros usuários estão aproveitando-a em diversos casos de uso — desde o roteamento HTTP simples até arquiteturas multilocatário avançadas. Isso demonstra um interesse crescente nas possibilidades da API Gateway, mesmo que muitas equipes ainda prefiram esperar para ver.
Na F5, observamos uma dinâmica semelhante. Muitos de nossos clientes estão evitando dar esse salto de imediato. Não por falta de interesse, mas porque buscam equilibrar a inovação com a segurança operacional proporcionada por soluções maduras de Ingress. Por isso, acreditamos que a jornada rumo à Gateway API não precisa ser apressada. Ela só precisa ser estratégica.
Vamos analisar em detalhes. Alguns dos desafios da migração para a Gateway API incluem:
- Reformulação complexa da infraestrutura: A migração pode exigir a reescrita de automações e alterações nos pipelines de aplicações existentes.
- Lacunas no suporte do ecossistema: O suporte completo a ferramentas e controladores ainda está em evolução.
- Falta de tempo e conhecimento especializado: A curva de aprendizado e a refatoração exigem tempo dedicado.
- Aversão ao risco: As equipes hesitam em alterar o que já está funcionando.
No entanto, também há benefícios substanciais:
- Design orientado a funções: Os recursos da API Gateway são divididos por função organizacional. Isso permite que os desenvolvedores façam alterações sem afetar outras equipes.
- Políticas de tráfego padronizadas: Muitas políticas de tráfego comuns são totalmente integradas à própria API, tornando a configuração universal entre as implementações e muito mais fácil de gerenciar do que as anotações do Ingress.
- Extensibilidade: Os pontos de extensão permitem que as implementações ampliem a API Gateway para oferecer recursos personalizados dentro da estrutura da API.
Se há algo que sabemos sobre entrega de aplicações e infraestrutura, é o seguinte: mudanças levam tempo e exigem o convencimento de toda a empresa. Suporte contínuo, orientação e inovação são essenciais até mesmo para iniciar a transição.
Enfrentando os desafios da adoção da Gateway API: insights da F5
Na F5, temos participado ativamente do desenvolvimento e da evolução das redes do Kubernetes. Vivenciamos esses desafios em primeira mão e ajudamos equipes a superá-los.
Nossa experiência confirma uma verdade fundamental: adotar a Gateway API com sucesso não significa apenas implementar um novo padrão. Significa construir uma base para o sucesso futuro. Para isso, as organizações precisam de soluções que priorizem simplicidade, desempenho, flexibilidade e suporte robusto. Veja como esses princípios facilitam as transições e criam as condições para gerar valor a longo prazo:
- Simplicidade por meio de uma abordagem do zero: A migração para a Gateway API exige mais do que mudanças técnicas. Trata-se de uma transformação cultural e operacional. Ao começar do zero, podemos solucionar todos os pontos problemáticos do Ingress e proporcionar uma experiência de rede superior por meio de uma única interface: a Gateway API. Embora isso possa exigir mais esforço inicial, os benefícios de longo prazo — processos simplificados, redução da sobrecarga e resultados mais rápidos — superam em muito os desafios.
- Desempenho como base: O desempenho da rede é fundamental, especialmente em ambientes Kubernetes de grande porte. Implementações enxutas da Gateway API devem se apoiar em um plano de dados que busque minimizar a sobrecarga arquitetural, melhorando, assim, a latência, a eficiência no uso de recursos e a escalabilidade. As soluções devem combinar a flexibilidade da Gateway API com alto desempenho por padrão, garantindo que as equipes possam fazer a transição sem comprometer a velocidade ou a confiabilidade.
- Flexibilidade por meio de um design modular: Os ambientes Kubernetes variam muito, desde necessidades básicas de roteamento até arquiteturas complexas. As soluções modulares de Gateway API permitem que as equipes adotem recursos em conjunto com outras soluções, como malhas de serviço, para atender às necessidades do seu ambiente sem adicionar complexidade. Essa abordagem incentiva a experimentação e garante que as soluções permaneçam escaláveis e adaptáveis.
- Suporte como catalisador do sucesso: A orientação de especialistas pode ser muito útil durante a adoção da Gateway API. Uma documentação abrangente, recursos confiáveis e suporte prático reduzem as dificuldades da transição do Ingress. Parceiros de confiança e o envolvimento da comunidade simplificam significativamente a migração, transformando uma mudança desafiadora em um processo tranquilo e eficiente.
O futuro é a Gateway API... no seu próprio ritmo
Sabemos que 18 meses não é muito tempo — e que o fato de a Gateway API ter aberto um mundo de possibilidades não significa que todas as organizações já estejam prontas para adotá-la.
Para muitas equipes, a API Ingress não é apenas uma solução eficiente, mas também um componente essencial da infraestrutura existente. Há anos, a API Ingress serve como a espinha dorsal da rede do Kubernetes. Organizações com ambientes bem estabelecidos não precisam se sentir obrigadas a abandonar uma solução estável e bem-sucedida.
Na F5, estamos plenamente cientes dessa realidade e, por isso, não estamos abandonando a API Ingress. Continuamos investindo no desenvolvimento do F5 NGINX Ingress Controller, oferecendo inovações e recursos que o mantêm robusto, seguro e relevante para casos de uso modernos.
Para as organizações que desejam continuar usando o Ingress, temos o compromisso de garantir que ele permaneça uma solução de alto valor, capaz de executar com confiança as cargas de trabalho atuais do Kubernetes. Para as equipes que estão avaliando a Gateway API, o F5 NGINX Gateway Fabric — desenvolvido especificamente para essa finalidade — combina simplicidade moderna, desempenho e flexibilidade para ajudar as organizações a adotar o padrão com confiança.
A decisão de migrar para a API Gateway é uma mudança significativa que não precisa acontecer da noite para o dia. No entanto, em última análise, as organizações que fizerem essa transição estarão se preparando para crescer e inovar, ao mesmo tempo que estabelecem as bases para o sucesso futuro com um sistema moderno, escalável e interoperável que moldará o futuro das redes do Kubernetes. Seja hoje ou mais adiante, nós da F5 estaremos prontos quando você estiver. Para saber mais, entre em contato conosco na F5.
Sobre os autores
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.