<p>kubeadm sollte die Option --node-ip verfügbar machen</p>

Aus diesem Grund habe ich derzeit Probleme beim Einrichten eines Kubernetes-Clusters in DigitalOcean. Standardmäßig bindet kubelet die IP des Standard-Gateways, das in diesen Fällen die öffentliche IP-Adresse für den Internetverkehr ist, und legt sie offen bzw. sendet sie. Wenn Sie dann ein Pod-Netzwerk-Add-On (wie Weave) einrichten, bricht die Hölle los, da die Werbe-IP des Masters die IP-Adresse des internen Netzwerks ist, die Worker-Knoten jedoch versuchen, die öffentliche Adresse freizulegen: /

Die Lösung besteht darin, die unter /etc/systemd/system/kubelet.service.d/10-kubeadm.conf abgelegte Einheitendatei zu aktualisieren, um die --node-ip=<private_worker_ip> hinzuzufügen, Einheiten neu zu laden und kubelet neu zu starten, damit es funktioniert.

Wenn kubeadm dies standardmäßig tun kann, indem die Option übergeben wird, wie @nkratzke vorgeschlagen hat, wäre das großartig!

Ich wollte nur bestätigen, dass das Hinzufügen der Option --node-ip=<private-worker-ip> zu den Einstellungen in der Datei /etc/systemd/system/kubelet.service.d/10-kubeadm.conf dieses Problem für das zuvor erläuterte Setup nicht behebt. Obwohl die Knoten diese Schnittstelle abhören, verwendet Kubernetes weiterhin das Standard-Gateway für die Kommunikation zwischen Knoten, in diesem Fall die öffentliche IP-Adresse.

Ich habe das gleiche Problem. Ich habe deine Methode ausprobiert und es hat auch bei mir nicht funktioniert. Hast du es geschafft, dass es funktioniert?

@agsergi Ich habe versucht, einen k8s-Cluster in DigitalOcean mit aktivierter Option für privates Netzwerk einzurichten, was mich zu diesem Problem führte. Das Deaktivieren dieser Funktion hat es für mich getan, aber ich bin mir nicht sicher, ob Sie sich auf demselben Boot befinden.

Ich denke, dieses Problem tritt weiterhin auf, wenn mehr als zwei Netzwerkkarten an die Maschine angeschlossen sind.

Jungs,
Ich habe zwei Schnittstellen auf meiner VM, eine für NAT und eine für Hostonly-Adapter. Standardmäßig hat kubeadmin die Standard-Schnittstellen-IP (in meinem Fall NAT) verwendet, wenn Sie eine andere Schnittstelle verwenden möchten, dann verwenden Sie:
$ sudo kubeadm init --apiserver-werbeadresse =

Und es hat bei mir funktioniert.

@luxas Warum ist dies als Art / Support gekennzeichnet? Gibt es eine Möglichkeit, kubeadm mit einer Knoten-IP zu verwenden, die nicht die Quelle der Standardroute ist?

@evocage gibt es keine --apiserver-Advertise-Adresse =

Vielen Dank.

Ich bin auf Scaleway auf dasselbe Problem gestoßen.

Wenn ich den Master initialisiert habe, habe ich --apiserver-advertise-address=<private_net_IP> aber wenn ich einen Knoten hinzufügen möchte ( kubeadm join --toke=<token> <master_private_IP>:6443 ), werden Kube-Proxy- und Weave-Net-Pods nicht gestartet (Fehler beim Synchronisieren des Pods).

Aber wenn ich eine öffentliche IP an meinen Knoten anhänge und neu starte, läuft alles gut: Denken:

Irgendeine Idee?

Gleiches Problem beim Versuch, Kubernetes auf einem VM-Host mit einer einzelnen IP einzurichten, auf dem nur einige Ports an die VMs weitergeleitet werden können. Gibt es eine Problemumgehung, um es zum Laufen zu bringen?

Ich wollte nur +1. Ich versuche, auf eine Reihe von Digitalocean-VMs mit einer privaten IP-Adresse zu stoßen, aber die öffentlich zugängliche Adresse arbeitet sich irgendwie weiter in den Cluster hinein.

Ich habe es geschafft, private IPs zum Laufen zu bringen, indem ich dies auf dem Master ausgeführt habe:

kubeadm init --apiserver-advertise-address=<private-master-ip> init

Hinzufügen von --node-ip=<private-node-ip> zu /etc/systemd/system/kubelet.service.d/10-kubeadm.conf , erneutes Laden des Daemons, Neustarten von kubelet und anschließendes Ausführen von:

kubeadm join --token <token> <private-master-ip>:6443 --discovery-token-ca-cert-hash sha256:<hash>

@mongrelion Welche Art der Kommunikation zwischen dem Master- <-> Knoten verwendet noch öffentliche Schnittstellen? Ich konnte dies nicht replizieren, daher würde mich interessieren, ob sich kubernetes unerwartet verhält.

Das hat es geschafft! Die Kombination von --apiserver-advertise-address um sicherzustellen, dass der Master an der richtigen Stelle startet, und --node-ip in der Kubelet-Konfiguration war die magische Kombination.

Laut dieser Anfrage wäre es für ahnungslose Neulinge wie mich, die versuchen, Cluster hochzufahren, hilfreich, wenn diese Option --node-ip direkt in kubeadm damit die Konfigurationsdateien korrekt initialisiert werden :)

Vielen Dank an @jamiehannaford für diese Zusammenfassung. Denken wir, wir sollten dies sichtbarer dokumentieren?

@luxas Ja, ich denke, es wäre nützlich, diesen Anwendungsfall explizit dokumentiert zu haben

@jamiehannaford Wenn Sie auch dies zur Dokumentumbildung für https://github.com/kubernetes/website/pull/6103 hinzugefügt werden soll

@fabriziopandini Sicher! Getan

Hallo,

Ich möchte auch ein Feedback geben. Ich versuche, mit kubeadm einen sicheren Einzelknotencluster zu erstellen.
Ich möchte, dass alle kubernetes-Dienste an localhost gebunden werden, aber das funktioniert nicht.

Ich verwende diesen Befehl und der Cluster wird erstellt:
kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --apiserver-advertise-address=127.0.0.1 \ --apiserver-cert-extra-sans=127.0.0.1,staging.my-server.net
/etc/kubernetes/admin.conf und Freunde enthalten jedoch die öffentliche IP-Adresse des Masters.
server: https://75.xx.yy.zz:6443

Ich werde den --node-Ansatz ausprobieren, aber ich würde mich freuen, wenn Sie mir helfen können, eine Lösung dafür zu finden.

Mein Anwendungsfall:

Ich habe eine bullige Maschine, die ich als Staging-Umgebung und möglicherweise als Produktionsumgebung für kleine Projekte verwenden möchte, bei denen mir HA egal ist. Ich kann SSH verwenden und kubectl verwenden, um den Cluster zu steuern.

Vielen Dank,

Ich hatte genau das gleiche Problem wie @ Mosho1 hier und bin dem auf den Grund

Ich benutze DO und CoreOS, aber das hängt wirklich mit keinem zusammen und könnte bei anderen Anbietern und Distributionen passieren. Es hat auch nichts damit zu tun, dass die privaten Netzwerke von DO aktiviert oder deaktiviert sind: Ich habe das Problem in beiden Fällen reproduziert.

Was passiert ist, dass kubelet wie von kubeadm Schnittstellen betrachtet und beschließt, unabhängig von den zugewiesenen verfügbaren IPs oder Schnittstellen ein eigenes privates Subnetz in den Mix aufzunehmen, und dies auch weiterhin tun möchte das gleiche, das es als "main" betrachtet (erstes? WAN eins? Ich weiß nicht). Dieser ist nicht über ifconfig sichtbar, aber leicht über ip addr , und es wird auch eine Route eingerichtet, aber es besteht keine Chance, dass diese über das DO-Netzwerk fliegt, das die Knoten eth0 .

EDIT: Dank @klausenbusk scheint es, dass Kubelet die Anker-IP unter der Annahme

Die Lösung besteht in der Tat darin, kubelet mitzuteilen, welche IP verwendet werden soll. Es kann das öffentliche oder das private sein, wenn Sie das optionale private Netzwerk verwenden.

Hier ist, wie ich --node-ip . Achtung, dies setzt voraus, dass KUBELET_EXTRA_ARGS noch nicht in der Einheitendatei festgelegt wurde.

$ DROPLET_IP_ADDRESS=$(ip addr show dev eth0 | awk 'match($0,/inet (([0-9]|\.)+).* scope global eth0$/,a) { print a[1]; exit }')
$ echo $DROPLET_IP_ADDRESS  # check this, jus tin case
$ echo "Environment=\"KUBELET_EXTRA_ARGS=--node-ip=$DROPLET_IP_ADDRESS\"" >> /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
$ systemctl daemon-reload
$ systemctl restart kubelet

@lloeki Danke für das Schreiben. Würde es Ihnen etwas ausmachen, die Dokumente zu aktualisieren, möglicherweise hier: https://github.com/kubernetes/website/blob/master/docs/setup/independent/troubleshooting-kubeadm.md

Es wählt also das WAN (eth0) aus, sieht (oder ignoriert) eine öffentliche IP und beschließt, ein zweites privates Subnetz hinzuzufügen (wie in meinem Fall 10.19.0.0/255), wahrscheinlich unter der Annahme, dass alle Knoten eth0 sind auf dem gleichen Link.

Bist du dir da sicher? Es könnte nur die Anker-IP sein (vergleiche mit curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address )

@klausenbusk du hast absolut --node-ip .

Es scheint also, dass Kubelet diesen unter der Annahme aufgreift, dass es nützlich sein könnte, wenn es nicht so ist?

$ curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
10.19.0.39
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet yyy.yyy.yyy.yyy/20 brd yyy.yyy.yyy.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.19.0.39/16 brd 10.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever

Würde es Ihnen etwas ausmachen, die Dokumente zu aktualisieren?

@ Jamiehannaford Klingt so, als könnte ich das machen :)

/ @liztio zuweisen

Ich habe mir das angeschaut und denke, dass der Konsens, selbst wenn die Benutzer das Hinzufügen des Arguments --node-ip zu kubeadm anfordern, darin besteht, dass das Ändern der Kubelet-Konfiguration und die Verwendung der hier vorgeschlagenen Parameter wie @jamiehannaford der empfohlene Ansatz ist:
https://github.com/kubernetes/kubeadm/issues/203#issuecomment -335416377

(oder vielleicht an $ KUBELET_EXTRA_ARGS anhängen, bevor das kublet neu gestartet wird).

Angesichts der Entscheidung, keine zusätzlichen cmd-Argumente zu kubeadm hinzuzufügen, denke ich, dass es sicher sein könnte, dieses Problem zu schließen ... es sei denn, es gibt Pläne, dies mit kubeadm MasterConfig-Optionen zu aktivieren (irgendwie ?? ... wie wir uns darauf verlassen der Benutzer, der die Kubelet-Konfiguration bearbeitet und sich manuell auf Änderungen ausruht).

edit: oder vielleicht mit der dynamischen kubelet config wenn das möglich ist?

Alle oben genannten Vorschläge für Dokumentationsänderungen scheinen zusammengeführt zu sein.

@timstclair @liztio

Ich bin damit einverstanden, diesen zu schließen.

Beachten Sie nur, dass in Kubernetes 1.11 die Einstellung von KUBELET_EXTRA_ARGS in /etc/systemd/system/kubelet.service.d/20-custom.conf nicht mehr funktioniert: Sie sollte in / etc / sysconfig / kubelet festgelegt werden (eine etwas andere Syntax) dieser Dateien).

@stepin Ich habe gerade einen 1.11-Cluster mit kubeadm eingerichtet und danach cat: /etc/sysconfig/kubelet: No such file or directory

/etc/systemd/system/kubelet.service.d/20-custom.conf auch nicht, daher bin ich mir nicht sicher, was Sie dort gemacht haben.

Wenn das, was Sie gesagt haben, wahr ist, scheint das Spiel der Konfiguration Hot Potato fortgesetzt zu werden.

Ich konnte hier noch einen weiteren Speicherort für die Kubelet-Konfiguration finden: /etc/default/kubelet

Für zukünftige Reisende (zumindest für die nächste Woche) scheint dies zu funktionieren:

PRIVATE_IP=10.99.0.0
echo "KUBELET_EXTRA_ARGS=--node-ip=$PRIVATE_IP" > /etc/default/kubelet
systemctl daemon-reload
systemctl restart kubelet

Natürlich müssen Sie die IP-Adresse auf die IP-Adresse ändern, die sich auf diesem bestimmten Knoten befindet.

Haftungsausschluss: Ich überprüfe nur Kubernetes, daher kann ich nicht garantieren, dass dies nichts Schreckliches bewirkt. Obwohl /etc/systemd/system/kubelet.service.d/10-kubeadm.conf auf /etc/default/kubelet hinweist, denke ich, dass dies das Richtige ist.

@jazoom - Danke für Ihren Kommentar, es hat mich schließlich dazu gebracht, die systemd unit-Datei genauer zu lesen. Ich dachte, ich würde verrückt, da ich die gleiche Konfiguration in 1.10 aufrufen könnte, und alles funktionierte ... die Konfiguration in 1.11 aufrufen und die benutzerdefinierte --node-ip ich eingestellt hatte, galt überhaupt nicht. Der Wechsel zum Hinzufügen der zusätzlichen Argumente in /etc/default/kubelet das Problem für mich behoben.

@geerlingguy Gern geschehen .

Zumindest ging es nicht um "es funktioniert jedes zweite Mal, wenn ich einen 1.11-Cluster aufrufe". Diese nicht reproduzierbaren Probleme werden Sie wirklich verrückt machen.

Bin gerade in "Kubeadm 1.13" darauf gestoßen. Es wurde wie folgt behoben:

1) Fügen Sie "--node-ip" zu '/var/lib/kubelet/kubeadm-flags.env' hinzu:

[root@Node-18121 ~]# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS=--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.1 --node-ip=10.10.10.1

2) Starten Sie Kubelet neu:

systemctl daemon-reload && systemctl restart kubelet

^ Wenn jemand weiß, wie das mit schwebenden IPs funktioniert, die nicht auf der Netzwerkkarte angezeigt werden, lassen Sie es mich bitte wissen. Sonst erfolgreich.

Hallo,

Bitte versuchen Sie dies https://wiki.hetzner.de/index.php/Cloud_floating_IP_persistent/en .
Es funktioniert für Hetzner, aber ich denke, es ist generisch.
Eugen

Das hat perfekt funktioniert. Vielen Dank.

Ich bin gerade auf dieses Problem in "Kubeadm 1.13" gestoßen. Das Problem wurde mit den folgenden Methoden behoben:

1. Fügen Sie "--node-ip" in "/var/lib/kubelet/kubeadm-flags.env" hinzu:

[root@Node-18121 ~]# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS=--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.1 --node-ip=10.10.10.1

1. Starten Sie Kubelet neu:

systemctl daemon-reload && systemctl restart kubelet

Vielen Dank, bewegend