/cc @lukemarsden @luxas @mikedanese

Wenn wir #43474 komplett wiederherstellen, befinden wir uns wieder in einer Situation, in der wir 0.2.0-CNI-Plugins brechen (siehe https://github.com/kubernetes/kubernetes/issues/43014).

Sollten wir in Betracht ziehen, etwas wie https://github.com/kubernetes/kubernetes/pull/43284 zu tun

Auch /cc @thockin

/cc @ kubernetes / sig-network-bugs

Ref: https://github.com/kubernetes/kubernetes/issues/43397#issuecomment -289978351

@jbeda kann ich mit --loglevel=5 einige Kubelet-Protokolle abrufen?

@yujuhong – Sie erwähnen, dass Sie denken, dass dies wie beabsichtigt funktioniert. Unabhängig davon war kubeadm von diesem Verhalten abhängig. Wir haben mit #43474 einen Breaking Change eingeführt. Wir können über die richtige Lösung für 1.7 sprechen, aber im Moment müssen wir kubeadm wieder zum Laufen bringen.

Diskussion über Slack läuft jetzt – https://kubernetes.slack.com/archives/C09QYUH5W/p1490803144368246

Es sieht so aus, als ob DaemonSets auch dann geplant werden, wenn der Knoten nicht bereit ist. Das ist in diesem Fall wirklich, dass kubeadm etwas zu paranoid ist.

Der aktuelle Plan, den wir testen werden, sieht vor, dass kubeadm nicht mehr darauf wartet, dass der Master-Knoten bereit ist, sondern dass er nur registriert wird. Dies sollte gut genug sein, um ein CNI-DaemonSet zum Einrichten von CNI zu planen.

@kensimon testet das.

@jbeda ja, sieht so aus, als würde der DaemonSet-Controller sie immer noch in die Warteschlange stellen, hauptsächlich weil er die Netzwerkfähigkeit völlig ignoriert. Wir sollten das wirklich allgemeiner beheben. Gibt es in kube sofort etwas zu tun oder ist alles vorerst in kubeadm?

Ich versuche Kubernetes mit Kubeadm auf Ubuntu 16.04 zu installieren. Gibt es dafür eine schnelle Lösung?

@jbeda, wenn Sie eine gepatchte Version haben, können Sie sie gerne testen.

Ich habe kubeadm über den NotReady Status des Knotens hinwegkommen, aber die von ihm erstellte Dummy-Bereitstellung funktioniert nicht, da die node.alpha.kubernetes.io/notReady Befleckung die Ausführung verhindert. Das Hinzufügen von Toleranzen scheint nicht zu helfen, ich bin mir nicht ganz sicher, wie ich jetzt vorgehen soll. Kann jemand etwas Licht ins Dunkel bringen, wie man eine Kapsel einsetzt, die den notReady Makel toleriert?

Ich untersuche einige andere Optionen, z. B. den Knoten nicht als notReady zu markieren, aber es ist nicht klar, was wir tun möchten.

Wir haben es umgangen, indem wir KUBELET_NETWORK_ARGS aus der Kubelet-Befehlszeile entfernt haben. danach funktionierte kubeadm init einwandfrei und wir konnten das canal cni Plugin installieren.

@sbezverk würden Sie bitte beschreiben, wie das geht?

Kann die Ergebnisse von @sbezverk (gute Suche :) ) bestätigen, indem /etc/systemd/system/10-kubeadm.conf angepasst und KUBELET_NETWORK_ARGS entfernt wird, damit es auf Centos läuft. Getestet mit Gewebe.

@overip Sie müssen /etc/systemd/system/kubelet.service.d/10-kubeadm.conf bearbeiten

ExecStart = / usr / bin / kubelet $ KUBELET_KUBECONFIG_ARGS $ KUBELET_SYSTEM_PODS_ARGS $ KUBELET_NETWORK_ARGS $ KUBELET_DNS_ARGS $ KUBELET_AUTHZ_ARGS $ KUBELET_EXTRA_ARGS

$KUBELET_NETWORK_ARGS entfernen

und dann kubelet neu starten, nachdem bebeadm init funktionieren sollte.

das habe ich gemacht

kubeadm zurücksetzen

ENV-Einträge entfernen aus:

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Systemd- und Kube-Dienste neu laden

systemctl daemon-reload
systemctl Neustart kubelet.service

Init erneut ausführen

kubeadm init

Alles richtig und wenn wir schon dabei sind

Wenn Sie dies sehen:
kubelet: error: Kubelet konnte nicht ausgeführt werden: Kubelet konnte nicht erstellt werden: Fehlkonfiguration: kubelet cgroup driver: "cgroupfs" unterscheidet sich von docker cgroup driver: "systemd"

Sie müssen Ihre /etc/systemd/system/kubelet.service.d/10-kubeadm.conf bearbeiten und das Flag --cgroup-driver="systemd" hinzufügen

und mach es wie oben

kuebadm zurücksetzen
systemctl daemon-reload
systemctl Neustart kubelet.service
kubeadm init.

Ich würde vorsichtig sein, --network-plugin=cni aus den Kubelet-CLI-Flags zu entfernen, dies führt dazu, dass Kubelet standardmäßig das no_op-Plugin verwendet ... Ich wäre überrascht, wenn gängige Plugins wie Calico/Weave in diesem Fall überhaupt funktionieren würden (aber Andererseits ist mein Verständnis davon, wie diese Plugins darunter funktionieren, etwas eingeschränkt.)

@kensimon hm, ich habe keine Probleme mit meinem Setup gesehen, ich habe das Kanal-Cni-Plugin bereitgestellt und es hat gut funktioniert.

@sbezverk Funktioniert das Cross-Host-Networking auch gut?

@resouer kann das nicht bestätigen, ich habe 1.6.0 nur als All-In-One.

@resouer @sbezverk Ich

 [root@deploy-01 x86_64]# kubectl get nodes
 NAME        STATUS    AGE       VERSION
 deploy-01   Ready     51m       v1.6.0
 master-01   Ready     4m        v1.6.0

``` [ root@deploy-01 x86_64]# kubectl get pods -n kube-system
NAME BEREIT STATUS NEUSTART ALTER
etcd-deploy-01 1/1 Läuft 0 50m
kube-apiserver-deploy-01 1/1 Läuft 0 51m
kube-controller-manager-deploy-01 1/1 Läuft 0 50m
kube-dns-3913472980-6plgh 3/3 Laufen 0 51m
kube-proxy-mbvdh 1/1 Laufen 0 4m
kube-proxy-rmp36 1/1 Laufend 0 51m
kube-scheduler-deploy-01 1/1 Läuft 0 50m
kubernetes-dashboard-2396447444-fm8cz 1/1 Laufen 0 24m
weave-net-3t487 2/2 Laufen 0 44m
weben-net-hhcqp 2/2 Laufen 0 4m

```

Problemumgehung funktioniert, aber Flanell geht nicht...

@stevenbower Worst-Case-Szenario können Sie diese Einstellung zurücksetzen und kubelet neu starten, wenn Sie mit kubeadm business fertig sind.

Ich habe einen Cluster mit drei Knoten, bei dem weave funktioniert. Ich bin mir nicht sicher, wie stabil dies mit diesem Hack sein könnte, aber trotzdem danke! :smiley:

Auf einem Seitenknoten können Sie das $KUBELET_NETWORK_ARGS nach der Initialisierung auf den Masterpassagen zurücksetzen. Ich habe es auf der Maschine, der ich beigetreten bin, nicht entfernt, nur den cgroup-Treiber, sonst funktionieren Kubelet und Docker nicht zusammen.

Aber Sie müssen kubeadm nicht zurücksetzen, ändern Sie einfach /etc/systemd/system/kubelet.service.d/10-kubeadm.conf und führen Sie den systemctl-Tanz aus:

systemctl daemon-reload
systemctl Neustart kubelet.service

An diejenigen unter Ihnen, die KUBELET_NETWORK_ARGS fallen lassen und melden, dass es für Sie funktioniert:

Für mich habe ich 2 Cluster: einen, in dem ich den Patch von https://github.com/kubernetes/kubernetes/pull/43824 angewendet und kubeadm bei der Initialisierung normal fortfahren ließ, und einen mit gelöschtem KUBELET_NETWORK_ARGS. Auf dem Cluster mit entferntem KUBELET_NETWORK_ARGS schlägt jeglicher Datenverkehr zwischen Pods fehl.

Auf einem Cluster mit entferntem KUBELET_NETWORK_ARGS:

$ kubectl run nginx --image=nginx
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
wget: bad address 'nginx.default.svc.cluster.local'

Auf einem Cluster mit normalem KUBELET_NETWORK_ARGS, aber mit einem gepatchten kubeadm:

$ kubectl run nginx --image=nginx          
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
Connecting to nginx.default.svc.cluster.local (10.109.159.41:80)
index.html           100% |********************************************************************************************|   612   0:00:00 ETA

Wenn Sie zu denen gehören, die KUBELET_NETWORK_ARGS deaktiviert haben, prüfen Sie, ob die oben genannten Maßnahmen für Sie geeignet sind.

Ich schlage vor, dass wir sowohl den Knoten bereit als auch den Dummy-Deployment-Check ablegen
insgesamt für 1.6 und verschieben sie in eine Validierungsphase für 1.7.

Am 29. März 2017 10:13 schrieb "Dan Williams" [email protected] :

@jbeda https://github.com/jbeda ja, sieht aus wie das DaemonSet
Controller wird sie immer noch in die Warteschlange stellen, hauptsächlich weil er völlig unwissend ist
der Netzwerkfähigkeit. Wir sollten das wirklich allgemeiner beheben. Gibt es
Gibt es in kube sofort etwas zu tun oder ist alles vorerst in kubeadm?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290158416 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABtFIUw8GIJVfHrecB3qpTLT8Q4AyLVjks5rqpFKgaJpZM4MtMRe
.

Hat noch jemand Ubuntu 16.04 im Einsatz? Ich habe KUBELET_NETWORK_ARGS aus dem systemd Dienst entfernt und den systemd Daemon neu geladen. Ich kann einen Master-Knoten aufdrehen, aber keinem Knoten beitreten. Es schlägt fehl mit dem Fehler The requested resource is unavailable

KUBELET_NETWORK_ARGS entfernt, jeglicher Datenverkehr zwischen Pods schlägt fehl.

Ich wäre nicht überrascht, da KUBELET_NETWORK_ARGS kubelet sagt, welches Plugin verwendet werden soll, wo nach der Konfiguration und den Binärdateien gesucht werden soll. Du brauchst sie.

Ich empfehle #43835 (und den 1.6 Cherry Pick #43837) als Fix für 1.6. Ich habe beide getestet und sie funktionieren. Ich habe @jbeda und @luxas zugewiesen, beim Aufwachen zu überprüfen.

Beide PRs sehen vernünftig aus. Aber ich denke, wir sollten stattdessen https://github.com/kubernetes/kubernetes/pull/43824 verwenden. Obwohl es etwas komplizierter ist, behält es diesen Codepfad bei, damit Benutzer, die CNI vorkonfigurieren, ohne ein Daemonset zu verwenden (ich mache dies in https://github.com/jbeda/kubeadm-gce-tf, obwohl ich es nicht getan habe) auf 1.6) aktualisiert, warten immer noch darauf, dass die Knoten bereit sind.

Als Bonus ist dies @kensimons erster PR für Kubernetes und er hat alle Register gezogen, um dieses Zeug zu testen. Aber um ehrlich zu sein, sie sind beide praktikabel und ich möchte wirklich, dass es behoben wird. :)

Entschuldigung, ich habe https://github.com/kubernetes/kubernetes/pull/43824 verpasst

Ich bin auch mit beiden zufrieden, wenn beide auch funktionieren

@kensimon Es funktioniert bei mir, wenn ich KUBELET_NETWORK_ARGS während kubadm init deaktiviere. Dank deiner Anleitung konnte ich das verifizieren.

@webwurst bestätigt, KUBELET_NETWORK_ARGS während kubadm init deaktivieren. Ich musste kube-dns jedoch neu starten, damit es es abholt. Die Prüfung von @kensimon funktioniert, DNS löst sich auf.

Obwohl ich zustimme, dass dies ein schrecklicher Hack ist und für die meisten Leute zu schrecklich ist, um ihm zu folgen, wenn man sich die Slack-Kanäle ansieht.

Eine bessere Lösung bieten die Patches von

@coeki wie genau hast du kube-dns neu gestartet. Ich habe kubectl delete pod kube-dns-3913472980-l771x --namespace=kube-system ausprobiert und jetzt bleibt kube-dns auf ausstehend kube-system kube-dns-3913472980-7jrwm 0/3 Pending 0 4m
Es tat genau wie beschrieben: KUBELET_NETWORK_ARGS entfernen, sudo systemctl daemon-reload && sudo systemctl restart kubelet.service , kubeadm init , KUBELET_NETWORK_ARGS hinzufügen, wieder sudo systemctl daemon-reload && sudo systemctl restart kubelet.service
Aber dann bleibt mein Meister in NotReady . In describe bekomme ich

Conditions:
  Type          Status  LastHeartbeatTime           LastTransitionTime          Reason              Message
  ----          ------  -----------------           ------------------          ------              -------
...
KubeletNotReady         runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Ich habe den kube-dns-Neustart wie oben beschrieben versucht, aber kein Erfolg. Irgendeine Idee? Ich sterbe daran und versuche, unseren Cluster nach einem fehlgeschlagenen 1.6.0-Upgrade dieses Morgens wieder zum Laufen zu bringen :(

@patte Also ich nur delete pods kube-dns-3913472980-3ljfx -n kube-system Und dann kommt kube-dns wieder hoch.

Haben Sie nach kubeadm init KUBELET_NETWORK_ARGS hinzugefügt und erneut sudo systemctl daemon-reload && sudo systemctl restart kubelet.service ein Pod-Netzwerk wie Weave oder Calico installiert? Fügen Sie das zuerst hinzu, Sie sollten in der Lage sein, es zum Laufen zu bringen.

Ich habe es auf centos7 ausprobiert und getestet und es gerade auf Ubuntu/Xenial gemacht, sollte also funktionieren.

Um zusammenzufassen, was ich getan habe:

KUBELET_NETWORK_ARGS remove entfernen
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubeadm init --token=$TOKEN --apiserver-advertise-address=$(your apiserver ip address)

füge KUBELET_NETWORK_ARGS wieder hinzu
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubectl apply -f https://git.io/weave-kube-1.6

Ich bin einer Maschine beigetreten und muss normalerweise eine statische Route zu 10.96.0.0 (Cluster-IP) hinzufügen, da ich auf Landstreicher bin.
Verwenden Sie es mit dem $TOKEN, aber dieser Schritt ist extra.

Dann:

delete pods kube-dns-3913472980-3ljfx -n kube-system

Warte darauf

kubectl run nginx --image=nginx
kubectl expose deployment nginx --port 80
kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
/ # wget nginx.default.svc.cluster.local Connecting to nginx.default.svc.cluster.local (10.101.169.36:80) index.html 100% |***********************************************************************| 612 0:00:00 ETA

Funktioniert für mich, obwohl es ein schrecklicher Hack ist ;)

Ich bin wirklich überrascht, dass die Entwickler-Community von Kubernetes keine ETA für einen offiziellen Fix bereitgestellt hat. Ich meine, dies ist ein schrecklicher Fehler, der während des Codetests leicht abgefangen werden sollte. Da dies nicht der Fall ist, sollte zumindest 1.6.1 mit dem Fix so schnell wie möglich veröffentlicht werden, damit die Leute aufhören, ihre Cluster zu hacken und produktive Dinge tun ;). Liege ich hier falsch?

Hallo zusammen,

Ich war diese Woche etwas abgelenkt und das ist ein langer Thread voller
Kubeadm-Zeug kenne ich nicht so gut. Kann mir jemand zusammenfassen? ich
Ich denke, ich verstehe den Kern des Fehlers, aber was sind die vorgeschlagenen Lösungen und?
was macht sie schrecklich?

Am Do, 30. März 2017 um 8:13 Uhr, Serguei Bezverkhi < [email protected]

schrieb:

Ich bin wirklich überrascht, dass die Kubernetes-Entwicklungsgemeinschaft dies nicht hat
eine ETA für einen offiziellen Fix zur Verfügung gestellt. Ich meine, das ist ein schrecklicher Fehler, der
sollte während des Codetests leicht erwischt werden. Da dies nicht der Fall ist,
zumindest sollte 1.6.1 so schnell wie möglich mit dem Fix verschoben werden, damit die Leute es tun würden
Hör auf, ihre Cluster zu hacken und fang an, produktive Dinge zu tun ;). Bin ich?
hier falsch?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290442315 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AFVgVEoKuUf28VazmUApsnyfGhuAhZIqks5rq8aLgaJpZM4MtMRe
.

Eine Änderung in kubelet (#43474) führte dazu, dass kubelet begann, korrekt zu melden, dass das Netzwerk nicht bereit ist, bevor das cni-Plugin initialisiert wurde. Dies brach einige der Reihenfolgen, von denen wir abhängig waren, und verursachte einen Deadlock bei der Initialisierung des kubeadm-Masters. Wir haben es nicht verstanden, weil kubeadm e2e-Tests vor dieser Änderung einige Tage lang unterbrochen wurden.

Derzeit vorgeschlagene Fixes sind Nr. 43824 und Nr. 43835.

Okay, das habe ich verstanden. Die Verriegelung zwischen Netzwerk-Plugin
kommt und die Knotenbereitschaft ist im Moment ein wenig schrecklich.

Am Do, 30. März 2017 um 8:28 Uhr, Mike Danese [email protected]
schrieb:

Eine Änderung im Kubelet (#43474 .)
https://github.com/kubernetes/kubernetes/pull/43474 ) verursachte Kubelet zu
Starten Sie richtig, das Netzwerk zu melden, das nicht bereit ist, bevor das CNI-Plugin war
initialisiert. Dies hat einige Bestellungen gebrochen, von denen wir abhängig waren und die wir verursacht haben
ein Deadlock bei der Initialisierung des kubeadm-Masters. Wir haben es nicht erwischt, weil
kubeadm e2e-Tests waren vor dieser Änderung einige Tage unterbrochen.

Aktuell vorgeschlagene Fixes sind #43824
https://github.com/kubernetes/kubernetes/pull/43824 und #43835
https://github.com/kubernetes/kubernetes/pull/43835 .

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290447309 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AFVgVLzQLxeV6qp1Rw1fNALDDaf-Sktyks5rq8o2gaJpZM4MtMRe
.

Ich bevorzuge immer noch #43835. Es ist eine einfachere Änderung, ich denke nicht, dass die e2e-Checks dort durchgeführt werden sollten, wo sie sind, und es gibt Berichte darüber, dass #43824 immer noch nicht funktioniert. Ich werde mich heute bemühen, das zu lösen.

+1, um das Problem heute zu lösen, da viel Aufwand für den Umgang mit Sicherheiten aus der Problemumgehung verschwendet wird.

Ich kann nicht glauben, dass niemand kubeadm 1.6.0 wirklich ausprobiert hat, bevor 1.6.0 veröffentlicht wurde....

Und kubelet 1.5.6 + kubeadm 1.5.6 sind auch defekt, /etc/systemd/system/kubelet.service.d/10-kubeadm.conf verweist auf /etc/kubernetes/pki/ca.crt, aber kubeadm generiert nicht ca.crt, es gibt jedoch ca.pem.

Derzeit sind 1.6.0 und 1.5.6 die einzigen verbleibenden Releases im k8s apt-Repository...

"aus der Kiste gebrochen", Worte heute gelernt.

Ich bevorzuge immer noch #43835. Es ist eine einfachere Änderung, ich denke nicht, dass die e2e-Checks dort durchgeführt werden sollten, wo sie sind, und es gibt Berichte darüber, dass #43824 immer noch nicht funktioniert. Ich werde mich heute bemühen, das zu lösen.

Stimme Mike in diesem Fall zu. #43835 ist die einfachere Änderung, und die Validierung (falls erforderlich) kann in einer separaten Phase erfolgen.

@thockin wir brauchen wirklich feinkörnigere Bedingungen und Status für das Networking, insbesondere mit ho stNetwork:true. Knoten können für einige Pods bereit sein, andere jedoch nicht.

Wir können nodeNetworkUnavailable nicht verwenden, da dies spezifisch für Cloud-Anbieter ist. Wir brauchen wahrscheinlich einen anderen oder eine Möglichkeit für den Scheduler, ho stNetwork:true- Pods auf Knoten mit Net workReady:false zuzulassen oder die Taints für unbereite Knoten zum Laufen zu bringen. Und funktionierende kubeadm e2e-Tests :(

Zustimmen. Ich habe das Problem verzögert, weil ich keine guten Antworten hatte,
aber wir müssen das in 1.7 . bekommen

Am Do, 30. März 2017 um 10:02 Uhr, Dan Williams [email protected]
schrieb:

@tockin https://github.com/tockin wir brauchen wirklich feinere Körnung
Bedingungen und Status für die Vernetzung, insbesondere mit ho stNetwork:true.
Knoten können für einige Pods bereit sein, andere jedoch nicht.

Wir können nodeNetworkUnavailable nicht verwenden, da dies spezifisch für die Cloud ist
Anbieter. Wir brauchen wahrscheinlich einen anderen oder eine Möglichkeit für den Scheduler, dies zu tun
erlauben Sie ho stNetwork:true Pods auf Knoten mit Net workReady:false , oder machen Sie das
Taints funktionieren für unfertige Knoten.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290475480 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AFVgVAaO9c76_R8me9PDo96AQ1ZrplMxks5rq-A1gaJpZM4MtMRe
.

@tockin eine bevorzugte Lösung? Wir können entweder die Knotenbereitschaft blockieren und herausfinden, wer IsNodeReady() verwendet, wie wir es bereits getan haben, oder wir könnten eine weitere Knotenbedingung hinzufügen und dann wer-weiß-wie-viele Bits der Codebasis woanders dafür reparieren. Oder vielleicht gibt es noch eine andere Möglichkeit.

Wir können nodeNetworkUnavailable nicht verwenden, da dies spezifisch für Cloud-Anbieter ist. Wir brauchen wahrscheinlich einen anderen oder eine Möglichkeit für den Scheduler, ho stNetwork:true- Pods auf Knoten mit Net workReady:false zuzulassen oder die Taints für unbereite Knoten zum Laufen zu bringen.

Ich denke, der Scheduler kann so eingestellt werden, dass er Taints und Toleranzen respektiert, anstatt alle unfertigen Knoten vollständig auszuschließen.
Jemand muss die Toleranz jedoch auf die ho stNetwork:true- Pods anwenden. Ich weiß nicht, wer, aber es sollte nicht der Scheduler sein, da es viel zu viel zu sein scheint, dem Scheduler beizubringen, die Pod-Spezifikation zu verstehen.

/cc @davidopp @dchen1107

Außerdem scheint es für jeden, der meine oder michaels Patches ausprobiert hat und auf der kommenden Steuerungsebene hängen bleibt, so, als ob das Erstellen eines kubeadm aus master nicht funktioniert, wenn es einen v1.6.0-Cluster verwaltet , weil kubeadm versucht hat, kube-apiserver mit ungültigen Argumenten zu starten:

unknown flag: --proxy-client-cert-file

Wenn Sie meine oder Michaels Änderungen gegen einen v1.6.0-Cluster testen möchten, wählen Sie sie gegen v1.6.0 aus, anstatt vorerst auf dem Master aufzubauen.

@yujuhong der Scheduler wendet bereits automatisch Toleranzen auf Pods an (siehe https://github.com/kubernetes/kubernetes/pull/41414), dies scheint ein ähnlicher Anwendungsfall zu sein

Ich habe kein klares Bild von all den Makeln und der Bereitschaft bzgl
Netzwerk, an dieser Stelle. Dan, hast du eine halbe Stunde Zeit, um das aufzuschreiben?
aktuellen Zustand, damit wir anfangen können, ihn auseinander zu ziehen? Ich glaube du weißt es
Beste. Ich habe das Gefühl, dass wir eine Reihe von granularen Problemen haben, die wir nur haben
bisher deckend.

Am Do, 30. März 2017 um 10:22 Uhr, Ken Simon [email protected]
schrieb:

@yujuhong https://github.com/yujuhong der Planer schon
wendet automatisch Toleranzen auf Pods an (siehe #41414
https://github.com/kubernetes/kubernetes/pull/41414 ), das scheint wie ein
ähnlicher Anwendungsfall

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290481017 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AFVgVMas2IP5X5YA0V5626UlGbaS98jtks5rq-TCgaJpZM4MtMRe
.

@thockin kann ich das machen, wo soll ich es

Es gibt ein paar verwandte Probleme, können wir eines davon umbenennen, posten Sie a
Zusammenfassung des aktuellen Zustands und gehen von dort aus?

Am Do, 30. März 2017 um 10:50 Uhr, Dan Williams [email protected]
schrieb:

@tockin https://github.com/tockin Das kann ich machen, wo soll ich das hinstellen
es?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290489157 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AFVgVCXJYk9J0QmjTqQA6PPVuhzMhlLZks5rq-t-gaJpZM4MtMRe
.

Haben wir jederzeit eine Nachricht, wann dieser Fix in das CentOS-Repository portiert wird?

In 1.6 wendet Core Kubernetes standardmäßig keine Taints auf Knoten an. Der Scheduler respektiert Taints, die von Bereitstellungssystemen wie kubeadm, kops usw. hinzugefügt oder von Benutzern manuell hinzugefügt werden (und respektiert die entsprechenden Toleranzen, die Pods hinzugefügt werden).

In 1.6 schließt der Kubernetes-Scheduler standardmäßig Knoten von der Berücksichtigung aus, wenn sie bestimmte Knotenbedingungen melden, einschließlich der Nichtverfügbarkeit des Netzwerks. Der Code dafür ist hier . Es hat nichts mit Taints zu tun – es betrachtet nur den Knotenzustand.

In 1.6 können Sie ein Alpha-Feature aktivieren, das Kern-Kubernetes (den NodeController) veranlasst, einen NoExecute-Taint hinzuzufügen, wenn NodeReady == "False" oder NodeReady == "Unknown" vorhanden ist. Dies führt dazu, dass Pods, die auf dem Knoten ausgeführt werden, entfernt werden (wenn sie den Taint nicht tolerieren) und verhindert, dass neue Pods auf dem Node geplant werden (wenn sie den Taint nicht tolerieren).

Der langfristige Plan besteht darin, die gesamte Logik "wie der Kern von Kubernetes auf Knotenbedingungen reagiert, in Bezug auf Planung und Räumung" auf die Verwendung von Taints und Toleranzen (zB #42001) umzustellen. Aber wir sind noch nicht da und werden es auch noch eine Weile sein. Kurzfristig gibt es für einen Pod also keine Möglichkeit, NetworkUnavailable oder andere Knotenbedingungen zu "tolerieren", die Sie möglicherweise hinzufügen möchten.

Wenn ich verstehe, was @davidopp richtig gesagt hat, dann ist die Funktion NodeReady, die jetzt wahr oder falsch oder unbekannt zurückgibt, eine Liste mit dem ankreuzt, was benötigt wird. Wenn es eine Liste mit nicht erfüllten Werten zurückgeben könnte, können Sie dies testen.

Im Fall von kubeadm ist NetworkUnavailable der einzige. kubeadm kann true zurückgeben. Das ist für den Fall, dass wir nicht möchten, dass das Networking/Cni-Plugin zur kubeadm-Init-Zeit übergeben wird.

Denn wenn ich das richtig verstehe, werden die Taints und die Toleranz zumindest für kubeadm basierend auf dieser Funktion gesetzt.

Korrigiert mich, wenn ich falsch liege ;)

Ich springe zu diesem Thread, weil ich auf dieses Problem gestoßen bin und es nervt:

Warum kann die Netzwerkbereitschaft nicht zu einem Makel werden, den das Kubelet basierend auf dem Zustand des Netzwerks auf dem Knoten hinzufügt und entfernt?
Auf diese Weise kann der Knoten für alle Pods "bereit" sein, die die Netzwerkbereitschafts-Taint tolerieren (Pod-Netzwerk-Apps).

Was Host-Netzwerk-Pods angeht, könnte ein Zugangscontroller Toleranzen für die Bereitschaft des Pod-Netzwerks injizieren.

Ich denke, das stimmt mit dem langfristigen Plan in Davidopps Kommentar überein.

Ich denke, das stimmt mit dem langfristigen Plan in Davidopps Kommentar überein.

Ja genau. Der langfristige Plan besteht darin, für jeden Knotenzustand einen Taint zu haben und keine internen Elemente in Kubernetes mehr auf die Knotenbedingungen zu achten. Wir begannen diese Arbeit mit dem erwähnten 1.6-Alpha-Feature.

Ack. Gibt es einen Grund, in Patch-Release v1.6 nicht auf Taints umzusteigen?

Der Code zum automatischen Hinzufügen von Taints basierend auf Knotenbedingungen ging gerade in 1.6 in die Alpha-Phase. Es ist nicht bereit, sich darauf zu verlassen. (Und es behandelt derzeit nur den Zustand der Knotenbereitschaft, nicht das Netzwerk).

Wenn ich das richtig verstehe, müssen wir vorerst, da https://github.com/kubernetes/features/issues/166 etwas länger braucht, um die Netzwerkverfügbarkeit korrekt zu beeinträchtigen, einen Workaround durchführen. Wenn wir so schnell wie möglich einen Fix für kubeadm, wie #43835, mit einem Kommentar bereitstellen können, um dies mit https://github.com/kubernetes/features/issues/166 zu beheben, werden viele Leute glücklich sein.

@davidopp Ich nehme an, du nicht verlassen ". Mir fehlt immer noch die Beziehung zwischen der automatischen Bedingung und der Taint-Logik, die Sie erwähnt haben, mit dem Kubelet, das Taints direkt für Netzwerkprobleme veröffentlicht.

Ja danke, das war ein Tippfehler, jetzt behoben

Ja, Sie könnten Kubelet den Makel hinzufügen lassen. Es ist möglicherweise nicht ideal, wenn Kubelet die Taints für einige Knotenbedingungen hinzufügt und NodeController sie für andere Knotenbedingungen hinzufügt (letzteres ist notwendig, da nur der Master den nicht erreichbaren Knoten erkennen kann), aber das ist nur ein Argument der Softwareentwicklung, nichts Grundlegendes. Mein Plan war, dass NodeController die Taints für alle Knotenbedingungen hinzufügt, aber es gibt keine zwingende Anforderung, dies auf diese Weise zu tun.

Ack. In diesem Fall sind einer einzelnen Knotenbedingung mehrere Attribute zugeordnet, die der Knotencontroller möglicherweise nicht erkennen kann.
@mikedanese Ich kubeadm init das zu einem funktionierenden Knoten führt, ansprechend. Ich hoffe, dass die Anforderung, eine validation Phase hinzuzufügen, nicht in erster Linie auf diesem Problem basiert.
@dcbw @thockin @yujuhong irgendwelche Gedanken zur Verwendung von Taints zur Darstellung von Knotenkonfigurationsproblemen im Kubelet?

Beachten Sie, dass Sie die zuvor erwähnte Funktion ändern müssen (dh sie aus dem Satz von Bedingungen entfernen, die einen Knoten herausfiltern), wenn Sie möchten, dass Ihr neuer Taint das aktuelle automatische Herausfiltern von Knoten durch NetworkUnavailable ersetzt. Ich weiß nicht, welche anderen Nebeneffekte das haben wird, da diese Funktion in anderen Knotenlisten als nur dem Scheduler verwendet werden kann.

Gibt es eine Möglichkeit, 1.5.6 zu installieren, die unter Ubuntu funktionieren sollte? Wenn ja, könnten Sie bitte erklären, wie es geht? Vielen Dank!

Beachten Sie, dass Sie die zuvor erwähnte Funktion ändern müssen (dh sie aus dem Satz von Bedingungen entfernen, die einen Knoten herausfiltern), wenn Sie möchten, dass Ihr neuer Taint das aktuelle automatische Herausfiltern von Knoten durch NetworkUnavailable ersetzt. Ich weiß nicht, welche anderen Nebeneffekte das haben wird, da diese Funktion in anderen Knotenlisten als nur dem Scheduler verwendet werden kann.

@davidopp wir müssen vorsichtig sein mit NetworkUnavailable vs. NodeReady. Es gibt zwei separate Bedingungen, die wirklich bereinigt werden sollten:

nodeNetworkUnavailable – Dies ist spezifisch für Cloud-Routen und nur Cloud-Route-Controller löschen diese Bedingung, wenn Cloud-Routen zwischen Knoten eingerichtet wurden. Netzwerk-Plugins, die Overlays erstellen oder kein L3-Routing zwischen Knoten durchführen, möchten oder verwenden diese Bedingung nicht. Diese Bedingung wird von keinem Netzwerk-Plugin hinzugefügt; es wird von kubelet speziell hinzugefügt, wenn GCE oder AWS als Cloud-Anbieter ausgewählt werden. Wirkt sich nicht auf NodeReady aus, da es sich um eine separate Bedingung handelt.

NodeReady - direkt von den Netzwerk-Plugins betroffen (zB CNI oder Kubenet oder Remote-Laufzeiten wie Dockershim/CRI-O).

Es sind drei verschiedene Aspekte zu berücksichtigen:

1. Cloud-Routen - Wenn die Cloud-Infrastruktur und das Netzwerk-Plugin Cloud-Routen erfordern, muss das Fehlen von Cloud-Routen (z. B. NodeNetworkUnavailable=true) die Planung blockieren hostNetwork=false pods
2. Netzwerk-Plugins - Wenn das Plugin noch nicht bereit ist, muss dies die Planung von hostNetwork=false-Pods blockieren. Dies ist unabhängig von NodeNetworkUnavailable, da das Plugin möglicherweise keine direkte Interaktion mit einem Routes Controller hat, da es nicht von Cloud-Routen abhängt. Beispielsweise kann kubenet lokal auf dem Knoten verwendet werden, wenn Sie etwas anderes (Cloud-Routen, Flanell usw.) Knotenrouten eingerichtet haben.
3. hostNetwork=true Pods sollten alle diese Bedingungen ignorieren und geplant werden, jedoch vorbehaltlich anderer anwendbarer Bedingungen (Festplattenspeicher usw.).

NodeReady ist einfach ein zu großer Hammer. Ich denke, wir wollen wahrscheinlich eine zusätzliche NetworkPluginReady-Bedingung für die Netzwerk-Plugin-Bereitschaft (getrennt von der Cloud-Routen-Bereitschaft!)

Eine andere Arbeit herum habe ich gefunden.

Während kubeadm weiterhin '[apiclient] Erster Knoten hat sich registriert, aber noch nicht bereit' ausdruckt, habe ich 'kube-flannel.yml' bereitgestellt, das flanneld installiert. Und es funktionierte, ohne Konfigurationsdateien zu ändern.

1) kubeadm init --pod-network-cidr=10.244.0.0/16 &
2) cp /etc/kubernetes/admin.conf ~/.kube/config
3) kubectl apply -f kube-flannel-rbac.yml (notwendig in kubeadm 1.6)
4) kubectl apply -f kube-flannel.yaml
Verwenden Sie kube-flannel.yaml in https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml

Ich könnte den Masterknoten 'Ready' machen. Aber kube-dns ist mit der Nachricht fehlgeschlagen,

Error syncing pod, skipping: failed to "CreatePodSandbox" for "kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)" with CreatePodSandboxError: "CreatePodSandbox for pod \"kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"kube-dns-2759646324-nppx6_kube-system\" network: \"cni0\" already has an IP address different from 10.244.0.1/24"

Nachdem ich das Netzwerk-Plug-In auf weave-net geändert habe, hat es funktioniert.

@dcbw Ich weiß nicht genug über das in dieser Ausgabe diskutierte spezifische Problem, um Ihnen genau zu sagen, was zu tun ist. Ich wollte nur den aktuellen Status von Taints erklären und wie sie hier angewendet werden könnten.

BITTE TESTEN SIE DIE GEPATCHTE DEBS

Das kubernetes-xenial-unstable jetzt einen gepatchten Build 1.6.1-beta.0.5+d8a384c1c5e35d-00 , den @pipejakob und ich heute getestet haben. Die Knoten bleiben nicht bereit, bis ein Pod-Netzwerk erstellt wurde (zB durch Anwenden von Web-/Flanell-Konfigurationen). Konformitätstest bestanden. PTAL.

# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main
EOF

cc @luxas @jbeda

Ist die allgemeine Richtung, in der Makel so ziemlich alles ausdrücken können?
Bedingungen können und sind deshalb in jeder Hinsicht besser?

Ich stimme zu, dass wir ein granulareres Signal brauchen. Wir müssen das noch klären
Zusammenspiel zwischen Kubelet, Net Driver, Cloud Controller und Cloud Provider
um hostNetwork=false Pods zu entsperren, aber hostNetwork=true sollte nicht sein
verstopft.

Am Do, 30. März 2017 um 19:24, Dan Williams [email protected]
schrieb:

Beachten Sie, dass Ihr neuer Taint die aktuelle Automatik ersetzen soll
Um Knoten mit NetworkUnavailable herauszufiltern, müssen Sie die
Funktion, die ich bereits erwähnt habe (dh sie aus dem Satz von Bedingungen entfernen)
die einen Knoten herausfiltern). Ich weiß nicht, welche anderen Nebenwirkungen das sein wird
haben, da diese Funktion in anderen Knotenauflistern als nur den
Planer.

@davidopp https://github.com/davidopp wir müssen vorsichtig sein
NetworkUnavailable vs. NodeReady. Es gibt zwei unterschiedliche Bedingungen, die
sollte wirklich aufgeräumt werden:

nodeNetworkUnavailable - Dies ist spezifisch für Cloud-Routen und nur für Cloud
Route Controller löschen diese Bedingung, wenn Cloud-Routen zwischen Knoten
eingerichtet worden. Netzwerk-Plugins, die Overlays erstellen oder L3 nicht ausführen
Routing zwischen Knoten diese Bedingung nicht wünschen oder verwenden. Diese Bedingung ist
nicht von einem Netzwerk-Plugin hinzugefügt; es wird von kubelet speziell hinzugefügt, wenn
Als Cloud-Anbieter werden GCE oder AWS ausgewählt. Beeinflusst NodeReady nicht, da
es ist eine separate Bedingung.

NodeReady - direkt von den Netzwerk-Plugins betroffen (z. B. CNI oder kubenet
oder Remote-Laufzeiten wie dockershim/CRI-O).

Es sind drei verschiedene Aspekte zu berücksichtigen:

1. Cloud Routes - wenn die Cloud-Infrastruktur und das Netzwerk-Plugin
   Cloud-Routen erfordern, dann fehlende Cloud-Routen (z.
   NodeNetworkUnavailable=true) muss die Planung blockieren hostNetwork=false
   Schoten
2. Netzwerk-Plugins - wenn das Plugin noch nicht fertig ist, muss das
   Blockplanung von hostNetwork=false Pods
3. hostNetwork=true Pods sollten all diese Bedingungen ignorieren und
   geplant, aber vorbehaltlich anderer anwendbarer Bedingungen (Speicherplatz usw.)

NodeReady ist einfach ein zu großer Hammer. Ich denke, wir wollen wahrscheinlich einen
zusätzliche NetworkPluginReady-Bedingung für die Netzwerk-Plugin-Bereitschaft
(getrennt von Cloud-Routen-Bereitschaft!) und dann müssen wir das ausloten
bis hin zu Orten, die sich interessieren :(

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290597988 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AFVgVGIn0CpVkcHd2SVaoRsp2RJNEgXFks5rrGPqgaJpZM4MtMRe
.

Für alle, die immer noch versuchen, die temporäre Lösung durch Entfernen der kubelet KUBELET_NETWORK_ARGS-Konfigurationszeile zu entfernen, hat @jc1arke eine einfachere Führen Sie zwei Sitzungen mit dem neuen Master durch und wenden Sie, während Sie darauf warten, dass der erste Knoten bereit ist, eine Knotennetzwerkkonfiguration im zweiten an Sitzung:
Erste Sitzung nach dem Ausführen von kubeadmin init:

...
[apiclient] Created API client, waiting for the control plane to become ready
[apiclient] All control plane components are healthy after 24.820861 seconds
[apiclient] Waiting for at least one node to register and become ready
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
...

Zweite Sitzung (mit Calico. Ihre Wahl kann natürlich variieren):

root@kube-test-master-tantk:~# kubectl apply -f http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml
configmap "calico-config" created
daemonset "calico-etcd" created
service "calico-etcd" created
daemonset "calico-node" created
deployment "calico-policy-controller" created
job "configure-calico" created
root@kube-test-master-tantk:~#

Zurück zur ersten Sitzung:

...
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node is ready after 118.912515 seconds
[apiclient] Test deployment succeeded
[token] Using token: <to.ken>
[apiconfig] Created RBAC rules
...

Ist die allgemeine Richtung, in der Makel so ziemlich alles ausdrücken können?
Bedingungen können und sind deshalb in jeder Hinsicht besser?

Ja schon. Aus Gründen der Abwärtskompatibilität können wir wahrscheinlich keine der Knotenbedingungen loswerden, aber wir können die gesamte Logik im Master loswerden, die darauf basierend Maßnahmen ergreift (wie das Blockieren der Planung oder das Entfernen von Pods). Abgesehen davon, dass das Verhalten offensichtlicher wird (man muss sich nicht merken, welche Bedingungen die Planung blockieren, welche eine Räumung verursachen, wie lange wir auf eine Räumung warten usw.), ist die Reaktion auf die Bedingungen pro Pod konfigurierbar.

Habe gerade die Debs von @mikedanese und @pipejakob getestet , diese funktionieren

Getestet auf Ubuntu/Xenial:

root<strong i="9">@kube1</strong>:/home/ubuntu# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

Habe gerade die Debs von @mikedanese und @pipejakob getestet , es friert immer noch bei
[apiclient] Created API client, waiting for the control plane to become ready

Ich habe ungefähr fünf Minuten gewartet, aber es hat sich nichts geändert.
Und gestern wiederholte es sich immer wieder
[apiclient] First node has registered, but is not ready yet

TTI denke das Problem ist immer noch keine Lösung?

Getestet auf Ubuntu 16.04:
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean"2017 .Buildate:"clean"2017 -03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Plattform:"linux/amd64"}

@myqq0000 kannst du die von dir verwendete Version posten?

kubeadm version

@coeki Oh, ich vergesse es. Ich habe gerade bearbeitet und poste die Version in meinem vorherigen Kommentar. :)

@mikedanese Haben Sie vor, Centos Yum Repo zu aktualisieren? Oder ist es bereits in Yum Repo bereitgestellt?

Habe gerade 1.6.1-beta.0.5+d8a384c1c5e35d-00 ausprobiert (das in https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290616036 erwähnte 1.6.1-beta.0.5+48c6a53cf4ff7d-00 scheint nicht zu existieren).

Es scheint gut zu funktionieren.
Nicht verwandt: Beachten Sie, dass Sie bei der Verwendung von Weave https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml anstelle des „Standard“ https:/ anwenden müssen.

@mausch Könnten Sie mir sagen, wie ich diese Debs bekomme?

@srinat999 https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290616036

@mikedanese gepatchte Debs funktionieren für mich. danke für alle, die daran arbeiten! :Lächeln:

root@kube-test0:~# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

@mausch Danke. Sie funktionieren bei mir auch mit dem Web-Netzwerkanbieter.

Gibt es eine Chance, den gleichen Fix auch für Centos zu erstellen? Unser Gating-System verwendet hauptsächlich Centos für die Kubernetes-Clusterbasis. Wenn ich eine Centos-Version habe, kann ich ca. 100 Läufe von kubeadm init pro Tag als Test.

@mikedanese gepatchte Debs funktionieren teilweise für mich. kubeadm benachrichtigt, dass der Cluster bereit ist, der Knoten selbst jedoch nicht.

@squall0gd- Knoten sollten bereit sein, wenn ein Pod-Netzwerk angewendet wird, z. B. kubectl apply -f https://git.io/weave-kube-1.6

In meiner Testumgebung (in vagrant, basierend auf centos/7-Maschinen) hängt kubeadm einfach. Mit strace kann ich sehen, wie es versucht, eine Verbindung zum Kubelet-Server auf dem Master herzustellen, und FUTEX_WAIT, epoll_wait-Wiederholungsschleifen durchführt. Aber es kommt keine einzige Zeile ouf-Ausgabe von ihm.

kubelet startet nicht, was der Grund zu sein scheint.
(Aber ich kann keine Gründe dafür sehen, dass Kublet nicht gestartet werden kann.)

Ist das das Problem dieses Problems?

Ich bekomme Binärdateien aus dem http://yum.kubernetes.io/repos/kubernetes-el7-x86_64-Repository .
Ich versuche auch, die Binärdateien von https://storage.googleapis.com/kubernetes-release/release/v1.6.0/bin/linux/amd64/ zu aktualisieren.

==> Wo bekomme ich eine gepatchte Version von kubeadm zum Testen? <==

Hinweis: Ich habe eine (behauptete) gepatchte Version von kubeadm gefunden, auf die in dieser Ausgabe verwiesen wird: https://github.com/kensimon/aws-quickstart/commit/9ae07f8d9de29c6cbca4624a61e78ab4fe69ebc4 (gepatchte Version ist diese: https://heptio-aws-quickstart- test.s3.amazonaws.com/heptio/kubernetes/ken-test/kubeadm), aber das funktioniert bei mir nicht. Verhalten ist immer noch das gleiche (keine Ausgabe)...

@squall0gd Können Sie uns die genaue Nachricht zeigen, die Sie sehen? Basierend auf dem, was Sie beschreiben, frage ich mich, ob Sie die neuen .debs tatsächlich übernommen oder ältere zwischengespeicherte Versionen verwendet haben.

@tockin @davidopp, also werde ich gemäß Tims Vorschlag ein vorhandenes Problem übernehmen oder ein neues Bedingungen der Entwirrung des Netzwerks zu verfolgen und sie in Makel anstelle von tatsächlichen Bedingungen umzuwandeln, und kopiere die meisten von https://github. com/kubernetes/kubernetes/issues/43815#issuecomment -290597988 hinein.

Folgendes scheint bei mir mit dem unstable Repo zu funktionieren (nur den Master selbst getestet):

"sudo apt-get update && sudo apt-get install -y apt-transport-https",
"echo 'deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main' | sudo tee /etc/apt/sources.list.d/kubernetes.list",
"curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -",
"sudo apt-get update",
"sudo apt-get install -y docker.io",
"sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni",
"sudo service kubelet stop",
"sudo service kubelet start",
"sudo kubeadm init",
"sudo cp /etc/kubernetes/admin.conf $HOME/",
"sudo chown $(id -u):$(id -g) $HOME/admin.conf",
"export KUBECONFIG=$HOME/admin.conf",
"kubectl taint nodes --all dedicated-",
"kubectl apply -f https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml",

Dies spuckt an einem Punkt error: taint "dedicated:" not found aus, aber es scheint trotzdem weiterzugehen.

Führen wir diese Tests nicht auf dem 1.6-Zweig durch?

@davidopp-Knotenbedingungen sollen den Menschen zusätzliche Informationen liefern, um zu verstehen, was vor sich geht, z. B. den Grund, die Nachricht und die Übergangszeit.

kubeadm sieht nicht so aus, als ob es im Release-Zweig getestet wurde:
https://k8s-testgrid.appspot.com/release-1.6-all

@ bgrant0607 anscheinend waren die kubeadm e2e-Tests vor der Veröffentlichung 1.6, IIRC, ungefähr eine Woche lang deaktiviert / nicht funktionsfähig

Knotenbedingungen sollen dem Menschen zusätzliche Informationen liefern, um zu verstehen, was vor sich geht, z. B. den Grund, die Nachricht und die Übergangszeit.

@ bgrant0607 sind sie hauptsächlich für menschliche Informationen gedacht oder ist das nur ein glücklicher Nebeneffekt? Wenn in erster Linie für Menschen, sollten sie dann für Planungsentscheidungen verwendet werden, wie sie es derzeit sind, oder sollten wir davon abrücken?

@dcbw Taints sollen zur GUT der Unplanbarkeit und Störung werden. Schließlich sollte der Scheduler Bedingungen ignorieren.

https://github.com/kubernetes/kubernetes/pull/18263#issuecomment -169220144
https://github.com/kubernetes/kubernetes/issues/29178

Beachten Sie, dass wir Folgendes berücksichtigen müssen, wenn wir Knoten einen Taint hinzufügen möchten

a) Abwärtskompatibilität, wie beim Master-Taint: https://github.com/kubernetes/kubernetes/pull/43537

b) Versionsverzerrung. Beim Upgrade von Clustern auf 1.6 handelt es sich bei Kubelets um gemischte Releases, von denen einige möglicherweise bis zu 1.4 alt sind.

also um es zusammenzufassen oder wie ich das analysiere:

basierend auf @dcbw

nodeNetworkUnavailable ist ein Cloud-Provider-Ding, das nicht an kubeadm atm gebunden ist. Wir könnten darauf stoßen.

Aber NodeReady, das die Ursache für die Schleife ist, muss granularer werden. Dies ist, was @davidopp ein

gut, obwohl man argumentieren könnte, warum nicht beschriften?

Aber @dcbw hast du einen Thread gefunden, der für diese Diskussion besser geeignet ist? Denn dieser wird zu einem Eimer für Probleme mit der Bereitstellung und nicht wirklich zur Wurzel der Dinge.

Ich weiß, ich war Teil davon, das Problem nicht wirklich zu lösen und Hacks zu posten :)

Aber wie auch immer, wir sollten die Grundlagen an anderer Stelle besprechen, sicherstellen, dass hier eine ETA zum Fix platziert wird, und weitermachen.

Nicht bissig, aber gut :)

PS ja @bgrant0607 wir hätten das mehr
PS2 Wenn ich das falsch sehe, kannst du mir die Schuld geben ;)

@coeki Ich würde auch eine Anforderung hinzufügen, dass N-1-Versionen in

@kfox1111 Gating ist auch ein Problem ... wir brauchen eine bessere Strategie dafür :)

Warum überhaupt alte Releases löschen? Das könnte leicht die Automatisierung der Leute unterbrechen und wiederholbare Installationen verhindern.

Knotenbedingungen sollen dem Menschen zusätzliche Informationen liefern, um zu verstehen, was vor sich geht, z. B. den Grund, die Nachricht und die Übergangszeit.

Einverstanden. UX ist definitiv ein wichtiger Grund, warum wir Knotenbedingungen wahrscheinlich nicht loswerden können. Ich glaube jedoch, dass wir alle Verwendungen von Knotenbedingungen als Auslöser für Masteraktionen (wie Räumung und Blockierung der Planung) loswerden und stattdessen Taints verwenden können.

Auf lange Sicht (wie auf lange Sicht der v2-API) ist es denkbar, dass wir den Taints Grund und Nachricht hinzufügen und dann die Knotenbedingungen loswerden, aber ich habe nicht wirklich darüber nachgedacht und schlage dies definitiv nicht offiziell vor. (Wir haben bereits das Äquivalent der Übergangszeit in eine Richtung, nämlich TimeAdded.)

@coeki nein, was ich

Ich bitte darum, die alte Version nicht zu löschen, bevor die neue Version zumindest die erste Bugfix-Version durchlaufen hat. Für dieses Beispiel 1.6.1. Mindestens. Noch besser ist es, mehr ältere Versionen zu behalten. Dies ist eine bewährte Methode, damit die Betreiber weiterhin Fortschritte erzielen können, während Fehler in der neuen Version behoben werden.

@kfox1111 , das ist es, was Gating macht, nicht mit etwas gehen, das gut erscheint, und den alten guten vertrauenswürdigen Weg

@davidopp Ich stimme zu, dass Labels und Taints sich möglicherweise von einer API-Betrachtung, UX und Maschinen unterscheiden, aber im

Jedenfalls locken Sie mich in eine Diskussion, die wir wirklich nicht in dieser Ausgabe haben, das war mein Punkt.

Ich möchte noch einmal fragen: Wenn ich sehe, dass "kubeadm init" nur dort hängt, ohne dass eine Ausgabe erfolgt (versucht, eine Verbindung zum Kubelet-Server herzustellen, der nicht gestartet wurde), leide ich unter diesem Problem? Und wenn dies ein Fall ist, ist #43835 eine Lösung für mich?

Wo bekomme ich jetzt:

• entweder ältere (vor 1.6.0) Versionen von kubeadm / kubectl / kubelet
• oder eine gepatchte Version von kubeadm (einschließlich #43835 oder was auch immer andere Fixes)?

Vielen Dank!

(Anmerkung: die gepatchte Version von kubeadm in dem genannten verwiesen begeht oben für mich nicht funktioniert ...)

@obnoxxx versuche es mit der Spitze des Release-1.6-Zweigs.

$ gsutil ls gs://kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9

https://storage.googleapis.com/kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9/bin/linux/amd64/kubeadm

@mikedanese danke! versuche...

Wenn Sie kubeadm ausführen, ohne das Betriebssystempaket zu installieren, müssen Sie

$ cat <<EOF > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_EXTRA_ARGS
EOF
$ systemctl daemon-reload
$ systemctl restart kubelet

von https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/channel/stable/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

@mikedanese danke. Ich installiere das os-Paket (aus Kube Repo) und installiere dann die Binärdateien von der Web-URL über die Binärdateien von den RPMs ...

die Version 1.6.1-beta.0.12 hat bei mir jedoch nicht funktioniert:
kubeadm init noch hängt ohne Ausgang. (versucht, eine Verbindung zu Kubelet herzustellen)

Vergessen Sie auch nicht den systemd-Treiber, wenn Centos.

Systemtreiber?

https://github.com/kubernetes/release/issues/306

Gott, danke, das ist besser! :-)

@pipejakob Ich habe gerade keinen Zugriff auf diese Protokolle, aber ich habe die kubeadm-Version überprüft und es war die gleiche Version wie @webwurst . Außerdem habe ich mögliche kubeadm Versionen mit apt-cache policy kubeadm überprüft. Und es gab nur einen Eintrag - von kubernetes-xenial-unstable.
@mikedanese Ich habe es mit Flanell versucht, bevor ich
BEARBEITEN: Ich habe die gesamte Plattform neu erstellt und kubadm funktioniert einwandfrei :+1:

Leute, was ist der Status Quo für den Fix? Wird es bald ins Stable-Repository verschoben?

@mikedanese gepatchte Debs machen das gleiche "Netzwerk-Plugin ist nicht bereit".

Kann mir jemand sagen, wie man eine gepatchte Version von kubeadm für rhel (rpm) erstellt?

@mikedanese mit gepatchten debs die init meldet Erfolg, aber die Meldung "Netzwerk-Plugin ist nicht bereit: cni config uninitialized" bleibt bestehen.

Der Masterknoten befindet sich in NotReady .

Das weave-net (weaveworks/weave-kube:1.9.4 - https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml) befindet sich in 1/2 CrashLoopBackOff :

FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "weave"

Der kube-dns Pod befindet sich in 0/3 Pending .

@ChipmunkV Sie müssen wahrscheinlich kube-proxy für die Ausführung im Userspace konfigurieren. Dies war auch ein Problem in 1.5.

command:
  - /usr/local/bin/kube-proxy
  - --kubeconfig=/var/lib/kube-proxy/kubeconfig.conf
  # add this line:
  - --proxy-mode=userspace

Für das, was es wert ist, funktioniert kubernetes-xenial-unstable gut für mich.

@pstadler , danke an @errordeveloper im Chat, der darauf hingewiesen hat, dass ich überlappende Netzwerke habe, ich habe das IPALLOC_RANGE in der Webart neu konfiguriert.

Danke @thenayr. Ich könnte den Kubernetes-Master aufrufen, aber auch einen Worker mit kubeadm Join damit verbinden. Werde bald weitere Updates posten

@mikedanese ich habe ewig gebraucht um herauszufinden welche Version ich verwenden soll, bis ich alle Kommentare hier gelesen habe. Wir müssen es wirklich viel einfacher machen, Binärdateien für eine bestimmte Version zu finden. Ich habe versucht, das zu verwenden, worauf ci-cross/latest.txt zeigt (nämlich v1.7.0-alpha.0.1982+70684584beeb0c ), und das führte zufällig ein neues kube-apiserver Flag ein (nämlich --proxy-client-key-file in d8be13fee85075abfc087632b3dbc586a10897ad), was funktioniert mit keinem der letzten Tags in gcr.io/google_containers/kube-apiserver-amd64 ...

Wie können wir es einfacher machen, herauszufinden, welche Revisionen Binärdateien im Bucket haben? Es wäre schön, Verzeichnisse auflisten zu können, oder eine einfache Map-Datei zu haben oder einfach alles, was man nicht wissen oder erraten muss.

@errordeveloper Wir versuchen eine Veröffentlichung zu machen, damit wir einen Fix in den Stable-Zweig bringen können, sollte in O (Tagen) erfolgen, hoffe ich. In der Beschreibung dieses Problems befindet sich ein Link zu den gepatchten Debs in unstable.

Die vorherige Version 1.5.6 funktionierte für mich auf CentOs 7, aber jetzt kann ich nicht einmal ein Rollback durchführen, da die einzige Version von kubeadm in http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 die defekte 1.6 ist. 0. Irgendwelche Vorschläge, wie man kubeadm 1.5.6 RPM bekommt?

Tatsächlich ist es schade. Alte Versionen scheinen komplett entfernt worden zu sein. :-(

Meine Ergebnisse sind diese auf centos 7:

• Ich war nicht in der Lage, kubadm init dazu zu bringen, mir überhaupt ein Ergebnis zu liefern, selbst mit einem gepatchten, neuesten kubeadm, ohne etwas gegen kubectl zu unternehmen.
• Ich konnte kubectl mit den Anweisungen von @coeki starten , und dann hat kubeadm sogar bestanden. Aber danach geht bei mir nichts mehr. kubectl sagt

The connection to the server localhost:8080 was refused - did you specify the right host or port?

Irgendein Hinweis, was los ist?

@obnoxxx apiserver hört standardmäßig nicht auf 8080, sondern auf dem sicheren 6443-Port, Sie können dies mit netstat -tunlp überprüfen.
Sie müssen die admin.conf von /etc/kubernetes nach $HOME/.kube/config kopieren
Stellen Sie sicher, dass Sie die Berechtigungen für die Datei in Ihrem $HOME/.kube/ ändern, danach sollte Ihr kubectl in der Lage sein, den Apiserver ordnungsgemäß zu kontaktieren. HTH. Serguei

@apsinha Kennst du diesen Thread? Es könnte gut sein, dass einige Produktleute folgen, da ich denke, dass es einige wichtige Erkenntnisse für die Zukunft geben wird.

Aus meinem Kopf:

• 1.6.0 wurde nie automatisiert getestet: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290809481
• Binärdateien/Pakete für ältere Versionen wurden entfernt, sodass die Benutzer kein sicheres Rollback durchführen können; brach jede Installationsautomatisierung, die davon ausging, dass sie weiterhin verfügbar war: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290861903
• Keine öffentliche Ankündigung (die ich gesehen habe) dass dies kaputt ist
• Kein Zeitplan für eine Fehlerbehebung angegeben (ich bin Entwickler, daher weiß ich, wie widerlich es ist, gefragt zu werden, wann es behoben wird?
• Benutzer, die weiterhin an der Konversation teilnehmen, sind verwirrt über den Status der Dinge, die Problemumgehungen und den festen Zeitplan
• Viele technische Diskussionen unter den Mitwirkenden, von denen viele über langfristige Strategien handeln, werden im selben Thread zusammengefasst, in dem Benutzer versuchen herauszufinden, was vor sich geht und wie man mit dem unmittelbaren Problem umgeht

Keine Respektlosigkeit gegenüber all den großartigen Menschen, die Kubernetes zu dem machen, was es ist. Ich hoffe nur, dass es hier einige "lehrbare Momente" gibt, da dies in Bezug auf die öffentliche Wahrnehmung von Kubernetes als zuverlässig/stabil aussieht. (Zugegeben kubeadm ist Alpha/Beta, aber es hat immer noch viel Sichtbarkeit.)

Ich habe kubeadm-1.5.6 mit kubernetes/release.rpm gebaut, nur um (zu meiner Bestürzung) das zu finden

# rpm -Uvh kubectl-1.5.6-0.x86_64.rpm kubeadm-1.5.6-0.x86_64.rpm 
error: Failed dependencies:
        kubectl >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64
        kubelet >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64

@bostone Sie müssen die .spec hier anpassen.

@sbezverk danke für den Hinweis! Es ist jetzt besser...

Das ist kurios:

• Ich kann mich nicht erinnern, dass das Kopieren der admin.conf in früheren Versionen für mich notwendig war.
• Ich habe es vorher mit kubectl -s localhost:6443 versucht, aber das war nicht ausreichend.

Egal, jetzt kann ich weitermachen. Danke noch einmal

v1.6.1 wird gerade freigegeben. Es wird von EOD durchgeführt.

Einige Notizen:

1. Das Problem mit dem Löschen alter Pakete wurde hier verfolgt: https://github.com/kubernetes/release/issues/234. Aufgrund einiger verrückter Versionierung von kubeadm und der alphabetischen Sortierung dieser Dinge war es anscheinend nicht möglich, die 1.5.x-Version von kubeadm im Repo zu behalten. ( @bostone dein Problem wird dort auch referenziert)
2. kubeadm e2e-Tests für PRs, die hier verfolgt werden: https://github.com/kubernetes/kubeadm/issues/190
3. Was die öffentliche Ankündigung betrifft – ich habe

Das sind alles gute Themen, die man in einer PN ansprechen sollte. @pipejakob hat sich

@obnoxxx Die Anforderung zum Kopieren/Chown der admin.conf war vorher notwendig, da wir mit 1.5 hatten, dass der API-Server einen unsicheren Port freilegte. Das haben wir in 1.6 geändert. Jetzt müssen Sie sichere Anmeldeinformationen verwenden, um auf den API-Server zuzugreifen (siehe https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubeadm-2)

@mikedanese das klingt toll, danke!
Nur für den dummy ich bin - was wird die Auswirkung dieser Version 1.6.1 in Bezug auf dieses Problem sein?
Wird Kubelet ohne die Änderung in /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ( @coekis Workaround )

@jbeda danke für die Erklärung!

@jbeda Ich denke, die Verwirrung kommt von der offiziellen Kubadm-Installationsdokumentation, die das YUM-Repo auf http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 setzt. Dieses Repo hat nur kubeadm-1.6.0

Und wieder zu meiner Enttäuschung endete das Erstellen von 1.5.6 U/min und die Installation mit genau demselben Problem. Das Ausführen von kubeadm init hängt an der gleichen Zeile:

# kubeadm init
Running pre-flight checks
<master/tokens> generated token: "5076be.38581a71134596d0"
<master/pki> generated Certificate Authority key and certificate:
Issuer: CN=kubernetes | Subject: CN=kubernetes | CA: true
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2027-04-01 21:28:18 +0000 UTC
Public: /etc/kubernetes/pki/ca-pub.pem
Private: /etc/kubernetes/pki/ca-key.pem
Cert: /etc/kubernetes/pki/ca.pem
<master/pki> generated API Server key and certificate:
Issuer: CN=kubernetes | Subject: CN=kube-apiserver | CA: false
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2018-04-03 21:28:18 +0000 UTC
Alternate Names: [10.25.47.21 10.96.0.1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local]
Public: /etc/kubernetes/pki/apiserver-pub.pem
Private: /etc/kubernetes/pki/apiserver-key.pem
Cert: /etc/kubernetes/pki/apiserver.pem
<master/pki> generated Service Account Signing keys:
Public: /etc/kubernetes/pki/sa-pub.pem
Private: /etc/kubernetes/pki/sa-key.pem
<master/pki> created keys and certificates in "/etc/kubernetes/pki"
<util/kubeconfig> created "/etc/kubernetes/kubelet.conf"
<util/kubeconfig> created "/etc/kubernetes/admin.conf"
<master/apiclient> created API client configuration
<master/apiclient> created API client, waiting for the control plane to become ready

Ich denke, ich warte einfach auf die Veröffentlichung von 1.6.1 und hoffe...

1.6.1 ist raus.

@mikedanese hast du kubeadm getestet, bevor du diesen Fehler [apiclient] Created API client, waiting for the control plane to become ready . Auf CentOS 7 mit brandneuer 1.6.1-Installation

@bostone könntest du auf dieses Problem stoßen: #43805

Versuchen Sie bearbeite /etc/systemd/system/kubelet.service.d/10-kubeadm.conf und das Hinzufügen von --cgroup-driver=systemd

Denken Sie daran, systemctl daemon-reload; systemctl restart kubelet auszuführen

@gtirloni mit unserem Vorschlag bin ich am Ende von kubeadm init angekommen, jedoch erzeugt jeder Versuch, kubectl auszuführen, diesen Fehler: The connection to the server localhost:8080 was refused - did you specify the right host or port? Ich bin mir nicht sicher, wo und wie das geändert wird oder was der richtige Port ist dieser Punkt?

Ich bin mir nicht sicher, ob dies zusammenhängt, aber Folgendes sehe ich, wenn ich systemctl status kubelet :
``` systemctl status kubelet -l
● kubelet.service - kubelet: Der Kubernetes-Knotenagent
Geladen: geladen (/etc/systemd/system/kubelet.service; aktiviert; Herstellervoreinstellung: deaktiviert)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Aktiv: aktiv (läuft) seit Mo 2017-04-03 17:31:07 PDT; vor 11min
Dokumente: http://kubernetes.io/docs/
Haupt-PID: 10382 (Kubelet)
CGroup: /system.slice/kubelet.service
├─10382 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true - -network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain =cluster.local --authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt --cgroup-driver=systemd
└─10436 journalctl -k -f

03. Apr 17:41:56 sdl02269 kubelet[10382]: W0403 17:41:56.645299 10382 cni.go:157] cni-Konfiguration kann nicht aktualisiert werden: Keine Netzwerke in /etc/cni/net.d . gefunden
03. Apr 17:41:56 sdl02269 kubelet[10382]: E0403 17:41:56.645407 10382 kubelet.go:2067] Container-Laufzeitnetzwerk nicht bereit: NetworkReady=false Grund:NetworkPluginNotReady Nachricht:docker : Netzwerk-Plugin ist nicht bereit: cni config nicht initialisiert```

Ja, wir haben getestet. e2e-Tests bestehen auf dem Release-Zweig. Möglicherweise treffen Sie auf andere Probleme.

@bostone vielleicht fehlen dir diese Schritte nach kubeadm init ?

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

Sie müssen auch den hier beschriebenen Schritt 3 befolgen. Das scheint mit dem cni-Konfigurationsfehler zusammenzuhängen, den Sie erhalten.

Starrt auch auf [apiclient] Erstellter API-Client, der mit Ubuntu 16.04 und einer Neuinstallation von 1.6.1 bereits 10 Minuten darauf wartet, dass die Steuerungsebene bereit ist

@pingthings Ich würde empfehlen, dem Slack Kubernetes- und dem kubeadm Kanal beizutreten . Wir können Ihnen dort beim Debuggen helfen.

Ich habe meinen Kubernetes-Cluster erfolgreich auf centos-release-7-3.1611.el7.centos.x86_64 eingerichtet, indem ich die folgenden Schritte ausführe (ich gehe davon aus, dass Docker bereits installiert ist):

1) (aus /etc/yum.repo.d/kubernetes.repo) baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64-unstable
=> Um das unstable Repository für das neueste Kubernetes 1.6.1 zu verwenden
2) yum install -y kubelet kubeadm kubectl kubernetes-cni
3) (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) füge "--cgroup-driver=systemd" am Ende der letzten Zeile hinzu.
=> Dies liegt daran, dass Docker systemd für cgroup-driver verwendet, während kubelet cgroupfs für cgroup-driver verwendet.
4) systemctl kubelet aktivieren && systemctl kubelet starten
5) kubeadm init --pod-network-cidr 10.244.0.0/16
=> Wenn Sie bisher --api-advertise-addresses hinzugefügt haben, müssen Sie stattdessen --apiserver-advertise-address verwenden.
6) cp /etc/kubernetes/admin.conf $HOME/
sudo chown $(id -u):$(id -g) $HOME/admin.conf
export KUBECONFIG=$HOME/admin.conf
=> Ohne diesen Schritt erhalten Sie möglicherweise einen Fehler mit kubectl get
=> Ich habe es nicht mit 1.5.2 gemacht
7) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
=> 1.6.0 führt eine rollenbasierte Zugriffskontrolle ein, daher sollten Sie eine ClusterRole und eine ClusterRoleBinding hinzufügen, bevor Sie ein Flannel-Daemonset erstellen
8) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
=> Erstelle ein Flanell-Daemonset
9) (auf jedem Slave-Knoten) kubeadm join --token (Ihr Token) (ip):(port)
=> wie im Ergebnis von kubeadm init gezeigt

Alle oben genannten Schritte sind das Ergebnis der Kombination von Vorschlägen aus verschiedenen Themen rund um Kubernetes-1.6.0, insbesondere kubeadm.

Hoffe, das spart Ihre Zeit.

Dies scheint nicht behoben zu sein (Ubuntu LTS, kubeadm 1.6.1).

Erstens habe ich auch erlebt, dass kubeadm beim Verwenden des --apiserver-advertise-address Flags beim Verwenden des

let.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Apr 04 12:27:04 xxx kubelet[57592]: E0404 12:27:04.352780   57592 eviction_manager.go:214] eviction manager: unexpected err: failed GetNode: node 'xxx' not found
Apr 04 12:27:05 xxx kubelet[57592]: E0404 12:27:05.326799   57592 kubelet_node_status.go:101] Unable to register node "xxx" with API server: Post https://x.x.x.x:6443/api/v1/nodes: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.745674   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://x.x.x.x:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.746759   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://x.x.x.x:6443/api/v1/nodes?fieldSelector=metadata.name%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.747749   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://x.x.x.x:6443/api/v1/services?resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeou

Wenn ich dieses Flag nicht anbiete, besteht kubeadm, aber selbst dann erhalte ich beim Starten von kubelet folgende Fehlermeldung:

Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Kubelet weigert sich, ordnungsgemäß zu starten, und ich kann mich mit kubectl in keiner Weise mit dem Cluster verbinden

Anscheinend wurden 1.5.x kubeadm-Versionen nicht nur aus dem Centos-Repository entfernt, sondern auch aus Ubuntu LTS: https://packages.cloud.google.com/apt/dists/kubernetes-xenial/main/binary-amd64/Packages It erschwert ein Downgrade und unterbricht tatsächlich die Abwärtskompatibilität

@bostone

Haben Sie den Haken beim "Warten auf die Bereitschaft des Kontrollflugzeugs" herausgefunden? Ich sehe das gleiche, nachdem ich alle Änderungen mit 1.6.1 ausprobiert habe.

@gtirloni @srzjulio das Hinzufügen dieser Schritte nach kubeadm init hat nicht geholfen. Es hat den Kubelet-Dienst von failed auf active (running) geändert, aber ich habe immer noch die Nachricht The connection to the server localhost:8080 was refused - did you specify the right host or port? . Und wenn ich mir Dienste ansehe, die zuhören, kann ich nirgendwo 8080 sehen. Was ich sehen kann, ist, dass Kubelet auf diesen Ports lauscht:

kubelet    6397  root   12u  IPv6 611842      0t0  TCP *:4194 (LISTEN)
kubelet    6397  root   15u  IPv4 611175      0t0  TCP sdl02269.labs.teradata.com:49597->sdl02269.labs.teradata.com:sun-sr-https (ESTABLISHED)
kubelet    6397  root   16u  IPv4 611890      0t0  TCP localhost:10248 (LISTEN)
kubelet    6397  root   18u  IPv6 611893      0t0  TCP *:10250 (LISTEN)
kubelet    6397  root   19u  IPv6 611895      0t0  TCP *:10255 (LISTEN)

Es gibt also eine falsche (geänderte?) Einstellung, die fälschlicherweise auf 8080 verweist?

@bostone Es ist kein Kubelet-Port, den Sie benötigen, es ist ein Kube-Apiserver, er sollte auf dem 6443-Port lauschen.

@sbezverk Ich habe keine geändert (es steht in keiner Anleitung) Was muss ich tun, um von 8080 auf 6443 zu wechseln?

@bostone Wenn Sie im Apiserver-Manifest nichts geändert haben, wird standardmäßig der 6443-Port überwacht. Sie müssen nur /etc/kubernetes/admin.conf in $HOME/.kube/config kopieren, die Berechtigungen für die Konfigurationsdatei ändern und Sie sollten fertig sein.

@sbezverk BTW - Ich kubeadm init schlagen vor, sudo user zu verwenden. Wie lautet die Empfehlung dazu? Sollen alle Installationsschritte auch als Sudo ausgeführt werden?

Ok, ich habe alle Schritte von Grund auf neu gemacht und es scheint besser zu sein. Hier sind die Schritte, die bisher für mich funktioniert haben und ich als Root auf CentOS 7 laufe.

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
# setenforce 0
# yum install -y docker kubelet kubeadm kubectl kubernetes-cni
# vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

-cgroup-driver=systemd zu 10-kubeadm.conf hinzufügen und speichern

# systemctl enable docker && systemctl start docker
# systemctl enable kubelet && systemctl start kubelet
# sysctl -w net.bridge.bridge-nf-call-iptables=1
# systemctl stop firewalld; systemctl disable firewalld
# kubeadm init
# cp /etc/kubernetes/admin.conf $HOME/
# chown $(id -u):$(id -g) $HOME/admin.conf
# export KUBECONFIG=$HOME/admin.conf
# kubectl apply -f https://git.io/weave-kube

An diesem Punkt kann ich kubectl get nodes ausführen und meinen Masterknoten in der Liste sehen.
Wiederholen Sie alle Schritte für Minion außer kubeadm init und führen Sie stattdessen kubeadm join --token a21234.c7abc2f82e2219fd 12.34.567.89:6443 wie von kubeadm init generiert
Dieser Schritt ist abgeschlossen und ich kann Master- und Minion(s)-Knoten sehen

Und jetzt - das Problem:

# kubectl get nodes
NAME       STATUS     AGE       VERSION
abc02918   NotReady   42m       v1.6.1
abc04576   NotReady   29m       v1.6.1

# kubectl describe node abc02918
Events:
  FirstSeen LastSeen    Count   From            SubObjectPath   Type        Reason          Message
  --------- --------    -----   ----            -------------   --------    ------          -------
  43m       43m     1   kubelet, sdl02918           Normal      Starting        Starting kubelet.
  43m       43m     1   kubelet, sdl02918           Warning     ImageGCFailed       unable to find data for container /
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientDisk   Node sdl02918 status is now: NodeHasSufficientDisk
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientMemory Node sdl02918 status is now: NodeHasSufficientMemory
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasNoDiskPressure   Node sdl02918 status is now: NodeHasNoDiskPressure
  42m       42m     1   kube-proxy, sdl02918            Normal      Starting        Starting kube-proxy.

Sieht also so aus, als wären die Knoten nie fertig geworden. Irgendwelche Vorschläge?

Ich kann mir vorstellen, dass Ihr Gewebe nicht richtig bereitgestellt wird, weil Sie das verwenden
vor 1.6 yaml-Datei.

Versuchen Sie "kubectl apply -f https://git.io/weave-kube-1.6 "

Am Dienstag, den 4. April 2017 um 12:24 Uhr schrieb Bo Stone [email protected] :

Ok, ich habe alle Schritte von Grund auf neu gemacht und es scheint besser zu sein. Hier sind
die Schritte, die für mich bisher funktioniert haben und ich als root ausgeführt werde.

Katze <

[kubernetes]
name=Kubernetes
baseurl= http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
aktiviert=1
gpgcheck=1
repo_gpgcheck=1
gpgkey= https://packages.cloud.google.com/yum/doc/yum-key.gpg http://yum.kubernetes.io/repos/kubernetes-el7-x86_64enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https:/ /packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

Setzkraft 0

yum install -y docker kubelet kubeadm kubectl kubernetes-cni

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Fügen Sie -cgroup-driver=systemd zu 10-kubeadm.conf hinzu und speichern Sie

systemctl docker aktivieren && systemctl docker starten

systemctl kubelet aktivieren && systemctl kubelet starten

sysctl -w net.bridge.bridge-nf-call-iptables=1

systemctl stop Firewalld; systemctl Firewall deaktivieren

kubeadm init

cp /etc/kubernetes/admin.conf $HOME/

chown $(id -u):$(id -g) $HOME/admin.conf

export KUBECONFIG=$HOME/admin.conf

kubectl apply -f https://git.io/weave-kube

An dieser Stelle kann ich kubectl get node ausführen und meinen Master-Knoten im
aufführen.
Wiederholen Sie alle Schritte für Minion, außer natürlich kubeadm join
--token a21234.c7abc2f82e2219fd 12.34.567.89:6443 wie von kubeadm generiert
drin
Dieser Schritt ist abgeschlossen und ich kann Master- und Minion(s)-Knoten sehen

Und jetzt - das Problem:

kubectl bekommt Knoten

NAME STATUS ALTER VERSION
abc02918 NotReady 42m v1.6.1
abc04576 NotReady 29m v1.6.1

kubectl beschreiben den Knoten abc02918

Veranstaltungen:
FirstSeen LastSeen Count from SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- --- --- -------
43m 43m 1 Kubelet, sdl02918 Normaler Start Start-Kubelet.
43m 43m 1 kubelet, sdl02918 Warning ImageGCFailed keine Daten für Container gefunden /
43m 43m 29 kubelet, sdl02918 Normal NodeHasSufficientDisk Node sdl02918 Status ist jetzt: NodeHasSufficientDisk
43m 43m 29 kubelet, sdl02918 Normal NodeHasSufficientMemory Node sdl02918 Status ist jetzt: NodeHasSufficientMemory
43m 43m 29 kubelet, sdl02918 Normal NodeHasNoDiskPressure Node sdl02918 Status ist jetzt: NodeHasNoDiskPressure
42m 42m 1 kube-proxy, sdl02918 Normaler Start Start von kube-proxy.

Sieht also so aus, als wären die Knoten nie fertig geworden. Irgendwelche Vorschläge?

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291571437 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAeJQ6OFBV3s6OHmfOkUdwqQsJ1sjg23ks5rsnzMgaJpZM4MtMRe
.

Wenn ich CentOS und die Version 1.6.1-1 von kubeadm verwende und die obigen Schritte befolge, erhalte ich ein etwas anderes Verhalten: Der Cluster wird als bereit gemeldet, aber dann bleibe ich bei dieser Meldung hängen:

[apiclient] Temporarily unable to list nodes (will retry)

In den Protokollen haben wir jedoch immer noch den gleichen Fehler:

Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.491150  108575 pod_workers.go:182] Error syncing pod 2193220cb6f65d66c0d8762189232e64 ("kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"), skipping: failed to "StartContainer" for "kube-apiserver" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-apiserver pod=kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: W0404 13:30:30.524051  108575 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.524243  108575 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@sjenning Das ist es! Ich muss noch einige Images bereitstellen, um zu sehen, ob alles funktioniert, aber ich kann alle Knoten mit dem Status Ready ! Danke euch allen, Jungs (vorerst :)

@bostone Ich habe das gleiche Rezept befolgt, das Sie verwendet haben, aber unterschiedliche Ergebnisse erzielt - ich bin an kubeadm init nicht vorbeigekommen. Welche Docker-Version verwendest du? Vielleicht ist das der Unterschied in meinem Fall?

@dcowden Es ist alles, was Yum auf meinem System Docker version 1.12.6, build 96d83a5/1.12.6 . Was mir auch geholfen hat, war, alle VMs, die ich verwendet habe, neu bereitzustellen, anstatt zu versuchen, meine vorherigen Installationen zu reparieren

@bostone danke. Ich werde auf diese Version downgraden, um zu sehen, ob ich ein funktionierendes Setup bekomme. Auf meinem System ist die neueste Version eine seltsame 17.03.1.ce-Version (offensichtlich die neueste und beste)

Ich bin mir nicht sicher, ob es allgemein nützlich ist, aber ich habe ein ansibles Playbook, das
macht alle Schritte für CentOS 7

https://github.com/sjenning/kubeadm-playbook

YMMV, aber es dokumentiert zumindest den Prozess. Ich mache auch ein paar Dinge wie
Wechseln Sie Docker, um die Protokollierung von Json-Dateien und den Overlay-Speicher zu verwenden.

Könnte als Referenz nützlich sein, auch wenn Sie das Playbook nicht ausführen.

Am Dienstag, 4. April 2017 um 12:55 Uhr, Dave Cowden [email protected]
schrieb:

@bostone https://github.com/bostone danke. ich werde darauf downgraden
Version, um zu sehen, ob ich ein funktionierendes Setup bekomme. auf meinem system ist das neueste a
seltsame 17.03.1.ce-Version (offensichtlich die neueste und beste)

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291580822 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAeJQ7CUA4vxhF3T7nMc9wRu47rbWe-Kks5rsoQmgaJpZM4MtMRe
.

@sjenning Danke! das ist sehr hilfreich!

Ok, hier ist eine Komplikation. Nachdem kubeadm reset auf Master und Minion ausgeführt und Docker- und Kubelet-Dienste neu gestartet wurden, hängt kubeadm init an Created API client, waiting for the control plane to become ready . Kann jemand vollständige Schritte zum Zurücksetzen von kubeadm bereitstellen?
@sjenning haben Sie versucht, Ihr Playbook nach der ersten Ausführung erneut auszuführen?

@bostone hat in meinem Fall /var/lib/etcd/ verschoben .

@autostatic Das Verzeichnis war leer und das Umbenennen hat nicht geholfen. @sjenning dein Playbook hängt, ich habe ein Ticket für dich erstellt

Hat jemand versucht, das Dashboard auf v1.6.1 auszuführen? Ich erhalte eine Fehlermeldung, die Folgendes besagt:

`Verboten (403)

Benutzer " system: serviceaccount :kube- system:default " kann keine Namespaces im Clusterbereich auflisten. (Namensräume abrufen)
`

Ich schätze, ich muss mehr RBAC konfigurieren, wie Sie es tun müssen, um Flannel auszuführen?

@srzjulio Kannst du dafür ein neues Problem

@srzjulio Sie müssen die RBAC-Regeln aktualisieren. Wir haben diese verwendet, um uns in

apiVersion: rbac.authorization.k8s.io/v1alpha1
Art: ClusterRoleBinding
Metadaten:
Name: Cluster-Admin
RolleRef:
apiGroup: rbac.authorization.k8s.io
Art: ClusterRole
Name: Cluster-Admin
Themen:

• Art: Gruppe
  Name: System: Meister
• Art: Gruppe
  Name: System: authentifiziert
• Art: Gruppe
  Name: System: nicht authentifiziert

Seien Sie vorsichtig - Die Bindung, die @sbezverk dort hat,

kind: Group
name: system:unauthenticated

Das ist besonders schlimm. Das bedeutet, dass jeder, der Ihren API-Server kontaktieren kann, auch ohne Anmeldeinformationen, beliebige Befehle ausführen kann.

@jbeda entspricht dem Verhalten, das wir mit 1.5.6 direkt nach dem Auspacken hatten. Es gibt Benutzern die Möglichkeit, die Sicherheitskonfiguration zu überprüfen und schrittweise anzupassen, anstatt mit neuen Sicherheitsregeln nichts mehr tun zu können.

Tatsächlich ist es viel schlimmer, system:unauthenticated zu einem Cluster-Administrator zu machen als 1.5.6

Wenn Sie keine Autorisierung wünschen, verwenden Sie den AlwaysAllow-Genehmiger

Wenn Sie während des Audits alles zulassen möchten, verwenden Sie eine Kombination aus RBAC, AlwaysAllow

Dadurch werden anonyme Anfragen deaktiviert, RBAC-Verweigerungen im API-Serverprotokoll protokolliert, aber alle authentifizierten Anfragen können weiterhin tun, was sie wollen

Entschuldigung, und ich wiederhole das noch einmal, das hat nichts mit dem ursprünglichen Problem zu tun. Und obwohl es berechtigte Probleme und Probleme gibt, sollten wir das Gespräch an eine andere Stelle verlagern.

Nochmals Entschuldigung, drücken Sie die Eingabetaste zu früh, aber wie die Dinge stehen:

1 - Version 1.6.0 verursacht Probleme
2 - nicht alle sind fest
3 - Wechsel zu RBAC (meiner Meinung nach gut), aber es ist ein Problem, warum? siehe Punkt 4
4 - Dies wurde nicht sehr gut kommuniziert und es gibt nicht viele Dokumente/Blogs oder was auch immer, um es zu erklären
5 – Ich verneige mich vor allen Leuten, die versuchen zu retten, aber wir brauchen einen besseren Weg, dies zu tun

https://kubernetes.io/docs/admin/authorization/rbac/#service -account-permissions ist eine gute Anleitung zu den am wenigsten granularen Optionen, die Sie zum Öffnen von Berechtigungen haben.

Das Hinzufügen von " --cgroup-driver=systemd " im Kublet verursacht ein neues Problem auf Centos/RHEL 7.3 (vollständig aktuell - auch bekannt als Docker 1.10.3):

Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542322    3026 docker_service.go:196] No cgroup driver is set in Docker
Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542343    3026 docker_service.go:197] Falling back to use the default driver: "cgroupfs"
Apr 12 14:23:25 machine01 kubelet[3026]: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"

während wir deutlich sehen können, dass native.cgroupdriver=systemd im Docker-Daemon gesetzt ist:

 ps -ef|grep -i docker
root      4365     1  3 14:30 ?        00:00:33 /usr/bin/docker-current daemon --authorization-plugin=rhel-push-plugin --exec-opt native.cgroupdriver=systemd --selinux-enabled --log-driver=journald --insecure-registry 172.30.0.0/16 --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/vg.docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true

@ReSearchITEng warum aktualisieren Sie Docker nicht auf 1.12.6? Funktioniert wie ein Zauber mit dieser Version.

@sbezverk : Ich habe gerade auf 1.12.5 aktualisiert und jetzt funktioniert es! Vielen Dank!

Danke an alle für die Hilfe.
Endlich voll funktionsfähige k8s 1.6.1 mit Flanell. Alles ist jetzt in ansible Playbooks.
Getestet auf Centos/RHEL. Die Vorbereitungen begannen auch für Debian-basiert (zB Ubuntu), aber es könnte einige Verfeinerungen erforderlich sein.

https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/README.md

PS: Arbeit basierend auf sjenning/kubeadm-playbook - Vielen Dank @sjenning !

@sjenning @ReSearchITEng
Hallo, ich habe ein vagrant+ansible Playbook [0], das dem von Ihnen erstellten sehr ähnlich ist, aber ich kann es immer noch nicht zum Laufen bringen, obwohl es für mich beim Netzwerk-Setup fehlschlägt. Ich habe es mit Kaliko, Webart und Flanell versucht, und alle drei schlagen fehl (wenn auch mit unterschiedlichen Symptomen).

Ich verwende diese Versionen:
[ vagrant@master ~]$ docker --version
Docker-Version 1.12.6, Build 3a094bd/1.12.6
[ vagrant@master ~]$ kubelet --version
Kubernetes v1.6.1
[ vagrant@master ~]$ kubeadm-Version
kubeadm version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.1", GitCommit:"b0b7a323cc5a4a2019b2e9520c21c7830b7f708e", GitTreeState:"clean", BuildDate:"2017-04-03T20:33: 27Z", GoVersion:"go1.7.5", Compiler:"gc", Plattform:"linux/amd64"}

Fehler:

[vagrant<strong i="19">@master</strong> ~]$ kubectl get all --all-namespaces
NAMESPACE     NAME                                           READY     STATUS             RESTARTS   AGE
kube-system   po/calico-etcd-gvrhd                           1/1       Running            0          47m
kube-system   po/calico-node-7jvs8                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-7ljpn                           2/2       Running            0          47m
kube-system   po/calico-node-w15z3                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-zq3zx                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-policy-controller-1777954159-13x01   1/1       Running            0          47m
kube-system   po/etcd-master                                 1/1       Running            0          46m
kube-system   po/kube-apiserver-master                       1/1       Running            0          46m
kube-system   po/kube-controller-manager-master              1/1       Running            0          46m
kube-system   po/kube-dns-3913472980-16m01                   3/3       Running            0          47m
kube-system   po/kube-proxy-70bmf                            1/1       Running            0          45m
kube-system   po/kube-proxy-9642h                            1/1       Running            0          45m
kube-system   po/kube-proxy-jhtvm                            1/1       Running            0          45m
kube-system   po/kube-proxy-nb7q5                            1/1       Running            0          47m
kube-system   po/kube-scheduler-master                       1/1       Running            0          46m

NAMESPACE     NAME              CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
default       svc/kubernetes    10.96.0.1       <none>        443/TCP         47m
kube-system   svc/calico-etcd   10.96.232.136   <none>        6666/TCP        47m
kube-system   svc/kube-dns      10.96.0.10      <none>        53/UDP,53/TCP   47m

NAMESPACE     NAME                              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-system   deploy/calico-policy-controller   1         1         1            1           47m
kube-system   deploy/kube-dns                   1         1         1            1           47m

NAMESPACE     NAME                                     DESIRED   CURRENT   READY     AGE
kube-system   rs/calico-policy-controller-1777954159   1         1         1         47m
kube-system   rs/kube-dns-3913472980                   1         1         1         47m

[vagrant<strong i="5">@master</strong> ~]$ kubectl -n kube-system describe po/calico-node-zq3zx
Name:       calico-node-zq3zx
Namespace:  kube-system
Node:       node1/192.168.10.101
Start Time: Wed, 26 Apr 2017 19:37:35 +0000
Labels:     k8s-app=calico-node
        pod-template-generation=1
Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"DaemonSet","namespace":"kube-system","name":"calico-node","uid":"844cd287-2ab7-11e7-b184-5254008815b6","ap...
        scheduler.alpha.kubernetes.io/critical-pod=
Status:     Running
IP:     192.168.10.101
Controllers:    DaemonSet/calico-node
Containers:
  calico-node:
    Container ID:   docker://ca00b0a73a073a2d2e39cb0cc315b8366eaa20e2e479002dd16134b0d1e94f0b
    Image:      quay.io/calico/node:v1.1.3
    Image ID:       docker-pullable://quay.io/calico/node<strong i="6">@sha256</strong>:8e62eee18612a6ac7bcae90afaba0ed95265baba7bf3c0ab632b7b40ddfaf603
    Port:       
    State:      Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Wed, 26 Apr 2017 20:21:09 +0000
    Ready:      False
    Restart Count:  12
    Requests:
      cpu:  250m
    Environment:
      ETCD_ENDPOINTS:               <set to the key 'etcd_endpoints' of config map 'calico-config'> Optional: false
      CALICO_NETWORKING_BACKEND:        <set to the key 'calico_backend' of config map 'calico-config'> Optional: false
      CALICO_DISABLE_FILE_LOGGING:      true
      FELIX_DEFAULTENDPOINTTOHOSTACTION:    ACCEPT
      CALICO_IPV4POOL_CIDR:         192.168.0.0/16
      CALICO_IPV4POOL_IPIP:         always
      FELIX_IPV6SUPPORT:            false
      FELIX_LOGSEVERITYSCREEN:          info
      IP:                   
    Mounts:
      /lib/modules from lib-modules (ro)
      /var/run/calico from var-run-calico (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
  install-cni:
    Container ID:   docker://442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
    Image:      quay.io/calico/cni:v1.7.0
    Image ID:       docker-pullable://quay.io/calico/cni<strong i="7">@sha256</strong>:3612ffb0bff609d65311b45f4bae57fa80a05d25e1580ceb83ba4162e2ceef9f
    Port:       
    Command:
      /install-cni.sh
    State:      Running
      Started:      Wed, 26 Apr 2017 19:38:29 +0000
    Ready:      True
    Restart Count:  0
    Environment:
      ETCD_ENDPOINTS:       <set to the key 'etcd_endpoints' of config map 'calico-config'>     Optional: false
      CNI_NETWORK_CONFIG:   <set to the key 'cni_network_config' of config map 'calico-config'> Optional: false
    Mounts:
      /host/etc/cni/net.d from cni-net-dir (rw)
      /host/opt/cni/bin from cni-bin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
Conditions:
  Type      Status
  Initialized   True 
  Ready     False 
  PodScheduled  True 
Volumes:
  lib-modules:
    Type:   HostPath (bare host directory volume)
    Path:   /lib/modules
  var-run-calico:
    Type:   HostPath (bare host directory volume)
    Path:   /var/run/calico
  cni-bin-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /opt/cni/bin
  cni-net-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /etc/cni/net.d
  calico-cni-plugin-token-5wnmg:
    Type:   Secret (a volume populated by a Secret)
    SecretName: calico-cni-plugin-token-5wnmg
    Optional:   false
QoS Class:  Burstable
Node-Selectors: <none>
Tolerations:    CriticalAddonsOnly=:Exists
        node-role.kubernetes.io/master=:NoSchedule
        node.alpha.kubernetes.io/notReady=:Exists:NoExecute for 300s
        node.alpha.kubernetes.io/unreachable=:Exists:NoExecute for 300s
Events:
  FirstSeen LastSeen    Count   From        SubObjectPath           Type        Reason      Message
  --------- --------    -----   ----        -------------           --------    ------      -------
  46m       46m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulling     pulling image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulled      Successfully pulled image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulling     pulling image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulled      Successfully pulled image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Created     Created container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Started     Started container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1                  Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 10s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  43m   43m 2   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  42m   42m 3   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   40m 6   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  39m   36m 12  kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  44m   3m  12  kubelet, node1  spec.containers{calico-node}    Normal  Pulled      Container image "quay.io/calico/node:v1.1.3" already present on machine
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Started     (events with common reason combined)
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Created     (events with common reason combined)
  36m   15s 149 kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   15s 173 kubelet, node1  spec.containers{calico-node}    Warning BackOff Back-off restarting failed container

Dies sieht nach wichtigen Informationen aus, aber ich bin mir nicht sicher, wie ich es beheben kann:

[vagrant<strong i="6">@master</strong> ~]$ kubectl -n kube-system logs calico-node-zq3zx calico-node
Skipping datastore connection test
time="2017-04-26T20:20:39Z" level=info msg="NODENAME environment not specified - check HOSTNAME" 
time="2017-04-26T20:20:39Z" level=info msg="Loading config from environment" 
ERROR: Unable to access datastore to query node configuration
Terminating
time="2017-04-26T20:21:09Z" level=info msg="Unhandled error: client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
time="2017-04-26T20:21:09Z" level=info msg="Unable to query node configuration" Name=node1 error="client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
Calico node failed to start

Jede Hilfe wäre sehr dankbar...

[0]- https://github.com/thiagodasilva/kubernetes-swift/tree/master/roles

Ich konnte nicht feststellen, was an Ihrer Seite nicht stimmt.
Ich empfehle dringend, dass Sie versuchen, eine separate Installation mit den Playbooks hier zu erstellen: https://github.com/ReSearchITEng/kubeadm-playbook und versuchen, den Unterschied zu sehen.
PS: meine letzten Tests sind mit 1.6.2 , sowohl kube* als auch Bilder und scheint in Ordnung zu sein.

@kelseyhightower

@ReSearchITEng Entschuldigung, ich habe vergessen, mich zu melden, aber schließlich habe ich es zum Laufen gebracht, meine vagrant+ansible-Dateien sind hier: https://github.com/thiagodasilva/kubernetes-swift

Ich habe auch das gleiche Problem, aber ich kopiere einfach die cni-Konfiguration auf dem Master-Knoten an die entsprechende Position des Worker-Knotens, dann wurde es in Ordnung.

systemctl-status kubelet.service -l

● kubelet.service - kubelet: Der Kubernetes-Knotenagent
Geladen: geladen (/etc/systemd/system/kubelet.service; aktiviert; Herstellervoreinstellung: deaktiviert)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Aktiv: aktiv (läuft) seit Di 06.06.2017 10:42:00 CST; vor 18min
Dokumente: http://kubernetes.io/docs/
Haupt-PID: 4414 (Kubelet)
Speicher: 43.0M
CGroup: /system.slice/kubelet.service
├─4414 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --network-plugin=cni - -cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --authorizatio -ca-file=/etc/kubernetes/pki/ca.crt --cgroup-driver=cgroupfs
└─4493 journalctl -k -f

06. Juni 10:59:46 contiv1.com kubelet[4414]: W0606 10:59:46.215827 4414 cni.go:157] cni-Konfiguration kann nicht aktualisiert werden: Keine Netzwerke in /etc/cni/net.d . gefunden
06. Juni 10:59:46 contiv1.com kubelet[4414]: E0606 10:59:46.215972 4414 kubelet.go:2067] Container-Laufzeitnetzwerk nicht bereit: NetworkReady=false ready message:docker : network plugin is not ready: cni config nicht initialisiert
06. Juni 10:59:51 contiv1.com kubelet[4414]: W0606 10:59:51.216843 4414 cni.go:157] cni-Konfiguration kann nicht aktualisiert werden: Keine Netzwerke in /etc/cni/net.d . gefunden
06. Juni 10:59:51 contiv1.com kubelet[4414]: E0606 10:59:51.216942 4414 kubelet.go:2067] Container-Laufzeitnetzwerk nicht bereit: NetworkReady=false ready message:docker : network plugin is not ready: cni config nicht initialisiert
06. Juni 10:59:56 contiv1.com kubelet[4414]: W0606 10:59:56.217923 4414 cni.go:157] cni-Konfiguration kann nicht aktualisiert werden: Keine Netzwerke in /etc/cni/net.d . gefunden
06. Juni 10:59:56 contiv1.com kubelet[4414]: E0606 10:59:56.218113 4414 kubelet.go:2067] Container-Laufzeitnetzwerk nicht bereit: NetworkReady=false ready message:docker : network plugin is not ready: cni config nicht initialisiert
06. Juni 11:00:01 contiv1.com kubelet[4414]: W0606 11:00:01.219251 4414 cni.go:157] cni-Konfiguration kann nicht aktualisiert werden: Keine Netzwerke in /etc/cni/net.d . gefunden
06. Juni 11:00:01 contiv1.com kubelet[4414]: E0606 11:00:01.219382 4414 kubelet.go:2067] Container-Laufzeitnetzwerk nicht bereit: NetworkReady=false ready message:docker : network plugin is not ready: cni config nicht initialisiert
06. Juni 11:00:06 contiv1.com kubelet[4414]: W0606 11:00:06.220396 4414 cni.go:157] cni-Konfiguration kann nicht aktualisiert werden: Keine Netzwerke in /etc/cni/net.d . gefunden
06. Juni 11:00:06 contiv1.com kubelet[4414]: E0606 11:00:06.220575 4414 kubelet.go:2067] Container-Laufzeitnetzwerk nicht bereit: NetworkReady=false ready message:docker : network plugin is not ready: cni config nicht initialisiert

Der Status aller Knoten:
[ root@swarm net.d]# kubectl get node
NAME STATUS ALTER VERSION
contiv1.com Bereit 1h v1.6.4
contiv2.com Bereit 1h v1.6.4
swarm.com Bereit 1h v1.6.4

Irgendeine Auflösung dazu? Ich war nicht in der Lage, dies zu tun, selbst nachdem ich alle genannten Auflösungen ausprobiert hatte.

Da ich neu bei der Einrichtung von Kubernetes bin, bin ich total verwirrt. Ich habe versucht, https://medium.com/@SystemMining/setup -kubenetes-cluster-on-ubuntu-16-04-with-kubeadm-336f4061d929 zu folgen, die weave-kube für das Netzwerk verwenden, aber ich habe auch das gleiche Problem . Irgendeine Möglichkeit, dies zu lösen?
Ready False Mon, 12 Jun 2017 16:55:16 +0200 Mon, 12 Jun 2017 12:22:45 +0200 KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Warum ist das immer noch ein Thema? Ubuntu 16.04/CentOS 7.3 mit den neuesten Updates unter Verwendung der offiziellen k8s-Repos mit 1.6.4 und den hier beschriebenen Schritten: https://kubernetes.io/docs/setup/independent/install-kubeadm/
Jun 13 09:57:21 tme-lnx1-centos kubelet: W0613 09:57:21.871413 10321 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 13 09:57:21 tme-lnx1-centos kubelet: E0613 09:57:21.871788 10321 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@drajen Nein, dies betraf _nur v1.6.0_ . Es wird erwartet, dass kubelet kein Netzwerk findet, da Sie keines installiert haben. Lauf zum Beispiel einfach

kubectl apply -f https://git.io/weave-kube-1.6

Weave Net zu installieren und diese Probleme werden verschwinden. Sie können Flanell, Calico, Canal oder ein beliebiges CNI-Netzwerk installieren, wenn Sie möchten

@luxas Ich

@drajen Ich denke, @luxas ' Punkt ist, dass dies der falsche Ort ist, um nach der Einrichtung zu fragen.
Die verschiedenen Setup-Anleitungen bringen Sie über diesen Punkt hinaus - den typischen fehlenden Schritt in älteren Anleitungen, den luxas hilfreich erwähnt, da Sie eine Netzwerkkonfiguration vornehmen müssen, bevor alles richtig funktioniert.

Ja, es ist vielleicht nicht offensichtlich und es tut uns leid, aber wir können auch dort keinen einzigen Anbieternamen haben.

Chatte mit @drajen auf Slack und das Problem bezog sich auf die Cgroup, das Kubelet war fehlerhaft und konnte keine Pods erstellen, daher das Problem.

Danke an @luxas für das Ringen meines speziellen Problems: https://github.com/kubernetes/kubeadm/issues/302

Wenn ich dies immer noch in Arch auf 1.7 treffe, gibt es irgendwo eine schnelle Lösung?

Bearbeiten:

kubectl apply -f https://git.io/weave-kube-1.6

hat den Trick gemacht, sieht so aus, als ob wir nur CNI zum Laufen brauchten

Stellen Sie zumindest für CentOS/RHEL sicher, dass Sie /etc/systemd/system/kubelet.service.d/10-kubeadm.conf aktualisieren und das Flag --cgroup-driver="systemd" hinzufügen.

Wenn Sie auf demselben Computer erneut installieren, ist dies ein vollständiger ordnungsgemäßer Reset:
https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/reset.yml
(dies ist insbesondere erforderlich, wenn Sie Flanell verwenden)
Wenn Sie alles in einem machen möchten, möchten Sie vielleicht das gesamte Projekt verwenden: https://github.com/ReSearchITEng/kubeadm-playbook/

Ich bin auf dieses Problem gestoßen und absolut nichts, was ich oben gelesen habe, hat funktioniert. Also versuchte ich es noch einmal mit einem viel kontrollierteren Setup, wechselte von Ubuntu auf das neueste CoreOS, ging zunächst zu einer früheren Version von k8s und war im Allgemeinen sehr anal, was alles in jeder VM installierte. Ich verwende NICHT kubeadm, sondern eine Kombination aus Vagrant und Ansible.

(Warum? weil ich keine Ahnung hatte, was in kubeadm vor sich ging, und so dachte, dass ich zumindest die Kontrolle habe und in der Lage bin, übereifrige Preflight-Checks zu umgehen, ganz zu schweigen von dem Gefühl, dass ich im Allgemeinen mehr Kontrolle über die Automatisierung hätte, und auch Sie müssen sich keine Sorgen über die Warnung machen, Alpha-Software in der Produktion nicht anzuwenden.)

Als ich dieses Setup mit einer älteren (1.4.3) Edition von k8s ausprobiert habe, war dieser Ansatz goldrichtig. Ich habe dann versucht, auf 1.71 zu aktualisieren. Noch einmal, ich stoße immer noch auf das gleiche Problem, obwohl ich überhaupt kein kubeadm verwende.

Ich habe bestätigt, dass ich Calico in jedem meiner Knoten verwende, einschließlich des Masters und der drei potenziellen Arbeiter. ALLE meine Knoten melden sich als NotReady, daher bin ich mir nicht wirklich sicher, wie ich Weave (oder etwas anderes) anwenden kann, um es zum Laufen zu bringen.

Diese ganze Sache scheint nur Huhn/Ei ... kann keinen Pod zuordnen, weil das Netzwerk fehlschlägt, aber es muss ein Netzwerk laufen, um ein Netzwerk unter /etc/cni/net.d zu erstellen, um Pods zuordnen zu können. Und wieder funktionierte das alles vor ein paar Stunden mit k8s 1.4.3. Ich bin sehr frustriert!

Ich wäre dankbar für alle Einblicke, die jemand geben könnte.

Fußnoten:

Auf Master: journalctl -r -u kubelet gibt mir

24. Juli 00:48:16 rogue-kube-master-01 kubelet-wrapper[7647]: E0724 00:48:16.592274 7647 kubelet.go:2136] Container-Laufzeitnetzwerk nicht bereit: NetworkReady=false Grund:NetworkPluginNotReady message:docker : Netzwerk-Plugin ist nein
24. Juli 00:48:16 rogue-kube-master-01 kubelet-wrapper[7647]: W0724 00:48:16.590588 7647 cni.go:189] cni-Konfiguration kann nicht aktualisiert werden: Keine Netzwerke in /etc/cni/net . gefunden .D

docker ps | grep kaliko

(zur besseren Lesbarkeit abgeschnitten)
cde ... quay.io/calico/ Leader-Wähler @ sha256 : ... "/run.sh --election = c" Vor 8 Stunden bis 8 Stunden
f72... calico/ kube-policy-controller@sha256 :... "/dist/controller" vor 8 Stunden Bis 8 Stunden
c47... gcr.io/google_containers/pause-amd64:3.0 "/pause" vor 8 Stunden Bis 8 Stunden

Es gibt keine /etc/cni/net.d

Aus meiner kubectl-Box:
kubectl bekommt Knoten
10.0.0.111 NotReady,SchedulingDisabled 8h v1.7.1+coreos.0
10.0.0.121 NotReady 8h v1.7.1+coreos.0
10.0.0.122 NotReady 8h v1.7.1+coreos.0
10.0.0.123 NotReady 8h v1.7.1+coreos.0

kubectl apply -f https://git.io/weave-kube-1.6

HATTE NICHTS repariert und scheint tatsächlich nur noch mehr Probleme zu verursachen.

bill@rogue :~/vagrant_rogue/rogue-cluster$ kubectl apply -f https://git.io/weave-kube-1.6
Servicekonto "weave-net" erstellt
Clusterrollenbindung "weave-net" erstellt
daemonset "weave-net" erstellt
Fehler vom Server (Forbidden): clusterroles.rbac.authorization.k8s.io "weave-net" ist verboten: Versuch, zusätzliche Berechtigungen zu erteilen: [PolicyRule{Resources:["pods"], APIGroups:[""], Verbs: ["get"]} PolicyRule{Resources:["pods"], APIGroups:[""], Verbs:["list"]} PolicyRule{Resources:["pods"], APIGroups:[""], Verben: ["watch"]} PolicyRule{Ressourcen:["namespaces"], APIGroups:[""], Verbs:["get"]} PolicyRule{Resources:["namespaces"], APIGroups:[""], Verben: ["list"]} PolicyRule{Resources:["namespaces"], APIGroups:[""], Verbs:["watch"]} PolicyRule{Resources:["nodes"], APIGroups:[""], Verben: ["get"]} PolicyRule{Ressourcen:["nodes"], APIGroups:[""], Verbs:["list"]} PolicyRule{Resources:["nodes"], APIGroups:[""], Verben: ["watch"]} PolicyRule{Resources:["networkpolicies"], APIGroups:["extensions"], Verbs:["get"]} PolicyRule{Resources:["networkpolicies"], APIGroups:["extensions"], Verben:["list"]} PolicyRule{Ressourcen:["networkpolicies"], APIGroups:["extensions"], Verbs:["watch"]}] user=&{kube-admin [system:a authentifiziert] map[]} ownerrules=[] ruleResolutionErrors=[]

bill@rogue :~/vagrant_rogue/rogue-cluster$ kubectl Get Pods --namespace=kube-system
NAME BEREIT STATUS NEUSTART ALTER
kube-apiserver-10.0.0.111 1/1 Läuft 1 8h
kube-controller-manager-10.0.0.111 1/1 Läuft 1 8h
kube-dns-v20-fcl01 0/3 Ausstehend 0 8h
kube-proxy-10.0.0.111 1/1 Läuft 1 8h
kube-proxy-10.0.0.121 1/1 Läuft 1 8h
kube-proxy-10.0.0.122 1/1 Läuft 1 8h
kube-proxy-10.0.0.123 1/1 Läuft 1 8h
kube-scheduler-10.0.0.111 1/1 Laufen 1 8h
kubernetes-dashboard-v1.4.1-29zzk 0/1 Ausstehend 0 8h
weave-net-2lplj 1/2 CrashLoopBackOff 3 3m
weave-net-2nbgd 1/2 CrashLoopBackOff 3 3m
weave-net-fdr1v 2/2 Laufend 0 3m
weave-net-jzv50 1/2 CrashLoopBackOff 3 3m

Eine eingehendere Untersuchung der Webfehler zeigt, dass sie entweder (a) keine Verbindung zum Apiserver herstellen können oder (b) im Fall des mit "Running" markierten Servers sich beschweren, dass er sich nicht mit sich selbst verbinden kann.

@billmilligan Bei ähnlichen Problemen funktioniert

@Paxa @billmilligan Wenn Sie Hilfe erhalten möchten, kommentieren Sie dieses Problem nicht. Öffnen Sie stattdessen neue im kubeadm-Repository mit ausreichend angeforderten Details.

@luxas Hochachtungsvoll muss ich fragen, ob dies ein neues Problem ist. Da ich beim Einrichten von k8s ohne kubeadm genau das gleiche Ergebnis erhalte wie alle anderen mit kubeadm, scheint dies kubeadm als Ursache des Problems zu beseitigen. Vielleicht sollte dieses Thema entsprechend umbenannt werden?

@billmilligan respektvoll, da es sich bei dem Problem um kubeadm handelt und Sie es ohne kubeadm reproduzieren können, ist es dann der falsche Ort, um es abzulegen? Ich denke, dieser Thread hat das Problem mit kubeadm gelöst. Dies ist ein neues Thema. Ich denke, es wird als neues Thema mehr Aufmerksamkeit bekommen. Da die Leute in diesem Thread denken, dass es bereits gelöst ist, und es ignorieren.

Ich benutze kubeadm und war von diesem Problem betroffen, und es wurde seit 1.6.1 behoben. Ich habe seitdem verlorene k8s bereitgestellt, also denke ich wirklich, dass Sie ein separates Problem haben.

@kfox1111 Danke für das Feedback. Ich werde ein neues Problem einreichen, aber die Anzahl der Leute, die es in 1.7.x immer noch zu tun scheinen, lässt mich immer noch wundern.

TL;DR;

Die Fehlermeldung

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

ist NICHT unbedingt schlecht.

Diese Fehlermeldung sagt Ihnen, dass Sie einen Drittanbieter für die Implementierung von CNI-Spezifikationen einbinden müssen .

Was ist CNI und wie lässt es sich in Kubernetes integrieren?

CNI steht für Container Network Interface und definiert eine Spezifikation , die kubelet verwendet, um ein Netzwerk für den Cluster zu erstellen. Auf dieser Seite finden Sie weitere Informationen dazu, wie Kubernetes die CNI-Spezifikation verwendet, um ein Netzwerk für den Cluster zu erstellen.

Kubernetes ist es egal, wie das Netzwerk erstellt wird, solange es die CNI-Spezifikation erfüllt.

kubelet ist dafür verantwortlich , neue Pods mit dem Netzwerk zu verbinden (kann beispielsweise ein Overlay-Netzwerk sein).
kubelet liest ein Konfigurationsverzeichnis (oft /etc/cni/net.d ) für CNI-Netzwerke.
Wenn ein neuer Pod erstellt wird, liest das Kubelet Dateien aus dem Konfigurationsverzeichnis, exec wird an die in der Konfigurationsdatei angegebene CNI-Binärdatei ausgegeben (die Binärdatei befindet sich oft in /opt/cni/bin ). Die auszuführende Binärdatei gehört einem Drittanbieter (wie Weave, Flannel, Calico usw.) und wird von diesem installiert.

kubeadm ist ein generisches Tool zum Einrichten von Kubernetes-Clustern und weiß nicht, welche Netzwerklösung Sie wollen und bevorzugt niemanden speziell. Nachdem kubeadm init ausgeführt wurde, gibt es weder eine solche CNI-Binärdatei noch eine solche Konfiguration . Dies bedeutet, dass kubeadm init NICHT GENUG IST , um einen voll funktionsfähigen Cluster zum Laufen zu bringen.

Das bedeutet, dass nach kubeadm init die Kubelet-Protokolle sagen:

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

das wird sehr erwartet. Wäre dies nicht der Fall, hätten wir einen bestimmten Netzanbieter bevorzugt.

Wie kann ich diesen Fehler "beheben"?
Der nächste Schritt im kubeadm-Leitfaden für die ersten Schritte ist "Installieren eines Pod-Netzwerks".
Dies bedeutet, kubectl apply ein Manifest von Ihrem bevorzugten CNI-Netzwerkanbieter.

Das DaemonSet kopiert die benötigten CNI-Binärdateien nach /opt/cni/bin und die erforderliche Konfiguration nach /etc/cni/net.d/ . Außerdem wird er den eigentlichen Daemon ausführen, der das Netzwerk zwischen den Nodes einrichtet (indem er beispielsweise iptables-Regeln schreibt).

Nach der Installation des CNI-Anbieters bemerkt das Kubelet "Oh, ich habe einige Informationen zum Einrichten des Netzwerks" und verwendet die Konfiguration und die Binärdateien von Drittanbietern.

Und wenn das Netzwerk vom Drittanbieter eingerichtet wird (durch Kubelet-Aufruf), wird der Node sich selbst als Ready markieren.

Wie hängt dieses Problem mit kubeadm zusammen?

Gegen Ende des v1.6-Zyklus wurde ein PR zusammengeführt, der die Art und Weise änderte, wie Kubelet den Ready/NotReady Status meldete. In früheren Versionen hatte kubelet immer den Status Ready gemeldet, unabhängig davon, ob das CNI-Netzwerk eingerichtet war oder nicht. Dies war eigentlich falsch und wurde geändert, um den CNI-Netzwerkstatus zu respektieren. Das heißt, NotReady wenn CNI nicht initialisiert wurde, und Ready wenn es initialisiert wurde.

kubeadm in v1.6.0 hat fälschlicherweise darauf gewartet, dass sich der Masterknoten im Zustand Ready bevor er mit den restlichen kubeadm init Aufgaben fortfährt. Wenn sich das kubelet-Verhalten änderte, um NotReady zu melden, wenn CNI nicht initialisiert wurde, wartete kubeadm ewig, bis der Node Ready .

DIESE AUSGABE GEHT UM DIESES WAIT-FEHLER AUF DER KUBEADM-SEITE

Wir haben die Regression in v1.6.1 jedoch schnell behoben und einige Tage nach v1.6.0 veröffentlicht.

Bitte lesen Sie die Retrospektive, um mehr darüber zu erfahren und warum v1.6.0 mit diesem Fehler veröffentlicht werden könnte.

Was tun Sie also, wenn Sie glauben, dieses Problem in kubeadm v1.6.1+ zu sehen?

Nun, ich glaube wirklich, Sie nicht. Dieses Problem tritt auf, wenn kubeadm init Deadlocks ist.
Kein Benutzer oder Betreuer haben das in v1.6.1+ gesehen.

Was Sie werden allerdings sehen ist

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

nach jedem kubeadm init in allen Versionen über v1.6, aber das IST NICHT SCHLECHT

Wie auch immer, öffnen Sie bitte ein neues Problem, wenn Sie etwas Unerwartetes mit kubeadm sehen

Bitte kommentieren Sie dieses Thema nicht weiter. Öffnen Sie stattdessen ein neues.

@billmilligan Sie müssen also nur kubectl apply das Manifest eines CNI-Anbieters erstellen , um Ihren Cluster zum Laufen zu bringen, denke ich

Ich fasse das oben Gesagte ziemlich genau zusammen, aber hoffentlich klarer und detaillierter.
Wenn Sie Fragen zur Funktionsweise von CNI haben, wenden Sie sich bitte an die normalen Supportkanäle wie StackOverflow, ein Problem oder Slack.

(Zuletzt entschuldige ich den fetten Text, aber ich hatte das Gefühl, dass er nötig war, um die Aufmerksamkeit der Leute zu erregen.)