Geschrieben von Thomas Kruse
am 24. Juli 2018
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.
Geschrieben von Thomas Kruse
am 23. Juli 2018
Im Artikel Kubernetes Cluster mit Raspberry Pi wurde ein Cluster-Setup mit Raspberry Pi Computern gezeigt.
Als Alternative dazu bieten ODROID-C2 Maschinen doppelt so viel RAM und auch etwas mehr CPU Leistung.
Viel wichtiger ist dabei jedoch die deutlich bessere Netzwerkanbindung mit 1Gbit, die auch tatsächlich erreicht werden.
Der ODROID unterstützt schnellen eMMC Speicher und UHS-1 SDR50 MicroSD, der preislich deutlich günstiger als die eMMC Module sind.
Der ODROID besitzt als Hauptspeicher DDR3 SDRAM Module, die rund doppelt so hoch getaktet sind, wie die LPDDR2 des Raspberry Pi 3.
Preislich liegt ein Raspberry Pi 3 bei ca. 36 Euro und ein ODROID C2 bei 58 Euro - je nach Einsatzzweck ist das Preis-Leistungsverhältnis bei dem ODROID deutlich besser.
Die ARMv8 Architektur des ODROID C2 wird von Arch Linux und Ubuntu Cloud als 32 und 64 bit Variante unterstützt, Raspian gibt es bisher lediglich als 32 bit Variante.
Ein Nachteil beim 64bit Betrieb ist der etwas höhere Speicherbedarf.
Zwar hat der ODROID mit 2GB RAM doppelt so viel Speicher wie der Raspberry Pi, doch für den Betrieb vieler Container kann man nie genug Speicher haben.
Hier kann man nun von einem Trick profitieren, der in ähnlicher Form bereits auch von Apple standardmässig eingesetzt wird, um Nutzern auch mit relativ wenig Speicher ein gutes Gesamterlebnis zu bieten.
Geschrieben von Thomas Kruse
am 13. Juli 2018
Ein Mini-Cluster für Kubernetes eignet sich hervorragend für Experimente und zum Training.
Wie beispielsweise in Kubernetes Cluster mit Raspberry Pi erklärt, eignen sich für einen kostengünstigen Start Raspberry Pi Minicomputer ausgezeichnet.
Leider ist ARM aktuell nicht im Fokus der diversen Cloud-Native Storage Lösungen, so dass sich als Alternative ein externes Volume anbietet.
Das häufig anzutreffende Synology NAS bietet NFS Support.
Wie sich dies mit Kubernetes einsetzen lässt, wird im folgenden illustriert.
Geschrieben von Thomas Kruse
am 6. Juli 2018
Sowohl für Trainings als auch eigene Experimente ist ein physischer Cluster oft anschaulicher, als virtuelle Maschinen.
Als preiswerter Einstieg bieten sich bereits seit geraumer Zeit die Raspberry Pi Minicomputer an.
Für rund 40 Euro pro Gerät erhält man einen Rechner mit 1 Gb RAM und vier ARM Kernen.
Dazu wird noch eine USB Stromversorgung und MicroSD Speicherkarten benötigt, und schon kann es los gehen.
Geschrieben von Thomas Kruse
am 29. Juni 2018
Im Markt der Serverless-Ansätze positioniert sich Oracle mit Project Fn.
Dieser Beitrag demonstriert den Einsatz des Fn Project um mittels Docker oder Kubernetes Function-As-A-Service (FaaS) bzw. Serverless Architekturen umzusetzen.
Als Demo wird eine Java Anwendung mit Project Fn als Docker-Container erstellt und im Fn Server betrieben.
Geschrieben von Thomas Kruse
am 22. Juni 2018
Docker ist die führende Umsetzung von Linux Containern - kein Wunder, hat Docker die Idee von Containern als leichtgewichtige Alternative zu Virtualisierung erst populär gemacht.
Inzwischen hat sich das Ökosystem deutlich weiterentwickelt.
Google hat mit dem Kubernetes Projekt den defacto Standard für Scheduling und Verwaltung von Containern und zugehörigen Resourcen geschaffen.
Neben Docker existieren mit rkt (CoreOS) und CRI-O (Open Container Initiative) weitere Container Runtimes für das mittlerweile gesetzte OCI Image Format.
Relativ neu dabei sind die Werkzeuge buildah zum Bauen von Containern und podman zur Ausführung mittels CRI-O (beide von Project Atomic, RedHat).
Warum entstehen unterschiedliche Runtimes und Build-Toolchains?
Welche Vorteil für Nutzer im Kontext von Docker oder Kubernetes ergeben sich daraus?
Geschrieben von Thomas Kruse
am 8. Juni 2018
Der Trend weg von großen, schwerfälligen Applikationsservern hin zu Microservices und Containern wird durch die Cloud als Ablaufumgebung stark beschleunigt.
Konsequent weitergedacht erhält man noch kleinere Dienste, Nanoservices, die lediglich einzelne Funktionen umsetzen.
Als minimale Deploymenteinheit lässt sich darüber eine feingranulare Skalierung erzielen, und durch verringerten Overhead eine kosteneffiziente Nutzung der Infrastruktur realisieren.
Vorreiter war Amazon mit Lambda, doch auch andere Cloud Anbieter zogen schnell nach, und bieten Function-as-a-Service (FaaS) oder "serverless" Umgebungen an.
Kubernetes als De-facto-Standard für containerbasierte Cloudinfrastruktur bietet von Haus aus zwar kein vergleichbares Modell an, jedoch gibt es mit Oracle Fn, Kubeless und Open Whisk zahlreiche Projekte, die FaaS als OpenSource Plattform für den Einsatz in eigener Cloudinfrastruktur oder auch öffentlichen Kubernetes Cloud-Runtimes ermöglichen wollen.
Im folgenden wird ein kurzer Blick auf Kubeless in Kombination mit Java geworfen.
Ausschlaggebend für diese Auswahl war ein relativ unkompliziertes Setup, wodurch die Hemmschwelle für Experimente verringert wird.