Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
No mundo do desenvolvimento, fazer o deploy de uma stack que inclui web, API e cache como Redis pode parecer simples na teoria, mas na prática, os detalhes de configuração fazem toda a diferença.
Recentemente, me deparei com um cenário onde o time tentou integrar AngularJS, Node.js e Redis tudo rodando em Kubernetes. O erro de "getaddrinfo ENOTFOUND" é clássico quando o DNS do Kubernetes não consegue resolver o nome do serviço Redis. A decisão fica mais saudável quando o time consegue medir o impacto depois.
A questão central está na configuração do Redis no Kubernetes, especialmente na definição do hostname. Muitos esquecem que o nome do serviço precisa estar exatamente igual ao que é definido na configuração do pod ou deployment. Além disso, a comunicação entre os componentes deve estar na mesma namespace ou usar o DNS completo. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.
Outro ponto que ajuda muito é usar variáveis de ambiente para definir o endereço do Redis, assim fica mais fácil ajustar o ambiente sem mexer no código. Também recomendo verificar se o serviço do Redis está ativo e acessível usando comandos simples como kubectl exec ou nslookup. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar.
A experiência mostra que, mesmo com tudo configurado, o problema de DNS costuma ser o vilão. Ter uma estratégia de monitoramento e logs claros ajuda a identificar rapidamente se o problema é de rede, configuração ou permissão. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.
No seu caso, verificar se o nome do serviço redis está correto, se o namespace está definido, além de testar a conexão manualmente, pode ajudar a evitar surpresas na hora do deploy final.
Custo de manutenção de um cluster bem configurado pesa menos do que ficar lidando com esses erros e retrabalho.
Já passei por isso, o problema geralmente é o nome do serviço ou o namespace. Às vezes, o DNS do cluster demora pra propagar e dá esse erro. Eu faria um teste manual com
nslookupdentro do pod pra conferir.Exato, e não dá pra esquecer de checar se o Redis tá rodando na mesma namespace ou se o serviço foi criado com o nome certinho.
No meu backend, o que ajuda é usar o nome do serviço do Kubernetes mesmo, tipo redis, e cuidar para que o StatefulSet ou Deployment dele está correto. Depois, só ajustar a variável de ambiente no app.