ripristinare il master kubeadm distrutto

Dec 30 2020

Ho creato un cluster kubernetes con 1 master e 2 worker utilizzando kubeadm 1.20 e ho eseguito il backup di etcd. Ho distrutto il master apposta per vedere come testare come riportare il cluster allo stato di esecuzione.

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

Ho parzialmente successo in quanto il segreto che ho creato prima di distruggere il master è visibile dopo il ripristino di etcd, quindi quella parte sembra funzionare.

TUTTAVIA i pod core non sono autorizzati a effettuare richieste al server API, in base ai log dei pod core:

[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

Immagino che abbia qualcosa a che fare con i token dell'account di servizio, quindi manca un passaggio per autorizzare i pod ad autenticarsi su api-server dopo la sostituzione del db etcd.

Cosa mi sto perdendo?

Risposte

2 coderanger Dec 30 2020 at 13:38

Se avessi eseguito solo il backup dei contenuti di Etcd, kubeadm avrebbe generato nuovi certificati utilizzati per firmare i JWT di ServiceAccount. I vecchi gettoni non verrebbero più verificati. Poiché questo non viene generalmente fatto durante la manutenzione ordinaria, non credo che il controller SA sappia riemettere i token. Se elimini tutti i segreti sottostanti, dovrebbe comunque essere ristampato.