NETWAYS Blog

Das war die KubeCon 2023

von Daniel Bodky | Mai 19, 2023 | NETWAYS

Ende April stand für die Kollegen im Consulting Daniel Bodky und Markus Waldmüller eine der großen Konferenzen des Kalenderjahres an – die KubeCon+CloudNativeCon EU 2023 in Amsterdam, wohin es NETWAYS bereits letzten Sommer im Rahmen der Startup Days verschlagen hatte. Mit fachlichem Vorwissen und Ortskenntnis konnten sich die beiden also in den Konferenzalltag mit Talks, Podiumsdiskussionen und dem allseits bekannten „Hallway Track“ voller interessanter Gespräche stürzen. In diesem Blogpost blicken sie zurück: Wie war die Konferenz, was treibt Anwender und Betreiber um, und welche Trends konnten sie ausmachen?

So fanden wir uns also zusammen mit den über 10.000 Teilnehmern (ja, richtig gelesen!) unter dem Motto „Community in Bloom“ im Amsterdamer RAI Kongresszentrum ein. Nach den Workshops am Vortag erfolgte die Eröffnung der eigentlichen Konferenz durch Priyanka Sharma, der Geschäftsführerin (Executive Director) der Cloud Native Computing Foundation (CNCF). Sie erwähnte u.a., dass 58% der Anwesenden zum ersten Mal an einer KubeCon teilnahmen. Wie auch an den anderen Konferenztagen fanden anschließend eher sponsorenlastige Keynotes statt, bevor dann ab dem späten Vormittag die tiefergehenden Tech-Talks angesetzt waren.

Neben den zahlreichen Präsentationen zu verschiedensten Themen waren in zwei großen Hallen mit GitLab, AWS, SUSE Rancher, Google Cloud und Co. auch ca. 220 Aussteller vertreten, bei denen man sich vor, zwischen und nach den Sessions zusätzlich auf dem neusten Stand zu Kubernetes und anderen Cloud Produkten bringen konnte.

Die Auswahl an Talks war groß, die professionellen und privaten Bekanntschaften aus aller Welt allgegenwärtig, und zwischendurch lockte der ein oder andere Sticker, eine spezifische Frage zu einem Produkt oder einfach nur Neugierde in die Ausstellerhalle. An dieser Stelle auf sämtliche Eindrücke einzugehen wäre wohl etwas zu viel verlangt. Wir hoffen, dass ihr uns verzeiht und euch unsere persönlichen Highlights ausreichen.

Unsere Highlights

Einen Tag vor Beginn der eigentliche Konferenz fand u.A. die ArgoCon im Rahmen der „Co-located Conferences“ statt, die sich Daniel nicht entgehen lassen wollte. Das war wohl auch die richtige Entscheidung:

„Rückblickend würde ich fast soweit gehen, zu sagen, dass mir die ArgoCon am besten gefallen hat. Hier konnte ich mich einen Tag lang den Themen GitOps (dazu später mehr), Workflows, Deployments und Events widmen – alles Themen, die das Argo-Projekt abbilden kann. Eines meiner Highlights dieses ersten Tages war der Beitrag „Scaling GitOps using ArgoCD Application-Sets: Lessons learnt“ von Amit Dsouza, der ein eher selten genutztes Feature in ArgoCD, Application Sets, und seine möglichen Vor- und Nachteile genauer beleuchtete.“

Im Verlauf der folgenden Tage waren insbesondere die 90-minütige Frage-Antwort-Session von Kelsey Hightower zum Thema „From Community to Customers“ sowie die „Wasserstandsmeldung“ „The State of Backstage in 2023“ zum CNCF-Projekt Backstage von besonderem Interesse. Hierbei handelt es sich um eine Internal Developer Platform (IDP, auch hierzu später mehr) entwickelt von Spotify. Natürlich gab es noch viele weitere gute Beiträge zu unterschiedlichsten Themen und Problemstellungen.

GitOps, Wasm, Service Meshes und IDPs – die Trends im Überblick

Die KubeCon EU, die von den „großen“ Konferenzen meistens am frühesten im Kalenderjahr angesetzt ist, wird gerne auch als Trendbarometer und Gradmesser für Technologien und Frameworks rund um Cloud-Native und Kubernetes wahrgenommen. Und so stellt sich natürlich auch 2023 die Frage: „Wo geht’s hin?“. Einen ersten Aufschluss darüber können oft die Co-located Conferences an „Day Zero“ der KubeCon geben – zu brandaktuellen Themen gibt es oftmals gesteigertes Interesse an Workshops, Einführungen, Fallstudien und tiefergehenden Talks. So finden sich Interessengruppen zu eigenen, kürzeren, parallel stattfindenden Konferenzen zusammen. Daniel besuchte z.B. die ArgoCon, die sich u.A. mit dem Thema GitOps befasste, also der Praxis, zu deployende Anwendungen und teilweise auch Infrastruktur in Git zu versionieren, um einen eindeutigen, nachvollziehbaren und deklarativen Stand seiner Umgebung zu forcieren.

Doch auch andere Co-located Conferences befassten sich mit momentan heiß gehandelten Themen, sei es der Cloud Native Wasm Day, Istio Day oder Linkerd Day. Wasm steht für „Web Assembly“, ein portierbares Compilationtarget für verschiedene Programmiersprachen, das bspw. im Vergleich zu Javascript mehr Performanz und Plattformunabhängigkeit für Webanwendungen verspricht. Mehr Informationen zu WebAssembly findet man unter https://webassembly.org.
Istio und Linkerd hingegen sind zwei Service Mesh Technologien, die sich um das Management und die Absicherung von Netzwerkverkehr innerhalb von Microservice-Architekturen, aber auch zwischen Endnutzer und Anwendung(en) kümmern. Dass die zwei „beliebtesten“ Service Meshes parallel eigene Konferenzen veranstalten, spricht für den Einfluss und Nachfrage der darunterliegenden Technologie. Wir sind jedenfalls gespannt, wie sich die Thematik rund um Netzwerkarchitekturen auf und um Kubernetes herum weiterentwickeln wird.

Ein drittes Thema, das auf der Kubecon großen Anklang zu finden schien, waren sogenannte Internal Developer Platforms (IDP). In einer „cloud-native“ Welt, in der sich Anwendungen aus vielen einzelnen Microservices und verschiedensten Technologien und Frameworks zusammensetzen, wird es für Entwickler zunehmend schwieriger, den Überblick zu behalten und weiterhin ungehindert gute Software zu schreiben. Das Konzept einer internen Entwicklerplattform, die eine Übersicht über im Unternehmen vorhandene Technologien, festgelegte Konventionen und Best Practices und im Bestfall sogar die Integrationen bestehender Dritttools bietet, kann den Alltag für Entwicklerteams deutlich vereinfachen.
Das wohl bekannteste Projekt in dieser Sparte ist Backstage (s.o.), ursprünglich entwickelt von Spotify und momentan ein „incubating project“ in der CNCF. Aber auch andere Produkte und Projekte existieren, so waren bspw. die beiden Anbieter „Port“ und „Mia-Platform“ Sponsoren der diesjährigen KubeCon EU.
Es wird sicherlich spannend sein zu sehen, wie sich Developer Tools und Plattformen die kommenden Monate und Jahre weiterentwickeln werden, und welche Tools sich letzten Endes durchsetzen können.

Fazit

Auch wenn die vielen Teilnehmer fast schon als Kleinstadt durchgehen würden, war die Konferenz sehr gut organisiert, sodass dem Wissenstransfer überhaupt nichts im Wege stand und wir eine unüberschaubare Anzahl an neuen Informationen und Kenntnissen mitnehmen konnten.
Bei der KubeCon EU im nächsten Frühjahr in Paris sind wir auf jeden Fall wieder vertreten und freuen uns bis dahin unser Wissen an unsere Kunden weiterzugeben bzw. dort umzusetzen.

Sei es ein Training rund um Docker und Kubernetes für Einsteiger, die Zusammenarbeit in und an euren cloud-native Projekten oder die Arbeit mit Containern im CI/CD-Bereich, z.B. auf GitLab – für Anfragen aller Art zu Cloud Native stehen wir natürlich gerne zur Verfügung!

Daniel Bodky

Consultant

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und berät nun Kunden zu den Themen Icinga2 und Kubernetes. 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.

Lies mehr von Daniel und triff unser Team

Kubernetes 101: So installierst und verwaltest du Anwendungen

von Daniel Bodky | Apr 24, 2023 | DevOps & Container, NETWAYS

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

Hi! Ich bin Daniel, Open Source IT Consultant und großer Kubernetes-Fan. In der NETWAYS Blogserie „Alles rund um Kubernetes“ nehme ich Dich mit auf eine Reise in die Welt der Containerorchestrierung. Unter dem Überbegriff „Kubernetes 101“ gebe ich dir regelmäßig Tipps, Hilfestellungen und meine Einschätzungen zur Arbeit mit Kubernetes und wie du damit am besten umgehen kannst.
Angefangen bei einer Vorstellung des Tools selbst und der dahinterstehenden Ideologie über die Installation auf unterschiedlichen Betriebssystemen in verschiedensten Umgebungen bis hin zum Betrieb und der Absicherung eines Kubernetes-Clusters werde ich auf viele Szenarien und Gesichtspunkte eingehen.

Im bereits fünften Teil der Serie gehe ich auf neue Best Practices bei der Installation von Anwendungen auf K8s ein und wie diese sich von den bisherigen Methoden unterscheiden. Viel Spaß!

Nachdem wir uns vergangene Woche damit befasst haben, welche Mittel und Wege existieren, um sich ein Cluster entweder für Tests oder für Produktion zu installieren, sind wir nun (hoffentlich) an dem Punkt angekommen, an dem wir erste Anwendungen auf Kubernetes portieren oder neu installieren möchten. Da sich Kubernetes als Containerorchestrator deutlich von „althergebrachten“ Betriebsumgebungen für Anwendungen unterscheidet, ist es nur logisch, dass sich auch Best Practices für die Installation und den Betrieb dieser Anwendungen unterscheiden. Grob lassen sich die zu beachtenden Gesichtspunkte in 5 Felder unterteilen:

Dateisystem vs. Container
Monolithen vs. Microservices
Stateful vs. Stateless
Blackbox vs. Whitebox
Monitoring vs. Observability

Diese Felder und ihre Implikationen bedingen einander teilweise. Fangen wir also mit dem evtl. offensichtlichsten an – der Installationsmethodik.

Dateisystem vs. Container

Der größte und für viele auch folgenschwerste Unterschied zwischen Anwendungen, die in Kubernetes laufen ,und solchen, die auf VMs oder physischen Servern installiert werden, ist Containerisierung der Workloads. Jede Anwendung muss als Containerimage definiert, gebaut, gesichert und verteilt werden – dies erfordert oftmals eine Umstellung bestehender Abläufe für Tests, Bau und Verteilung der Software, bspw. in den CI/CD-Pipelines der Entwickler- und DevOps-Teams. Des Weiteren muss oftmals neue Infrastruktur eingerichtet werden, um etwa Imagescans oder eine eigene Container- und Artefaktregistry für das Unternehmen bereitstellen zu können.

Des Weiteren gilt es natürlich, entsprechendes Know-How in den Teams aufzubauen – nicht jede/r Entwickler/in hat in der Vergangenheit mit Docker und containerisierten Anwendungen gearbeitet, geschweige denn entwickelt. Auch wenn Tools wie Docker Desktop oder Podman Desktop den Einstieg heutzutage erleichtern, müssen Mindset, Praktiken und Routinen oftmals erst aufgebaut werden. Gleiches gilt für die Handhabe der Containerimages nach dem Bau: Wie werden Sie gespeichert und für Pipelines und Cluster verfügbar gemacht? Nutzt man hierfür eine offene Plattform (GitHub Container Registry, DockerHub), eine SaaS-Lösung (Artifactory), oder baut eigene Infrastruktur auf (Harbor)?
Mit diesen möglichen Problematiken sollte man sich im Bestfall bereits im Vorfeld befassen und aufkommende Fragen initial klären, um einen möglichst reibungslosen Umstieg auf Kubernetes für alle beteiligten Teams zu gewährleisten.

Monolithen vs. Microservices

Eine direkte Folge der Containerisierung von Anwendungen ist die Transition von sog. Monolithen zu Microservices. Der Grund hierfür ist klar: In einer Umgebung, in der Softwarereleases oft mehrmals täglich stattfinden und ein Orchestrator installierte Anwendungen nach Belieben skalieren, verwerfen oder an anderer Stelle erneut initialisieren kann, sind Anwendungen mit einer Paketgröße von mehreren Gigabyte nicht praktikabel – man möchte schmale Pakete im Bereich von maximal einigen Hundert Megabyte, um flexibel und schnell in Sachen Verteilung und Installation zu sein.

Hierfür ist es gängige Praxis, bestehende Anwendungen umzustrukturieren bzw. bei der Entwicklung neuer Anwendungen bereits in der Designphase auf die spätere Installation als Microservices hinzuwirken, um Monolithen zu vermeiden. Unter einem Monolithen versteht man ein einzelnes Softwarepaket, das sich von Operatoren nur als eine Einheit installieren lässt und keinerlei Flexibilität und Unabhängigkeit seiner Komponenten bietet – alle Bestandteile sind unter der Haube fest miteinander „verdrahtet“. Hat man nun Probleme mit der Performanz eines bestimmten Features (ein sog. Bottleneck) bleibt einem keine andere Wahl, als den gesamten Monolithen zu skalieren – in den meisten Fällen Ressourcenverschwendung.

Viel sinniger wäre es doch, die einzelnen Bestandteile zu trennen – das Ergebnis sind viele verschiedene Microservices, die im Bestfall jeweils nur eine Aufgabe übernehmen. Ein solcher Ansatz ermöglicht die Skalierung einzelner Bestandteile der Anwendung, bspw. des viel frequentierten Webshops, anstatt direkt die gesamte Anwendung skalieren zu müssen. Die Kommunikation der einzelnen Microservices untereinander geschieht in solchen Szenarien über das (clusterinterne) Netzwerk bspw. via HTTP oder gRPC.

Stateful vs. Stateless

Eine direkte Folge der Umsetzung von Anwendungen als Microservices wiederum ist eine Transition von zustandsabhängigen (stateful) zu größtenteils zustandslosen (stateless) Anwendungen – während die meisten Monolithen zustandsabhängig sind (fast jede nennenswerte Anwendung muss an irgendeinem Punkt Daten persistent speichern können), müssen nur die wenigsten Microservices Daten persistent speichern. In vielen Fällen reicht ein lokaler Cache, bspw. zum Speichern von Nutzersitzungen oder dem Vorhalten von oft angefragten Daten.

Wirkliche Persistenz benötigen nur die Microservices, die sich unmittelbar mit der Verarbeitung und Speicherung von Daten befassen und hierfür bspw. mit rückgelagerten Datenbanken oder Dateisystemen kommunizieren. Mittlerweile gibt es allerdings genug Fallstudien, in denen auch Services wie Blockspeicher oder Datenbanken direkt auf Kubernetes betrieben werden.

Blackbox vs. Whitebox

Neben der Umstellung von „Stateful“ auf „Stateless“ betrifft eine weitere große Veränderung im Design von Anwendungen bestehend aus Microservices den Ansatz ihrer Überwachung: Anstatt lediglich von außen auf die Anwendung zu blicken und evtl. auftretende Symptome einer Fehlfunktion zu erkennen, bspw. durch HTTP-Anfragen an für Nutzer angebotene Webendpunkte (sog. Blackbox-Monitoring), instrumentalisiert man seine Microservices von vornherein so dass man tatsächliche Metriken aus den im Service ablaufenden Prozessen erhält (sog. Whitebox-Monitoring).

Beliebt für die Umsetzung ist hierbei Prometheus, was einen etablierten Standard für Metriken liefert, weit verbreitet ist und Funktionsbibliotheken für die Instrumentalisierung von Code in verschiedenen Programmiersprachen bietet. Prometheus sammelt die Metriken der Services über Webendpunkte ab und speichert sie in einer internen Timeseriesdatenbank (TSDB) ab. Ist Prometheus für euch ein gänzlich unbekannter Begriff, kann ich euch an dieser Stelle wärmstens unser Prometheus Fundamentals Training ans Herz legen, mit dem man in kürzester Zeit relativ vertraut mit Prometheus und seinem Funktionsumfang wird.
Verfolgt man also Whitebox- statt Blackboxmonitoring, hat man die tatsächlichen Metriken seiner Microservices zur Verfügung und kann bei aufkommenden Komplikationen Ursachen statt Symptomen bekämpfen. Des Weiteren können die Metriken zur permanenten Weiterentwicklung und Verbesserung der Serviceperformanzen genutzt werden – eine Win-Win-Situation!

Monitoring vs. Observability

Aufbauend auf dem letzten Absatz zu Blackbox- vs. Whiteboxmonitoring lässt sich die Monitoring-Philosophie im Hinblick auf K8s oder „Cloud-Native“ generell noch vertiefen und erweitern: Man spricht von den Three pillars of observability (Drei Säulen der Beobachtbarkeit/Observability) Metrics, Traces und Logs. Metriken werden von Anwendungen und Services selbst bereitgestellt und bieten wie bereits erklärt einen ungetrübten Einblick in das Innenleben einzelner Services. Traces erlauben es, Prozessketten über Servicegrenzen hinweg zu verfolgen und bspw. zu ermitteln, in welchen Stadien der Verarbeitung besonders hohe Latenzen entstehen. Logs ermöglichen die Verarbeitung von Events o.Ä., die von den einzelnen Anwendungen protokolliert werden.

Aus der Fülle an verschiedenen Datentypen und den dafür benötigten Praktiken entsteht die Entwicklung von Monitoring hin zu Observability – es ist nicht mehr ausreichend, lediglich „von außen“ auf seine monolithische Anwendung zu blicken, sondern es gilt, stattdessen in den Services selbst anzusetzen und soviel Informationen wie möglich abzugreifen.
Für alle drei Arten an Beobachtungen gibt es umfangreiches Tooling in der Opensource-Gemeinschaft, das einem hilft, den Überblick über seine Cluster und die darauf betriebenen Anwendungen zu behalten, diese nach und nach zu optimieren und bei Fehlern schnell oder sogar proaktiv reagieren zu können. Auch bei der Einhaltung von Service Level Agreements (SLAs) gegenüber den Kunden oder internen Service Level Agreements (SLAs) hilft eine lückenlose Observability-Strategie.

Sollten diese Punkte etwas viel auf einmal gewesen sein oder du bereits absehbare Probleme bei der Umsetzung auf dich zukommen siehst, kann ich euch erneut auf unsere Services rund um Container, DevOps und Kubernetes verweisen – wir sind in vielen der genannten Bereichen bereit, dir mit Rat und Tat zur Seite zu stehen und bei der Umsetzung zu unterstützen. Ansonsten bleibt mir für heute nur, „bis zum nächsten Mal“ zu sagen, wenn wir uns genauer anschauen, wie man Anwendungen auf Kubernetes denn nun im Detail verwaltet und skaliert.

Daniel Bodky

Consultant

Lies mehr von Daniel und triff unser Team

Kubernetes 101: Wie du ein Kubernetes-Cluster installierst

von Daniel Bodky | Apr 17, 2023 | NETWAYS

This entry is part 3 of 4 in the series Alles rund um Kubernetes

Hi! Ich bin Daniel, Open Source IT Consultant und großer Kubernetes-Fan. In der NETWAYS Blogserie “Alles rund um Kubernetes” nehme ich Dich mit auf eine Reise in die Welt von Kubernetes. Unter dem Überbegirff “Kubernetes 101” gebe ich dir regelmäßig Tipps, Hilfestellungen und meine Einschätzungen zur Arbeit mit Kubernetes und wie du damit am besten umgehen kannst.
Angefangen bei einer Vorstellung des Tools selbst und der dahinterstehenden Ideologie über die Installation auf unterschiedlichen Betriebssystemen in verschiedensten Umgebungen bis hin zum Betrieb und der Absicherung eines Kubernetes-Clusters werde ich auf viele Szenarien und Gesichtspunkte eingehen.

In diesem Artikel geht es um das erstmalige Starten eines Kubernetes Clusters. Und nun viel Spaß bei deinem Einstieg in die Container-Orchestrierung!

Nachdem wir uns in den vergangenen Artikeln bereits damit beschäftigt haben, was Kubernetes eigentlich ist, warum man es brauchen könnte und wie Kubernetes und seine API eigentlich funktionieren, juckt es dich inzwischen sicherlich in den Fingern, Kubernetes einmal selbst auszuprobieren.

Hierbei haben wir allerdings die Qual der Wahl – wie in vorangegangenen Blogposts bereits erwähnt, listet die CNCF fast 50 verschiedene Kubernetes-Distributionen auf ihrer Seite. Diese unterscheiden sich vor Allem durch ihren Fokus auf verschiedene Nutzergruppen oder Einsatzumgebungen voneinander:

Lokal
Auf Serverhardware oder in VMs
In der Cloud
„at the edge“ oder im IoT-Bereich

Aus diesem Grund werde ich heute diese vier Anwendungsumgebungen etwas genauer beleuchten und für alle Domänen mögliche Installationskandidaten sowie zusätzliches, nützliches Tooling betrachten. Los geht’s!

Lokale Kubernetes-Installation

Kubernetes lokal zu installieren ist längst nicht so unsinnig, wie es zunächst scheinen mag – wie sinnvoll kann eine Container-Orchestrierung über mehrere Nodes hinweg auf einem Node schon sein? Die Antwort lautet: Sehr!

Für jeden Entwickler in einem Projekt ein eigenes Cluster auf firmeninterner Hardware oder in der Cloud zu provisionieren ist oftmals unrentabel, und eine lokale Kubernetes-Installation verhält sich zumindest ähnlich genug, um Feedback für die Entwickler zu geben. Auch für den Einsatz in CI/CD-Pipelines für Integrations- und End-to-End-Tests bietet sich die Installation eines „lokalen“ Clusters zur Pipeline-Laufzeit an.

Welche Möglichkeiten zur Installation eines lokalen Clusters gibt es also? Hier ein kurzer Überblick:

Docker Desktop – genau, richtig gelesen! Docker Desktop bietet bereits seit einigen Versionen die Möglichkeit, ein lokales Kubernetes-Cluster in der momentan aktuellsten Version mit einem Node zu installieren. Hierfür wird im Hintergrund von Docker eine VM erstellt, in die dann Kubernetes und Tools für persistente Speicherverwaltung und Netzwerkanbindung des Clusters installiert werden. Docker Desktop kümmert sich darüber hinaus um die automatische Konfiguration der lokalen kubeconfig des Nutzers.
Rancher Desktop – sehr ähnlich wie Docker Desktop, allerdings ohne Containerverwaltung – die GUI kümmert sich lediglich um die Konfiguration einer lokalen (versteckten) VM, in die ein Kubernetes-Cluster installiert wird, ebenfalls mit einem Node und zusätzlichen Onboard-Mitteln für Speicher und Netzwerk.
Ebenfalls wie Docker Desktop kümmert sich auch Rancher Desktop um die automatische Konfiguration der lokalen kubeconfig. Ich persönlich bevorzuge von beiden Tools mittlerweile Rancher Desktop, da man hier nicht wie bei Docker Desktop auf die „aktuellste“ Kubernetes-Version beschränkt ist.
Minikube – Das Projekt wird von einer offiziellen Kubernetes SIG (Special Interest Group) entwickelt und maintained, im Gegensatz zu Docker/Rancher Desktop erlaubt einem Minikube eine deutlich erweiterte Konfiguration des Clusters auf Komponentenebene. Auch die Aktivierung verschiedener Updates wie Dashboards uvm. ist möglich.
Microk8s – Microk8s ist eine von Canonical bereitgestellte Lösung für lokale Kubernetes-Installationen, die allerdings auch für die Installation „richtiger“ Cluster über mehrere Nodes hinweg genutzt werden kann. Ähnlich wie bei Minikube können auch hier tiefergreifende Konfigurationen vorgenommen und Addons nach Bedarf an und ausgeschaltet werden.

Installation auf Hardware oder VMs

Hat man sich auf seinem lokalen Rechner oder Laptop ausgetobt, möchte man evtl. zum ersten Mal ein tatsächlich verteiltes Cluster als Proof of Concept oder sogar schon für den Produktionsbetrieb auf firmeneigener Hardware oder einer eigenen VM-Flotte einrichten. Neben dem bereits erwähnten Microk8s gibt es für dieses Szenario noch ein paar andere nennenswerte Möglichkeiten, sich ein Cluster einzurichten.

kubeadm – das „offizielle“ Tool zur Installation von Kubernetes. Es kann dazu genutzt werden, um ein Cluster und seine Komponenten analog zu dem Aufbau einzurichten, der im letzten Teil dieser Serie zu Cluster-Architektur beschrieben wurde – kubelet, etcd, und die anderen Bestandteile eines Clusternodes laufen hierbei als einzelne Systemservices. kubeadm kümmert sich um Dinge wie Zertifikatsgenerierung und erstmalige Einrichtung sowie das einfache Hinzufügen neuer Nodes in das Cluster. Diese Art der Installation eignet sich auch für eine automatisierte Umsetzung bspw. via Ansible.
Rancher – ein Cluster-Management-Tool von SUSE, mit dem sich Cluster sowohl on-prem als auch in der Cloud erstellen und zentral verwalten lassen. Auf lokalen VMs oder Hardware lassen sich hierbei wahlweise Cluster auf der Basis von K3s oder RKE1/2, beides ebenfalls von SUSE verwaltete Kubernetes-Plattformen.
K3s – gerade eben bereits erwähnt, lässt sich K3s auch außerhalb des Rancher-Kontexts hervorragend für Kubernetes-Installationen nutzen. K3s besticht durch seinen abgespeckten Umfang und die Bündelung aller benötigten Komponenten in eine ausführbare Datei, was die Installation und Verwaltung enorm erleichtern kann. Auch hier ist eine Automatisierung durch Dritttools wie Ansible möglich.

Installation in der Cloud

In der Cloud hat man endgültig die Qual der Wahl – (fast) jeder Cloudanbieter hat dieser Tage eine sog. „Managed Kubernetes“-Lösung im Angebot, die mit einigen Klicks bestellt werden kann und nach ein paar Minuten verfügbar ist. Am beliebtesten sind hier natürlich die „Big Three“ (Google Cloud, AWS, Azure Cloud), bei denen man aber in den meisten Fällen auch mehr Geld lässt als bei kleineren Mitbewerbern. Es gilt also, Kosten und Nutzen abzuwägen, oftmals reicht eine Lösung von kleineren Cloudanbietern wie bspw. unser Managed Kubernetes by NWS.

Natürlich kann man sich auch in der Cloud einzelne Server provisionieren und sich mit den oben erwähnten Tools sein eigenes Cluster. losgelöst von den gemanagten Angeboten der Provider, bauen. Auch die Verteilung eines Clusters über mehrere Cloud-Anbieter hinweg für eine maximale Fehlertoleranz ist ein Modell, das in der Vergangenheit bereits umgesetzt wurde. „Die Cloud“ bietet also vielfältige Möglichkeiten, Kubernetes-Cluster ganz nach Bedarf, erwartbaren Risiken und Problemen aufzubauen, um maximal flexibel zu bleiben.

Kubernetes at the Edge

Immer beliebter wird auch der Betrieb von kleinen Kubernetes-Clustern „at the edge“, also möglichst nahe beim Endnutzer. So hat bspw. die amerikanische Fastfood-Kette „Chick-Fill-A“ in jeder ihrer Filialen ein 3-Node-Cluster in Betrieb, in Summe über 2500 Cluster. Auch für solche Anwendungszwecke möchte man eine möglichst robuste und einfach zu wartende Kubernetes-Lösung einsetzen. Zwei beliebte Optionen hierfür sind – einmal mehr und auch von Chick-Fill-A genutzt – K3s sowie Talos.

Talos wird von SideroLabs entwickelt und ist eher Betriebssystem als nur Kubernetes-Plattform, wenn man es genau nimmt. Es spinnt quasi den Gedanken von K3s, eine gebündelte, vorkonfigurierte Zusammenstellung aller Komponenten bereitzustellen, einen Schritt weiter, und stellt direkt das Betriebssystem. Dieses ist minimal gehalten und immutable, was die Sicherheit drastisch erhöht und die Größe der zu installierenden Software minimiert. Sämtliche Konfiguration des Nodes und der Kubernetes-Installation darauf wird via API-Zugriffen vorgenommen.

Choose your Fighter

Wie eingangs erwähnt, sind die verschiedenen Umsetzungsmöglichkeiten einer Kubernetes-Installation schier endlos – weswegen auch dieser Artikel keinen Anspruch auf Vollständigkeit erhebt. Er kann allerdings trotzdem eine gute Übersicht über einige der momentan populärsten Lösungen geben und entspricht auch den von mir favorisierten Tools, um Kubernetes-Cluster in verschiedenen Umgebungen umzusetzen. Ich kann nur empfehlen, sich mit einigen aufgelisteten Lösungen vertraut zu machen, um ein Gespür dafür zu entwickeln, wie sich der Umgang mit Kubernetes auf verschiedenen Distributionen und Plattformen voneinander unterscheidet, angefangen bei einer lokalen Installation mit Docker/Rancher, und fortgeführt im eigenen Rechenzentrum oder der Cloud.

Daniel Bodky

Consultant

Lies mehr von Daniel und triff unser Team

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

von Daniel Bodky | Mrz 30, 2023 | Container, Docker, Kubernetes, NETWAYS, Technology, Serien

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

Hi! Ich bin Daniel, Open Source IT Consultant und großer Kubernetes-Fan. In der NETWAYS Blogserie “Alles rund um Kubernetes” nehme ich Dich mit auf eine Reise in die Welt der Container-Orchestrierung. Unter dem Überbegriff “Kubernetes 101” gebe ich dir regelmäßig Tipps, Hilfestellungen und meine Einschätzungen zur Arbeit mit K8s und wie du damit am besten umgehen kannst.
Angefangen bei einer Vorstellung des Tools selbst und der dahinterstehenden Ideologie über die Installation auf unterschiedlichen Betriebssystemen in verschiedensten Umgebungen bis hin zum Betrieb und der Absicherung eines Clusters werde ich auf viele Szenarien und Gesichtspunkte eingehen.

Heute geht es um die Architektur und die API eines Kubernetes Clusters. „Welche Teile des Clusters greifen wie ineinander?“, „Was sind grundlegende API-Ressourcen, die ich im Alltag brauche?“ Und „Wie greife ich auf sie zu?“
Und nun viel Spaß bei deinem Einstieg in die Container-Orchestrierung!

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

Consultant

Lies mehr von Daniel und triff unser Team

Kubernetes 101: Das ist Kubernetes und darum ist es genau richtig für dich!

von Daniel Bodky | Mrz 9, 2023 | Serien, NETWAYS, Automation

This entry is part 1 of 4 in the series Alles rund um Kubernetes

Hi! Ich bin Daniel, Open Source IT Consultant und großer Kubernetes-Fan. In der NETWAYS Blogserie “Alles rund um Kubernetes” nehme ich Dich mit auf eine Reise in die Welt von Kubernetes. Unter dem Überbegriff “Kubernetes 101” gebe ich dir regelmäßig Tipps, Hilfestellungen und meine Einschätzungen zur Arbeit mit Kubernetes und wie du damit am besten umgehen kannst.
Angefangen bei einer Vorstellung des Tools selbst und der dahinterstehenden Ideologie über die Installation auf unterschiedlichen Betriebssystemen in verschiedensten Umgebungen bis hin zum Betrieb und der Absicherung eines Kubernetes-Clusters werde ich auf viele Szenarien und Gesichtspunkte eingehen.

Um dir den Einsteig in Kubernetes so einfach wie möglich zu machen fangen wir zunächst einmal mit den Basics an. Ich beantworte die Fragen „Was ist Kubernetes eigentlich?“ „Warum ist es momentan so im Trend?“ Und „Könnte dir Kubernetes den Betrieb deiner Anwendungen erleichtern?“.
Und nun viel Spaß bei deinem Einstieg in die Container-Orchestrierung!

Egal, ob du bereits einmal versucht hast, online begehrte Tickets zu ergattern, dir bei einschlägigen Onlineshops einen Raspberry Pi zu sichern, oder in letzter Zeit einfach nur einmal ChatGPT ausprobieren wolltest, eine Sache hatten diese drei (völlig frei erfundenen) Szenarien mutmaßlich gemeinsam – die Websites waren langsam, crashten, oder ließen dich minuten- bis stundenlang in einer Warteschlange sitzen. Das liegt in den meisten Fällen ganz einfach daran, dass die Webserver bzw. dahinter gelagerten Backends der Flut an Anfragen nicht gewachsen sind. Hat man seine Anwendungen „traditionell“ auf VMs oder direkt auf Hardware installiert, fällt es mitunter schwer, kurzfristig auf solche Anfragespitzen zu reagieren. Die Folge aus Nutzersicht sind u.a. Serviceausfälle, Timeouts oder Drosselungen, was es natürlich zu vermeiden gilt. Hierbei kann Kubernetes helfen, und Ausfallsicherheit ist einer der am öftesten genannten Vorteile des Betriebs von Anwendungen auf Kubernetes – doch was ist Kubernetes überhaupt?

Was ist Kubernetes – und was ist es nicht?

Kubernetes ist ein ursprünglich von Google entwickelter Container-Orchestrator und war ursprünglich als interner Nachfolger für Borg gedacht. Mitte 2014 wurde Kubernetes dann von Google als Open Source Software releast. Im Rahmen des Releases der Version 1.0.0 am 21. Juli 2015 wurde es an die CNCF (Cloud Native Computing Foundation) überschrieben, eine Tochter-Foundation der Linux Foundation, die inzwischen eine große Anzahl an Projekten betreibt und verwaltet (s. CNCF Landscape). Die bei Veröffentlichung dieses Artikels aktuelle Version von Kubernetes ist v1.26. Wie der Begriff Container-Orchestrator bereits erahnen lässt, kümmert sich Kubernetes um den Betrieb von in Containern laufenden Anwendungen innerhalb eines sog. Clusters, also einer verteilten Umgebung auf mehreren Nodes, die bspw. auf VMs aufgesetzt werden und gemeinsam die Ressourcen des Clusters bereitstellen. Aspekte, um die sich Kubernetes kümmert, betreffen u.A.

Netzwerk: Wie können Container miteinander kommunizieren? Wie können Endnutzer und andere Dienste außerhalb des Clusters mit Cluster-internen Diensten kommunizieren?
Scheduling: Wie müssen/sollen/dürfen Container auf die verschiedenen Cluster-Nodes verteilt werden, sodass sie möglichst ausfallsicher/ressourceneffizient/gleichmäßig verteilt sind?
Berechtigungen: Welche Entität (Nutzer, Service, Systemaccount) darf in welchem Kontext was?
Servicediscovery: Welche Services sind in einem Cluster zu finden und reagieren auf (Nutzer-)Anfragen?
Flexibilität: Wieviel Last müssen meine Services gerade verarbeiten? Wie soll auf Spitzen reagiert werden?

Worum sich Kubernetes hingegen nicht kümmert, ist der tatsächliche Betrieb der Container auf den jeweiligen Nodes des Clusters – ganz im Gegenteil. Kubernetes ist zu einem großen Teil agnostisch gegenüber der genutzten Container-Runtime, sie muss lediglich konform zur von Kubernetes definierten Plugin-Schnittstelle CRI (Container Runtime Interface) sein. Das ermöglicht die Nutzung verschiedener Container-Runtimes wie bspw. containerd oder CRI-o je nach Anforderungen und Vorlieben.

Kubernetes kümmert sich ebenso wenig um Speicherverwaltung oder die Etablierung eines Cluster-internen Netzwerks, auch hierfür definiert es allerdings Schnittstellen, die von Plugins genutzt werden können, um solche Dienste zu ermöglichen: CSI (Container Storage Interface) bzw. CNI (Container Network Interface). Wichtig ist außerdem darauf hinzuweisen, dass Kubernetes deine Anwendungen nicht „magisch“ ausfallsicher macht – die Anwendungen müssen von vornherein dahingehend entworfen und entwickelt werden, dass sie Ausfallsicherheit bieten können, Kubernetes unterstützt dann bei der Realisierung.

Die Existenz der gerade besprochenen Schnittstellen für Runtimes, Netzwerk und Speicherverwaltung ist ein gutes Beispiel für eine von Kubernetes größten Stärken – der Abstrahierung und Standardisierung einer ganzen Bandbreite an Fähigkeiten und Voraussetzungen für den alltäglichen Betrieb von Anwendungen. Möglich macht das eine umfangreiche und bei Bedarf frei erweiterbare API, die den momentanen (und teilweise historischen) Zustand des Clusters für berechtigte Akteure zugänglich und manipulierbar macht. Mehr dazu gibt es im kommenden Blogpost zur Architektur von Kubernetes.

Container, Docker, Kubernetes – Warum der Hype?

Betrachtet man den Fokus auf Konferenzen rund um Softwareentwicklung- bzw. -betrieb seit ca. 2017/8, sind Themen im Blickpunkt fast immer Kubernetes, Docker, Container, oder alle drei gemeinsam. Softwareentwicklung befindet sich seitdem im Wandel, weg von sog. Monolithen, die sämtliche Bestandteile einer Applikation als ein „Bündel“ beinhalten, hin zu einer Flotte an Microservices, die voneinander unabhängig entwickelt, getestet, installiert und skaliert werden können. Aufgrund der abgespeckten Größe dieser Microservices bietet sich eine Installation in von Betriebssystemen weitestgehend unabhängigen Containern an, was die Flexibilität weiter erhöht.

Der de-facto Standard sowohl für die Definition und Paketierung dieser Container in sog. Images als auch für die Entwicklung der beinhalteten Software auf den lokalen Rechnern der Entwickler ist Docker. Benötigt man im alltäglichen, produktiven Betrieb der Microservices in ihren Kombinationen dann eine Vielzahl von Containerinstanzen, wird es Zeit für einen Orchestrator: Kubernetes. Aus diesen Zusammenhängen ergibt sich die seit Jahren steigende globale Popularität und Adaptierung von Containern, Docker und Kubernetes bei vielen Unternehmen, von Fortune 10 Companies bis zu Startups.

In der Theorie ermöglicht die bereits erwähnte umfangreiche Kubernetes-API in Kombination mit den offenen, wohl-definierten Schnittstellen den für den Betrieb der Cluster zuständigen Plattformteams, je nach Bedarf vorhandene oder interne Dritt-Software einzubinden, um gewünschtes Verhalten der Plattform als Ganzes zu erzielen oder existierendes Verhalten zu erweitern oder zu präzisieren.
Gleichzeitig ermöglicht es Entwicklern, sich durch die Kapselung von Software in Microservices sowie die Abstraktion der späteren Laufzeitumgebung durch Kubernetes, sich voll und ganz auf ihre Software zu konzentrieren und gleichzeitig schneller Feedback zu bekommen – CI/CD (Continuous Integration/Continuous Delivery) ist gelebter Alltag auf und mit Kubernetes. In der Praxis ist das „Unterfangen Kubernetes“ natürlich nicht ganz so einfach – sonst würde ich nicht hier sitzen und diese Artikelserie schreiben.

Ist Kubernetes etwas für mich und meine Anwendungen?

Als Consultant muss ich hier natürlich antworten „Das kommt darauf an…“ – nutzt du/dein Unternehmen evtl. bereits heute Container für den Betrieb von Applikationen bspw. mittels Docker Compose oder Docker Swarm? Dann ist Kubernetes lediglich der nächste logische Schritt, zumal die beiden genannten Lösungen ab einer gewissen Größe und einem gewissen Anforderungsproblem nicht mehr flexibel und skalierbar genug sein werden.
Erfahrung zeigt, dass gerade zustandslose („stateless“) Applikationen verhältnismäßig einfach auf Kubernetes migrierbar sind und enorm von den „Bordmitteln“ eines Kubernetes-Clusters profitieren (Loadbalancing, Scheduling auf verschiedene Nodes, Servicediscovery, usw.). Doch auch wenn ihr größtenteils zustandsbehaftete („stateful“) Applikationen im Einsatz habt oder noch „klassisch“, ohne den Einsatz von Containern, deployed, ist das im Jahr 2023 kein zwingendes Argument gegen Kubernetes mehr.

Grundsätzlich bist du sicherlich gut damit beraten, dir Kubernetes einmal anzuschauen, wenn du von mindestens einem der oben erwähnten Vorteile (Containernetzwerk, Scheduling, Berechtigungsmanagement, Servicediscovery, Flexibilität) im Gegensatz zu der momentan im Einsatz befindlichen Infrastruktur (Hypervisors, Baremetal, Cloud ohne Kubernetes) profitieren könntest. Es gibt Ressourcen, Tools und Hilfsmittel für fast alle denkbaren Szenarien rund um Anwendungsentwicklung und -betrieb, und ansonsten sind wir mit unserem Schulungs– und Beratungsangebot rund um Kubernetes ja auch noch da. Und nicht zuletzt folgen noch einige Blogartikel in dieser Serie, die hoffentlich das ein oder andere Fragezeichen wegwischen werden.