Wiederherstellen des zerstörten Kubeadm-Masters
Ich habe mit kubeadm 1.20 einen 1-Master-2-Worker-Kubernetes-Cluster erstellt und die etcd gesichert. Ich habe den Master absichtlich zerstört, um zu testen, wie der Cluster wieder in den Betriebszustand versetzt werden kann.
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
Ich bin teilweise erfolgreich darin, dass das Geheimnis, das ich vor der Zerstörung des Masters erstellt habe, nach der Wiederherstellung von etcd sichtbar ist, sodass dieser Teil zu funktionieren scheint.
JEDOCH sind die Coredns-Pods nicht autorisiert, Anfragen an den API-Server zu stellen, basierend auf den Protokollen der Coredns-Pods:
[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
Ich vermute, es hat etwas mit Dienstkonto-Token zu tun, daher fehlt mir ein Schritt, um Pods nach dem Ersetzen von etcd db für die Authentifizierung beim API-Server zu autorisieren.
Was vermisse ich?
Antworten
Wenn Sie nur den Inhalt von Etcd gesichert hätten, hätte kubeadm neue Zertifikate generiert, die zum Signieren der ServiceAccount-JWTs verwendet wurden. Alte Token wurden nicht mehr überprüft. Da dies in der Regel nicht während der routinemäßigen Wartung erfolgt, kann der SA-Controller die Token meines Erachtens nicht erneut ausstellen. Wenn Sie alle zugrunde liegenden Geheimnisse löschen, sollte die Neuausgabe jedoch durchgeführt werden.