DEV Community

Celso Nery
Celso Nery

Posted on

Kubernetes On-Premise: Renovando Certificados Expirados

🇺🇸 English version here.

Em instalações on-premise do Kubernetes feitas com kubeadm, os certificados internos do cluster (usados para autenticação entre os componentes do control-plane) são gerados com validade de 1 ano por padrão. Passado esse período, é comum começar a ver um erro como este ao tentar usar o kubectl:

Unable to connect to the server: x509: certificate has expired or is not yet valid.
Enter fullscreen mode Exit fullscreen mode

Esse é um problema puramente de manutenção — não indica falha de configuração — mas, se não for tratado, deixa o cluster inacessível via kubectl. Neste artigo, mostro como verificar e renovar esses certificados.

Verificando a validade dos certificados

Antes de renovar, é possível checar o estado atual (e a data de expiração) de cada certificado do cluster:

kubeadm certs check-expiration
Enter fullscreen mode Exit fullscreen mode

Esse comando lista todos os certificados gerados pelo kubeadm, indicando quais já expiraram e quais ainda estão válidos — útil tanto para diagnosticar o erro quanto para acompanhar preventivamente quando a próxima renovação será necessária.

Renovando os certificados

Para renovar todos os certificados de uma vez, execute no servidor master:

kubeadm certs renew all
Enter fullscreen mode Exit fullscreen mode

A saída deve confirmar que os certificados foram renovados:

Done renewing certificates. You must restart the kube-apiserver, kube-controller-manager, kube-scheduler and etcd, so that they can use the new certificates.
Enter fullscreen mode Exit fullscreen mode

Como o próprio comando indica, a renovação por si só não é suficiente — os componentes do control-plane precisam ser reiniciados para passarem a usar os novos certificados.

Atualizando o acesso via kubectl

Como o admin.conf também é gerado a partir dos certificados antigos, é necessário copiá-lo novamente para o seu ~/.kube/config depois da renovação:

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Enter fullscreen mode Exit fullscreen mode

Sem esse passo, mesmo com os certificados renovados no cluster, o kubectl continuará usando as credenciais antigas (já expiradas) localmente.

Reiniciando os componentes do control-plane

Por fim, force a recriação dos pods estáticos responsáveis pelo control-plane, para que eles carreguem os novos certificados:

kubectl -n kube-system delete pod -l 'component=kube-apiserver'
kubectl -n kube-system delete pod -l 'component=kube-controller-manager'
kubectl -n kube-system delete pod -l 'component=kube-scheduler'
kubectl -n kube-system delete pod -l 'component=etcd'
Enter fullscreen mode Exit fullscreen mode

Esses são pods estáticos, gerenciados diretamente pelo kubelet (não por um Deployment ou ReplicaSet) — por isso, ao serem deletados, o próprio kubelet os recria automaticamente, já lendo os certificados atualizados.

Prevenindo o problema no futuro

Como os certificados expiram anualmente por padrão, vale considerar:

  • Rodar kubeadm certs check-expiration periodicamente (por exemplo, via um cron job de monitoramento), para ser avisado antes da expiração acontecer;
  • Documentar a data de instalação (ou da última renovação) do cluster, já que o erro só costuma aparecer quando alguém tenta acessar o cluster e o kubectl já não funciona mais.

Esse é um daqueles procedimentos simples, mas fáceis de esquecer — especialmente em clusters de laboratório ou homologação que ficam meses sem interação direta.

Top comments (0)