Migração do ingress-nginx: Escolhendo um Novo Controlador

Migração do ingress-nginx: Escolhendo um Novo Controlador

O ingress-nginx tem sido por muito tempo o controlador de ingress padrão para Kubernetes, mas após o anúncio do fim do suporte ativo, muitas equipes tiveram que considerar a migração. Neste artigo, descrevemos como escolhemos um novo controlador de ingress.

Por que a questão da troca do controlador de ingress se tornou relevante

A maioria dos engenheiros que trabalham com Kubernetes já sabe que o ingress-nginx está se aposentando. O anúncio oficial do Kubernetes afirma que o suporte ao ingress-nginx continuará em modo de "melhor esforço" até março de 2026. Após essa data, o projeto deixará de receber novos lançamentos, correções de bugs e atualizações de segurança.

Nós, como muitas equipes do setor, usamos o ingress-nginx por muito tempo em nossos próprios clusters e nos de clientes. O controlador funciona de forma estável, é bem estudado e fecha as tarefas básicas de roteamento de tráfego. Ao mesmo tempo, uma pequena, mas reveladora pesquisa no Reddit mostra que o ingress-nginx ainda ocupa quase metade do mercado.

Após o aparecimento da data oficial de término do suporte, a situação mudou drasticamente. A questão não é mais se é necessário migrar, mas como fazer isso com segurança e sem grandes mudanças na infraestrutura. Agora, todos precisam responder a algumas perguntas:

• Para onde migrar?
• Quais são os riscos ao mudar?
• Quanto custará a migração?
• Quais serão as limitações e incompatibilidades?

Ingress API vs. Gateway API

Paralelamente, um novo padrão para publicação de serviços está se desenvolvendo no ecossistema Kubernetes — o Gateway API. Gradualmente, ele está se tornando a principal direção de desenvolvimento em vez da clássica Ingress API.

O Gateway API resolve tarefas que antes precisavam ser fechadas com configurações complexas de ingress, anotações e mecanismos adicionais. Simplificando, a principal ideia do Gateway API é uma separação mais clara de responsabilidades e um roteamento mais flexível. No Ingress clássico, tudo é geralmente descrito em um único objeto de ingress: host, regras de roteamento, TLS, às vezes parâmetros adicionais por meio de anotações. À medida que a infraestrutura cresce, essas configurações se tornam cada vez mais complexas e pioram a escalabilidade.

No Gateway API, a arquitetura é imediatamente dividida em vários níveis lógicos. O objeto Gateway descreve o ponto de entrada no cluster para um host específico, e os objetos Route são responsáveis pelas regras de roteamento. Se traçarmos uma analogia com o nginx:

• Gateway — nível do host
• Route — nível de localização e roteamento dentro dele

Essa abordagem permite que diferentes equipes gerenciem independentemente sua parte da configuração e simplifica a manutenção da infraestrutura.

Você pode ler mais sobre as diferenças da API na documentação oficial.

Ao mesmo tempo, a transição para o Gateway API requer certos custos de trabalho: você precisa reescrever manifestos, atualizar gráficos Helm, alterar os pipelines CI/CD e testar o roteamento e o TLS.

Portanto, decidimos dividir a migração em várias etapas. Primeiro, substituir o controlador de ingress por uma solução moderna e suportada com alterações mínimas nos serviços atuais e, em seguida, transferir gradualmente a infraestrutura para o Gateway API à medida que os processos e ferramentas estiverem prontos.

Assim, reduziremos os riscos e não combinaremos várias grandes mudanças de uma só vez. Além disso, é importante levar em consideração o estado atual do ecossistema. Muitos gráficos Helm populares, incluindo Bitnami e outras soluções amplamente utilizadas, ainda estão focados no Ingress clássico e estão apenas começando a adicionar suporte ao Gateway API. Portanto, o Ingress permanecerá parte das infraestruturas de produção por algum tempo, apesar do desenvolvimento do novo padrão.

Nosso contexto: infraestrutura e limitações

Para entender a escala da migração, é importante descrever o contexto de nossa infraestrutura.

Atualmente em operação estão:

• 5 clusters Kubernetes próprios
• Mais de 500 recursos de ingress
• Dezenas de clusters de clientes em nuvens públicas, infraestrutura on-premise e em ambientes de clientes.

Quaisquer alterações na camada de rede afetam imediatamente um grande número de sistemas com diferentes requisitos e níveis de criticidade.

Separatamente, vale a pena notar os ambientes de produção com alta carga, onde a publicação de serviços para fora é uma parte crítica da infraestrutura. Em tais sistemas, quaisquer alterações devem ser executadas com a maior precisão possível, sem tempo de inatividade e sem afetar os usuários. Isso limita automaticamente as opções de migração. Você não pode simplesmente alternar o controlador com um lançamento ou reescrever as configurações em massa. Uma transição gradual com testes e a possibilidade de reversão é necessária.

Complexidade adicional é criada pelas configurações acumuladas do ingress-nginx. Ao longo dos anos de operação, usamos ativamente anotações para configurar roteamento, segurança e comportamento do proxy.

Por exemplo:

• Mecanismos de autenticação e integração com serviços externos
  • auth-url
  • auth-signin
  • auth-response-headers
• Gerenciamento de protocolos e comportamento de serviços de backend
  • backend-protocol
  • x-forwarded-prefix
  • x-forwarded-proto
• Configurações CORS
  • enable-cors
  • cors-allow-origin
  • cors-allow-methods
  • cors-allow-credentials
• Parâmetros de buffer e timeouts
  • proxy-body-size
  • proxy-buffer-size
  • proxy-buffers-number
  • proxy-connect-timeout
  • proxy-read-timeout
  • proxy-send-timeout
  • client-body-buffer-size
• Roteamento e reescrita de caminhos
  • rewrite-target
• Snippets de configuração personalizados
  • configuration-snippet
  • server-snippet

Os dois últimos itens são especialmente sensíveis durante a migração. Eles permitem que você incorpore configurações nginx arbitrárias diretamente na configuração de ingress e fornecem flexibilidade muito alta. Ao mesmo tempo, isso cria uma forte dependência da implementação específica do controlador. Tais construções são quase impossíveis de transferir para outra solução sem alterações, e são elas que geralmente se tornam o principal ponto de complexidade durante a migração.

Requisitos para uma nova solução de ingress / gateway

Quando ficou claro que não seria possível permanecer no ingress-nginx a longo prazo, o próximo passo foi determinar os requisitos para a nova solução. Precisávamos de uma ferramenta que funcionasse de forma estável com o Ingress clássico, suportasse o Gateway API, permitisse a migração gradualmente e afetasse minimamente os serviços atuais.

• Um dos critérios-chave foi a maturidade do projeto. Olhamos não apenas para a funcionalidade, mas também para a atividade de desenvolvimento, a frequência de atualizações, a qualidade da documentação e o tamanho da comunidade. Isso está diretamente relacionado aos riscos operacionais: quanto mais a solução é usada, maior a probabilidade de que os problemas que surgem já sejam conhecidos e tenham soluções prontas.
• Não menos importante foi a simplicidade e previsibilidade da migração. Já temos centenas de recursos de ingress e um grande número de automações em torno deles: gráficos Helm, pipelines e modelos de configuração. Portanto, procuramos uma solução que nos permitisse manter ao máximo os manifestos existentes e o comportamento atual dos serviços.
• A complexidade da configuração, a facilidade de operação, o registro, o monitoramento e a facilidade de diagnóstico foram avaliados separadamente. Para ambientes de produção, o desempenho e a estabilidade sob carga também são críticos, por isso estudamos adicionalmente os resultados dos testes de carga e as recomendações da comunidade.

A lista final de requisitos ficou assim:

• Suporte para Ingress clássico
• Compatibilidade com configurações existentes
• Suporte ao Gateway API
• Desenvolvimento ativo do projeto
• Mudanças mínimas durante a migração
• Comportamento previsível
• Alto desempenho
• Capacidade de trabalhar em nuvens e infraestrutura on-premise

Candidatos para substituir o ingress-nginx

No próximo artigo, contaremos o que escolhemos e como organizamos uma transição perfeita.

Você já passou por essa situação? Qual foi a sua escolha e por quê?