Neuigkeiten von trion.
Immer gut informiert.

Artikel in der Kategorie 'kubernetes'

Docker Images ohne Dämon bauen mit Kaniko 3 Nov

Geschrieben von Thomas Kruse am 3. November 2018
Kaniko

Kubernetes nutzt Container Images im OCI- oder Docker-Format, um Workload im Cluster zu verteilen und auszuführen. Möchte man - zum Beispiel im Rahmen eines CI-Builds - in einem Kubernetes-Cluster auch Docker-Images bauen, gibt es im wesentlichen drei Ansätze:

  1. Verwendung des außenliegenden Docker-Daemons

  2. Verwendung eines Docker-Daemons in einem Container (Docker-in-Docker)

  3. Verwendung eines alternativen Build Werkzeugs

Den Docker-Daemon, der im Cluster selbst Container bereitstellt, in einem Build-Container zu verwenden bringt vor allem den Nachteil mit sich, dass der Build die Stabilität der Cluster-Node beeinträchtigen kann. Zudem ist nicht gesagt, dass überhaupt ein Docker-Daemon bereitsteht, schließlich könnte der Kubernetes-Cluster auch CRI-O als Runtime verwenden. Diese Option scheidet somit in der Regel aus.

Docker-in-Docker (DinD) ist eine häufig gewählte Option, verlangt jedoch, dass der entsprechende Container priviligiert gestartet wird. Aus Sicherheitsaspekten ist diese Option zwar nicht optimal, lässt sich jedoch in der Praxis gut einsetzen. Das gilt selbst dann, wenn die Container-Engine des Clusters gar kein Docker verwendet.

Als letzte Optionen bleibt noch die Verwendung spezialisierter Werkzeuge zur Erstellung von Container-Images. In diesem Beitrag wurde die Verwendung von Buildah beschrieben, in Spring Boot mit Jib die Verwendung von Jib.

Jib ist speziell auf Java-Anwendungen ausgerichtet, buildah benötigt zum Bauen von Images root-Berechtigungen - beide Werkzeuge bringen damit gewisse Einschränkungen mit.

Von Google kommt das Werkzeug Kaniko, das in diesem Beitrag vorgestellt wird, und speziell für den Einsatz in Kubernetes konzipiert wurde.

Kubernetes Upgrade auf ARM mit CRI-O und Arch Linux 26 Okt

Geschrieben von Thomas Kruse am 26. Oktober 2018
Kubernetes

In diesem Beitrag wurde die Installation von Kubernetes auf ODROID unter Arch Linux ARM beschrieben. Nachdem Kubernetes 1.12 veröffentlich wurde, ist es an der Zeit, sich auch mit dem Thema Kubernetes Update zu beschäftigen.

Das grundsätzliche Vorgehen bei einem Upgrade von Kubernetes erfolgt in mehreren Schritten:

  1. Update der Kubernetes Binaries auf den Master Nodes (Control Plane)

  2. Update der Kubernetes Pods auf den Master Nodes

  3. Aktualisierung der Worker Nodes auf die neuesten Kubernetes Binaries

Kubernetes Upgrades werden jeweils zwischen Minor Versionen supported, d.h. ein Update von 1.10 zu 1.12 muss über den Zwischenschritt eines Updates auf Kubernetes 1.11 erfolgen. Das konkrete Vorgehen hängt von dem gewählten Verfahren zur Kubernetes Einrichtung ab. Da der Beispiel-Cluster mit kubeadm eingerichtet wurde, wird auch das Update von Kubernetes mit kubeadm upgrade durchgeführt.

Docker Multi-Arch-Image 6 Sep

Geschrieben von Thomas Kruse am 6. September 2018
Docker

Docker-Images sind plattformabhängig: Während früher Docker ausschließlich unter Linux auf x86 Plattformen ein Thema war, kamen mit der ARM-Architektur und Windows-Containern zusätzliche Varianten hinzu. Die einzige Option, das jeweils richtige Image für die Plattform auszuwählen, war dann, mit Image Tags zu arbeiten, sofern von einem Projekt überhaupt mehrere Architekturen unterstützt wurden und nicht ein ganz anderes Repository genutzt werden musste. Tags sind eindimensional und es gibt ggf. weitere Image-Varianten zu berücksichtigen. Darum hat jedes Projekt eine eigene Namenskonvention erstellt, beispielsweise gibt es dann foo/mariadb:amd64, foo/mariadb:arm, foo/mariadb:alpine-amd64 und foo/mariadb:alpine-arm. Damit werden die zu verwendenen Image-Namen plattformabhängig und können nicht übergreifend verwendet werden, z.B. in Kubernetes-Deploymentmanifests.

Das Problem wurde erkannt und Docker hat in mehreren Schritten den "Multi-Architecture-Support" implementiert.

Docker-Registry in Kubernetes Raspberry PI 28 Aug

Geschrieben von Thomas Kruse am 28. August 2018
Kubernetes

Wie ein Docker-Image für die Docker-Registry für ARM 64, z.B. für Raspberry PI oder ODROID C2, erzeugt wird, wurde im letzten Artikel beschrieben: Cross-Build von Docker Image Registry für ARM 64. Nun geht es darum, mit diesem Image in Kubernetes eine Docker-Registry aufzubauen, um damit Container-Images im Cluster zur Verfügung zu stellen.

Für die TLS-Absicherung sorgt traefik, der in Kubernetes als Ingress fungiert und von Let’s Encrypt SSL-Zertifikate ausstellen läßt. (Die Einrichtung von traefik als Kubernetes-Ingress kann hier nachgelesen werden: Traefik als Kubernetes Ingress. )

Docker-Registry auf ARM 64 - Cross-Compiling Docker-Images 24 Aug

Geschrieben von Thomas Kruse am 24. August 2018
Docker

Bisher gibt es die offizielle Docker Registry lediglich als x86 Docker Image. Damit ist ein Betrieb unter ARM oder ARM 64 aktuell nicht möglich. Obwohl Docker Multi-Arch-Support eingeführt hat, also die Möglichkeit unter dem selben Image-Namen verschiedene Architekturen zu bedienen, ist das bei dem hauseigenen Image leider noch nicht umgesetzt worden. In diesem Beitrag geht es nun darum, ein passendes Image durch Cross-Compilation zu erstellen und damit eine Registry bereit zu stellen.

Der Betrieb des mit Docker erstellen Image wird unter CRI-O erfolgen, womit die Interoperabilität, dank der Standardisierung von OCI, unter Beweis gestellt wird.

Kubernetes Ingress mit traefik 20 Aug

Geschrieben von Thomas Kruse am 20. August 2018
Kubernetes

Um auf Kubernetes-Dienste zuzugreifen gibt es mehrere Möglichkeiten, eine davon ist der Ingress. Ingress eignet sich für HTTP basierte Dienste und kann Funktionalitäten wie TLS-Terminierung und Load-Balancing übernehmen. Im Prinzip handelt es sich bei Ingress also um so etwas wie einen Reverse-Proxy.

Kubernetes bringt dabei keine Ingress-Implementierung mit, sondern es gibt diverse Optionen von nginx über HA-Proxy und Apache Trafficserver bis zu traefik. Wie traefik als Kubernetes-Ingress-Implementierung eingesetzt werden kann, wird in diesem Beitrag vorgestellt.

Kubernetes Rook Storage auf ARM 64 11 Aug

Geschrieben von Thomas Kruse am 11. August 2018
Kubernetes

In einer Public-Cloud-Umgebung wird dauerhafter Speicher für Kubernetes in der Regel durch den jeweiligen Cloud-Provider bereitgestellt. Bedarf an dauerhaften Speicher gibt es dabei regelmäßig, wenn Daten nicht in den jeweiligen Datenbanken oder Messaging-Systemen der Umgebung gehalten wird, sondern lokale.

Wird der Kubernetes Cluster sogar lokal betrieben, gibt es entsprechnd keinen Cloud-Provider, der Storage in Form von Object-Store oder Block-Storage zur Verfügung stellen könnte. Neben NFS und iSCSI, mit denen klassische SAN-Systeme angebunden werden können, wächst auch das Angebot an Cloud-Native-Storage. Dabei handelt es sich um Softwarelösungen, die flexibel und dynamisch Speicher im gesamten Kubernetes Cluster zur Verfügung stellen können.

In diesem Beitrag wird der Einsatz von Rook (https://www.rook.io) auf einem ARM 64 Cluster mit ODROID C2 Knoten demonstriert.

Kubernetes Dashboard auf ARM 64 3 Aug

Geschrieben von Thomas Kruse am 3. August 2018
Kubernetes

Kubernetes bietet eine Weboberfläche zur Clusterverwaltung bzw. Administration: Das sogenannte Kubernetes Dashboard. Das Dashboard gibt es als vorbereitetes Deployment für die Architekturen AMD/Intel 64 und ARM. Leider gibt es derzeit kein fertiges ARM 64 Deployment. Wer das reguläre ARM Deployment ausprobiert, wird zwar die zugehörigen Resourcen erfolgreich erzeugen, jedoch wird der Container nicht erfolgreich starten und in der Folge wird der Pod-Status mit einem der Fehler Error oder CrashLoopBackOff ausgegeben.

Fehlerhaftes Kubernetes Dashboard Deployment auf ARM 64
$ kubectl get pods --all-namespaces
NAMESPACE     NAME                        READY  STATUS              RESTARTS
kube-system   kubernetes-dashboard-7d597  0/1    ContainerCreating   0
kube-system   kubernetes-dashboard-7d597  0/1    Error               0
kube-system   kubernetes-dashboard-7d597  0/1    CrashLoopBackOff    1

Kubernetes auf ODROID Arch Linux ARM Mainline Kernel 1 Aug

Geschrieben von Thomas Kruse am 1. August 2018
Arch Linux

Das Setup von Kubernetes mit Arch Linux ARM 64bit auf einem ODROID C2 wurde im vorherigen Beitrag zu Kubernetes gezeigt. Als Overlay-Network wurde Weave verwendet, was leider im Zusammenspiel mit dem ODROID C2 Linux Kernel zu Abstürzen durch eine Kernel Panic führen kann. Die zugehörige Issue findet sich hier: https://github.com/weaveworks/weave/issues/3314

Eine Lösung ist, auf den "Fast Data Path" zu verzichten, was zur Folge hat, dass die Performance sich verringert und die CPU Belastung steigt. Alternativ kann der ODROID C2 mit einem aktuellen Linux Kernel, dem Mainline (oder Upstream) Linux Kernel verwendet werden.

CRI-O Kubernetes Worker Setup auf Arch Linux ARM 29 Jul

Geschrieben von Thomas Kruse am 29. Juli 2018
CRI-O

Nachdem im vorherigen Beitrag zu Kubernetes gezeigt wurde, wie mittels CRI-O ein Kubernetes Master Node eingerichtet wird, folgt nun eine Worker Node. Das besondere auch hier: Es wird Arch Linux auf ARM 64bit Architektur verwendet.

Für das Setup wird kubeadm verwendet, daher wird auch die Ausgabe von einem Kubernetes-Master Setup benötigt, da dort das erforderliche Token ausgeben wird.

Beispiel für kubeadm Setup Ausgabe auf Kubernetes Master Node
You can now join any number of machines by running the following on each node
as root:

  kubeadm join 10.23.15.110:6443 --token nnnxv2.2p7n2zwuddqedg25 --discovery-token-ca-cert-hash sha256:7563bc0dcf826a37e96f820725147a61d9970a094e1428832283f803aad91cd3

Kubernetes mit CRI-O auf Arch Linux ARM 28 Jul

Geschrieben von Thomas Kruse am 28. Juli 2018
CRI-O

Auch wenn Docker stand heute die vermutlich am weitesten verbreitete Container-Lösung darstellt, gibt es doch einen regen Wettbewerb. Besonders seit Kubernetes in Version 1.5 das Container-Runtime-Interface (CRI) eingeführt hat, mit dem sich die tatsächliche Container-Implementierung austauschen lässt. Das CRI-O Projekt stellt einen Adapter zwischen der durch die OCI (Open Container Initiative) spezifizierten Schnittstellen für Container-Runtimes und dem durch Kubernetes mit CRI definierten Integrationspunkten dar. Standardmäßig verwendet CRI-O die OCI konforme Containerimplementierung runc.

Andere OCI kompatible Laufzeitumgebungen wie rkt oder Intel Clear Container lassen sich damit ebenfalls einsetzen. In einem typischen Docker basierten Setup sähe die Interaktion so aus:

  • Der kubelet Prozess verwaltet die Container der Node, nutzt dabei die CRI Schnittstelle zur Kommunikation

  • mit dem dockershim, einer CRI-zu-Docker API Bridge, die ihrerseits

  • mit dem eigentlichen docker-Daemon kommuniziert, der dann

  • mit dem containerd-Daemon kommuniziert und darüber

  • runc aufruft, um konkrete Container zu managen

Mit CRI-O sieht die Interaktion so aus:

  • Der kubelet Prozess verwaltet die Container der Node, nutzt dabei die CRI Schnittstelle zur Kommunikation

  • mit dem CRI-O-Daemon, der dann eine OCI kompatible Container-Laufzeitumgebung aufruft, im Default ist das

  • die runc, die auch Docker verwendet

Der Stack bei CRI-O ist also deutlich geringer, ist jedoch als auf Kubernetes fokussierter Stack auch kein vollständiger Ersatz für die vielen verschiedenen Anwendungsfälle von Docker.

Im folgenden geht es um das konkrete Setup von CRI-O mit Kubernetes unter Arch Linux ARM.

Kubernetes auf Arch Linux ARM 24 Jul

Geschrieben von Thomas Kruse am 24. Juli 2018
Kubernetes

Auch wenn Arch Linux meist topaktuelle Pakete hat, so ist dies bei Projekten wie Kubernetes auf der ARM Architektur nicht der Fall. Auch im AUR, also dem von der Community gepflegten Bereich, finden sich für ARM 64 bit keine Kubernetes Pakete. Es ist jedoch relativ einfach, sich auf Basis des Quellcodes von Kubernetes einen eigenen Build zu erzeugen. Damit sind sowohl für ARM 32bit als auch ARM 64bit eigene Arch Linux Kubernetes Pakete in überschaubarer Zeit und mit nur wenigen Handgriffen gebaut.

Wie das geht, wird im folgenden Beitrag erklärt.

Los geht's!

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