1. Problema Inicial: CoreDNS Instável
Tudo começou com a percepção de que a resolução de nomes de serviço dentro do cluster estava falhando intermitentemente. Uma investigação inicial apontou diretamente para o CoreDNS, o resolvedor de DNS padrão do Kubernetes.
Sintoma e Diagnóstico
Mesmo com baixo uso de recursos, os pods do CoreDNS reiniciavam constantemente, indicando que não conseguiam atingir um estado saudável.
Copiar
kubectl get pods -n kube-system -l k8s-app=kube-dns
coredns-5d9dd78484-c62xd 0/1 Running 11 (35s ago)
2. Causa Raiz: Falha da CNI (Weave Net)
A instabilidade do CoreDNS era um sintoma de um problema mais profundo na camada de rede. A investigação dos logs da CNI em uso, Weave Net, revelou a verdadeira causa do problema.
⚠️ Causa Raiz Identificada
A empresa Weaveworks encerrou suas operações, e seu domínio de verificação de versão (`checkpoint-api.weave.works`) tornou-se inacessível. Isso causava falhas de DNS dentro do próprio Weave Net, degradando toda a rede do cluster.
Copiar
kubectl logs -f -n kube-system -l name=weave-net
Error checking version: dial tcp: lookup checkpoint-api.weave.works ... server misbehaving
✅ Decisão e Ação Corretiva
A solução foi remover completamente a CNI sem suporte (Weave Net) e a tentativa falha de migração para Calico, para preparar o cluster para uma CNI estável.
Copiar
# Remover recursos do Calico
kubectl delete installation default
kubectl delete -f https://raw.githubusercontent.com/projectcalico/calico/v3.30.2/manifests/tigera-operator.yaml
# Limpeza das interfaces de rede nos nós (exemplo)
sudo ip link delete weave || true
sudo ip link delete tunl0 || true
sudo rm -f /etc/cni/net.d/10-calico.conflist
3. Solução da CNI: Migração para Flannel
Com o cluster limpo, a CNI Flannel foi escolhida por sua simplicidade. No entanto, a instalação inicial revelou um problema de configuração fundamental no próprio cluster Kubernetes.
⚠️ Novo Obstáculo: Pod CIDR Não Atribuído
Os logs do Flannel mostraram o erro `node "ora24" pod cidr not assigned`. Isso ocorreu porque o `kube-controller-manager` não estava configurado para alocar um range de IPs para os pods em cada nó.
✅ Ação Corretiva Final da Rede
A solução foi editar o manifesto estático do `kube-controller-manager` para definir o `cluster-cidr` e habilitar a alocação de CIDR para os nós. Após essa correção, o Flannel foi instalado com sucesso e o CoreDNS, após um reinício manual, estabilizou.
Copiar
# 1. Editar o manifesto do controller-manager
sudo nano /etc/kubernetes/manifests/kube-controller-manager.yaml
# Adicionar:
# - --allocate-node-cidrs=true
# - --cluster-cidr=10.244.0.0/16
# 2. Instalar o Flannel
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
# 3. Reiniciar o CoreDNS para se adaptar à nova CNI
kubectl rollout restart deployment coredns -n kube-system
4. Conexão com Rancher
Com a rede e o DNS do cluster finalmente estáveis, o último passo era restabelecer a comunicação com a plataforma de gerenciamento Rancher.
⚠️ Sintoma Final: Cluster Desconectado
A UI do Rancher mostrava o cluster como `Disconnected`. A verificação do namespace `cattle-system` revelou que ele estava vazio.
Causa: O agente do Rancher não estava implantado no cluster.
✅ Resolução: Implantação do Agente Rancher
A solução foi obter o comando de registro na UI do Rancher e executá-lo no cluster. Isso implantou o `cattle-agent`, que se conectou com sucesso ao servidor Rancher.
Copiar
# Comando obtido da UI do Rancher (exemplo)
curl --insecure -sfL https://<URL_DO_SEU_RANCHER>/v3/import/<token>.yaml | kubectl apply -f -
Resultado: O status do cluster no Rancher mudou para 'Active', concluindo a resolução do problema.