Work in Progress

Kubernetes: Der erste Kontakt

Kubernetes ist sehr viel mehr, als nur Container. Eine sorgfältige Auswahl der Plattform ist maßgeblich für den Erfolg des Projektes. Die Installation von Kubernetes ist aufgrund ihrer Komplexität auf mehreren Seiten beschrieben. Zum Vorgehen wird diese Reihenfolge empfohlen:

1. Erstellung eines VLANs für Kubernetes auf den Switches für die Nodes.
2. Aufbau eines Storage LAN, ggf. Infiniband.
3. Installation und Konfiguration von OPNsense für DHCP und Haproxy.
4. Installation einer minimalen Linux Distribution auf allen Servern, die als Node laufen sollen.
5. Installation erste Control Plane.
6. Installation Netzwerklösung für Kubernetes, z.B. Weave oder Calico.
7. Installation weiterer Control Planes, es werden für einen Cluster mindestens 3 Control-Planes benötigt.
8. Installation Worker, die Anzahl richtet sich nach der benötigten Leistung. Es können praktisch beliebig viele Worker installiert werden.
9. Have Fun!

Version

Die Beiträge dieser und der folgenden Seiten zu Kubernetes beziehen sich auf die Version v1.25+

Überlegungen zur Architektur

Man kann man sehr schön Kubernetes Controller und Worker bauen, aber ohne eine weitere Infrastruktur bringt das nicht sehr viel. Die Backends für Kubernetes müssen alle redundant ausgeführt werden, sonst bringt Kubernetes mit seiner Redundanz nichts.

Legacy

Die grüne Wiese hat man selten, meist gibt es irgendwelche Altlasten (z.B. Windows Server), die auch noch laufen sollen. Die alte Perimeter Infrastruktur hat also noch lange nicht ausgedient und ist immer noch gut als weitere Verteidigungslinie geeignet. Container sind selbst stateless, dennoch müssen irgendwo Daten noch persistent gespeichert werden. Zwischen Kubernetes Netz und der restlichen Welt ist eine Firewall sinnvoll, damit es einen single Point of Contact gibt und auch im K-Fall schneller reagieren kann.

Firewall

Zwischen der alten Welt und Kubernetes sollte auf jeden Fall eine Firewall laufen, alleine schon deswegen, damit man an einer zentralen Stelle suchen und eingreifen kann, falls etwas passiert ist.

SQL Datenbank

Eine Datenbank sollte klassisch aufgebaut werden, da die Platzhirsche MariaDB und Postgres verteilt noch nicht so optimal funktionieren. Im Falle von Postgres sollten für die Authentifizierung X.509 Client Zertifikate verwendet werden. Weiterhin sollten die Tabellen verschlüsselt werden im SInn von Shit happens. Wenn man der Datenbank noch die freie Wahl hat, dann sollte man sich Apache Ignite ansehen.

Storage

Ceph ist das passende Gegenstück von Kubernetes für persistente Objekte, sofern diese nicht in die SQL Datenbank sollen. Notfalls geht auch NFS4, allerdings kann das schnell zum Flaschenhals werden, wenn man mehrere hundert Worker Nodes mit einigen tausend Containern hat von denen einige persistente Files benötigen. Für erste Gehversuche mit Kubernetes ist NFS4 aber ok.

PKI

Kubernetes hat zwar seine eigene PKI, diese sollte aber ausschließlich nur für Kubernetes verwendet werden. Für die Authentifizierung von Anwendungen/Services untereinander sollte eine eigene PKI Lösung aufgebaut werden.

Sicherheit

Das Kubernetes Netz sollte über eine leistungsfähige Firewall vom Rest des Legacy Netzes getrennt sein. Die Firewall sollte zumindest Rulesets enthalten, die folgende Zugriffe von und nach außen regelt:

• Zugriffe auf die Control Planes
• Zugriffe nach außen aus dem Kubernetes Netz (hier ist insbeondere das Logging interessant)

Mandantenfähigkeit

Kubernetes ist von Hause aus nicht mandantenfähig. Es gibt jedoch Module, mit denen das möglich ist.

Dazu meine Meinung: Es ist keine gute Idee, Kubernetes in diese Richtung zu vergewaltigen, denn innerhalb von Kubernetes hat ein ein weitgehend offenes Netzwerk. Einschränkungen in der Kommunikation sind zwar über Namespaces und Policies möglich, aber schon ein kleiner Fehler ermöglicht unerwünschte Kommunikationsbeziehungen. Innerhalb eines Mandanten ist das zwar eine Schwachstelle, muss aber nicht gleich eskalieren. Wenn dagegen interne Services unterschiedlicher Kunden Kontakt haben, dann kann so etwas fatal sein.

Mandanten sollte über getrennte Kubernetes Instanzen implementiert werden. Mit Kubernetes Nodes auf virtuellen Maschinen ist das leicht möglich, wenn sich die VMs in unterschiedlichen V(x)LANs befinden, dann ist das Risiko deutlich geringer.

Anleitungen

Für Kubernetes entstehen Anleitungen für die einzelnen Aspekte von Kubernetes