Heute konnte in unserem Labor-K8s-Cluster nicht mehr daran gearbeitet werden. Als ich mich damit befasste, lag es daran, dass die Zertifikate abgelaufen waren.
Ich habe die Zertifikate und Konfigurationen neu generiert, aber wenn ich Kubelet neu starte, gelangen wir immer noch connection refusedzum API-Server. Der API-Server läuft, aber Port 6443 ist nicht geöffnet. Beim Debuggen von Protokollen erscheint der folgende Fehler in der Ausgabe (vielleicht eine falsche Fährte, aber ich bin nicht sicher):
Current certificate CN (system:node:lab-02) does not match requested CN (system:node:control-plane-xm2c9)
Dies ist ein kubeadmerstellter Cluster. Ich habe kubeadmalle Zertifikate (außer der Zertifizierungsstelle) neu generiert. Die folgenden Befehle wurden verwendet:
# kubeadm init phase certs apiserver --apiserver-cert-extra-sans control-plane-xm2c9 --apiserver-advertise-address 192.168.2.78
# kubeadm init phase certs apiserver-etcd-client
# kubeadm init phase certs apiserver-kubelet-client
Ich habe die Konfigurationen erstellt mit:
# kubeadm init phase kubeconfig admin --apiserver-advertise-address 192.168.2.78
# kubeadm init phase kubeconfig kubelet --apiserver-advertise-address 192.168.2.78
# kubeadm init phase kubeconfig controller-manager --apiserver-advertise-address 192.168.2.78
# kubeadm init phase kubeconfig scheduler --apiserver-advertise-address 192.168.2.78
Ich durchforste immer noch die Protokolle. Ich glaube, das ist die Ursache meines Problems, aber ich bin nicht sicher, wie ich es lösen kann. Jede Hilfe wäre großartig! TIA
Antwort1
Das Problem bestand, wenn ich mich richtig erinnere, darin, dass es ein Zertifikat gab, das die oben genannten Befehle nicht aktualisierten, obwohl dies erforderlich war. Es war das saZertifikat. Glücklicherweise hatte ich, bevor ich mit der Arbeit daran begann, alle Zertifikate gesichert /var/tmpund das saZertifikat war noch vorhanden und gültig. Als ich das saZertifikat zurück in das Zertifikatsverzeichnis kopierte und neu startete, kubeletfunktionierte alles wieder.