Neuigkeiten von trion.
Immer gut informiert.

Artikel in der Kategorie 'kubernetes'

DockerHub Multi-Arch Image als Autobuild 14 Okt

Geschrieben von Thomas Kruse am 14. Oktober 2019
Docker

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 )

Kubernetes in Docker mit k3s 28 Aug

Geschrieben von Thomas Kruse am 28. August 2019
Kubernetes

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 API mit Java anbinden 28 Mai

Geschrieben von Thomas Kruse am 28. Mai 2019
Kubernetes

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 Read-Only API Zugriff 18 Mai

Geschrieben von Thomas Kruse am 18. Mai 2019
Kubernetes

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.

Kubernetes on ODROID-N2 6 Mai

Geschrieben von Thomas Kruse am 6. Mai 2019
Kubernetes

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:

  • Use Arch Linux ARM64 as base operating system (this is quite lean and kept very much up to date)

  • Vanilla Kubernetes will be used, compiled and packaged as Arch ARM64 packages on the ODROID N2

  • Plain kubeadm will be used to setup the Kubernetes cluster

  • CRI-O as container runtime (instead of Docker)

  • Single master node and 4 worker nodes

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:

  • zram for compressed memory as swap device

  • Disable GPU memory allocation to make use of the full 2GB/4GB of the ODROID-N2

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

Kubernetes Feature Gates konfigurieren 3 Mai

Geschrieben von Thomas Kruse am 3. Mai 2019
Kubernetes

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.

Konfiguration von Kubernetes Admission Controller 2 Mai

Geschrieben von Thomas Kruse am 2. Mai 2019
Kubernetes

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.

Beispiel für einen Kubernetes Mutating Admission Controller 25 Apr

Geschrieben von Thomas Kruse am 25. April 2019
Kubernetes

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 Mutating Admission Controller 22 Apr

Geschrieben von Thomas Kruse am 22. April 2019
Kubernetes

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.

Kubernetes Deployment mit CI Server 23 Feb

Geschrieben von Thomas Kruse am 23. Februar 2019
Kubernetes

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.

Kubernetes Zertifikate verwenden 3 Feb

Geschrieben von Thomas Kruse am 3. Februar 2019
Kubernetes

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.

Kaniko mit Custom CA Certificates 2 Feb

Geschrieben von Thomas Kruse am 2. Februar 2019
Kaniko

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.

Los geht's!

Bitte teilen Sie uns mit, wie wir Sie am besten erreichen können.