Im vorherigen Artikel PostgreSQL in Kubernetes und OpenShift wurden die Grundlagen zum Betrieb von PostgreSQL in Containern und Kubernetes vorgestellt.
Für eine einzelne Umgebung funktioniert das Verfahren soweit ganz gut. Wenn jedoch verschiedene Varianten, z.B. für mehrere Umgebungen, bereitgestellt werden sollen, steigt der Aufwand und auch das Risiko von Configuration Drift. Helm tritt an, um dabei Abhilfe zu schaffen.

Galt vor einigen Jahren noch das Motto, dass Datenbanken besser außerhalb von (Docker-)Containern oder gar eines Kubernetes Clusters betrieben werden sollten, so hat sich das Bild inzwischen stark gewandelt. Nicht nur, dass sich Kubernetes als das neue Betriebssystem von Rechenzentren und der Cloud etabliert hat, es gibt sogar unmittelbare Vorteile bei der Integration von Plattformdiensten mit Kubernetes.
Welche grundsätzlichen Optionen es gibt, und wie das Vorgehen aussehen kann, beleuchtet dieser Beitrag.

Ursprünglich war Docker konzipiert als Eierlegendewollmilchsau Probleme rund um den Betrieb von Software in der Cloud zu lösen.
Dazu gehören verschiedene Aspekte von Bereitstellung der Software als Image bis hin zur Laufzeitumgebung mit Persistenz. Im Kontext von Kubernes kann es zu Überschneidungen kommen, die sich in unangenehmen Überraschungen äußern. Worauf es zu achten gilt, wenn Docker VOLUMEs und Kubernetes im Spiel sind - zum Beispiel bei Datenbanken - wird in diesem Beitrag vorgestellt.

Nachdem DockerHub die automatischen Builds von Docker Images nicht mehr kostenlos für jeden anbietet, bieten sich GitHub Actions als eine praktische Alternative an. ( Die Umsetzung von Multi-Arch Builds mit DockerHub wurde in dem Beitrag Docker Multi Arch Images mit DockerHub behandelt.)
In diesem Beitrag wird eine Umsetzung von Multi-Arch Images am Beispiel das Angular-CLI Docker Images vorgestellt.

In vielen Kundenprojekten ist der Wunsch zu beobachten, von klassisch betriebenen Anwendungen sofort in die Cloud oder zumindest nach Kubernetes zu migrieren. Vielleicht schwingt dabei der Wunsch mit, Zeit zu sparen, indem Zwischenschritte ausgelassen werden. Oder man ist sich sehr wohl bewußt, dass man in Gewissen Bereichen versäumt hat, Know-How aufzubauen und in Modernisierung zu investieren.

Wir empfehlen regelmäßig zumindest kleine Zwischenschritte einzuplanen, um Erfahrungen mit der Erstellung aber auch dem Design von Anwendungen für Container- und Cloudumgebungen zu sammeln. Das gilt um so mehr, wenn das Unternehmen sich nicht ganze Teams, die sich nur um Infrastruktur und Support kümmern können, leisten möchte.

Eine gute Möglichkeit zum Start stellt der Einsatz von Docker Containern ohne automatischen Orchestrator wie Kubernetes, Mesos oder Docker-Swarm dar. Dabei wählt man typischerweise eine Anwendung aus, die nicht absolut essentiell ist, und optimalerweise bereits von einem Team mit modernen Technologien und vor allem Mindset entwickelt und betreut wird.

Mit verhältnismäßig wenig Infrastruktur können dann auch bereits Patterns aus der Cloud-Welt verprobt werden und entsprechende Erfahrungen mit den notwendigen Umsystemen und Prozessen gewonnen werden. Wichtig ist dabei, dass man den Schwenk auf fertige Lösungen vornimmt, und nicht mit eigenen Mitteln Dinge nachbaut und wartet, die ein Orchestrator mitliefert.

Hat man sich für traefik als Reverseproxy und Loadbalancer entschieden, um Container verfügbar zu machen, kann man bereits von vielen Vorzügen profitieren.

Ein Kunde wünschte sich Canary-Deployments auszuprobieren, und das allein mit traefik. Wie so ein Canary oder A/B Deployment mit traefik umgesetzt werden kann, zeigt der folgende Beitrag.

Bei Drone CI handelt es sich um einen OpenSource continuous integration (CI) Server. Dabei setzt Drone CI auf die Ausführung des Builds mittels Containern. Typischerweise werden dabei Docker oder Kubernetes als Container Plattform eingesetzt.

Eine Buildpipeline wird in YAML definiert, dabei können sowohl services definiert werden, die im Build verwendet werden, als auch persistente volumes und natürlich die Buildabläufe als steps.

Single Board Computer (SBC) wie der Raspberry Pi oder die ODROID-Serie eignen sich sehr gut als stromsparende und hinreichend performante Maschinen für Container-Hosting mit Docker oder Kubernetes.
In dem Artikel "Kubernetes auf Odroid N2" wurde die Einrichtung von Kubernetes auf ODROID N2 mit Arch Linux ARM beschrieben.
Der von Hardkernel, dem Hersteller der ODROIDs, bereitgestellte Kernel basiert auf einem alten Stand und wurde durch zusätzliche Treiber und Patches für den ODROID N2 kompatibel gemacht.
Leider bringt der verwendete Kernel einige Nachteile mit sich: So gibt es zum Teil Abstürze und Instabilitäten. Der Prometheus Node-Exporter führt zu einem sofortigen Absturz, so dass an Metrikmonitoring gar nicht zu denken ist. (Hier scheint das Problem in der dynamischen Taktung zu liegen cpufreq_cpu_get, taucht im Stacktrace stets auf.)

Abhilfe schafft der sogenannte Mainline-Kernel. Das ist ein nicht gepatchter Kernel und kann seit Linux 5.5 prinzipiell verwendet werden, da die Unterstützung der verwendeten Hardwarekomponenten des ODROID N2 in diesem enthalten ist.

Bereits in diesem Beitrag zu Docker Multi-Arch Images wurden die Grundlagen erläutert, wie Docker-Images dank Manifest automatisch passend für die jeweilige Plattform ausgewählt werden.

Doch die Erstellung solcher multiplen Images und der zugehörigen Manifest-Dateien ist mit dem automatischen Build auf Docker Hub nicht so intuitiv umsetzbar, wie bei regulären Images. Eine Lösung kann da ein eigener Buildserver inkl. Build-Agents für die zu unterstützenden Plattformen darstellen.

Dieser Beitrag erklärt, wie unter Verwendung von QEMU zur Cross-Compilation und den DockerHub Build Hooks entsprechende Docker-Images und das Manifest vollautomatisch erzeugt und publiziert werden können. (Hintergründe zum Cross Build von Docker Images finden sich hier: Docker Multi-Arch Images )

Update: In diesem Artikel wird ein ähnliches Verfahren, jedoch mit GitHub Actions vorgestellt: Multi Arch Images mit GitHub Actions.

Von Rancher Labs stammt eine abgespeckte Version von Kubernetes mit dem Namen k3s. Kubernetes wird oft als k8s abgekürzt, so dass eine reduzierte Version passenderweise als k3s bezeichnet werden kann.

Das Ziel von k3s ist, eine Kubernetes Umgebung anbieten zu können, wenn begrenzte Resourcen in der Betriebsumgebung den Einsatz einer regulären Kubernetes Installation erschweren oder unmöglich machen.

Im Gegensatz zum vollen Kubernetes Stack benötigt k3s kein etcd als Datenspeicher, sondern setzt auf SQLite. Hier macht sich die Architektur von Kubernetes natürlich besonders bezahlt: Da lediglich der Kubernetes API Server auf die Persistenz zugreifen darf, merken alle weiteren Komponenten von der Umstellung nichts. Um weiteren Hauptspeicher zu sparen wurden auch viele Controller Manager entfernt, die in der Zielumgebung jedoch sowieso nicht sinnvoll zum Einsatz kommen würden.

Im folgenden schauen wir uns an, wie mit Docker und k3s ein Kubernetes Cluster als Docker Container aufgesetzt werden kann. Das ist besonders praktisch, wenn es darum geht, Tests zu machen oder mit Kubernetes zu entwickeln. So spart man sich Minikube oder einen Testcluster.
Übringens arbeitet man auch bei Kubernetes selbst daran, Docker als Umgebung nutzen zu können: Das kind-Projekt (Kubernetes in Docker) verfolgt einen vergleichbaren Ansatz: https://kind.sigs.k8s.io/

Natürlich kann k3s auch ganz ohne Docker eingesetzt werden und ist sogar der Regelfall, denn k3s soll z.B. in Kombination mit Raspberry Pi und vergleichbaren Single Board Computer (SBC) gut verwendet werden können.
Mehr zu k3s gibt es auf der offiziellen Homepage: https://k3s.io/

Kubernetes bietet mit seiner erweiterbaren API eine sehr einfache Möglichkeit zusätzliches Verhalten mit Kubernetes zu integrieren. Neben der API-Spezifikation als OpenAPI (ehemals Swagger) stellt das Kubernetes-Projekt auch fertige Clients für verschiedene Programmiersprachen an. Eine besondere Rolle nimmt der Kubernetes Go-Client ein, da dieser auch innerhalb von Kubernetes selbst eingesetzt wird.

Auf Basis der OpenAPI-Spezifikation stehen generierte Clients für Java, Python, C# und JavaScript. Zu den offiziellen Kubernetes-Clients kommen noch durch die Community erstellte und gepflegte Libraries für diverse Sprachen hinzu.

Im Folgenden wird demonstriert, wie die Kubernets-API mit Java verwendet werden kann. Wie der dazu benötigte lesende API-Zugriff eingerichtet werden kann, wurde bereits in Kubernetes Readonly API Zugriff erklärt.