przywrócić zniszczonego mistrza kubeadm
Utworzyłem 1-główny klaster kubernetes z 2 pracownikami przy użyciu kubeadm 1.20 i utworzyłem kopię zapasową etcd. Celowo zniszczyłem mastera, aby zobaczyć test, jak przywrócić klaster do stanu działania.
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
Częściowo mi się to udaje, ponieważ sekret, który stworzyłem przed zniszczeniem mastera, jest widoczny po przywróceniu etcd, więc ta część wydaje się działać.
JEDNAK coredns pody są nieautoryzowane do wysyłania żądań do serwera API w oparciu o logi 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
Domyślam się, że ma to coś wspólnego z tokenami konta usługi, więc brakuje mi kroku, aby autoryzować pody do uwierzytelniania na serwerze API po wymianie bazy danych etcd.
czego mi brakuje?
Odpowiedzi
Gdyby utworzono kopię zapasową tylko zawartości Etcd, program kubeadm wygenerowałby nowe certyfikaty używane do podpisywania tokenów ServiceAccount JWT. Stare tokeny nie będą już weryfikować. Ponieważ zwykle nie jest to wykonywane podczas rutynowej konserwacji, nie sądzę, aby kontroler SA wiedział, aby ponownie wydać tokeny. Jeśli usuniesz wszystkie ukryte sekrety, powinieneś zrobić to ponownie.