restaurar maestro kubeadm destruido
Creé un clúster de kubernetes de 1 maestro y 2 trabajadores usando kubeadm 1.20 y realicé una copia de seguridad de etcd. Destruí el maestro a propósito para ver cómo hacer que el clúster vuelva al estado de ejecución.
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
Logré parcialmente que el secreto que creé antes de destruir el maestro es visible después de la restauración de etcd, por lo que esa parte parece funcionar.
SIN EMBARGO, los pods de coredns no están autorizados a realizar solicitudes al servidor api, según los registros de los pods de 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
Supongo que tiene algo que ver con los tokens de la cuenta de servicio, por lo que me falta un paso para autorizar a los pods a autenticarse en api-server después del reemplazo de etcd db.
¿Qué me estoy perdiendo?
Respuestas
Si solo hizo una copia de seguridad del contenido de Etcd, kubeadm habría generado nuevos certificados utilizados para firmar los JWT de ServiceAccount. Las fichas antiguas ya no se verificarían. Como esto generalmente no se hace durante el mantenimiento de rutina, no creo que el controlador de SA sepa volver a emitir los tokens. Sin embargo, si elimina todos los secretos subyacentes, debería volver a emitirse.