Kubeadm: Wie erneuere ich das Zertifikat, wenn das Apiserver-Zertifikat abgelaufen ist?

Duplikat von https://github.com/kubernetes/kubeadm/issues/206.

@zalmanzhao hast du es geschafft, dieses Problem zu lösen?

Ich habe vor etwas mehr als einem Jahr einen kubeadm v1.9.3 Cluster erstellt und er hat die ganze Zeit gut funktioniert. Ich habe heute eine Bereitstellung aktualisiert und festgestellt, dass ich von der API gesperrt war, weil das Zertifikat abgelaufen ist. Ich kann nicht einmal kubeadm alpha phase certs apiserver , weil ich failure loading apiserver certificate: the certificate has expired bekomme (die kubeadm-Version ist derzeit 1.10.6 da ich ein Upgrade durchführen möchte).

Das Hinzufügen von insecure-skip-tls-verify: true zu ~/.kube/config → clusters[0].cluser hilft auch nicht – ich sehe You must be logged in to the server (Unauthorized) wenn ich versuche, kubectl get pods (https://github. com/kubernetes/kubernetes/issues/39767).

Der Cluster funktioniert, aber er lebt sein eigenes Leben, bis er sich selbst zerstört oder die Dinge repariert werden 😅 Leider konnte ich in #206 keine Lösung für meine Situation finden und frage mich, wie ich da rauskomme. Das einzige relevante Material, das ich ausgraben konnte, war ein Blog-Beitrag namens _'Wie man abgelaufene Zertifikate im Kubernetes-Cluster ändert'_ , der auf den ersten Blick vielversprechend aussah. Allerdings hat es am Ende nicht gepasst, weil mein Master-Rechner keinen /etc/kubernetes/ssl/ Ordner hatte (nur /etc/kubernetes/pki/ ) – entweder habe ich eine andere k8s-Version oder ich habe diesen Ordner einfach ohne es zu merken gelöscht.

@errordeveloper könntest du bitte etwas empfehlen? Ich würde gerne Dinge ohne kubeadm reset und Nutzlasterholung reparieren.

@kachkaev Hatten Sie Glück bei der Erneuerung der Zertifikate, ohne den kubeadm zurückzusetzen?
Wenn ja, bitte teilen, ich habe das gleiche Problem hier mit k8s 1.7.4. Und ich kann anscheinend kein Upgrade durchführen ($ kubeadm Upgrade-Plan), da der Fehler erneut auftaucht und mir mitteilt, dass das Zertifikat abgelaufen ist und die Master in meinem Cluster nicht aufgelistet werden können:

[ERROR APIServerHealth]: the API Server is unhealthy; /healthz didn't return "ok"
[ERROR MasterNodesReady]: couldn't list masters in cluster: Get https://172.31.18.88:6443/api/v1/nodes?labelSelector=node-role.kubernetes.io%2Fmaster%3D: x509: certificate has expired or is not yet valid

Leider habe ich am Ende aufgegeben. Die Lösung bestand darin, einen neuen Cluster zu erstellen, die gesamte Nutzlast darauf wiederherzustellen, die DNS-Einträge zu wechseln und schließlich den ursprünglichen Cluster zu löschen 😭 Zumindest gab es keine Ausfallzeiten, da ich das Glück hatte, während der Umstellung gesunde Pods auf den alten k8s zu haben.

Danke @kachkaev für die Antwort. Ich werde es trotzdem noch einmal versuchen.
Wenn ich was finde, werde ich es hier posten...

Wenn Sie eine Version von kubeadm vor 1.8 verwenden, bei der meiner Meinung nach die Zertifikatsrotation #206 eingeführt wurde (als Beta-Funktion ) oder Ihre Zertifikate bereits abgelaufen sind, müssen Sie Ihre Zertifikate manuell aktualisieren (oder Ihren Cluster neu erstellen, was es scheint, dass einige (nicht nur @kachkaev) am Ende darauf zurückgreifen).

Sie müssen eine SSH-Verbindung zu Ihrem Masterknoten herstellen. Wenn Sie kubeadm >= 1.8 verwenden, fahren Sie mit 2 fort.

1. Aktualisieren Sie Kubeadm, falls erforderlich. Ich war vorher am 1.7.

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm

1. Sichern Sie alte Apiserver-, Apiserver-Kubelet-Client- und Front-Proxy-Client-Zertifikate und -Schlüssel.

$ sudo mv /etc/kubernetes/pki/apiserver.key /etc/kubernetes/pki/apiserver.key.old
$ sudo mv /etc/kubernetes/pki/apiserver.crt /etc/kubernetes/pki/apiserver.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.crt /etc/kubernetes/pki/apiserver-kubelet-client.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.key /etc/kubernetes/pki/apiserver-kubelet-client.key.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.crt /etc/kubernetes/pki/front-proxy-client.crt.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.key /etc/kubernetes/pki/front-proxy-client.key.old

1. Generieren Sie neue Apiserver-, Apiserver-Kubelet-Client- und Front-Proxy-Client-Zertifikate und -Schlüssel.

$ sudo kubeadm alpha phase certs apiserver --apiserver-advertise-address <IP address of your master server>
$ sudo kubeadm alpha phase certs apiserver-kubelet-client
$ sudo kubeadm alpha phase certs front-proxy-client

1. Alte Konfigurationsdateien sichern

$ sudo mv /etc/kubernetes/admin.conf /etc/kubernetes/admin.conf.old
$ sudo mv /etc/kubernetes/kubelet.conf /etc/kubernetes/kubelet.conf.old
$ sudo mv /etc/kubernetes/controller-manager.conf /etc/kubernetes/controller-manager.conf.old
$ sudo mv /etc/kubernetes/scheduler.conf /etc/kubernetes/scheduler.conf.old

1. Generieren Sie neue Konfigurationsdateien.

Hier gibt es einen wichtigen Hinweis. Wenn Sie sich in AWS befinden, müssen Sie den Parameter --node-name in dieser Anfrage explizit übergeben. Andernfalls erhalten Sie eine Fehlermeldung wie: Unable to register node "ip-10-0-8-141.ec2.internal" with API server: nodes "ip-10-0-8-141.ec2.internal" is forbidden: node ip-10-0-8-141 cannot modify node ip-10-0-8-141.ec2.internal in Ihren Protokollen sudo journalctl -u kubelet --all | tail und der Master-Knoten wird melden, dass es Not Ready wenn Sie kubectl get nodes ausführen.

Stellen Sie sicher, dass Sie die in --apiserver-advertise-address und --node-name Werte durch die richtigen Werte für Ihre Umgebung ersetzen.

$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address 10.0.8.141 --node-name ip-10-0-8-141.ec2.internal
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"

1. Stellen Sie sicher, dass Ihr kubectl an der richtigen Stelle nach Ihren Konfigurationsdateien sucht.

$ mv .kube/config .kube/config.old
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
$ sudo chmod 777 $HOME/.kube/config
$ export KUBECONFIG=.kube/config

1. Starten Sie Ihren Masterknoten neu

$ sudo /sbin/shutdown -r now

1. Stellen Sie erneut eine Verbindung zu Ihrem Master-Knoten her, greifen Sie nach Ihrem Token und vergewissern Sie sich, dass Ihr Master-Knoten "Bereit" ist. Kopieren Sie das Token in Ihre Zwischenablage. Sie benötigen es im nächsten Schritt.

$ kubectl get nodes
$ kubeadm token list

Wenn Sie kein gültiges Token haben. Sie können eine erstellen mit:

$ kubeadm token create

Das Token sollte etwa so aussehen wie 6dihyb.d09sbgae8ph2atjw

1. SSH in jeden der Slave-Knoten und verbinden Sie sie erneut mit dem Master

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm
$ sudo kubeadm join --token=<token from step 8>  <ip of master node>:<port used 6443 is the default> --node-name <should be the same one as from step 5>

1. Wiederholen Sie Schritt 9 für jeden Verbindungsknoten. Vom Master-Knoten aus können Sie überprüfen, ob alle Slave-Knoten verbunden und bereit sind mit:

$ kubectl get nodes

Hoffentlich bringt dich das dahin, wo du sein musst @davidcomeyne.

Vielen Dank @danroliver !
Das werde ich auf jeden Fall ausprobieren und meine Erkenntnisse hier posten.

@danroliver Danke! Habe es gerade auf einem alten Single-Node-Cluster ausprobiert, ebenso wie die Schritte bis 7. Es hat funktioniert.

@danroliver Hat bei mir

Hat bei mir nicht funktioniert, musste einen neuen Cluster einrichten. Aber schön, dass es anderen geholfen hat!

danke @danroliver . Für mich geht das
und meine kubeadm-version ist 1.8.5

Danke @danroliver , der die Schritte zusammengestellt hat. Ich musste kleine Ergänzungen zu deinen Schritten machen. Auf meinem Cluster läuft v1.9.3 und es befindet sich in einem privaten Rechenzentrum außerhalb des Internets.

Auf dem Meister

1. Bereiten Sie einen kubeadm config.yml .

apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
api:
  advertiseAddress: <master-ip>
kubernetesVersion: 1.9.3

1. Sicherungszertifikate und conf-Dateien

mkdir ~/conf-archive/
for f in `ls *.conf`;do mv $f ~/conf-archive/$f.old;done

mkdir ~/pki-archive
for f in `ls apiserver* front-*client*`;do mv $f ~/pki-archive/$f.old;done

1. Die kubeadm-Befehle auf master hatten --config config.yml wie folgt:

kubeadm alpha phase certs apiserver --config ./config.yml 
kubeadm alpha phase certs apiserver-kubelet-client --config ./config.yml 
kubeadm alpha phase certs front-proxy-client --config ./config.yml
kubeadm alpha phase kubeconfig all --config ./config.yml --node-name <master-node>
reboot

1. Token erstellen

Auf die Schergen

ich musste umziehen

mv /etc/kubernetes/pki/ca.crt ~/archive/
mv /etc/kubernetes/kubelet.conf ~/archive/
systemctl stop kubelet
kubeadm join --token=eeefff.55550009999b3333 --discovery-token-unsafe-skip-ca-verification <master-ip>:6443

Danke @danroliver! Nur bei meinem Single-Node-Cluster reichte es aus, die Schritte 1-6 (kein Neustart) zu befolgen und dann ein SIGHUP an kube-apiserver senden. Habe gerade die Container-ID mit docker ps und das Signal mit docker kill -s HUP <container id> .

Vielen Dank @danroliver! In unserem Single-Master/Multi-Worker-Cluster reichten die Schritte von 1 bis 7 aus, wir mussten nicht jeden Worker-Knoten erneut mit dem Master verbinden (was der schmerzhafteste Teil war).

Danke für diese tolle Schritt-für-Schritt-Anleitung, @danroliver! Ich frage mich, wie dieser Prozess auf einen Multi-Master-Cluster (Bare Metal, derzeit mit 1.11.1) und vorzugsweise ohne Ausfallzeiten angewendet werden könnte. Meine Zertifikate sind noch nicht abgelaufen, aber ich versuche zu lernen, wie man sie regeneriert/erneuert, bevor das passiert.

@kcronin
Bitte werfen Sie einen Blick auf dieses neue Dokument:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
Ich hoffe, das hilft.

@danroliver : Vielen Dank, es funktioniert.

Es ist nicht erforderlich, die Server neu zu starten.
Es reicht aus, Kube-System-Pods (apiserver, schduler, ...) mit diesen beiden Befehlen neu zu erstellen:

systemctl restart kubelet
für i in $(docker ps | egrep 'admin|controller|scheduler|api|fron|proxy' | rev | awk '{print $1}' | rev);
do docker stop $i; getan

Damit hatte ich auch auf einem 1.13 Cluster zu tun, in meinem Fall liefen die Zertifikate also etwas anders ab
Auch Umgang mit einer einzelnen Master\Control-Instanz vor Ort, sodass Sie sich nicht um ein HA-Setup oder AWS-Besonderheiten kümmern mussten
Habe die hinteren Stufen nicht aufgenommen, wie die anderen Jungs oben aufgenommen haben

Da die Zertifikate noch nicht abgelaufen waren, hatte der Cluster bereits Workloads, die ich weiterarbeiten wollte
Musste sich zu diesem Zeitpunkt auch nicht mit etcd-Zertifikaten befassen, also weggelassen

Also auf hohem Niveau musste ich

• Auf dem Meister
  
  
  
  • Neue Zertifikate auf dem Master generieren
  
  
  • Generieren Sie neue kubeconfigs mit eingebetteten Zertifikaten
  
  
  • Generieren Sie neue Kubelet-Zertifikate - Client und Server
  
  
  • Generieren Sie ein neues Token für die Worker-Knoten-Kubelets
  
  
• Für jeden Arbeiter
  
  
  
  • Entleeren Sie den Arbeiter zuerst auf dem Master
  
  
  • ssh zum Worker, stoppen Sie das Kubelet, entfernen Sie Dateien und starten Sie das Kubelet neu
  
  
  • Entkordele den Arbeiter am Master
  
  
• Auf Meister am Ende
  
  
  
  • Token löschen
  
  

# On master - See https://kubernetes.io/docs/setup/certificates/#all-certificates

# Generate the new certificates - you may have to deal with AWS - see above re extra certificate SANs
sudo kubeadm alpha certs renew apiserver
sudo kubeadm alpha certs renew apiserver-etcd-client
sudo kubeadm alpha certs renew apiserver-kubelet-client
sudo kubeadm alpha certs renew front-proxy-client

# Generate new kube-configs with embedded certificates - Again you may need extra AWS specific content - see above
sudo kubeadm alpha kubeconfig user --org system:masters --client-name kubernetes-admin  > admin.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-controller-manager > controller-manager.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-scheduler > scheduler.conf

# chown and chmod so they match existing files
sudo chown root:root {admin,controller-manager,kubelet,scheduler}.conf
sudo chmod 600 {admin,controller-manager,kubelet,scheduler}.conf

# Move to replace existing kubeconfigs
sudo mv admin.conf /etc/kubernetes/
sudo mv controller-manager.conf /etc/kubernetes/
sudo mv kubelet.conf /etc/kubernetes/
sudo mv scheduler.conf /etc/kubernetes/

# Restart the master components
sudo kill -s SIGHUP $(pidof kube-apiserver)
sudo kill -s SIGHUP $(pidof kube-controller-manager)
sudo kill -s SIGHUP $(pidof kube-scheduler)

# Verify master component certificates - should all be 1 year in the future
# Cert from api-server
echo -n | openssl s_client -connect localhost:6443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from controller manager
echo -n | openssl s_client -connect localhost:10257 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from scheduler
echo -n | openssl s_client -connect localhost:10259 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

# Generate kubelet.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo chown root:root kubelet.conf
sudo chmod 600 kubelet.conf

# Drain
kubectl drain --ignore-daemonsets $(hostname)
# Stop kubelet
sudo systemctl stop kubelet
# Delete files
sudo rm /var/lib/kubelet/pki/*
# Copy file
sudo mv kubelet.conf /etc/kubernetes/
# Restart
sudo systemctl start kubelet
# Uncordon
kubectl uncordon $(hostname)

# Check kubelet
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

Lassen Sie uns ein neues Token für Knoten erstellen, die dem Cluster wieder beitreten (nach dem Neustart von Kubelet)

# On master
sudo kubeadm token create

Jetzt für jeden Arbeiter - einen nach dem anderen

kubectl drain --ignore-daemonsets --delete-local-data WORKER-NODE-NAME

ssh zum Worker-Knoten

# Stop kubelet
sudo systemctl stop kubelet

# Delete files
sudo rm /etc/kubernetes/kubelet.conf
sudo rm /var/lib/kubelet/pki/*

# Alter the bootstrap token
new_token=TOKEN-FROM-CREATION-ON-MASTER
sudo sed -i "s/token: .*/token: $new_token/" /etc/kubernetes/bootstrap-kubelet.conf

# Start kubelet
sudo systemctl start kubelet

# Check kubelet certificate
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout | grep Not

Zurück zum Meister und entkordele den Arbeiter

kubectl uncordon WORKER-NODE-NAME

Nachdem alle Arbeiter aktualisiert wurden - Token entfernen - läuft in 24 Stunden ab, aber lass es uns loswerden

On master
sudo kubeadm token delete TOKEN-FROM-CREATION-ON-MASTER

@pmcgrath Danke für das Posten dieser Schritte. Ich habe es geschafft, ihnen zu folgen und meine Zertifikate zu erneuern und einen funktionierenden Cluster zu erhalten.

Wenn Sie eine Version von kubeadm vor 1.8 verwenden, bei der meiner Meinung nach die Zertifikatsrotation #206 eingeführt wurde (als Beta-Funktion ) oder Ihre Zertifikate bereits abgelaufen sind, müssen Sie Ihre Zertifikate manuell aktualisieren (oder Ihren Cluster neu erstellen, was es scheint, dass einige (nicht nur @kachkaev) am Ende darauf zurückgreifen).

Sie müssen eine SSH-Verbindung zu Ihrem Masterknoten herstellen. Wenn Sie kubeadm >= 1.8 verwenden, fahren Sie mit 2 fort.

1. Update Kubeadm, if needed. I was on 1.7 previously.

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm

1. Backup old apiserver, apiserver-kubelet-client, and front-proxy-client certs and keys.

$ sudo mv /etc/kubernetes/pki/apiserver.key /etc/kubernetes/pki/apiserver.key.old
$ sudo mv /etc/kubernetes/pki/apiserver.crt /etc/kubernetes/pki/apiserver.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.crt /etc/kubernetes/pki/apiserver-kubelet-client.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.key /etc/kubernetes/pki/apiserver-kubelet-client.key.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.crt /etc/kubernetes/pki/front-proxy-client.crt.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.key /etc/kubernetes/pki/front-proxy-client.key.old

1. Generate new apiserver, apiserver-kubelet-client, and front-proxy-client certs and keys.

$ sudo kubeadm alpha phase certs apiserver --apiserver-advertise-address <IP address of your master server>
$ sudo kubeadm alpha phase certs apiserver-kubelet-client
$ sudo kubeadm alpha phase certs front-proxy-client

1. Backup old configuration files

$ sudo mv /etc/kubernetes/admin.conf /etc/kubernetes/admin.conf.old
$ sudo mv /etc/kubernetes/kubelet.conf /etc/kubernetes/kubelet.conf.old
$ sudo mv /etc/kubernetes/controller-manager.conf /etc/kubernetes/controller-manager.conf.old
$ sudo mv /etc/kubernetes/scheduler.conf /etc/kubernetes/scheduler.conf.old

1. Generate new configuration files.

Hier gibt es einen wichtigen Hinweis. Wenn Sie sich in AWS befinden, müssen Sie den Parameter --node-name in dieser Anfrage explizit übergeben. Andernfalls erhalten Sie eine Fehlermeldung wie: Unable to register node "ip-10-0-8-141.ec2.internal" with API server: nodes "ip-10-0-8-141.ec2.internal" is forbidden: node ip-10-0-8-141 cannot modify node ip-10-0-8-141.ec2.internal in Ihren Protokollen sudo journalctl -u kubelet --all | tail und der Master-Knoten wird melden, dass es Not Ready wenn Sie kubectl get nodes ausführen.

Stellen Sie sicher, dass Sie die in --apiserver-advertise-address und --node-name Werte durch die richtigen Werte für Ihre Umgebung ersetzen.

$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address 10.0.8.141 --node-name ip-10-0-8-141.ec2.internal
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"

1. Ensure that your `kubectl` is looking in the right place for your config files.

$ mv .kube/config .kube/config.old
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
$ sudo chmod 777 $HOME/.kube/config
$ export KUBECONFIG=.kube/config

1. Reboot your master node

$ sudo /sbin/shutdown -r now

1. Reconnect to your master node and grab your token, and verify that your Master Node is "Ready". Copy the token to your clipboard. You will need it in the next step.

$ kubectl get nodes
$ kubeadm token list

Wenn Sie kein gültiges Token haben. Sie können eine erstellen mit:

$ kubeadm token create

Das Token sollte etwa so aussehen wie 6dihyb.d09sbgae8ph2atjw

1. SSH into each of the slave nodes and reconnect them to the master

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm
$ sudo kubeadm join --token=<token from step 8>  <ip of master node>:<port used 6443 is the default> --node-name <should be the same one as from step 5>

1. Repeat Step 9 for each connecting node. From the master node, you can verify that all slave nodes have connected and are ready with:

$ kubectl get nodes

Hoffentlich bringt dich das dahin, wo du sein musst @davidcomeyne.

Das brauche ich nur für 1.14.2 .. irgendwelche Hinweise zur Vorgehensweise

Damit hatte ich auch auf einem 1.13 Cluster zu tun, in meinem Fall liefen die Zertifikate also etwas anders ab
Auch Umgang mit einer einzelnen Master\Control-Instanz vor Ort, sodass Sie sich nicht um ein HA-Setup oder AWS-Besonderheiten kümmern mussten
Habe die hinteren Stufen nicht aufgenommen, wie die anderen Jungs oben aufgenommen haben

Da die Zertifikate noch nicht abgelaufen waren, hatte der Cluster bereits Workloads, die ich weiterarbeiten wollte
Musste sich zu diesem Zeitpunkt auch nicht mit etcd-Zertifikaten befassen, also weggelassen

Also auf hohem Niveau musste ich

* On the master

  * Generate new certificates on the master
  * Generate new kubeconfigs with embedded certificates
  * Generate new kubelet certicates - client and server
  * Generate a new token for the worker node kubelets

* For each worker

  * Drain the worker first on the master
  * ssh to the worker, stop the kubelet, remove files and restart the kubelet
  * Uncordon the worker on the master

* On master at the end

  * Delete token

# On master - See https://kubernetes.io/docs/setup/certificates/#all-certificates

# Generate the new certificates - you may have to deal with AWS - see above re extra certificate SANs
sudo kubeadm alpha certs renew apiserver
sudo kubeadm alpha certs renew apiserver-etcd-client
sudo kubeadm alpha certs renew apiserver-kubelet-client
sudo kubeadm alpha certs renew front-proxy-client

# Generate new kube-configs with embedded certificates - Again you may need extra AWS specific content - see above
sudo kubeadm alpha kubeconfig user --org system:masters --client-name kubernetes-admin  > admin.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-controller-manager > controller-manager.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-scheduler > scheduler.conf

# chown and chmod so they match existing files
sudo chown root:root {admin,controller-manager,kubelet,scheduler}.conf
sudo chmod 600 {admin,controller-manager,kubelet,scheduler}.conf

# Move to replace existing kubeconfigs
sudo mv admin.conf /etc/kubernetes/
sudo mv controller-manager.conf /etc/kubernetes/
sudo mv kubelet.conf /etc/kubernetes/
sudo mv scheduler.conf /etc/kubernetes/

# Restart the master components
sudo kill -s SIGHUP $(pidof kube-apiserver)
sudo kill -s SIGHUP $(pidof kube-controller-manager)
sudo kill -s SIGHUP $(pidof kube-scheduler)

# Verify master component certificates - should all be 1 year in the future
# Cert from api-server
echo -n | openssl s_client -connect localhost:6443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from controller manager
echo -n | openssl s_client -connect localhost:10257 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from scheduler
echo -n | openssl s_client -connect localhost:10259 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

# Generate kubelet.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo chown root:root kubelet.conf
sudo chmod 600 kubelet.conf

# Drain
kubectl drain --ignore-daemonsets $(hostname)
# Stop kubelet
sudo systemctl stop kubelet
# Delete files
sudo rm /var/lib/kubelet/pki/*
# Copy file
sudo mv kubelet.conf /etc/kubernetes/
# Restart
sudo systemctl start kubelet
# Uncordon
kubectl uncordon $(hostname)

# Check kubelet
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

Lassen Sie uns ein neues Token für Knoten erstellen, die dem Cluster wieder beitreten (nach dem Neustart von Kubelet)

# On master
sudo kubeadm token create

Jetzt für jeden Arbeiter - einen nach dem anderen

kubectl drain --ignore-daemonsets --delete-local-data WORKER-NODE-NAME

ssh zum Worker-Knoten

# Stop kubelet
sudo systemctl stop kubelet

# Delete files
sudo rm /etc/kubernetes/kubelet.conf
sudo rm /var/lib/kubelet/pki/*

# Alter the bootstrap token
new_token=TOKEN-FROM-CREATION-ON-MASTER
sudo sed -i "s/token: .*/token: $new_token/" /etc/kubernetes/bootstrap-kubelet.conf

# Start kubelet
sudo systemctl start kubelet

# Check kubelet certificate
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout | grep Not

Zurück zum Meister und entkordele den Arbeiter

kubectl uncordon WORKER-NODE-NAME

Nachdem alle Arbeiter aktualisiert wurden - Token entfernen - läuft in 24 Stunden ab, aber lass es uns loswerden

On master
sudo kubeadm token delete TOKEN-FROM-CREATION-ON-MASTER

Ich weiß, dass dieses Problem geschlossen ist, aber ich habe das gleiche Problem mit 1.14.2 und die Anleitung gibt keine Fehler aus, aber ich kann keine Verbindung zum Cluster herstellen und das Token erneut ausgeben (ich erhalte die Authentifizierung fehlgeschlagen).

Bei einem k8s-Cluster, der mit kubeadm v1.9.x erstellt wurde, trat das gleiche Problem auf ( apiserver-kubelet-client.crt ist am 2. Juli abgelaufen) im Alter von v1.14.1 lol

Ich musste auf 4 verschiedene Quellen verweisen, um die Zertifikate zu erneuern, die Konfigurationsdateien neu zu generieren und den einfachen 3-Knoten-Cluster zurückzubringen.

@danroliver gab sehr gute und strukturierte Anweisungen, die der untenstehenden Anleitung von IBM sehr nahe kamen.
[Erneuern von Kubernetes-Clusterzertifikaten] von IBM WoW! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

HINWEIS: IBM Financial Crimes Insight mit Watson private wird von k8s unterstützt, das wusste ich nie.

Problem mit Schritt 3 und Schritt 5

Schritt 3 sollte NICHT die Phase im Befehl enthalten

$ sudo kubeadm alpha certs renew apiserver
$ sudo kubeadm alpha certs renew apiserver-kubelet-client
$ sudo kubeadm alpha certs renew front-proxy-client

Schritt 5 sollte unten verwendet werden, kubeadm alpha hat nicht kubeconfig all, das ist stattdessen eine kubeadm-Initphase

# kubeadm init phase kubeconfig all
I0705 12:42:24.056152   32618 version.go:240] remote version is much newer: v1.15.0; falling back to: stable-1.14
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file

in 1.15 haben wir eine bessere Dokumentation für die Zertifikatserneuerung hinzugefügt:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

Außerdem verlängert kubeadm upgrade die Zertifikate nach 1.15 automatisch für Sie!

Bei einem mit kubeadm v1.9.x erstellten k8s-Cluster trat im Alter von v1.14.1 das gleiche Problem auf (apiserver-kubelet-client.crt ist am 2. Juli abgelaufen)

ältere Versionen als 1.13 werden bereits nicht unterstützt.
Wir empfehlen den Benutzern dringend, mit diesem schnelllebigen Projekt Schritt zu halten.

derzeit gibt es Diskussionen in der LongTermSupport Working Group , um Versionen von Kubernetes für längere Zeiträume zu unterstützen, aber die Einrichtung des Prozesses kann eine Weile dauern.

Danke @pmorie .
Funktioniert für Kube-Version 1.13.6

Nur ein Kommentar und eine Funktionsanfrage: Dieser Ablauf des Zertifikats hat uns heute Morgen in der Produktion auf unserem Kubernetes 1.11.x-Cluster erreicht. Wir haben alles oben (und zu den Links) versucht, sind aber auf zahlreiche Fehler gestoßen, haben nach ein paar Stunden aufgegeben und sind mit einem großen abgespritzten Cluster vollständig stecken geblieben. Glücklicherweise waren es ungefähr 2 Wochen bis zum Upgrade auf Kubernetes 1.15 (und zum Erstellen eines neuen Clusters), sodass wir am Ende einfach einen neuen 1.15-Cluster von Grund auf neu erstellt und alle unsere Benutzerdaten kopiert haben.

Ich wünschte sehr, es hätte eine Warnung gegeben, bevor dies geschah. Wir sind einfach ohne Vorwarnung von "unglaublich stabilem Cluster" zu "völlig kaputtem höllischem Albtraum" übergegangen und hatten wahrscheinlich unsere schlimmste Ausfallzeit aller Zeiten. Glücklicherweise war es ein Freitagnachmittag an der Westküste, also relativ wenig Auswirkungen.

Von allem, was oben besprochen wurde und in allen verlinkten Tickets, das Einzige, was einen Riesen gemacht hätte
Unterschied für uns wird nicht erwähnt: Beginnen Sie mit der Anzeige einer Warnung, wenn Zertifikate bald ablaufen . (Wenn Sie zB kubectl verwenden und das Zertifikat innerhalb weniger Wochen abläuft, sagen Sie es mir bitte!).

Entschuldigung für Ihre Probleme. Normalerweise liegt es in der Verantwortung des Betreibers
um die Zertifikate auf der Festplatte auf Ablauf zu überwachen. Aber ich stimme zu, dass der Mangel
der einfachen Überwachung kann zu Problemen führen. Das ist einer der Gründe, warum wir a . hinzugefügt haben
Befehl zum Überprüfen des Zertifikatablaufs in kubeadm. Sehen
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

Bitte beachten Sie auch, dass kubeadm nach 1.15 Uhr Zertifikate automatisch verlängert
Aktualisierung. Was die Benutzer ermutigt, auch häufiger zu aktualisieren.
Am 20.07.2019 um 03:49 Uhr schrieb "William Stein" [email protected] :

Nur ein Kommentar und eine Funktionsanfrage: Dieser Ablauf des Zertifikats hat uns getroffen
Produktion auf unserem Kubernetes 1.11.x-Cluster heute Morgen. Wir haben es versucht
alles oben (und zu links), aber auf zahlreiche fehler gestoßen, nach a . aufgegeben
einige Stunden mit einem großen abgespritzten Cluster vollständig stecken bleiben. Glücklicherweise,
Wir waren ungefähr 2 Wochen vom Upgrade auf Kubernetes 1.15 (und dem Aufbau) entfernt
ein neuer Cluster), also haben wir am Ende nur einen neuen 1.15-Cluster von Grund auf neu erstellt
und Kopieren aller unserer Benutzerdaten.

Ich wünschte sehr, es hätte eine Warnung gegeben, bevor dies geschah. Wir gerade
ging von "unglaublich stabilem Cluster" zu "völlig kaputter Hölle"
Albtraum" ohne Vorwarnung und hatte wahrscheinlich unsere schlimmste Ausfallzeit aller Zeiten.
Glücklicherweise war es Freitagnachmittag an der Westküste, also relativ minimal
wirkungsvoll.

Von allem, was oben und in allen verlinkten Tickets besprochen wurde, das eine
das wäre massiv geworden
Unterschied für uns wird nicht erwähnt: Beginnen Sie mit der Anzeige einer Warnung, wenn Zertifikatewerden bald auslaufen . (ZB wenn Sie kubectl verwenden und das Zertifikat ist
in ein paar Wochen ausläuft, bitte sagen Sie es mir!).

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubeadm/issues/581?email_source=notifications&email_token=AACRATDWBQHYVVRG4LYVTXLQAJOJHA5CNFSM4EGBFHKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXZJLOKDNP
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AACRATC437G4OZ3ZOEQM5LLQAJOJHANCNFSM4EGBFHKA
.

@neolit123 Danke; Wir werden unserer eigenen Überwachungsinfrastruktur etwas hinzufügen, um regelmäßig nach bevorstehenden Zertifikatsproblemen zu suchen, wie in Ihrem Kommentar erläutert.

@danroliver Vielen Dank für deine Antwort. Es hat mir viel Zeit gespart.
Erwähnenswert sind die "etcd"-bezogenen Zertifikate, die in gleicher Weise erneuert werden sollten. Ein erneutes Laden der Konfiguration ist nicht erforderlich, da sie in Metadaten-YAML-Dateien als Referenz verwendet wird.

Für Kubernetes v1.14 finde ich dieses von @desdic vorgeschlagene Verfahren am hilfreichsten:

• https://stackoverflow.com/a/56334732/1147487
  
  
  
  • Alle Zertifikate sichern und neu generieren:
  
  

$ cd /etc/kubernetes/pki/
$ mv {apiserver.crt,apiserver-etcd-client.key,apiserver-kubelet-client.crt,front-proxy-ca.crt,front-proxy-client.crt,front-proxy-client.key,front-proxy-ca.key,apiserver-kubelet-client.key,apiserver.key,apiserver-etcd-client.crt} ~/
$ kubeadm init phase certs all --apiserver-advertise-address <IP>

• Alle kubeconfig-Dateien sichern und neu generieren:

$ cd /etc/kubernetes/
$ mv {admin.conf,controller-manager.conf,mv kubelet.conf,scheduler.conf} ~/
$ kubeadm init phase kubeconfig all
$ reboot

• kopiere neue admin.conf :

$ cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

Für Kubernetes v1.14 finde ich diese Vorgehensweise am hilfreichsten:

* https://stackoverflow.com/a/56334732/1147487

Ich habe den Fix erstellt, nachdem ich meinen eigenen Cluster repariert hatte .. gehofft, dass jemand anderes ihn verwenden könnte

@danroliver gab sehr gute und strukturierte Anweisungen, die der untenstehenden Anleitung von IBM sehr nahe kamen.
[Erneuern von Kubernetes-Clusterzertifikaten] von IBM WoW! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

Schön! Ich frage mich, wann das veröffentlicht wurde. Ich hätte das sicherlich hilfreich gefunden, als ich das durchgemacht habe.

Hinweis zu Token in K8s 1.13.x (evtl. andere K8s-Versionen)
Wenn Sie Ihr CA-Zertifikat ( /etc/kubernetes/pki/ca.crt ) neu generiert haben, haben Ihre Token (siehe kubectl -n kube-system get secret | grep token ) möglicherweise eine alte CA und müssen neu generiert werden. Zu den fehlerhaften Token gehörten kube-proxy-token , coredns-token in meinem Fall (und andere), was dazu führte, dass clusterkritische Dienste sich nicht mit der K8s-API authentifizieren konnten.
Um Token neu zu generieren, löschen Sie die alten, und sie werden neu erstellt.
Gleiches gilt für alle Dienste, die mit der K8s-API kommunizieren, wie PV Provisioner, Ingress Controllers, cert-manager usw.

Danke für diese tolle Schritt-für-Schritt-Anleitung, @danroliver! Ich frage mich, wie dieser Prozess auf einen Multi-Master-Cluster (Bare Metal, derzeit mit 1.11.1) und vorzugsweise ohne Ausfallzeiten angewendet werden könnte. Meine Zertifikate sind noch nicht abgelaufen, aber ich versuche zu lernen, wie man sie regeneriert/erneuert, bevor das passiert.

Hallo @kcronin , wie hast du das mit der Multi-Master-Konfiguration gelöst? Ich weiß nicht, wie ich mit --apiserver-advertise-address . fortfahren sollda ich 3 IPs habe und nicht nur eine.

Vielen Dank

@pmcgrath Falls ich 3 Master habe, sollte ich die Schritte für jeden Master wiederholen? oder was ist die . Fall

@SuleimanWA , Sie können admin.conf sowie die CA-Datei kopieren, wenn CA neu generiert wurde.
Für alles andere sollten Sie die Schritte zum Regenerieren von Zertifikaten (für etcd, kubelet, Scheduler usw.) auf jedem Master wiederholen

@anapsix
Ich betreibe einen 1.13.x-Cluster und apiserver meldet Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid] nachdem ich die Zertifikate durch Ausführen von kubeadm alpha certs renew all erneuert habe.

Um Token neu zu generieren, löschen Sie die alten, und sie werden neu erstellt.

Auf welches Token beziehen Sie sich in diesem Fall? Wird das von kubeadm generiert oder wie kann ich das Token löschen?

-----AKTUALISIEREN-----
Ich habe herausgefunden, dass es das Geheimnis selbst ist. In meinem Fall war der Kube-Controller nicht aktiv, sodass das Geheimnis nicht automatisch generiert wurde.

hohe Version verwenden:

kubeadm alpha certs erneuern alle

Wenn das Kubelet des ersten Master-Knotens heruntergefahren ist (systemctl stop kubelet), können andere Master-Knoten CA auf dem ersten Master-Knoten nicht kontaktieren. Dies führt zu der folgenden Meldung, bis kubelet auf dem ursprünglichen Master-Knoten wieder online gebracht wird:

kubectl bekommt Knoten
Fehler vom Server (InternalError): Ein Fehler auf dem Server ("") hat die erfolgreiche Anfrage verhindert (Knoten abrufen)

Gibt es eine Möglichkeit, die CA-Rolle auf andere Master-Knoten zu übertragen, während das Kublet auf dem ursprünglichen CA-Knoten inaktiv ist?

@anapsix
Ich betreibe einen 1.13.x-Cluster und apiserver meldet Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid] nachdem ich die Zertifikate durch Ausführen von kubeadm alpha certs renew all erneuert habe.

Um Token neu zu generieren, löschen Sie die alten, und sie werden neu erstellt.

Auf welches Token beziehen Sie sich in diesem Fall? Wird das von kubeadm generiert oder wie kann ich das Token löschen?

-----AKTUALISIEREN-----
Ich habe herausgefunden, dass es das Geheimnis selbst ist. In meinem Fall war der Kube-Controller nicht aktiv, sodass das Geheimnis nicht automatisch generiert wurde.

Hallo, ich habe diese Aufgabe erledigt, aber nicht in der Version 1.13. Darf ich ein paar Dinge fragen, wenn du das schon gemacht hast?
Also im Grunde werde ich tun:
kubeadm alpha certs erneuern alle (wodurch das Control Plane cert uber pki/ Ordner auf Masters aktualisiert wird).
kubeadm init phase kubeconfig zum Aktualisieren der kube-Konfigurationsdateien. (Über Meister und Arbeiter).
Starten Sie kubelet auf allen Knoten neu.

Muss ich immer noch ein Token erstellen und Join auf Worker-Knoten ausführen? Können Sie, wenn möglich, die von Ihnen durchgeführten Schritte mitteilen?