NETWAYS Blog

Graylog Release Version 5.2 ist da! HURRA!

by Daniel Neuberger | Nov 3, 2023 | Technology, Graylog, Logging & Security

Diese Woche wurde Graylog 5.2 veröffentlicht. Natürlich gibt es auch in diesem Release wieder Abstufungen für Open, Operations und Security.

Da wir nicht auf alles eingehen können, möchte ich hier auf die hervorzuhebenden Neuerungen und Änderungen eingehen. Ein vollständiges Changelog zum Release findet sich hier. Im Folgenden wollen wir auf zwei bemerkenswerte neue Features bzw. Änderungen im Detail eingehen.

HOT New Feature in Graylog OPEN/OPERATIONS/SECURITY: Pipeline Rule Builder UI

Der neue Pipeline Rule Builder UI ist wohl die auffälligste Neuerung und daher möchte ich darauf näher eingehen.

Das neue Pipeline Rule UI ist für all diejenigen hilfreich, die sich mit dem Schreiben von Pipeline Rule Code nicht auskennen oder sich noch nicht mit Pipeline Processing beschäftigt haben und daher Extraktoren am Input verwendet haben. Das neue UI (UserInterface) bringt hier eine ähnliche Handhabung wie bei den Extractoren. Die Extraktoren sind schon lange auf dem Weg aus dem Graylog heraus und sind und waren nie ein Weg für dynamische Verarbeitung.

Da dieses Menü bisher noch keine Erklärung gefunden hat, habe ich ein kurzes Video dazu gemacht. Vielleicht hilft das ja dem ein oder anderen von euch dies als Dokumentation zum verstehen.

Ausgangslage für das Video:

TCP RAW Input auf Port 5114 mit statischem Feld “demo” und dem Wert true
rsyslog Daemon der im JSON Format sendet
Pipeline und Stream für die Daten vorkonfiguriert.

Breaking Change in Graylog Security: lluminate Bundle

Dies sollte beachtet werden:

Die Verarbeitung von IP-Adressen zu Geo-IP-Informationen wurde aus dem Illuminate Bundle entfernt und benötigt nun den globalen “Geoip Resolver Processor”. Daher muss dieser aktiviert werden und dem “Illuminate Processor” folgen. Dabei braucht ihr keine Angst haben, dass jetzt mehr Ressourcen verbraucht werden. Mittlerweile kann der Processor unterscheiden zwischen reserved und public IP. Zu dem könnt ihr ein “Enforce default Graylog schema” aktivieren, dies sorgt dafür das nur Felder aufgelöst werden welche dem GIM entsprechen. Das sind folgende Felder:

destination_ip
destination_nat_ip
event_observer_ip
host_ip
network_forwarded_ip
source_ip
source_nat_ip

Bedeutet aber auch das ihr diese Felder selbst auch bei anderen Applikation welche nicht im ILLUMINATE vorhanden sind entsprechend erzeugen müsst.

Wenn “Enforce default Graylog schema” nicht aktiviert ist wird jedes Feld mit einer nicht reservierten IP-Addresse übersetzt.

Hierzu folgend die Einstellung für die Processor-Plugins welche notwendig sind:

Graylog Processor configuration order and activation

Dazu muss dann entsprechend auch der Geo-IP Processor konfiguriert sein und die entsprechenden Informationsdatenbanken zum Beispiel von Maxmind auf allen Servern abgelegt sein.

Alle weiteren Neuerungen und Änderungen in Graylog ILLUMINATE findet ihr hier.

Wir wünschen euch viel Spaß beim aktualisieren und Arbeiten mit den Neuerungen. Wenn ihr nicht weiter weißt oder Hilfe beim aktualisieren benötigt wir von NETWAYS Professional Services helfen euch gerne dabei. Meldet euch einfach bei unseren Sales TEAM!

Daniel Neuberger

Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

Read more from Daniel and meet the Team

Do Servers Dream of Electric Sadness?

by Tim Albert | Aug 1, 2023 | Technology

Als Systemadministrator ist man oft mit einer Vielzahl von Fehlermeldungen konfrontiert, die manchmal klar verständlich, manchmal mehrdeutig und manchmal völlig nichtssagend sein können. Wichtig ist hierbei, sich nicht von der Meldung in der Herangehensweise an den Fehler beeinflussen zu lassen und somit von vornherein auf dem Holzweg unterwegs zu sein.

Zwei Hosts down, oder nur redis und mysql?

In diesem Blogbeitrag werden wir die Bedeutung eines methodischen Denkens und eines gut ausgestatteten Werkzeugkastens für Systemadministratoren erkunden.

Kenne Deine Umgebung:

Für die korrekte Interpretation ist es nicht nur wichtig, seine Umgebung zu kennen, sondern auch zu wissen, welche Werkzeuge in dem persönlichen Werkzeugkasten vorhanden sind. Sieht der Fehler nach Schraube aus, ich halte allerdings einen Hammer in der Hand, wird der Fehler gerne als Nagel interpretiert.Beides hält ja irgendwie Dinge zusammen und mit ausreichend Ausdauer, bekommt auch ein Hammer mit einer Schraube eine Verbindung zustande. Die Schraubverbindung mit einem Hammer zu lösen ist hier allerdings schon wieder eine andere Geschichte.

Aufbau Deines Werkzeugkastens:

Der Werkzeugkasten eines Systemadministrators baut sich über viele Jahre Erfahrung zusammen, kann aber auch durch realitätsnahe Übungen erweitert werden, was dann auch eine gewaltige Zeitersparnis beim Lösungsweg mit sich bringt. Ein sehr sympathischer Ansatz ist der Advent of Code mit dem Fokus auf programmatischen Lösungen, um so auch eventuell eine neue Sprache näher zu beleuchten.

Realitätsnahe Herausforderungen:

Mit realitätsnahen Herausforderungen auf AWS-Root Servern locken dagegen die traurigen Server auf https://sadservers.com. In derzeit 20 unterschiedlichen Szenarien darf man, falls nötig auch mit Tipps, eine definierte Aufgabe via bash lösen. Während der Beginn und die Zeitvorgaben entspannt anfangen, wird es je nach Kenntnisstand ziemlich schnell ziemlich fordernd. Einen ersten Einblick bietet auch das zugehörige GitHub Repository

Austausch und Schulungen:

Wer danach oder währenddessen Interesse daran hat, den Werkzeugkasten über einen Monat hin weiter zu befüllen, sollte einen Blick auf https://linuxupskillchallenge.com/ riskieren. Auch Personen, die schon Jahrzehnte im Geschäft sind, erfahren bei solchen Challenges nicht nur neues, sondern auch der Austausch mit Gleichgesinnten hilft hierbei enorm. Wem das alles zu digital ist, findet vielleicht in unseren Schulungen und Events nicht nur sich selbst eher wieder, sondern auch mehr Gleichgesinnte.

Ein gut ausgestatteter Werkzeugkasten und ein methodischer Ansatz sind entscheidend für den Erfolg eines Systemadministrators. Indem Du Deine Umgebung kennst, Deine Werkzeuge verstehst und durch praktische Übungen und Herausforderungen Dein Wissen erweiterst, wirst Du in der Lage sein, Fehler effektiv zu lösen und die Herausforderungen Deines Berufs zu meistern!

Tim Albert

Senior Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...

Read more from Tim and meet the Team

NETWAYS RAID-Rechner

by Johannes Rauh | Jul 21, 2023 | Development, Ausbildung, Technology

In einer zunehmend digitalen Welt, in der Hochverfügbarkeit und Datensicherheit von größter Bedeutung sind, wird die Implementierung von RAID-Systemen immer wichtiger. Die für deinen Use Case passende Konfiguration eines RAID-Systems spielt deshalb eine nicht zu vernachlässigende Rolle.

Um die passende Konfiguration zu finden, gibt es zwei populäre Ansätze:

Berechnen, wie viel nutzbarer Speicher am Ende tatsächlich zur Verfügung steht
Bestimmen, wie viel Speicherplatz benötigt wird und auf diesem Wert die Anzahl der dafür benötigten Festplatten berechnen

Damit du diese Berechnungen nicht selbstständig durchführen musst, habe ich im Rahmen meiner Ausbildung zum Fachinformatiker für Anwendungsentwicklung einen RAID-Rechner entwickelt.

Dieser ergänzt unseren Rechner-Stack, zu dem bereits die beliebten Subnetz– und SLA-Rechner gehören.

Was ist eigentlich RAID?

RAID steht für “Redundant Array of Independent Disks” und ist eine Technologie zur Datenredundanz und Leistungssteigerung in Speichersystemen. Dabei werden mehrere physische Festplatten zu einem logischen Verbund zusammengefasst.

Um die vielfältigen Anforderungen an moderne IT-Infrastrukturen und Datenspeicherung bestmöglich abzubilden, gibt es mehrere RAID-Level mit unterschiedlichen Eigenschaften. In meinem NETWAYS RAID-Rechner werden folgende RAID-Level verwendet:

RAID 0: Daten werden auf mehrere Festplatten verteilt, um die Leistung zu verbessern
RAID 1: Daten werden auf mehreren Festplatten synchron gehalten, um höhere Datensicherheit zu gewährleisten
RAID 5: Daten und Paritätsinformationen werden auf mehrere Festplatten verteilt
RAID 6: Ähnlich wie RAID 5, allerdings mit doppelter Parität
RAID 10: Kombination aus RAID 0 und 1, die Daten werden sowohl verteilt als auch gespiegelt gespeichert

Funktionalität des RAID-Rechners

Der RAID-Rechner, den ich entwickelt habe, ist eine einfache Anwendung, die es dir ermöglicht, die in der Einleitung genannten Ansätze zu verfolgen.
Du kannst den nutzbaren Speicher anhand folgender Parameter berechnen:

RAID-Level
Anzahl der Festplatten
Kapazität pro Festplatte

Ein zusätzliches Feature meines Rechners ist, dass du dir den Preis pro nutzbarem GB anzeigen lassen kannst. Vorausgesetzt, du hast den Preis deiner Festplatten angegeben (oder eine Vorstellung, wie teuer sie sein sollen).

Alternativ kannst du die Anzahl der benötigten Festplatten berechnen, indem du den gewünschten nutzbaren Speicherplatz, die Kapazität pro Festplatte und den RAID-Level angibst.

Zur Auswahl stehen dir die gängigen RAID-Level 0, 1, 5, 6 und 10. Zu jedem Level gibt es zudem eine kurze Erklärung und eine Empfehlung, in welchen Fällen es Verwendung finden könnte. Zusätzlich kannst du die Speichereinheiten verschiedene Währungen frei auswählen.

Um zwischen den beiden einzelnen Rechnern zu wechseln, habe ich mich entschieden, eine HTML-Checkbox mit CSS so zu stylen, dass sie wie ein umlegbarer Schalter aussieht.

Wenn du nun Lust darauf bekommen hast, den NETWAYS RAID-Rechner selbst auszuprobieren, kannst du das hier machen. Ich wünsche dir viel Spaß beim Testen, Herumspielen und produktiven Einsetzen meiner Anwendung.

Johannes Rauh

Junior Developer

Johannes hat bevor er zu NETWAYS gekommen ist eine Ausbildung zum technischen Assistenten für Informatik abgeschlossen. 2022 startete er bei Icinga seine Ausbildung zum Fachinformatiker für Anwendungsentwicklung, um seinem Interesse für das Programmieren und der Softwareentwicklung weiter nachzugehen und sein Wissen zu vertiefen. Nach der Arbeit geht er regelmäßig ins Fitnessstudio oder verbringt Abende mit einem Cocktail und seiner Freundin vor Netflix.

Read more from Johannes and meet the Team

Hochverfügbarkeit bei Datenbanken, wofür ist das gut?

by Valeria Thiele | Apr 21, 2023 | NETWAYS, Datenbanken

Hallo, ich bin Valeria, Junior-Developerin bei NETWAYS und habe mich lange damit beschäftigt, über welches Thema ich in meinem nächsten Blogpost schreiben soll. Vor Kurzem habe ich an einer MySQL-Schulung von NETWAYS teilgenommen und mich anschließend mit dem Thema der Hochverfügbarkeit bei Datenbanken in einem Projekt auseinandergesetzt. Da ich das Thema sehr interessant fand, möchte ich nun mein Wissen gerne mit Euch teilen.

Was bedeutet Hochverfügbarkeit?
Warum ist es so wichtig, Daten permanent abrufen zu können?
Wie kann man Hochverfügbarkeit gewährleisten?
Welche Varianten gibt es?
Fazit

Was bedeutet Hochverfügbarkeit?

In einer Welt, in der Daten für Unternehmen immer wichtiger werden, ist es entscheidend, dass diese Daten immer verfügbar sind. Abhilfe schafft hier Hochverfügbarkeit oder auch HADR (High Availability and Disaster Recovery). Datenbanken sind demnach so eingerichtet, dass sie selbst bei einem Ausfall eines Servers oder einer anderen kritischen Komponente, unabhängig von äußeren Einflüssen wie Hardwareausfällen, Netzwerkausfällen oder Stromausfällen, weiterhin verfügbar sind.

Warum ist es so wichtig, Daten permanent abrufen zu können?

Es gibt einige Bereiche, in denen Hochverfügbarkeit von Daten nicht mehr wegzudenken ist. Stell Dir vor, Du betreibst eine große E-Commerce-Plattform, welche für ein paar Stunden nicht abrufbar ist. Was passiert?

Der fehlende Zugriff auf Unternehmensdaten kann einen massiven Umsatzverlust bedeuten. Wenn ein Kunde nicht auf seine Kundendaten zugreifen kann, kann er keine Bestellungen aufgeben, wodurch potenzielle Einnahmen verloren gehen.

Dies führt in der Regel auch zu einer sinkenden Kundenzufriedenheit und/oder möglicherweise sogar zu Kundenverlusten. Wenn ein Unternehmen nicht in der Lage ist, seinen Kunden einen effektiven und reibungslosen Service zu bieten, wird er es schwer haben, neue Kunden zu gewinnen.

Wenn ein Kunde die Webseite nicht aufrufen kann, wird er sich mit großer Wahrscheinlichkeit auf die Suche nach einer anderen Webseite machen, was die Chance diesen Kunden zu gewinnen zunichte macht.

In diesem Beispiel ging es “nur” um Verluste, die mit einer Minderung des Umsatzes einhergehen. Doch wie sieht es in anderen Bereichen aus?

Wenn Datenbanken im Bereich autonomer Fahrzeuge ausfallen, kann dies schwerwiegende Konsequenzen haben. Zum Beispiel kann es dazu führen, dass die autonomen Fahrzeuge nicht mehr in der Lage sind, ihre Umgebung korrekt wahrzunehmen und somit Unfälle oder andere sicherheitsrelevante Vorfälle verursachen.

Auch könnten wichtige Informationen wie Verkehrsdaten, Wetterinformationen oder Straßenbedingungen nicht mehr verfügbar sein, was die Sicherheit und Zuverlässigkeit der autonomen Fahrzeuge beeinträchtigen würde. Zudem könnten Service- und Wartungsprozesse beeinträchtigt werden, was zu Verzögerungen oder Ausfällen führen könnte.

Auch im Gesundheitswesen, Flugverkehr, Energieversorgung, Finanzdienstleistungen, Sicherheitsbehörden ect. spielt Hochverfügbarkeit eine große Rolle.

Wie kann man Hochverfügbarkeit gewährleisten?

Vermeidung eines Single Point of Failure (SPoF). Dies beschreibt eine Komponente in einem System, bei deren Ausfall das gesamte System ausfallen würde. Ein Beispiel hierfür wäre ein Server, auf dem eine Anwendung läuft. Wenn dieser Server ausfällt, ist die Anwendung nicht mehr verfügbar.
Redundanz integrieren. Dadurch wird sichergestellt, dass eine Backup-Komponente einspringen kann, falls eine Komponente ausfällt. Es ist dabei wichtig, dass ein zuverlässiges Crossover oder Failover gewährleistet ist, um einen Wechsel von der ausgefallenen Komponente zur Backup-Komponente ohne Datenverlust oder Leistungseinbußen zu ermöglichen.
Monitoring. Um die Erkennbarkeit von Ausfällen zu gewährleisten, sollten Systeme über Mechanismen verfügen, um Fehler automatisch zu erkennen und zu beheben. Es sollten auch eingebaute Mechanismen zur Vermeidung von Fehlern mit gemeinsamer Ursache vorhanden sein, bei denen mehrere Komponenten gleichzeitig ausfallen können. Dadurch kann sichergestellt werden, dass Ausfälle schnell erkannt und behoben werden können, um eine schnelle Wiederherstellung des Systems zu gewährleisten.

Welche Varianten für Hochverfügbarkeitslösungen bei Datenbanken gibt es?

Ein häufig verwendetes Konzept ist die Verwendung von Redundanz und Replikation. Dabei werden die Daten auf mehreren Servern repliziert. Im Falle eines Serverausfalls kann ein anderer Server sofort einspringen und die Daten bereitstellen.

Es gibt zwei Arten von Replikationen: Master-Slave- und Multi-Master-Replikationen.

Bei einer Master-Slave-Replikation wird der Master-Server als Hauptserver betrachtet welcher alle Zugriffsverhältnisse beherrscht. Der Slave-Server stellt nur Lese-Zugriff zur Verfügung. Das bedeutet, dass die Suchlast auf den Slave-Servern verteilt werden kann.

Kommt es jedoch zu einem Ausfall des Master-Servers, kann dies zu einer Unterbrechung des Schreibzugriffs führen, da kein Knoten als neuer Masterknoten fungieren kann, bis der ursprüngliche Masterknoten wieder verfügbar ist. Infolgedessen ist der Masterknoten ein Single Point of Failure, der das gesamte System beeinträchtigen kann.

Bei einer Master-Slave-Kombination sollte insbesondere sichergestellt werden, das der Master-Server die indizierende Datenmenge auch bewältigen kann. Wenn große Datenmengen zu indizieren sind, empfiehlt es sich dann die Indizes aufzuteilen und mehrere Master-Server einzusetzen.

Bei einer Multi-Master-Replikation sind alle Server gleichwertig und replizieren Daten untereinander. Wenn ein Server ausfällt, übernehmen die verbleibenden Server seine Aufgaben. Doch hier wird es kniffelig. Wenn alle Server gleiches Stimmrecht haben, was passiert wenn mehrere Server an der selben Datei zeitgleich eine Änderung vornehmen?

Es kann zu einem “Split-Brain” kommen. Jeder Knoten glaubt, dass er der Hauptknoten ist, was zu Inkonsistenzen und Datenverlust führen kann. Diese müssen manuell aufgelöst werden, bevor die Änderungen an alle Knoten weitergeleitet werden und sich der Cluster abschaltet.

Um dies zu vermeiden wird immer eine ungerade Anzahl an Knoten empfohlen, damit ein Quorum (eine Mehrheit der verfügbaren Knoten) bestimmt werden kann. Wenn beispielsweise ein Cluster aus fünf Knoten besteht, würde das Quorum aus mindestens drei Knoten bestehen. Wenn das Quorum unterschritten wird, kann es zu einem Ausfall des Clusters kommen.

Ein Quorum stellt somit sicher, dass immer eine ausreichende Anzahl von Knoten verfügbar ist, um eine Abstimmung über Datenänderungen durchzuführen.

Zudem sind Multi-Master-Systeme in der Regel etwas komplexer als Master-Slave-Systeme und erfordern mehr Konfiguration und Wartung, was zu höheren Betriebskosten führen kann.

Welche der Varianten genutzt wird, hängt letztendlich von den spezifischen Anforderungen und Bedürfnissen des Datenbanksystems ab. Wenn die Anwendung eine hohe Schreiblast aufweist und eine hohe Verfügbarkeit erfordert, kann eine Multi-Master-Replikation bevorzugt werden, da sie eine effiziente Lastverteilung und eine schnelle Wiederherstellung nach einem Ausfall ermöglicht. Wenn jedoch die Schreiblast nicht so hoch ist und die Konsistenz der Daten wichtiger ist als die Verfügbarkeit, kann eine Master-Slave-Replikation bevorzugt werden, da sie eine strengere Konsistenz der Daten gewährleistet.

Fazit:

Die Bedeutung von Hochverfügbarkeit nimmt in der heutigen Zeit immer mehr zu, da die Abhängigkeit von Daten und Systemen in allen Bereichen des Lebens und der Wirtschaft zunimmt. Unternehmen müssen in der Lage sein, ihre Daten und Anwendungen rund um die Uhr zu nutzen, um wettbewerbsfähig zu bleiben und Kundenbedürfnisse zu erfüllen. Dies gilt nicht nur für große Unternehmen, sondern auch für kleine und mittelständische Unternehmen, die auf stabile und verlässliche IT-Infrastrukturen angewiesen sind. Zudem wird die Verfügbarkeit von Daten auch in immer mehr Bereichen des täglichen Lebens wichtiger, beispielsweise im Gesundheitswesen oder in der öffentlichen Verwaltung.

Valeria Thiele

Junior Developer

Valeria unterstützt seit September 2022 das NETWAYS Managed Services Team. Als Auszubildende Fachinformatikerin für Anwendungsentwicklung packt sie stets der Ehrgeiz, etwas zu programmieren. Sie ist aber auch sehr gespannt und neugierig, was sie in ihrer Ausbildung noch alles erwarten wird. In ihrer Freizeit findet man sie nahezu überall: auf dem Bike in den Bergen, am Piano spielend, nächtelang Zocken oder Netflixen, auf Wanderwegen, in Museen interessante Dinge entdecken oder auf dem Wasser im Kajak. Sie ist einfach immer wieder auf der Suche nach neuen Entdeckungen und Abenteuern, digital wie analog, offline wie auch online.

Read more from Valeria and meet the Team

Kubernetes 101: Aufbau eines K8s-Cluster und die Möglichkeiten der API

by Daniel Bodky | Mar 30, 2023 | Container, Docker, Kubernetes, NETWAYS, Technology, Serien

This entry is part 2 of 7 in the series Alles rund um Kubernetes

In meinem ersten Blogpost ging es zuerst einmal darum zu klären, was Kubernetes denn eigentlich ist. Jetzt, wo wir ergründet haben, welche Ansätze und Ideen Kubernetes verfolgt und warum diese sinnvoll sein können, gehen wir einen Schritt weiter, und schauen uns an, wie diese umgesetzt werden. Dafür wollen wir zwei Aspekte betrachten: Zum Einen der Aufbau eines Kubernetes-Clusters selbst, inklusive aller Teilbausteine, die für den reibungslosen Betrieb benötigt werden. Zum Anderen die im letzten Blogpost bereits mehrfach erwähnte API, wir als Schnittstelle nutzen und die uns eine ganze Bandbreite an API-Ressourcen anbietet, mit denen wir auf Kubernetes arbeiten können. Let’s get going!

Aufbau eines Kubernetes-Clusters

Beginnen wir mit einem sog. “Ten-Thousand Foot View“, um uns den groben Aufbau eines Clusters auf Infrastrukturebene vor Augen zu führen:

Wir sehen hier ein Cluster bestehend aus 8 Nodes – drei sog. Leader-Nodes und fünf Follower-Nodes. Die Leader-Nodes bilden zusammen die sog. Controlplane des Clusters und stellen Dienste wie clusterinternes DNS und die Kubernetes-API bereit. Um die API und damit letzten Endes das Cluster hochverfügbar zu machen, wird der Controlplane ein Loadbalancer vorgelagert. In Cloud-Umgebungen ist dies oft per Default die bereitgestellte Lösung des jeweiligen Providers, in eigenen Rechenzentren oder on-premise kann hierfür auf Lösungen wie HAProxy oder MetalLB zurückgegriffen werden. Best Practices diktieren, dass auf den Leader-Nodes möglichst keine Anwendungen deployed werden sollten, die nicht für den Betrieb des Clusters selbst benötigt werden.

Hierfür sind die fünf Follower-Nodes gedacht, die mit der Kubernetes-API ebenfalls via Loadbalancer interagieren und die für den jeweiligen Node gescheduleten Anwendungen ausführen. Auf diesen Nodes können beliebige Anwendungen entsprechend der jeweils verfügbaren Ressourcen deployed werden. Die API in der Controlplane kümmert sich hierbei um ein passendes Scheduling, damit Ressourcen auf den Follower-Nodes nicht erschöpft werden und angegebene Voraussetzungen wie bspw. spezielle benötigte Hardware (GPU, SSD, etc.) auf dem jeweiligen Node erfüllt werden.
Die letzte im Schaubild dargestellte Komponente stellt eine lokale Terminalsession auf Seiten eines Endnutzers dar. Dieser kommuniziert via kubectl mit der Softwareschnittstelle, dem de-facto Standardtool für Interaktion mit der API von außerhalb des Clusters.

Doch welche Komponenten laufen denn nun auf den jeweiligen Node-Klassen? Gehen wir doch einmal etwas weiter ins Detail:

Wir sehen hier exemplarisch jeweils einen Leader und Follower-Node als VMs in der Detailansicht, mit all den Anwendungen, die auf den jeweiligen Node-Klassen typischerweise installiert sind. Gehen wir die verschiedenen Anwendungen doch einmal durch:

etcd – Key/Value-Store für den Zustand und die Historie der Kubernetes-API; Wird normalerweise auf den Leader-Nodes installiert, kann allerdings auch auf externe Maschinen ausgelagert werden
kube-apiserver – PI-Server des Kubernetes-Clusters; Wird für Hochverfügbarkeit auf allen Leader-Nodes installiert
kube-scheduler – Kümmert sich um das Scheduling der in das Cluster deployten Anwendungen; Wird auf Leader-Nodes installiert
kube-controller-manager – Ein Bündel an sog. Kubernetes-Controllern, das sich um die Verwaltung verschiedener Kubernetes-Ressourcen kümmert; Wird auf Leader-Nodes installiert
kubelet – Kommuniziert mit der API und der lokalen Container-Runtime, um Container auf den Nodes auszuführen; Wird auf allen Nodes installiert
kube-proxy – Routet Netzwerk-Traffic zu Containern, sobald dieser auf den jeweiligen Nodes ankommt; Wird auf allen Nodes installiert
Container Runtime – Im Beispiel containerd; andere Implementierungen sind möglich, bspw. CRI-o; Wird auf allen Nodes installiert

Zu erwähnen ist, dass nicht alle Cluster so aussehen müssen. Beispielsweise ließe sich auch eine Controlplane umsetzen, auf der keinerlei Container ausgeführt werden – in diesem Fall könnte man auf die Installation von kubelet, kube-proxy und containerd auf Leader-Nodes verzichten (für eine Referenzinstallation s. Kubernetes the Hard Way auf GitHub). Auf Clustern in der Cloud wird man außerdem fast immer einen sog. cloud-controller-manager auf Leader-Nodes finden, der gewisse Funktionalitäten im Cloud-Bereich integriert, bspw. automatische Provisionierung benötigter Loadbalancer in der hostenden Cloud.

Auch können sich die genauen Ausprägungen einer Kubernetes-Installation je nach Kubernetes-Distribution unterscheiden – momentan listet die CNCF 59 zertifizierte Distributionen. K3s bspw. bündelt die verschiedenen Komponenten in eine Binary, was den Betrieb im Alltag etwas erleichtern kann und den Ressourcen-Fußabdruck des Clusters senkt.

Die Kubernetes’ API – endlose Weiten

Haben wir unser Cluster nun wie oben skizziert (oder ganz anders) installiert, möchten wir natürlich mit ihm interagieren – hierfür gibt es verschiedene Möglichkeiten, angefangen bei cURL über das offizielle Kubernetes Dashboard bis zu Wrappern für das lokale Terminal. Letzteres ist der gängigste Weg – fast alle Tutorials und technische Dokumentationen zu Kubernetes und darauf zu installierende Anwendungen erwähnen kubectl, was sich auf jedem gängigen Betriebssystem paketiert installieren lassen sollte. Haben wir kubectl lokal installiert und eingerichtet (wir benötigen eine sog. kubeconfig, die Verbindungsinformationen für unser(e) Cluster enthält), können wir uns zum ersten Mal die API anschauen:

Je nach Cluster (im Beispiel ein Rancher Desktop Cluster) scheint uns Kubernetes zwischen 60 und 70 verschiedene API-Objekte anzubieten! Wo also anfangen und wo aufhören? Oder gleich alle 70 behandeln? Fangen wir doch einfach mit der kleinsten Einheit an Workload an, die K8s für uns bereit hält – dem Pod. Ein Pod kapselt einen oder mehrere Container in einem Bündel, das sich Netzwerk- und Speicherressourcen teilt.

Daraus folgt, dass alle Container eines Pods immer auf demselben Node gescheduled werden. Ein Pod alleine profitiert allerdings noch nicht von Kubernetes’ Orchestrierungsmöglichkeiten – ist bspw. der hostende Node nicht erreichbar, können wir auch die in unserem Pod laufenden Anwendungen nicht mehr erreichen.

Wir benötigen also eine weitere Abstraktionsebene, die es uns erlaubt, mehrere identische Pods auf verschiedene Nodes zu schedulen: das sog. Deployment. Ein Deployment definiert ein Pod-Template, sowie eine Anzahl an gewünschten Repliken und weitere Konfiguration, die von Kubernetes zur Orchestrierung des Deployments genutzt wird. Unter der Haube wird dann vom API-Server ein ReplicaSet erzeugt, das die gerenderte Version des Pod-Templates enthält.

Auf diese Weise ermöglicht eine Deployment-Ressource uns nicht nur die Ausführung mehrerer Repliken eines einzelnen Pods, sondern auch eine Versionierung verschiedener ReplicaSets – wieviele genau von der API gespeichert werden, hängt von den Einstellungen des API-Servers zusammen. Hier nochmal ein Schaubild zu den Zusammenhängen:

Zu sehen ist ein Deployment mit drei dazugehörigen ReplicaSets, die sich in der Anzahl der definierten Replicas unterscheiden (Kubernetes erstellt bei jeglicher Änderung eines Deployments ein neues ReplicaSet, nicht nur bei Änderung der Replicas). Das momentan aktive ReplicaSet wiederum verwaltet der Konfiguration entsprechend fünf Pods.

Möchte man seine deployten Anwendungen nun untereinander oder für Endnutzer außerhalb des Clusters verfügbar machen, kommen Services ins Spiel. Ein Service ist eine API-Ressource, die einen gewissen Pool an Pods als Endpoints definiert und für diese als Round-Robin Loadbalancer fungiert. Auf diese Weise benötigt man nur eine IP, um zuverlässig einen funktionalen Pod eines Deployments zu erreichen. Kubernetes kümmert sich hierbei automatisch darum, Traffic nur zu funktionalen Pods weiterzuleiten.
Es gibt drei Arten von Services:

ClusterIP – der Service erhält eine innerhalb des Clusters erreichbare IP-Adresse, ist von außerhalb des Clusters aber nicht ohne Weiteres zu erreichen
NodePort – der Service wird auf jedem Node auf einem zufälligen, hohen Port (ca. 30.000+) verfügbar gemacht
Loadbalancer – eine Erweiterung des NodePort-Typs, wobei den Ports ein Loadbalancer vorgelagert wird; funktioniert am reibungslosesten in Public Clouds

Zusätzlich gibt es die Möglichkeit, HTTP-Traffic anstatt mittels Loadbalancer auf L4 mit einem sog. Ingress auf L7 zu routen – die Konfiguration unterscheidet sich hierbei abhängig vom genutzten IngressController.

Weitere nennenswerte, grundlegende API-Ressourcen innerhalb von Clustern wären bspw. Namespaces zur Trennung von anwendungslogisch zusammenhängenden Deployments etc. sowie zur Umsetzung von role-based access control (RBAC), Secrets zur Bereitstellung vertraulicher Daten wie bspw. Passwörtern, Zertifikaten, oder Token, und ConfigMaps für häufig genutzte Konfigurationssnippets. Wer mitgezählt hat wird merken, dass wir gerade erst bei 7 von den oben angezeigten 70 Ressourcentypen angekommen sind – und das ist noch lange nicht das Ende der Fahnenstange, da eine der Stärken der Kubernetes-API schließlich ihre Erweiterung durch sog. CustomResourceDefinitions (CRDs) ist. Für einen ersten Einblick soll der momentane Stand trotzdem fürs Erste genügen.

kubectl – das Schweizer Taschenmesser für Kubernetes

Bereits im letzten Absatz eingangs erwähnt, ist jetzt der Moment für kubectl gekommen, das offizielle Kommandozeilentool für den täglichen Umgang mit Kubernetes und seiner API. Ich könnte an dieser Stelle mehrere 1000 Wörter über den Gebrauch schreiben und trotzdem noch sehr viel unerwähnt lassen, und genau aus diesem Grund folgt nun gemäß dem Motto “Ein Bild sagt mehr als tausend Worte” lediglich eine Auflistung einiger gängiger und oft genutzter kubectl Kommandos, um einen ersten Eindruck von der Nutzung des Tools zu bekommen.

Hier zu sehen sind einige der häufigsten Kommandos, zu denen neben get und create wohl auch noch apply, logs und describe gehören dürften. Neben dem expliziten (imperativen) Erstellen von API-Ressourcen via CLI können mit kubectl auch bestehende Kubernetes-Manifeste (in YAML oder JSON) in das Cluster “gepusht” werden, was einem deklarativen Ansatz entspricht und in der Praxis der gängigere Weg ist.

Für heute war das aber genug trockene Theorie rund um Architektur, API-Aufbau und Clusterkomponenten – im nächsten Teil der Serie werden wir uns genauer anschauen, wie wir uns denn nun basierend auf der in diesem Artikel erläuterten Architektur unser eigenes Cluster installieren können, entweder auf lokaler Infrastruktur, in der Cloud (z.B. Managed Kubernetes bei NMS), oder auf deinem persönlichen Rechner! Abonniere also gerne auch den RSS-Feed unseres Blogs und sei bereit für den nächsten Artikel der Kubernetes 101 Reihe!

Daniel Bodky

Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

Read more from Daniel and meet the Team