restaurer le maître kubeadm détruit
J'ai créé un cluster kubernetes 1-master 2-workers en utilisant kubeadm 1.20 et sauvegardé le etcd. J'ai détruit le maître exprès pour voir comment remettre le cluster en état de fonctionnement.
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
J'ai partiellement réussi en ce que le secret que j'ai créé avant de détruire master est visible après la restauration etcd, donc cette partie semble fonctionner.
CEPENDANT, les pods coredns ne sont pas autorisés à faire des requêtes au serveur api, en fonction des journaux des 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
Je suppose que cela a quelque chose à voir avec les jetons de compte de service, il me manque donc une étape pour autoriser les pods à s'authentifier auprès du serveur api après le remplacement de la base de données etcd.
Qu'est-ce que je rate?
Réponses
Si vous avez uniquement sauvegardé le contenu d'Etcd, kubeadm aurait généré de nouveaux certificats utilisés pour signer les JWT ServiceAccount. Les anciens jetons ne seraient plus vérifiés. Comme cela n'est généralement pas fait pendant la maintenance de routine, je ne pense pas que le contrôleur SA sait réémettre les jetons. Si vous supprimez tous les secrets sous-jacents, la réédition doit cependant être effectuée.