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.

Kubernetes ist flexibel um neue Funktionalität erweiterbar: Dabei gibt es neben CRDs (Custom Resource Definitions), mit denen die Kubernetes API um neue Typen und Operationen erweitert wird, auch Admission Controller. Admission Controller können dazu dienen, bestimmte Vorgaben einzuhalten. Beispielsweise, dass stets Ressourcen-Limits und -Requests spezifiziert werden. Wird dann ein Objekt angelegt, bei dem die Vorgaben nicht eingehalten werden, kann die Erzeugung abgelehnt werden.

Um das Konzept der Admission Controller zu veranschaulichen werden in einer kleinen Artikelserie die Grundlagen und die Umsetzung eines Beispiel-Mutating Admission Controllers mit Python vorgestelt.

In dem Beitrag zu Kubernetes Continuous Integration wurde am Beispiel von Drone CI gezeigt, wie Builds in einem Kubernetes Cluster umgesetzt werden können. Nun ist es oft der Wunsch von Kunden wie Entwicklern, möglichst schnell auf den aktuellen Stand auch zugreifen zu können. Dies Verfahren wird auch Continuous Deployment genannt, da stets der aktuelle Entwicklungsstand zur Nutzung bereit steht.

Dieser Beitrag zeigt daher auf, wie mit Kubernetes und Drone ein solches Deployment umgesetzt werden könnte. Damit das Setup nicht zu komplex wird, wird lediglich der aktuelle master-Branch in Kubernetes deployt.

Im vorherigen Beitrag wurde erklärt, wie die Kubernetes Certificate Authority über die Kubernetes API angesprochen werden kann. Innerhalb des Kubernetes Clusters wird über die CA eine Vertrauensbeziehung etabliert - doch wie sieht es mit externen Zugriffen aus?
Nicht alles geschieht rein innerhalb des Clusters. Ein offensichtliches Beispiel ist der Betrieb einer (Docker) Container Registry innerhalb von Kubernetes. Das grundsätzliche Setup wurde in dem Beitrag Docker Registry in Kubernetes erläutert.

Da die Registry von der jeweiligen Container-Runtime angesprochen wird, geschieht dies regelmäßig direkt von einer Node und erfolgt damit nicht durch Kubernetes. Damit muss die Node über die passenden CA Zertifikate verfügen, sonst erhält man die Fehlermeldung, dass das X509 Zertifikat nicht validiert werden konnte. Nun geht es also darum, das CA Zertifikat von Kubernetes auf die einzelnen Nodes zu verteilen.

Damit Kaniko mit einer eigenen Registry verwendet werden kann, die TLS Zertifikate von einer eigenen Certificate Authority (CA) verwendet, wird ein eigenes Kaniko Container-Image benötigt. Wenn darin die passenden Zertifikate enthalten sind, kann Kaniko auf die Registry ohne Probleme zugreifen.

Dieses Beispiel baut auf dem vorherigen Beitrag auf und verwendet daher schon ein spezielles Kaniko Image für ARM Maschinen.

Kaniko ist in Version 1.0 erschienen, damit ist es Zeit, sich das Werkzeug genauer anzusehen. Bereits in Mit Kaniko Docker Images ohne Daemon bauen und Mit Kaniko Docker Images in Kubernetes bauen wurde Kaniko vorgestellt. Auch wenn sich Kaniko weiterentwickelt hat - so braucht man keine root-Rechte mehr, um ein Image zu bauen - so gibt es leider noch kein ARM oder ARM64 Image.

In diesem Beitrag geht es also darum, wie auf Basis eines existierenden Dockerfile ein Build in Kubernetes durchgeführt werden kann. Dabei wird der Docker-in-Docker Ansatz gewählt, womit auch bei einer anderen Container-Runtime wie rkt oder CRI-O keine Probleme auftreten.

Zertifikate spielen in einem Kubernetes Cluster eine wichtige Rolle: Durch Zertifikate wird eine Vertrauensbeziehung ausgedrückt.
Vor allem bei einer statischen Beziehung zwischen Services lässt sich eine Authentifizierung durch TLS Zertifikate sehr effizient ausdrücken.

Kubernetes bringt daher auch typischerweise eine eigene Certificate Authority (CA) mit, die als Trust-Root für alle im Kubernetes Cluster verwendeten Zertifikate dienen kann.
Eine eigene CA kann, je nach verwendeten Verfahren zur Cluster Einrichtung, ebenfalls verwendet werden, oder es können intermediate-CA Zertifikate eingesetzt werden. Standard ist jedoch dass jeder Kubernetes Cluster über eine eigene CA verfügt.

Wie man mit dieser CA interagieren kann wird in diesem Beitrag erklärt.

In diesem Kubernetes Beitrag geht es darum, eine CI Pipeline auf Kubernetes Infrastruktur aufzusetzen. Wie bereits in den vorherigen Kubernetes Beiträgen soll auch hier ein Augenmerk auf dem Support der ARM Plattform gelegt werden. Leider trotz der zunehmenden Verbreitung von ARM im Serverumfeld noch immer nicht selbstverständlich, dass Multi-Arch Images bereitgestellt werden.