Introdução
O Kubernetes, frequentemente chamado de K8s, consolidou-se como a principal plataforma para orquestração de containers, graças à sua capacidade de escalar aplicações, garantir alta disponibilidade e oferecer grande flexibilidade operacional.
No entanto, esse mesmo poder torna sua administração mais complexa, especialmente em ambientes corporativos e de produção.
Para lidar com essa complexidade, surgiu um amplo ecossistema de ferramentas que auxilia times de tecnologia a enfrentar desafios como:
- Padronização de implantações
- Automação de processos
- Monitoramento e visibilidade do ambiente
- Segurança e conformidade
- Gerenciamento de múltiplos clusters
Neste artigo, são apresentadas ferramentas fundamentais para trabalhar com Kubernetes em 2025, explicando de que forma cada uma contribui para tornar a operação mais eficiente, segura e confiável.
Ferramentas Essenciais do Ecossistema Kubernetes
1. Kubectl
O kubectl é a principal interface de linha de comando para interação com clusters Kubernetes. Ele permite criar, atualizar, remover e inspecionar recursos, além de acessar logs, eventos e executar operações administrativas.
É considerado indispensável no dia a dia de qualquer profissional que trabalhe com Kubernetes.
2. Helm
Conhecido como o gerenciador de pacotes do Kubernetes, o Helm facilita a instalação e o gerenciamento de aplicações por meio dos chamados charts.
Ele possibilita reutilização de configurações, controle de versões e execução de rollbacks, tornando os deployments mais organizados, padronizados e previsíveis.
3. Lens Kubernetes IDE
O Lens é uma interface gráfica que simplifica a visualização e a administração de clusters Kubernetes.
Ele fornece informações detalhadas sobre nós, pods, serviços, workloads, eventos e logs, tudo em uma interface intuitiva e centralizada.
É especialmente útil para quem prefere uma visão visual e consolidada do ambiente.
4. Argo CD
O Argo CD é uma ferramenta de entrega contínua baseada no conceito de GitOps, onde o estado desejado do cluster é definido em repositórios Git.
Ele garante que o ambiente Kubernetes esteja sempre sincronizado com as configurações versionadas, promovendo rastreabilidade, consistência e maior controle sobre mudanças.
5. OPA Gatekeeper
O OPA Gatekeeper é voltado para governança e políticas de segurança.
Com ele, é possível definir regras que controlam o que pode ou não ser executado no cluster, como:
- Restrições de imagens
- Uso de permissões elevadas
- Padrões obrigatórios de configuração
Isso ajuda a manter conformidade e reduzir riscos operacionais.
6. Prometheus e Grafana
Essa dupla é amplamente utilizada para monitoramento e observabilidade em ambientes Kubernetes:
- Prometheus coleta métricas detalhadas do cluster e das aplicações
- Grafana transforma essas métricas em dashboards visuais e interativos
Juntas, essas ferramentas permitem identificar gargalos, antecipar falhas e acompanhar o desempenho do ambiente em tempo real.
7. Kubecost
O Kubecost é focado na análise e otimização de custos em ambientes Kubernetes.
Ele fornece visibilidade sobre gastos por namespace, aplicação ou equipe, ajudando organizações a controlar despesas, atribuir custos corretamente e identificar oportunidades de economia.
Conclusão
Embora o Kubernetes ofereça uma base extremamente poderosa para execução de aplicações em containers, seu uso eficiente depende fortemente das ferramentas corretas.
As soluções apresentadas neste artigo auxiliam diretamente na automação, observabilidade, segurança e controle financeiro dos clusters.
Uma estratégia recomendada é iniciar com ferramentas essenciais como kubectl, Helm, Lens, Prometheus/Grafana e Argo CD, evoluindo gradualmente para soluções mais especializadas conforme a maturidade da infraestrutura aumenta.
Como Investiguei Timeouts de DNS em um Cluster EKS de Grande Porte
Visão Geral
Em um cluster AWS EKS de grande escala, enfrentamos problemas intermitentes de timeouts na resolução de nomes DNS. O objetivo deste texto é relatar o processo de investigação que seguimos para encontrar a causa raiz desse problema e como chegamos à correção final.
Relato Inicial do Bug
O problema surgiu quando nossa pipeline de integração contínua começou a apresentar falhas inconsistentes. Os erros mostravam que alguns serviços não conseguiam resolver determinados nomes de host, por exemplo:
UNAVAILABLE: CURL error Could not resolve hostname
Esses erros foram observados em várias instâncias, mas sem um padrão claro de ocorrência.
Ao verificar os registros do CoreDNS, encontramos mensagens de erro indicando timeouts de I/O nas consultas DNS:
[ERROR] plugin/errors: A: read udp … i/o timeout
Essas mensagens mostravam que as consultas DNS estavam falhando ao tentar alcançar o resolvedor do Route 53 dentro da VPC.
Abertura de Chamado com AWS Support
Com registros e dados em mãos, abrimos um chamado na AWS, pois a interface de suporte pode ser complicada para agregar logs e detalhes manualmente. Uma das principais descobertas da AWS foi a existência de um limite rígido de 1024 pacotes por segundo (PPS) para serviços que utilizam endereços link-local — que é onde as consultas DNS estão sendo encaminhadas no EKS.
Para verificar se esse limite estava sendo excedido, executamos um comando específico (ethtool -S eth0 | grep linklocal_allowance_exceeded) em um dos nós afetados e confirmamos valores não nulos, indicando que o limite estava de fato sendo ultrapassado.
Investigando o Tráfego de Pacotes DNS
Sabendo que pacotes demais estavam sendo descartados por causa do limite PPS, começamos a coletar o tráfego DNS para identificar quais consultas eram as mais frequentes. Usamos tcpdump para capturar pacotes na porta 53 (DNS), depois filtramos e ordenamos os domínios mais requisitados.
O que chamou muita atenção foi que um único nome de host gerava muitas consultas repetidas, indicando um possível problema de amplificação de consultas — ou seja, cada nome estava gerando múltiplas requisições para o resolvedor DNS.
Entendendo o Papel do ndots nas Consultas
Dentro de contêineres Kubernetes, o arquivo /etc/resolv.conf mostra os domínios de busca e a opção ndots. No nosso caso, o valor ndots:5 fazia com que nomes de host que não tinham muitos pontos fossem tratados como não totalmente qualificados. Isso fazia com que o resolver tentasse várias combinações de pesquisa antes de uma resposta final — multiplicando o número de consultas enviadas ao CoreDNS e, consequentemente, ao resolvedor VPC.
Por exemplo, ao tentar resolver ip-…compute.internal, o resolvedor fazia tentativas com vários search domains, o que gerava 5 consultas por hostname (e, na verdade, 10 quando consideradas as versões IPv4 e IPv6).
Encontre a Origem das Consultas
Com base nos padrões das consultas DNS observados, percebemos que elas vinham de pods com host networking habilitado — ou seja, pods que utilizam a mesma interface de rede dos nós Kubernetes.
Usando kubectl, filtramos os pods por nó e identificamos o que estava gerando as múltiplas requisições DNS. Quando conectamos ao pod suspeito e rodamos novamente tcpdump, vimos padrões repetitivos de consultas DNS para seu próprio hostname — sugerindo uma operação contínua dentro do próprio processo desse serviço.
Descoberta do Comportamento do sudo
Após uma análise mais profunda, chegamos ao código do pod que fazia chamadas com sudo. Embora o comando em si não gerasse DNS, quando executado com sudo ocorria uma série de consultas DNS internas.
Utilizando ferramentas como ltrace, identificamos que as chamadas realizadas por sudo estavam acionando funções de busca de hostname — justamente o que estava gerando o excesso de consultas DNS.
Correção Aplicada
O motivo do comportamento estava ligado à configuração interna do sudo, que por padrão tentava resolver nomes de host. A correção consistiu em desativar essa busca por nome de host no sudo, adicionando a linha abaixo na configuração do container:
echo ‘Defaults !fqdn’ | sudo tee /etc/sudoers.d/00-no-fqdn
sudo chmod 440 /etc/sudoers.d/00-no-fqdn
Após essa alteração, as consultas DNS geradas por comandos sudo desapareceram quase que completamente, reduzindo significativamente o tráfego e eliminando os timeouts.
Resultado Final
Depois de aplicar a modificação no sudo, a quantidade de consultas DNS sem resposta caiu drasticamente, e os timeouts observaram uma redução significativa — o que melhorou a confiabilidade das resoluções de nomes em nosso cluster EKS.
Fim do Suporte ao Ingress-NGINX em 2026 — Significado e Caminhos para o Futuro
Visão Geral
O projeto Ingress-NGINX Controller, mantido pela comunidade Kubernetes como um controlador de entrada (Ingress Controller), está oficialmente chegando ao fim de sua vida útil em março de 2026. Isso significa que não haverá mais atualizações, correções de bugs ou patches de segurança após essa data, forçando equipes que dependem dele a repensarem a forma como o tráfego é roteado em seus clusters Kubernetes.
É importante diferenciar duas coisas que muitas vezes são confundidas:
- Ingress-NGINX (projeto da comunidade Kubernetes) — chegando ao fim da manutenção em 2026.
- NGINX-Ingress Controller mantido pela F5/NGINX Inc. — continua ativo e apoiado.
O foco aqui é o Ingress-NGINX (comunitário) que está sendo oficialmente aposentado.
O Que é um Ingress Controller?
Um Ingress Controller em Kubernetes atua como uma ponte entre o mundo externo e os serviços dentro de um cluster. Ele observa recursos Ingress definidos no cluster e traduz essas definições em regras que direcionam o tráfego HTTP/HTTPS para os serviços corretos.
Esse componente é essencial para ambientes de produção, pois:
- Gerencia como o tráfego externo chega aos serviços internos,
- Faz terminação TLS,
- Pode executar regratação de endereços, autenticação, redirecionamentos e outras funções de roteamento.
Ingress-NGINX tem sido, por muitos anos, uma das opções mais utilizadas e recomendadas pela comunidade Kubernetes para isso.
O Que o Fim da Vida Útil Significa
Quando um projeto atinge End-Of-Life (EOL), como o Ingress-NGINX vai fazer em março de 2026, isso implica:
- Não haverá novos lançamentos oficiais,
- Nenhuma correção de erros será disponibilizada,
- Atualizações de segurança serão interrompidas,
- O repositório ficará apenas leitura no GitHub.
Ou seja, embora suas instâncias atuais de Ingress-NGINX continuem funcionando, elas não receberão suporte ativo nem melhorias, deixando os clusters vulneráveis a riscos e incompatibilidades futuras.
Por Que Isso Está Acontecendo
A decisão de aposentar o projeto comunitário não foi súbita. Entre os principais motivos estão:
- Capacidade limitada de manutenção — o projeto tem poucas pessoas dedicadas, muitas vezes trabalhando em tempo parcial ou voluntário.
- Artigos e análises recentes apontam que problemas de segurança e complexidade tornaram o código difícil de sustentar sem um time maior.
- O API Ingress original foi congelado em termos de desenvolvimento, abrindo espaço para substitutos mais modernos.
O Que Isso Não Afeta
É importante esclarecer o que não está sendo aposentado:
- O Ingress API em si (a especificação Kubernetes para regras de entrada) continua ativa e não está sendo removida.
- O servidor NGINX tradicional ou soluções comerciais como NGINX Plus ou NGINX-Ingress totalmente suportado pela F5/NGINX Inc. continuam disponíveis e com suporte ativo.
Portanto, a mudança está relacionada especificamente à versão comunitária do Ingress-NGINX.
Quais São as Alternativas
Com o fim do Ingress-NGINX comunitário, times têm várias opções para escolher como substituto ou estratégia de migração:
Gateway API
O Gateway API é um modelo mais recente, padronizado pela comunidade Kubernetes, projetado para substituir o Ingress de forma mais robusta, com:
- Maior expressividade para regras de roteamento,
- Separação de responsabilidades entre infraestrutura e aplicações,
- Compatibilidade com múltiplos ambientes e operadores.
Esse modelo está se tornando o novo padrão recomendado para controlar a entrada de tráfego em clusters modernos.
Outros Ingress Controllers Modernos
Se você quer continuar usando um controlador de entrada com funcionalidades semelhantes ao Ingress-NGINX (isso é, lidar com regras de tráfego e TLS dentro do cluster), existem várias alternativas ativas e mantidas pela comunidade, como:
- Traefik — muito usado em ambientes cloud-native e com suporte a Gateway API;
- HAProxy Ingress — outra opção popular;
- Controladores baseados em Envoy — como Contour;
- Controladores específicos de provedores (ex.: AWS Load Balancer Controller).
Recomendações para Equipes de Infraestrutura
Se sua organização depende de Ingress-NGINX em produção hoje, considere:
- Auditar seus clusters agora para identificar onde o Ingress-NGINX está sendo usado.
- Planejar uma estratégia de transição gradual para Gateway API ou outro controlador antes de março de 2026.
- Testar controladores substitutos em ambientes de homologação antes da mudança em produção para minimizar riscos futuros.
Conclusão
O fim da vida útil do Ingress-NGINX controller comunitário em março de 2026 representa um ponto de virada significativo no ecossistema Kubernetes, exigindo que equipes revisem suas estratégias de tráfego e adaptem suas infraestruturas.
Embora continue funcionando após essa data, sua ausência de atualizações — especialmente de security patches — torna sua operação arriscada em ambientes de produção. Assim, a recomendação é agir agora para migrar para soluções mais modernas e suportadas.
