kubeadm version : 1.10.2
Umwelt :
Vor ein paar Monaten habe ich mit kubeadm 1.9.3
einen kubernetes 1.9.3 HA-Cluster erstellt, der der 'offiziellen' Dokumentation https://kubernetes.io/docs/setup/independent/high-availability/ folgt und die eingerichtet hat etcd
HA-Cluster, der es mit statischen Pods auf den Masterknoten hostet
Ich wollte meinen Cluster mit den neuesten kubeadm
auf k8s 1.10.2
aktualisieren. Nach dem Aktualisieren von kubeadm
beim Ausführen von kubeadm upgrade plan
wurde der folgende Fehler angezeigt:
[root@shared-cob-01 tmp]# kubeadm upgrade plan
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/plan] computing upgrade possibilities
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.9.3
[upgrade/versions] kubeadm version: v1.10.2
[upgrade/versions] Latest stable version: v1.10.2
[upgrade/versions] FATAL: context deadline exceeded
Ich untersuche das Problem und habe die 2 Hauptursachen gefunden:
kubeadm
identifiziert etcd
Cluster nicht als TLS-fähigDie Anleitung weist Sie an, den folgenden Befehl im statischen Pod etcd
- etcd --name <name> \
- --data-dir /var/lib/etcd \
- --listen-client-urls http://localhost:2379 \
- --advertise-client-urls http://localhost:2379 \
- --listen-peer-urls http://localhost:2380 \
- --initial-advertise-peer-urls http://localhost:2380 \
- --cert-file=/certs/server.pem \
- --key-file=/certs/server-key.pem \
- --client-cert-auth \
- --trusted-ca-file=/certs/ca.pem \
- --peer-cert-file=/certs/peer.pem \
- --peer-key-file=/certs/peer-key.pem \
- --peer-client-cert-auth \
- --peer-trusted-ca-file=/certs/ca.pem \
- --initial-cluster etcd0=https://<etcd0-ip-address>:2380,etcd1=https://<etcd1-ip-address>:2380,etcd2=https://<etcd2-ip-address>:2380 \
- --initial-cluster-token my-etcd-token \
- --initial-cluster-state new
kubeadm >= 1.10
prüft (hier: https://github.com/kubernetes/kubernetes/blob/release-1.10/cmd/kubeadm/app/util/etcd/etcd.go#L56), ob etcd
hat TLS aktiviert, indem das Vorhandensein der folgenden Flags im statischen Pod-Befehl überprüft wird.
"--cert-file=",
"--key-file=",
"--trusted-ca-file=",
"--client-cert-auth=",
"--peer-cert-file=",
"--peer-key-file=",
"--peer-trusted-ca-file=",
"--peer-client-cert-auth=",
Da jedoch die Flags --client-cert-auth
und --peer-client-cert-auth
in den Anweisungen ohne Parameter verwendet werden (Boolesche Werte), hat kubeadm
den Cluster etcd
für TLS nicht erkannt aktiviert.
PERSÖNLICHE BEHEBUNG:
Ich habe meinen statischen Pod-Befehl etcd
aktualisiert, um - --client-cert-auth=true
und - --peer-client-cert-auth=true
ALLGEMEINES FIX:
Aktualisieren Sie die Anweisungen, um --client-cert-auth=true
und --peer-client-cert-auth=true
und entspannen Sie die Kubeadm-Checks mit "--peer-cert-file"
und "--peer-key-file"
(ohne Gleichen).
kubeadm
hat nicht die richtigen Zertifikate verwendetNach dem Beheben von Punkt 1 bestand das Problem weiterhin, da kubeadm
nicht die richtigen Zertifikate verwendete.
Wenn Sie dem kubeadm HA-Leitfaden folgen, sind die erstellten Zertifikate tatsächlich ca.pem
ca-key.pem
peer.pem
peer-key.pem
client.pem
client-key.pem
Aber die neuesten kubeadm
erwarten stattdessen ca.crt
ca.key``peer.crt
peer.key``healthcheck-client.crt
healthcheck-client.key
.
Die kubeadm-config
MasterConfiguration-Schlüssel etcd.caFile
, etcd.certFile
und etcd.keyFile
werden ignoriert.
PERSÖNLICHE BEHEBUNG:
Das .pem
Zertifikat wurde in das .crt
und .key
Äquivalent umbenannt und die etcd
statische Pod-Konfiguration aktualisiert, um sie zu verwenden.
ALLGEMEINES FIX:
Verwenden Sie die Werte kubeadm-config
data.caFile
, data.certFile
und data.keyFile
, leiten Sie die richtigen Zertifikate aus der statischen Pod-Definition etcd (Pod-Pfad + Volumes hostPath) ab und / oder erstellen Sie Ein neues temporäres Client-Zertifikat, das während des Upgrades verwendet werden soll.
Der Upgrade-Plan sollte korrekt ausgeführt worden sein
Erstellen Sie einen k8s ha-Cluster mit kubeadm 1.9.3
https://kubernetes.io/docs/setup/independent/high-availability/ und versuchen Sie, ihn mit den neuesten kubeadm
auf k8s >= 1.10
zu aktualisieren kubeadm
Dieses Problem scheint in kubeadm 1.10.3
behoben zu sein, obwohl der statische etcd
Pod nicht automatisch aktualisiert wird, da er als "extern" erkannt wird.
Ich verwende kubeadm 1.10.3
und habe die gleichen Probleme. Mein Cluster ist 1.10.2 mit einem externen sicheren etcd
@brokenmass Sehen die Werte für Ihre persönlichen Korrekturen für die zweite Ursache, die Sie bemerken, folgendermaßen aus:
caFile: /etc/kubernetes/pki/etcd/ca.crt
certFile: /etc/kubernetes/pki/etcd/healthcheck-client.crt
keyFile: /etc/kubernetes/pki/etcd/healthcheck-client.key
@detiber kannst du bitte helfen?
@FloMedja
In meinem Fall sehen die Werte so aus:
caFile: /etc/kubernetes/pki/etcd/ca.pem
certFile: /etc/kubernetes/pki/etcd/client.pem
keyFile: /etc/kubernetes/pki/etcd/client-key.pem
und 1.10.3 funktioniert korrekt
@brokenmass Mit kubeadm 1.10.3 funktioniert also alles, ohne dass Ihre persönlichen Korrekturen erforderlich sind. In diesem Fall bin ich wenig verwirrt. Ich habe kubeadm 1.10.3, aber die gleiche Fehlermeldung, die Sie in diesem Fehlerbericht erwähnen. Ich werde meine Konfiguration überprüfen, möglicherweise mache ich anderswo Fehler
füge hier deine kubeadm-config, etcd static pods yml und die volle Ausgabe von kubeadm upgrade plan
hinzu (oder trete kubernetes slack bei und sende mir eine direkte Nachricht)
Ich entschuldige mich, ich sehe das gerade. @chuckha hat die ursprüngliche Arbeit für die statischen Pod-HA-etc-Dokumente erledigt. Ich werde in den nächsten Tagen mit ihm zusammenarbeiten, um zu sehen, ob wir helfen können, die HA-Upgrades zu korrigieren.
@detiber danke. Der Upgrade-Plan funktioniert endlich. Aber ich habe einige Probleme mit den Rennbedingungen, wenn ich versuche, den Cluster zu aktualisieren. Manchmal funktioniert es. Manchmal habe ich den gleichen Fehler wie kubernetes / kubeadm / issue / 850 . kubeadm wird in den Race-Zustand versetzt, wenn versucht wird, einen Pod auf einem Knoten neu zu starten.
Ich bin heute auf einige Probleme gestoßen, als ich ein Test-Env-Setup dafür bekam, und mir läuft die Zeit davon, bevor mein Wochenende beginnt. Ich werde das Anfang nächster Woche wieder aufnehmen.
/ @chuckha @detiber zuweisen
@chuckha @detiber @stealthybox Gibt es ein Update dazu?
Das 1.9-> 1.10 HA-Upgrade war also kein unterstützter oder überprüfter Pfad.
Wir sind derzeit dabei, unsere Wartungsdokumente für 1.11-> 1.12 zu aktualisieren, die wir in Zukunft beibehalten möchten.