Zum Inhalt

Kubernetes Einstieg

Diese Site wurde erstellt als Grundlage für eine grobe Unterweisung von Kollegen zum Thema Kubernetes und Deployments in entsprechenden Umgebungen.

Es wird hier nicht im Einzelnen auf den Aufbau eines Clusters eingegangen, sondern es soll hierbei vor allem um den Umgang und Betriebs einer Kubernetes Plattform gehen.

Somit wird hier mit Kubernetes Umgebungen aus der Rancher-Familie (von SuSE ) gearbeitet:

  • K3s für Single Systeme (und Raspberry PI)
  • RKE2 für Cluster (ggf. mit CIS-Härtung)

zu vermittelnde Inhalte

Zunächst sollen die grundlegenden Komponenten in einer Kubernetes Umgebung beschrieben werden.

Danach sollten die Layer innerhalb einer Kubernetes Umgebung dargestellt werden.

Ebenso in Folge die Manifeste zu einem Deployment und die ggf. benötigten Teile hierzu. Dazu auch Möglichkeiten für fortlaufende Deployments und entsprechende Wartungen.

Das Arbeiten mit Pods und Möglichkeiten zu Fehleranalyse.

Warum Kubernetes

Was soll mit dem Umbau auf Kubernetes erreicht werden, bzw. welche Möglichkeiten eröffnen sich damit? Diese Frage sollte man für jede dafür angedachte Komponente klären, denn es macht nicht immer Sinn alles auf diese Basis umzubauen.

Es gibt Applikationen / Services, bei denen gewisse Anforderungen gegeben seien müssen, die nicht unbedingt in einer Kubernetes Umgebung umgesetzt werden können. Als Beispiel wäre ein DHCPd Service nicht sinnig umzusetzen und sollte besser weiterhin native bleiben.

Andererseits kann jede Applikation, die "nach Außen"1 hin via HTTP oder stateless wie bsplw. eine REST-API, aber auch Mail-Dienste wie SMTP, IMAP und/oder POP3 oder gar ein Proxy in einer Kubernetes Umgebung umgesetzt werden.

Innerhalb einer Organisation (eines LANs - also On-Prem oder gar Off-Prem) kann der Betrieb einer Container Umgebung wie Kubernetes einen Vorteil bei der Wartung der darunterliegenden Systemen bedeuten. Gerade wenn es darum geht kontinuierlich die Systeme auf Stand zu halten kann hierdurch eine logische Abtrennung zwischen dem eigentlichen System und der darauf liegenden Applikation erreicht werden. Denn alle geforderten Abhängigkeiten wie benötigte Libraries oder anderer zu installierenden Komponenten können (bzw. sollten) in dem Container "vereint" werden und müssen nicht im System selbst installiert werden. Es reicht somit ein minimales Basis-System, das maximal nur mit den für die Container-Plattform benötigten Komponenten ausgestattet wird - dieses ist recht einfach auf Stand zu halten und es müssen nicht ständig die applikationsbedingten Abhängigkeiten berücksichtigt werden.

Ein weiterer Nebeneffekt ist, dass es dadurch auch möglich wird verschiedene Applikationen mit unterschiedlichen Abhängigkeiten (auch zwar gleiche Komponenten, aber in verschiedenen Versionen) auf den Systemen parallel zu betrieben. Somit muss nicht speziell für jede entsprechende Abhängigkeit ein eigenes System aufgebaut werden. Dadurch zeigt sich dann auch eine Möglichkeit die Auslastung der Systeme besser ausnutzen zu können. Es wird dadurch nicht mehr für jede Anforderung ein eigenes spezialisiertes System benötigt, sondern es beschränkt sich im Gesamten auf die Anzahl der Worker-Nodes in der Kubernetes Umgebung. Nur wenn es sich dann zeigt, dass alle Nodes ausgelastet sind muss ein weiterer Node dazu genommen werden. (Wer sich zu dem Thema weiter informiert dürfte auch schnell Möglichkeiten finden den Prozess zur Skalierung zu automatisieren - dies aber auch zumeist in Abhängigkeit der darunter liegenden Bereitstellungsplattform für die Systeme selbst, weswegen dies hier nicht behandelt wird.)

Innerhalb einer Kubernetes Umgebung kann dann auch für eine Applikation / eines Services die Anzahl der Pods (und darin enthaltenen Container) flexibel skaliert werden um erhöhte Last-Anforderungen dynamisch gerecht zu werden - hierzu gibt es auch Autoscaling Funktionen.

Liste von Aspekten für Kubernetes

Kurz zusammengefasst kann man im groben folgende Punkte für den Einsatz einer Kubernetes Umgebung (auch im eigenen LAN) anführen:

  • logische Abtrennung der System-Ebene zu Applikation und/oder Service
    • keine direkten Abhängigkeiten zwischen Applikationen / Services und dem Systemen durch weitere zu installierenden Komponenten
    • somit bessere, bzw. unabhängigere Planbarkeit und Ausführung von Patch-Zyklen der Systeme selbst
  • bessere Auslastung der Systeme
    • keine Vielzahl an spezialisierten Systeme mehr, sondern nur noch standardisierte Nodes
    • Anzahl der benötigten Nodes wird durch die Gesamtauslastung aller Applikationen im Cluster bestimmt
  • flexible Skalierung bei Lastspitzen möglich
    • eine Erhöhung der Pod-Anzahl ist jederzeit möglich um Lastspitzen schnell entgegnen zu können
  • ein Service-Discovery ist bereits Bestandteil einer Kubernetes Umgebung
    • eine in sich innerhalb eines Namespaces geschlossene Applikation mit all seinen Services kann dadurch inklusiver seiner Konfigurationen selbst innerhalb eines Clusters dupliziert werden
    • Namespace übergreifend können aber auch Services bereitgestellt werden unabhängig der dahinter stehenden Pod-Anzahl
  • Reproduzierbarkeit der gesamten Umgebung
    • im Notfall kann die gesamte Umgebung reproduziert werden da alles in Manifesten (und somit Code) vorliegen sollte (Deployment-as-Code auch als Bestandteil von CI/CD)
    • wenn alle Manifeste und Deployments der gesamten Umgebung bsplw. in einem Git gepflegt werden ist auch eine Revisionssicherheit für ein Audit gewährleistet

Es gibt auch noch einige Security-Aspekte, auf die aber separat zu einem anderen Zeitpunkt eingegangen wird.

Warum Rancher

Dies hat vor allem einen pragmatischen Hintergrund - einerseits ist der Aufwand für den Betrieb der System-Komponenten sehr überschaubar, andererseits kann im gewerblichen Enterprise Umfeld direkt vom Hersteller entsprechende Support-Möglichkeiten in Anspruch genommen (bzw. "eingekauft") werden. Auch beim Thema Sicherheit und Härtung gibt es hier interessante Aspekte und Unterstützungen.

Es soll mit dieser Entscheidung eine Kubernetes-Plattform betrieben werden können, die mit einfachsten Mitteln standardisiert umgesetzt werden kann. Ein weiterer Aspekt liegt dabei auch weitsichtig gedacht bei einem späteren hybriden Betrieb oder der Bereitstellung unter anderem bei public Service Providern, da es gerade auch hier breite Unterstützung dafür gibt.

Falls es sich aber dennoch zeigen sollte, dass die Anforderungen an eine Kubernetes-Umgebung recht speziell werden sollten, so wird man nicht umher kommen in Eigenregie diese spezialisierte Umgebung aufzubauen. Man sollte sich aber bewusst sein, dass dann auch der Wartungsaufwand schnell sehr stark ansteigt.

  1. "nach Außen" bedeutet in dem Fall das Ansprechen eines Services von außerhalb der Kubernetes Umgebung, oder generell eines Services / einer Applikation als komplette Einheit, die von einem Client entsprechend angesprochen wird. ↩