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.

Kubernetes ist durch seine erweiterbare API etwas besonderes: Auf der einen Seite werden für die Clusterverwaltung benötigte Objekte durch die Kubernetes-API bereitgestellt und erlauben damit, beliebige Programme in die Clusterverwaltung einzubeziehen. Zum anderen können beliebige Anwendungen und Produkte die Kubernetes-API um eigene Funktionalität erweitern und damit auf einheitliche, herstellerunabhängige Weise bereitgestellt werden.

Auch - oder gerade - innerhalb eines Kubernetes Clusters kann ein API Zugriff sinnvoll sein. Kubernetes stellt den API-Server daher standardmäßig als Service kubernetes im default Namespace zur Verfügung.
Im Folgenden wird gezeigt, wie die API verwendet werden kann, und wie ein spezieller Serviceaccount angelegt wird, der lediglich Leserechte für die Kubernetes-API besitzt.

The ODROID-N2 is an amazing single board computer: It is available with 4GB RAM - and with an eMMC card for high speed storage and a power supply it costs less than 100 Euros. With 4+2 ARM64 CPU cores the ODROID-N2 provides an interesting platform to operate a small Kubernetes cluster without too much worrying about the power bill.

This article explains how to setup Kubernetes on ODROID-N2 single board computers. Since there are several options for operating system as well as Kubernetes distribution and setup method, this article makes the following decisions:

Unfortunately there is no mainline Linux Kernel support for the ODROID-N2, but Hardkernel promised to work on it. The following features are currently not working as desired:

Previous experiences with Arch Linux ARM 64bit and Kubernetes on Raspberry Pi and ODROID (ODROID-C2 to be precise) can be found here:

In Kubernetes sind Features in unterschiedlichen Reifegraden enthalten. Einige Features sind im Stadium beta oder auch bereits stabil. Diese Features sind automatisch aktiviert und allgemein nutzbar. Anders ist dies bei den Features im Stadium alpha, diese müssen explizit durch den Administrator aktiviert werden.
Je nach Kubernetes-Version ist die Menge der verfügbaren und automatisch aktivierten Features unterschiedlich.

Die vorhergehenden Beiträge befassten sich mit dem TTL Controller Feature als Beispiel für Admission Controller:

Passend dazu wird nun gezeigt, wie das Feature des TTL-Controllers im Kubernetes-Cluster aktiviert werden kann.

Nachdem das Konzept von Kubernetes Admission Controllern in dem Beitrag Kubernetes Admission Controller beschrieben wurde und in Beispiel für Admission Controller gezeigt wurde, wie ein Admission Controller Webhook implementiert werden kann, geht es nun darum, diesen in Betrieb zu nehmen.

Der Webhook an sich kann sowohl in dem selben Kubernetes-Cluster betrieben werden, in dem er auch verwendet wird, als auch völlig unabhängig von Kubernetes.
Damit Kubernetes bei einem so mächtigen Element sicherstellen kann, dass mit dem korrekten Webhook kommuniziert wird, muss die Verbindung TLS gesichert sein und Kubernetes dem Zertifikat vertrauen. Für den Aufbau der Trust-Chain werden entweder die vom zugrundeliegenden Betriebssystem bereitgestellten CA-Zertifikate verwendet, oder es kann in der Webhook Konfiguration explizit ein CA Zertifikat angegeben werden. Um das Beispiel möglichst vollständig nachvollziehbar zu gestalten, wird mit Hilfe der internen Certificate Authority von Kubernetes ein Zertifikat erstellt, wie in diesem Artikel beschrieben: Verwendung von Kubernetes Zertifikaten.

Wird der Webhook in Kubernetes betrieben, so muss vorher natürlich ein Container-Image gebaut werden und für das Image ein Deployment samt entsprechendem Service in Kubernetes angelegt werden.

Im vorherigen Beitrag zu Kubernetes Admission Controller wurde beschrieben, wie das Konzept eines Admission Controllers in Kubernetes allgemein funktioniert. Anhand eines in Python geschriebenen Mutating Admission Controller wird im folgenden gezeigt, wie einfach ein Admission Controller implementiert werden kann.

Als Beispiel soll dazu ein Anwendungsfall aus der Kubernetes-Praxis dienen: Wenn Kubernetes-(Batch-)Jobs erfolgreich beendet wurden, sollen die zugehörigen Job-Objekte in der Regel entfernt werden. Das verschafft auf der einen Seite einen besseren Überblick, zum anderen wird unnötiger Overhead auf der Control Plane vermieden.
Dazu bietet Kubernetes auch ein Feature: Den TTL-Controller für Resourcen im Zustand finished. Aktuell ist dazu das Feature Gate TTLAfterFinished für den Controller-Manager und den API-Server in Kubernetes zu aktivieren. Anschließend prüft der TTL Controller bei Job Resourcen, ob das Property .spec.ttlSecondsAfterFinished gesetzt ist. Dann werden Jobs, die entweder completed oder failed sind durch den Controller nach Ablauf der entsprechenden Zeit entfernt.

Doch nicht immer werden Kubernetes-Job-Objekte bereits mit einem Wert für das ttlSecondsAfterFinished Attribut versehen. Um genau das sicherzustellen, soll nun ein entsprechender Mutating Admission Controller entwickelt werden.