Neuigkeiten von trion.
Immer gut informiert.

Artikel in der Kategorie 'kubernetes'

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.

Kaniko ARM Image 1 Feb

Geschrieben von Thomas Kruse am 1. Februar 2019
Kaniko

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.

Kubernetes TLS Zertifikate 29 Jan

Geschrieben von Thomas Kruse am 29. Januar 2019
Kubernetes

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.

Kubernetes continuous Integration (CI) 26 Jan

Geschrieben von Thomas Kruse am 26. Januar 2019
Kubernetes

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.

Kubernetes 1.13 auf ARM mit CRI-O und Arch Linux 14 Dez

Geschrieben von Thomas Kruse am 14. Dezember 2018
Kubernetes

In diesem Beitrag wurde die Installation von Kubernetes auf ODROID unter Arch Linux ARM beschrieben.

Hier geht es nun um das Update auf Kubernetes 1.13, auch in diesem Fall mit selbst übersetzten Paketen für Arch Linux. Bei anderen Distributionen sind ggf. bereits die Upstream Pakete verfügbar.

Wie schon in Kubernetes Upgrade Arch Linux ARM im Detail beschrieben, wird das Update in folgenden Schritten durchgeführt:

  1. Update der Container Runtime (falls erforderlich)

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

  3. Update der Kubernetes Pods auf den Master Nodes

  4. Aktualisierung der Kubernetes Binaries auf den Worker Nodes

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.

Los geht's!

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