Kubeadm: Das Kubeadm-Update auf 1.10 schlägt auf dem ha k8s / etcd-Cluster fehl

Erstellt am 20. Mai 2018  ·  13Kommentare  ·  Quelle: kubernetes/kubeadm

FEHLERBERICHT

Versionen

kubeadm version : 1.10.2

Umwelt :

  • Kubernetes Version : 1.9.3
  • Cloud-Anbieter oder Hardwarekonfiguration : 3 x k8s Master HA
  • Betriebssystem : RHEL7
  • Kernel : 3.10.0-693.11.6.el7.x86_64

Was ist passiert?

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:

1) kubeadm identifiziert etcd Cluster nicht als TLS-fähig

Die 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).

2) kubeadm hat nicht die richtigen Zertifikate verwendet

Nach 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.

Was hast du erwartet?

Der Upgrade-Plan sollte korrekt ausgeführt worden sein

Wie kann man es reproduzieren (so minimal und präzise wie möglich)?

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

areHA areUX areupgrades documentatioimprovement kinbug prioritimportant-soon

Alle 13 Kommentare

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.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen