ARP Broadcast aus MAC VLAN

[haydibe]

Im Enterprise Umfeld gibt es in der Regel Loadbalancer als Einstiegspunkt, und etliche DNS-Einträge die darauf zeigen.

Ehrlich gesagt nutzt da in den letzten Jahren aber auch kaum einer Docker, sondern nur Docker Desktop für die lokale Entwicklung und lokale Tests. Der Betrieb läuft fast immer auf Kubernetes, oder einer gemanagten Containerlösung wie AWS ECS. Bei den Cloud-Anbietern kann man hier noch mit Security Groups nachhelfen. Im Kubernetes-Umfeld gibt es die NetworkPolicies, die erlauben Portfilter zu definieren.

Typischerweise gibt es aber nicht nur den einen Cluster, sondern je nach Team, Projekt, Verfahren mehrere Cluster für unterschiedliche Stages.

 

[JohneDoe]

Ja gut stimmt.... Bei uns läuft auch alles als K8s Cluster. Bei den Cloudanbietern bin ich raus. Das nutzen wir nicht bzw. die Kunden nicht.
Ich dachte da eher an interne Anwendungen, aber auch die müssen ja ordentlich skalieren und ohne Ausfall laufen. Stimmt.... für reines Docker gibt es wirklich nicht viele Einsatzzwecke im professionellen Einsatz. Ich wollte lokal auch auf K8s bzw. um genau zu sein auf k3s setzen, aber leider habe ich zu Hause nicht den Storage als HA Lösung. Dann hätte ich immer noch nur einen Single Point of Failure und deshalb hab ich erstmal gelassen

 

[kingkong66]

Es gibt eine Lösung wie ich mein macvlan mit dem Host koppeln kann (wenn man denn unbedingt will):

IP des zu koppelnden containers 192.168.5.210. Dieser läuft im macvan mac0

- Mit SSH auf der Synology einstloggen
- sodu -i
auf der Synology eine Bridge-Koppelung eingeben:
(spezialdevice mac1 mit derselben Adresse wie mein Container plus route auf mein macvlan mac0)

ip link add mac1 link eth0 type macvlan mode bridge
ip addr add 192.168.5.210/32 dev mac1
ip link set mac1 up
ip route add 192.168.5.208/28 dev mac1

Die Anleitungen unter https://www.synology-forum.de/threads/macvlan-zugriff-auf-den-host.103178/ und http://www.stueben.de/iobroker-im-docker-auf-der-synology-diskstation-im-gleichen-subnet/ haben bei mir auf der 723+ mit DSM 7.3..... nicht mehr richtig funktioniert. Mit mit meinem Befehlssatz war IP 192.168.5.210 sowohl vom Host, als auch vom ArbeitsPC aus pingbar.

Diese Anpassungen verschwinden mit jedem reboot. Heisst ich muss noch ein Script "basteln" welches diesem Befehlssatz bei jedem reboot wieder neu durchführt

root@NAS723:~# ip route
default via 192.168.5.1 dev eth0 src 192.168.5.50
192.168.5.0/24 dev eth0 proto kernel scope link src 192.168.5.50
192.168.5.208/28 dev mac1 scope link
root@NAS723:~# ping 192.168.5.210
PING 192.168.5.210 (192.168.5.210) 56(84) bytes of data.
64 bytes from 192.168.5.210: icmp_seq=1 ttl=64 time=0.025 ms
64 bytes from 192.168.5.210: icmp_seq=2 ttl=64 time=0.036 ms

Vergesst diese Lösung!
Ping klappt zwar wunderbar, nur antwortet hier (vermutlich) nicht der Container, sonder das mac1 Ding. Http geht nicht zum Container durch. Muss noch einmal über die Bücher. Sorry!!!!

 

[haydibe]

Ich wollte lokal auch auf K8s bzw. um genau zu sein auf k3s setzen, aber leider habe ich zu Hause nicht den Storage als HA Lösung. Dann hätte ich immer noch nur einen Single Point of Failure und deshalb hab ich erstmal gelassen

Hier gibt es solide OpenSource Lösungen wie Longhorn, OpenEBS, LINSTOR (via Piraeus Operator). Privat könnte man auch das freie Portworx Essentials verwenden. War mir persönlich zu umständlich, und der Ressourcenverbrauch war Dank etlicher Satelliten-Dienste nicht ganz ohne.

Ich verwendende im Homeland RKE2 mit Longhorn. Langt für das was ich tue.

 

[haydibe]

Ping klappt zwar wunderbar, nur antwortet hier (vermutlich) nicht der Container, sonder das mac1 Ding. Http geht nicht zum Container durch. Muss noch einmal über die Bücher. Sorry!!!!

Kann ich nicht nachvollziehen. Zeig doch mal wie du testest.

Wenn eine Container nur an einem MACVLAN Netzwerk hängt, dann ist der Container-Port schon der finale Port an der MACVLAN-IP. Den kann man dann nur ändern, wenn das Image es über Variablen vorgesehen hat, oder eine entsprechende Anwendungs-Konfiguration in den Container gemountet wird.

 

[JohneDoe]

es solide OpenSource Lösungen wie Longhorn

Das wollte ich einsetzen, aber hab mir dann gedacht, dass mir ein Node als storage auch nichts bringt bei HA. Wenn der down ist, dann sind auch alle Container down. Da bringt mir die HA durch k3s auch nichts. Und extra Hardware dafür anschaffen war es mir nicht wert.

RKE2 kenne ich noch nicht. Muss ich mir mal angucken. Vielleicht probier ich es noch mal alles aufzusetzen. Aber das dauert noch bis ich dafür Zeit habe

 

[haydibe]

Mit einem einzelnen Node bringt es tatsächlich nichts. Es ist aber trotzdem angenehmer mit Longhorn als Default StorageClass zu arbeiten, als mit binds via hostPath.

Was dann noch zusätzlich sinnvoll wäre sowas wie K8sup für PV Backups zu verwenden, oder gleich Velero, um die Manfieste des Clusters, der Namespaces, einzelnen Ressourcen und/oder nur PVs zu sichern. Afaik ist bei beiden das einfachste, wenn man S3 als Storage verwendet. Wenn man sowas online nicht hat, kann man sowas auch als Container auf dem NAS betreiben. Das ist dann zwar nicht HA, aber zumindest mit wenig Aufwand sicher und wiederherstellbar.

RKE2 ist quasi der gehärtete Bruder von K3S. Mir hatte das damals besser gefallen, weil es wie upstream Kubernetes direkt etcd mitbringt. Ich weiß nicht, ob es heute noch so ist, damals wurden nur Datenbanken als Cluster Datastore unterstützt.

Ich verwende Pulumi um die VMs auf Proxmox hochzuziehen und eine Ansible Galaxy Rolle, um den RKE2 Cluster zu installieren und aktualisieren. Aktuell auch noch Ansible um die Grundinstallation vom Cluster durchzuführen. Zuhause habe ich aber auch noch kein Renovate am laufen... wenn es sich damit nicht verträgt, muss ich die Grundinstallation auf irgendwas migrieren, dass durch Renovate aktuell gehalten werden kann. Es macht einfach keinen Spass händisch Chart Versionen und/oder Image Tags anpassen zu müssen...

Wir sollten diese Diskussion glaube ich besser als PM fortführen -> sind schon sehr Off-Topic.