Es ist bei nahezu allen Containerdiensten immer das selbe: irgendwann kommt man an den Punkt, dass man sich Persistenz wünscht. Meist ist bei all den DevOps Gedanken dann doch der Admin an der Reihe sich eine Lösung auszudenken. Doch die Sache mit dem Speicher ist heikel. Richtig gut (z.B. CEPH) kostet meist Geld (weil Hardware kaufen) und lohnt sich erst bei größeren Installationen. Einfach (z.B. GlusterFS) ist dann auch nicht so das gelbe vom Ei, wenn man nicht genügend Speicher zur Hand hat und ist dann auch nicht sooo toll, wenn man es etwas schneller braucht (zum Beispiel weil man es auf den Minions betreibt).
Natürlich gibt es auch noch ein paar andere Möglichkeiten (eigentlich nicht). Die wirklich einfachste die man auch meist irgendwie direkt zur Hand hat ist dabei allerdings NFS. Von Hause aus kann man zwar mit Kubernetes NFS PVs (Persistent Volumes) bereitstellen. Das ist dann aber Handarbeit. Wer sich die Arbeit von einem Provisioner abnehmen lassen möchte, dem empfehle ich dieses Projekt aus dem inkubator.
https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client Mittels Helm ist es schnell installiert, Aufgrund der zu erledigenden Aufgabe auch nicht sonderlich komplex und für die meisten Bereiche sicherlich ausreichend bis gut.
Wenn ich ein Thema ziemlich zweifelhaft finde, dann ist es Cloudcomputing. Ich kann verstehen wann und warum man das macht. Was mir aber nicht gelingt ist den wandel von "VServer" zu "CloudInstanz" zu akzeptieren - immerhin habe ich "damals" mehr für weniger einsatz bekommen.
Wie dem auch sei. Ich mag Proxmox als Möglichkeit seine Virtualisierung zu realisieren. Man könnte ja auf die Idee kommen, dass man das auch auf seinem Root-Server bei zum Beispiel Hetzner haben möchte. Lustiger Weise wird das sogar angeboten. Was dann leider noch zu tun ist, ist die Absicherung und vor allem aber die Einrichtung von virtuellen Netzwerken, damit man seine Infrastruktur auch fein separieren kann.
In meinem Setup mache ich das mit einfachen Linux-Bridges. Wer es nocht etwas "cooler" haben will, dem kann ich einen Cluster mit OpenVswitch empfehlen. Das kommt vielleicht ein anderes Mal.
Mein Ziel ist, das es eine Bridge gibt, an die ich bestimmten Traffic (in meinem Fall HTTP/HTTPS) weiterleite um dort mit Hilfe von zum Beispiel OpenSense einen Reversproxy mit SSL Offloading anzubieten. So kann ich dann "hinter" dieser Firewall beliebig viele "virtuelle Netzwerke" aufbauen und routen/regeln wie man es von einer "richtigen" Installation kennt.
Dazu richte ich mir zunächst eine Bridge ein die auch eine IP-Adresse bekommt und sorge dafür dass beim hochfahren auch gleich die notwendigen iptables Regeln gesetzt werden um zum einen das NAT für den ausgehenden Traffic zu realisieren. auch will ich, wie schon oben beschrieben, das eingehender Traffic auf Port 80 und 443 zur OpenSense Installation weitergereicht wird, die mit der Bridge verbunden ist.
/etc/network/interfaces
auto vmbr0
iface vmbr0 inet static
address 10.11.12.1
netmask 255.255.255.0
bridge-ports none
bridge-stp off
bridge-fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '10.11.12.0/24' -o ***NAME-SER-NETZWERKKARTE*** -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '10.11.12.0/24' -o ***NAME-SER-NETZWERKKARTE*** -j MASQUERADE
post-up iptables -t nat -A PREROUTING -i ***NAME-SER-NETZWERKKARTE*** -p tcp --dport 80 -j DNAT --to 10.11.12.2:80
post-up iptables -A FORWARD -j ACCEPT -p tcp --dport 80 -d 10.10.99.2
post-up iptables -t nat -A PREROUTING -i ***NAME-SER-NETZWERKKARTE*** -p tcp --dport 443 -j DNAT --to 10.11.12.2:443
post-up iptables -A FORWARD -j ACCEPT -p tcp --dport 443 -d 10.11.12.2Anschließend richte ich einfach weitere Bridges ein, die ich dann verwende um private LAN innerhalb des Proxmox bereitzustellen.
auto vmbr1
iface vmbr1 inet manual
bridge-ports none
bridge-stp off
bridge-fd 0Anschließend können die neuen Bridges wie folgt aktiviert werden:
ifup vmbr0
ifup vmbr1Manchmal ist es notwendig, dass man den sicheren Hafen verlässt und auf das große weite Meer segelt. So brauche ich hin und wieder einen aktuellen Mainstream-Kernel auf einem perse eher konservativen System wie CentOS.
Das ist in wenigen Schritten erledigt und erfordert auch nur einen Neustart hust.
yum -y install https://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
yum -y --enablerepo=elrepo-kernel install kernel-ml
yum -y --enablerepo=elrepo-kernel install kernel-ml-{devel,headers,perf}
sed -i 's/GRUB_DEFAULT=save/GRUB_DEFAULT=0/g' /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg
rebootWarum macht macht das? Zum Beispiel, weil man die LSB konformität von CentOS schätzt und auch die langen Supportzeiten des Systems als solches zu würdigen weiss, gleichzeitig aber herausfinden will/muss ob zum Beispiel Kubernetes sich anders verhält, wenn es einen aktuellen Kernel unter der Haube hat.
Quellen und Hinweise: