restaurar o mestre kubeadm destruído
Criei um cluster Kubernetes de 1 mestre e 2 trabalhadores usando o kubeadm 1.20 e fiz backup do etcd. Destruí o master de propósito para testar como fazer o cluster voltar ao estado de execução.
Kubernetes version: 1.20
Installation method: kubeadm
Host OS: windows 10 pro
Guest OS: ubuntu 18 on virtual box 6
CNI and version: weave-net
CRI and version: docker 19
Tive sucesso parcial no sentido de que o segredo que criei antes de destruir o master fica visível após a restauração do etcd, de modo que essa parte parece funcionar.
NO ENTANTO, os pods coredns não estão autorizados a fazer solicitações ao servidor API, com base nos logs dos pods coredns:
[INFO] plugin/ready: Still waiting on: "kubernetes"
E1229 21:42:25.892580 1 reflector.go:178] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:125: Failed to list *v1.Namespace: Unauthorized
E1229 21:42:29.680620 1 reflector.go:178] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:125: Failed to list *v1.Endpoints: Unauthorized
[INFO] plugin/ready: Still waiting on: "kubernetes"
E1229 21:42:39.492521 1 reflector.go:178] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:125: Failed to list *v1.Service: Unauthorized
Suponho que tenha algo a ver com tokens de conta de serviço, então há uma etapa que estou perdendo para autorizar os pods a se autenticar no api-server após a substituição do banco de dados do etcd.
o que estou perdendo?
Respostas
Se você fez backup apenas do conteúdo do Etcd, o kubeadm gerou novos certificados usados para assinar os JWTs do ServiceAccount. Os tokens antigos não seriam mais verificados. Como isso geralmente não é feito durante a manutenção de rotina, não acho que o controlador SA saiba como reemitir os tokens. Se você excluir todos os segredos subjacentes, será necessário fazer a reemissão.