🇺🇸 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.
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
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
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.
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
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'
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-expirationperiodicamente (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
kubectljá 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)