<p>kubeadm beschwert sich über bridge-nf-call und ip_forward, wenn keine Docker-Laufzeit verwendet wird</p>

Fühlt sich nicht wie ein Produktfehler an, sondern wie ein Dokumentationsfehler (nur ein fehlendes Handbuch). Derzeit haben wir nur Seiten darüber, wie man Kubernetes mit kubeadm mit Docker als Container-Laufzeit installiert. Wir sollten eine andere für cri-o haben.

IMO kubeadm sollte zumindest die Modprobe selbst ausführen. Ob dies auch für ip_forward der Fall ist, ist umstritten, da dies von der Systemkonfiguration bis zum Administrator abhängt.

@vrothberg - was denkst du? Sollten die beiden oben genannten Bedingungen (modprobe und sysctl) von kubeadm automatisch korrigiert werden, oder denken Sie, dass dies in CRI-O besser gehandhabt wird?

Docker erledigt beides automatisch

Und wenn Sie der Meinung sind, dass CRI-O nicht aufpassen sollte, wo sollte der schmutzige Hack Ihrer Meinung nach in openSUSE ausgeführt werden? im cri-o-paket oder im kubeadm-paket? ;)

Ich denke, das sollte das kubeadm-Paket tun. Danach können wir
Überprüfen Sie, ob dies wirklich ein Fehler ist oder ob er in ein Infoprotokoll herabgestuft werden kann.
Viele Dinge in K8s drehen sich immer noch darum, wie Docker Dinge macht, aber
Sie sind nicht immer notwendig.

Ich bin im Moment im Urlaub, werde aber hier und da E-Mails abrufen. Vielen Dank
für den Ping.

Am Mittwoch, den 12. September 2018 um 10:30 Uhr, Richard Brown [email protected]
schrieb:

@vrothberg https://github.com/vrothberg - was denkst du? Sollte die
über 2 Bedingungen (modprobe und sysctl) werden automatisch durch korrigiert
kubeadm, oder denkst du, dass dies in CRI-O besser gehandhabt wird?

Docker erledigt beides automatisch

Und wenn Sie der Meinung sind, dass CRI-O nicht aufpassen sollte, wo denken Sie dann?
Dirty Hack sollte in openSUSE getragen werden? in der cri-o-paket oder in der
Kubeadm-Paket? ;)

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubeadm/issues/1062#issuecomment-420559942 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ALI4g1dRKf5vWXz_7H27VktuD8nP5tAsks5uaMYogaJpZM4V_W70
.

Dieses Problem wird in openSUSE mit den folgenden Änderungen behoben: https://build.opensuse.org/package/rdiff/devel : kubic / kubernetes? Linkrev = base & rev = 9

Ich habe vor, umgehend etwas Ähnliches in der Upstream-RPM-Verpackung einzureichen

Docker neu zu starten hat den Trick gemacht ... Danke

Ich füge diese Informationen als zweites der Setup-Seite hinzu. Ich habe diesen Fehler gesehen und es hat mir mindestens 20 Minuten Schmerzen verursacht, bis ich auf diesen Thread gestoßen bin. Vielen Dank, dass Sie die Lösung geteilt haben.

Stellen Sie sicher, dass Sie die Prozedur befolgen, damit der Fehler nicht auftritt
https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cri -o

Das einfache Modifizieren von Dingen stellt nicht sicher, dass sie ausgeführt werden. Wenn Sie neu starten, bricht alles zusammen. Es sollte Ihnen sagen, dass Sie sicherstellen müssen, dass diese Dinge dauerhaft aktiviert sind. Das gilt für die sysctl-Regeln, aber nicht für die Module.

Wenn ich den Anweisungen zu solchen Dingen folge, lese ich nicht gerne in Dinge hinein und versuche, zusätzliche Schritte zu unternehmen, die auf Ahnungen beruhen. Wenn es mir sagt, dass ich etwas tun soll, mache ich es. Wenn nicht, tue ich es nicht. Ich warte darauf, dass die Dinge kaputt gehen und gehe zurück und repariere sie. Auf diese Weise habe ich eine bessere Vorstellung davon, ob es sich um eine schlechte Dokumentation handelt, die das Problem darstellt, anstatt um eine zufällige Sache, die ich gemacht habe, als die Dinge kaputt gingen.

Ich muss wahrscheinlich meine lokalen Hyper-V-Knoten-Images neu erstellen.