George Sims explica, em um material publicado no blog da CNCF em 3 de setembro de 2026, uma experiência de migração de um serviço de autenticação essencial em um cluster Kubernetes do namespace default para um namespace dedicado, sem interromper o serviço. O serviço, chamado pelo autor de auth-svc, era usado continuamente por dezenas de serviços e era responsável pela autenticação de usuários em uma região inteira do cluster; por isso, sua interrupção impediria o login nessa região.
O problema não era simplesmente transferir um objeto Deployment para outro namespace. Os consumidores dentro do cluster acessavam o serviço pelo nome auth-svc.default.svc.cluster.local, enquanto os usuários externos ao cluster o acessavam por meio de um Ingress separado. Além disso, os serviços consumidores pertenciam a equipes diferentes e operavam com cronogramas de lançamento distintos, o que tornava impraticável alterar todas as referências de uma só vez.
Por que não basta transferir o serviço e atualizar as referências?
O autor observa que o pipeline de implantação permitia implantar o serviço em apenas um namespace e não havia sido projetado para executar duas versões simultaneamente. Alterar a lógica do pipeline compartilhado afetaria outras equipes, algo que a equipe queria evitar. Também havia uma política baseada em OPA que impedia a existência simultânea de regras de Ingress idênticas em dois namespaces, para evitar roteamento ambíguo causado por uma migração incompleta.
Por esse motivo, a solução não foi baseada em obrigar cada consumidor a conhecer o novo endereço, mas em manter o endereço antigo válido temporariamente e redirecioná-lo para o serviço migrado.
ExternalName como endereço de redirecionamento
Depois de implantar a versão efetiva do serviço no novo namespace authentication, o objeto Service antigo em default foi convertido em um serviço do tipo ExternalName. Seu nome passou a apontar para auth-svc.authentication.svc.cluster.local, permitindo que os serviços que utilizavam o endereço antigo continuassem acessando a nova versão sem alterações imediatas no código nem uma nova implantação.
O autor compara esse mecanismo a um serviço de redirecionamento de correspondência: não é necessário entrar em contato com todos que possuem o endereço antigo; as solicitações são encaminhadas para o novo local até que os consumidores atualizem gradualmente seus endereços. No entanto, essa abordagem depende de os consumidores utilizarem um nome DNS; se alguns sistemas se conectarem a um endereço IP fixo ou ignorarem o DNS, a situação será diferente e a migração exigirá outro tratamento.
Antes de desligar a versão antiga, a equipe monitorou as métricas para confirmar que as solicitações recebidas no endereço antigo realmente chegavam ao novo Deployment e não falhavam nem entravam em um loop de redirecionamento. Após a verificação, o número de réplicas antigas foi reduzido a zero, em vez de serem excluídas imediatamente. Isso permitiu uma reversão rápida, mediante a reativação das réplicas antigas caso surgisse algum problema, deixando a exclusão definitiva para mais tarde.
Tratamento do conflito de Ingress
O caminho de acesso externo exigia um Ingress no novo namespace antes da remoção do Ingress antigo. No entanto, a política OPA impedia a criação simultânea das duas regras idênticas. Por isso, a equipe utilizou uma exceção temporária e específica, em vez de desativar completamente a política: foi adicionada uma etiqueta ao namespace authentication para permitir a superação da verificação de duplicidade de Ingress durante a migração, usando a chave policy.example.com/allow-duplicate-ingress: "true".
Durante a breve janela de sobreposição, o novo Ingress foi executado junto com o antigo; em seguida, foi verificado que o tráfego chegava ao novo Deployment. Depois disso, o Ingress antigo foi excluído, e a exceção temporária foi deixada para expirar, em vez de ser tratada como uma configuração permanente.
O que muda na prática?
A experiência mostra que a migração de um serviço sensível não exige necessariamente coordenação simultânea com todos os consumidores, desde que exista uma fronteira clara baseada em DNS. Isso, porém, não elimina a necessidade de testes graduais, monitoramento cuidadoso e um plano de reversão. A equipe executou o processo primeiro no ambiente de desenvolvimento e depois no ambiente de teste, aguardando duas semanas após o sucesso da etapa de teste antes de realizá-lo em produção.
A lição mais ampla é que o acúmulo de serviços dentro do namespace default pode permanecer sem consequências até que o serviço precise de políticas ou recursos restritos a um namespace dedicado. Nesse momento, a dívida operacional se torna um problema real. O ExternalName oferece um caminho prático para serviços que dependem de DNS, mas não é uma solução geral para sistemas que utilizam endereços fixos; além disso, a janela de sobreposição e a exceção de segurança devem ser intencionais, temporárias e acompanhadas de métricas claras.