Erfahrungen aus der Evaluation und dem Betrieb von Kubernetes

Für mein Unternehmen und meine Arbeit als Consultant und Entwickler von Software ist es wichtig, eine stabile, sichere und flexible Lösung für die Verwaltung von Container-Anwendungen zu betreiben. Daher habe ich über einen langen Zeitraum unterschiedliche Kubernetes-Distributionen und -Dienste getestet und die meisten davon mehrere Monate lang betrieben.

Diese Kubernetes-Distributionen und -Dienste zähle ich nachfolgend in alphabetischer Reihenfolge ihrer Namen auf. Einige der genannten Kubernetes Distributionen sind kostenlose quelloffene Softwarepakete, die man auf eigenen oder gemieteten Servern installieren kann. Andere sind sog. Managed Kubernetes Services, also Infrastruktur-Dienstleistungen, bei denen ein Cloud Provider die Verwaltung der Infrastruktur einschließlich der Installation und Updates der Betriebssysteme und der Kubernetes Software gegen monatliches Entgelt übernimmt, ggf. mit verschiedenen Optionen in Bezug auf Hochverfügbarkeit, Backups, Wiederherstellung, Updates, Monitoring und Skalierung.

• Amazon Elastic Kubernetes Service (EKS) ist ein Managed Kubernetes Service von Amazon Web Services. Dieses Angebot sehe ich immer wieder bei größeren Kunden im Einsatz, die sich das Entgelt gut leisten können, um den ggf. nicht unerheblichen Personalaufwand für die Administration zu ersparen, der damit verbunden ist, eigene Infrastruktur mit Betriebssystemen und Kubernetes Distributionen zu betreiben.

• Google Kubernetes Engine (GKE) ist ein Managed Kubernetes Service innerhalb der Google Cloud Platform. Da Google bekanntlich Kubernetes erfunden und später als quelloffene Software freigegeben hat, war es für mich wenig überraschend, dass die GKE reibungslos funktioniert hat, wenn man das entsprechende Entgelt dafür bezahlt.

• K3S ist eine leichtgewichtige und ressourcenschonende quelloffene Kubernetes Distribution, die ursprünglich von Rancher bzw. SUSE entwickelt wurde und deren Namensrechte jetzt bei der Linux Foundation liegen.

• Linode Kubernetes Engine (LKE) ist ein Managed Kubernetes Service von Linode, das mittlerweile zu Akamai gehört. Die Linode Cloud stellt weniger Services als beispielsweise Amazon Web Services oder die Google Cloud Platform zur Verfügung, aber sie ist kostengünstiger und der Kubernetes Cluster lief solide.

• MicroK8s ist eine ressourcenschonende Kubernetes Distribution von Canonical, die sich auch gut für Edge-Computing und lokale Entwicklungsumgebungen eignet. Sie ist relativ stark in das Ökosystem von Ubuntu eingebunden und die Entwickler bemühen sich, den Lern- und Installationsaufwand für Einsteiger gering zu halten.

• Rancher ist eine etwas schwergewichtigere Kubernetes Distribution mit einer umfangreichen grafischen Benutzerschnittstelle, die auch Funktionen zur Administration von Multi-Cluster-Umgebungen und von Erweiterungen unterstützt.

• RKE2 ist eine leichtgewichtige Kubernetes-Distribution von Rancher, das seit 2020 zu SUSE gehört. Sie konzentriert sich auf Sicherheit und Compliance mit den Anforderungen der Regierung und Bundesbehörden der Vereinigten Staaten.

• Talos Linux ist eine gehärtete, unveränderbare Linux Distribution von Sidero Labs, die Kubernetes beinhaltet und die mit Hilfe einer eigenen API und einem eigenen Werkzeug auf der Ebene der Kommandozeile verwaltet wird.

Jede dieser Distributionen hat ihre Stärken und Schwächen, und im Laufe meiner Projekte und Untersuchungen hat sich für mich herausgestellt, dass die Wahl der richtigen Kubernetes Distribution von den spezifischen Anforderungen und der technischen Umgebung abhängt, ebenso von den technischen Vorkenntnissen im Bereich Linux Administration und Container, die man als Anwender bzw. als Team mitbringt und/ oder die man erlernen möchte, was zweifelsfrei Zeit und Geld kostet.

K3S in der Hetzner Cloud

Nach intensiven und langen Tests entschied ich mich dazu, für mein Unternehmen die Kubernetes-Distribution K3S in der Hetzner Cloud im Zusammenspiel mit einigen anderen Managed Services von Cloudflare und Amazon Web Services zu verwenden.

K3S ist sehr stabil, performant und ressourcenschonend und bei Bedarf auch sehr hoch skalierbar. K3S hat eine gute Dokumentation und eine sehr aktive Community, von der sich ein Teil auch intensiv mit der Hetzner Cloud befasst.

Kubernetes Distributionen bzw. Cluster müssen an die spezifischen technischen Gegebenheiten der Systemumgebung des Rechenzentrums bzw. des Cloud Anbieters angepasst und darin integriert werden. Eine gute Dokumentation und Support sowie eine aktive Community sind von unschätzbarem Wert, um Hilfe bei Problemen zu erhalten und die komplexen Anforderungen zu bewältigen.

Hetzner betrieb lange Zeit Rechenzentren nur in Deutschland bzw. in der EU, wodurch Hetzner trotz der mittlerweile erfolgten Expansion nach Nordamerika und Asien und trotz der vielen Vorzüge des Angebots international derzeit noch weniger bekannt ist als andere Cloud Anbieter.

Deshalb neigen Entwickler und Nutzer diverser Kubernetes Distributionen dazu, sich mehr mit den Eigenarten anderer Cloud Provider zu befassen und die Hetzner Cloud mit ihren technischen Eigenarten ein wenig zu vernachlässigen.

Für den Betrieb von K3S in der Hetzner Cloud findet man online verhältnismäßig viele Informationen, Artikel, Beiträge und Tipps, die sich mit diversen technischen Aspekten des Betriebs befassen, wenn auch nicht unbedingt auf der Website von K3S.

Vermutlich wird das Angebot an Informationen auch für den Betrieb anderer Distributionen nach und nach größer werden. Die Kubernetes Community wächst und sie ist sehr umtriebig, dynamisch und innovativ.

Für mein Unternehmen betreibe ich K3S-Cluster in mehreren Umgebungen in der Hetzner Cloud für Entwicklung, Test und für den produktiven Betrieb von Anwendungen. Der Control Plane jedes K3S Clusters besteht dabei aus drei Instanzen und ist damit hochverfügbar. Außerdem sind derzeit in jedem Kubernetes Cluster vier Worker Nodes im Einsatz.

Diese verhältnismäßig kleine, aber ausreichend große Anzahl von Nodes ermöglicht bereits eine horizontale Skalierung der Anwendungen und macht es zugleich möglich, dass man die Server des Clusters nach und nach aktualisieren und neu starten kann, ohne den laufenden Betrieb der Anwendungen und Datenbanken zu unterbrechen, die im Kubernetes Cluster laufen.

Die Hetzner Cloud bietet den Vorteil, dass die Infrastruktur sowohl kostengünstig als auch performant ist. Die Kubernetes Cluster laufen auf Servern mit ARM CPUs, die kostengünstig, ausreichend performant und zugleich sehr energieeffizient sind, was sowohl für die Umwelt als auch für das Budget vorteilhaft ist.

Infrastructure as Code, DevOps und GitOps

Die Ressourcen in der Hetzner Cloud und bei Amazon Web Services verwalte ich mit OpenTofu, einem Fork von HashiCorp Terraform. OpenTofu ist ein Projekt der Linux Foundation. Die Betriebssysteme auf den virtuellen Servern der Kubernetes Cluster halte ich mit Ansible Playbooks aktuell.

Um die Verwaltung und Aktualisierung der Kubernetes Cluster effizient zu gestalten, setze ich auf Flux, ein Werkzeug zur GitOps-Integration. Flux unterstützt Werkzeuge wie Kustomize und Helm, was es erleichtert, Erweiterungen und Anwendungen auf dem Cluster zu installieren und zu aktualisieren.

Mit Flux synchronisiere ich die Kubernetes Cluster mit Code in Git- und Helm-Repositories und automatisiere die Aktualisierung der Software und ihrer Konfiguration, die im Cluster installiert ist, sobald neuer Code bereitgestellt wird.

Der Infrastruktur-Code, auf den Flux zugreift, um die Kubernetes Cluster zu verwalten, wird in einem Forgejo Git Repository verwaltet, aber auch jedes andere Git Repository wäre dafür geeignet.

Wenn beispielsweise ein Kubernetes Operator oder eine selbst entwickelte Anwendung in den Cluster installiert werden soll, dann schreibe ich den entsprechenden Infrastruktur-Code und publiziere diesen im Forgejo Git Repository. Flux wendet diesen Code dann automatisch an, installiert und konfiguriert die Software.

Flux lässt sich über Webhooks, Container Repositories und Code auch sehr gut mit CI/CD-Pipelines integrieren und ermöglicht so ein nahtloses Zusammenspiel bei der Automatisierung des Deployments von Anwendungen in die Infrastruktur.

Für die Administration und Analyse der Cluster nutze ich außerdem kubectl und K9s, aber im Grunde nur lesend, weil die eigentliche Administration der Cluster über Flux, OpenTofu und Ansible erfolgt, wie ich bereits ausgeführt habe. K9s ist eine ausgesprochen nützliche terminalbasierte Benutzeroberfläche zur Visualisierung und Administration von Kubernetes Clustern, mit der man sich sehr schnell einen Überblick über viele technische Details eines Clusters verschaffen kann.

Ingress, Security und Secrets

Anstelle eines herkömmlichen Kubernetes Ingress Controllers, der oft in Verbindung mit Load Balancern des Cloud Providers eingesetzt wird, nutze ich Cloudflare Tunnel. Diese Lösung bietet eine sichere und verschlüsselte Verbindung zwischen den Kubernetes Clustern und den Rechenzentren von Cloudflare, sodass die Cluster nicht direkt dem öffentlichen Internet ausgesetzt sind.

Durch die Nutzung von Cloudflare Tunnel stehen alle Performance- und Sicherheitsfunktionen von Cloudflare zur Verfügung, wie beispielsweise CDN, TLS, DDoS-Schutz, Abwehr von Bots und eine Web Application Firewall.

Ein weiteres wichtiges Element im Betrieb der Kubernetes Cluster ist das Management von Secrets und Zugangsdaten. Hier setze ich auf den AWS Secrets Manager in Kombination mit External Secrets, einem Kubernetes Operator, der mit AWS Secrets Manager und anderen externe Secret-Management-Systeme interagieren kann. Zugangsdaten, Passwörter und sicherheitsrelevante Konfigurationsdaten werden sicher im AWS Secrets Manager verwaltet und über den External Secrets Operator als Secrets in den Kubernetes Cluster eingebunden.

PostgreSQL im Kubernetes Cluster

Für die Verwaltung von PostgreSQL-Datenbanken setze ich auf CloudNativePG, einen Kubernetes Operator, der wahlweise eine oder mehrere hochverfügbare und sehr performante PostgreSQL-Datenbanksysteme mit einer Primary/Standby-Architektur und Streaming Replication innerhalb von Kubernetes bereitstellt. Die Datenbank-Backups, darunter WAL-Archive und Base Backups, werden regelmäßig in Amazon S3 Bucket Buckets gespeichert, um eine langfristige Datensicherheit zu gewährleisten.

Argumente für einen Selbstbetrieb von Kubernetes

Auch wenn alle getesteten Kubernetes-Distributionen nach meiner Erfahrung gut funktionieren, ist der Selbstbetrieb von Kubernetes eine nicht zu unterschätzende Herausforderung. Updates und Wartungen erfordern oft tieferes technisches Verständnis und sie erfordern ein beachtliches Maß an Lernaufwand, zumal Kubernetes ständig weiter entwickelt wird, ebenso wie die Infrastrukturen in den Rechenzentren der Cloud Anbieter, die technisch natürlich nicht einheitlich aufgebaut sind, sondern erhebliche Unterschiede aufweisen. Dabei spielt beispielsweise die Konfiguration der Netzwerke eine besondere Rolle und sie kann eine intellektuelle Herausforderung darstellen.

Organisiertes Arbeiten und Selbstdisziplin sind zweifelsfrei erforderlich, um Kubernetes Cluster in einem Unternehmen erfolgreich selbst zu betreiben. Monitoring und Betriebsdokumentation sind unentbehrlich, denn Systemadministratoren machen Urlaub, werden krank, gehen in Rente oder wechseln das Unternehmen.

Als Argumente gegen Kubernetes sollte man diese Tugenden professioneller Arbeit aber nicht bewerten. Denn ordentliche Administratoren schreiben eine ordentliche Dokumentation. Weniger ordentliche Administratoren dokumentieren dagegen nichts oder nur rein formal ohne relevanten Inhalt. Dabei kommt es nicht darauf an, ob man Kubernetes oder ein anderes System administriert bzw. betreibt. Wer gut organisiert, engagiert und diszipliniert arbeitet und wer ausreichend Erfahrung als Systemadministrator hat, der kann den Betrieb eines Kubernetes Clusters bewältigen. Aber ohne diese Tugenden wird das dauerhaft nicht gut gehen.

Das wichtigste Argument für einen Selbstbetrieb ist wahrscheinlich das Argument der Kontrolle. Letztendlich geht es um die Frage von Insourcing vs. Outsourcing. Beim Insourcing hat das Unternehmen einen Vendor Lock-In bei den eigenen Mitarbeitern. Die erforderliche Software ist dagegen quelloffen und die Lizenzen anwenderfreundlich.

Beim Outsourcing hat das Unternehmen einen Vendor Lock-In bei einem Cloud Provider. Viele Cloud Provider und Dienstleister wollen nur standardisierte Dienstleistungen zu standardisierten Preisen anbieten, weil sie dadurch eine hohe Marge erzielen. Alles gute Zureden wird daran im Zweifelsfall nicht viel ändern.

Im eigenen Unternehmen hat es das Management selbst in der Hand, eine produktive und flexible Unternehmenskultur zu schaffen, an der alle Beteiligten ihre Freude haben.

Als Consultant und Softwareentwickler ist es mir seit vielen Jahren sehr wichtig, mich nicht nur mit der Konzeption und Programmierung von Anwendungen zu befassen, sondern auch mit technischen Details im Bereich der Administration von Linux Servern und von Netzwerken, weil mir das beispielsweise dabei hilft, sinnvolle System- und Softwarearchitekturen zu planen, Fehler im laufenden Betrieb zu verstehen und Anwendungen so zu planen und entwickeln, dass sie in der Infrastruktur von Kunden reibungslos laufen.

Ich gewinne so ein größeres Verständnis für die Bedürfnisse von Unternehmenskunden beim laufenden Betrieb ihrer ggf. sehr großen Anwendungslandschaft sowohl in eigenen Rechenzentren als auch in der Cloud.

Argumente gegen einen Selbstbetrieb von Kubernetes

Für Unternehmen, deren Schwerpunkt nicht im Bereich von IT und Software liegt und die ihre Softwareanwendungen möglicherweise sogar extern entwickeln und betreiben lassen, kann es organisatorisch und wirtschaftlich
vorteilhaft sein, mit einem kleinen IT-Team die Managed Kubernetes Services eines Cloud Anbieters zu verwenden, anstatt eigene Kubernetes Cluster zu betreiben.

Dahinter steckt letztendlich das Prinzip der Spezialisierung und der Arbeitsteilung, und es ist geradezu eine Binsenweisheit, dass Spezialisierung und Arbeitsteilung für alle Beteiligten große wirtschaftliche Vorteile bieten kann.

Als Manager oder Mitarbeiter eines großen finanzstarken Unternehmens weiß man natürlich, dass man genügend finanzielle Ressourcen hat, um viele IT-Spezialisten zu beschäftigen. Man wird daher vielleicht auch Kubernetes Cluster selbst betreiben wollen. Allerdings benötigt man dafür auch wirklich qualifiziertes Management und Fachpersonal. Aber selbst das reicht im Grunde noch nicht.

Man sollte nicht unterschätzen, dass der Selbstbetrieb von Kubernetes in einem Unternehmen eine sehr starke Serviceorientierung der Administratoren und ihrer Manager gegenüber den Kolleginnen und Kollegen aus anderen Abteilungen erfordert, die diese Cluster lediglich nutzen und die naturgemäß sehr viel weniger über die spezifischen technischen Details dieser Cluster wissen.

Auf dem freien Markt erhalten die Anwender von Kubernetes von diversen Cloud Providern oft gute Dokumentationen und gelegentlich auch guten Support, mindestens können sie aber externe Berater engagieren und direkt in ihre Teams integrieren, die sich damit auskennen.

Unternehmensinterne Dienstleister wollen ihr Personal oft nicht in die Teams von Anwendern integrieren, was den Know How Transfer erschweren kann. Sie genießen außerdem oft ein internes Monopol, weil das Management verbietet, externe Cluster zu verwenden. Es fehlt dann also an Leistungswettbewerb und an finanziellen Anreizen.

Aber auch wenn ein interner Dienstleister hoch motiviert ist, so hat er regelmäßig strukturelle Nachteile: nur selten darf ein interner Dienstleister seine Dienstleistungen auf dem freien Markt anbieten, was wiederum alle Ansätze zur Automatisierung und Rationalisierung sehr schnell unwirtschaftlich macht. Man hat zwar fast denselben Aufwand wie ein Cloud Provider, der Kubernetes Cluster betreibt, aber man hat nur einen winzigen kleinen Markt, auf dem man tätig ist. Möglicherweise wird dann etwas zu viel am Betrieb gespart und es entstehen dann technische Schulden.

Hinzu kommt, dass ein Selbstbetrieb von Kubernetes derzeit nur wenig standardisiert ist, weil Kubernetes nur eine Art von Softwarekern darstellt, der mit vielen “Plugins” erweitert wird. Es macht außerdem für die Anwender technologisch oft einen sehr großen Unterschied, ob man eine Kubernetes Version betreibt, die ein Jahr alt oder die drei Jahre alt ist.

Nach meiner Beobachtung wird der erforderliche Aufwand für den Selbstbetrieb oft unterschätzt. Unmöglich ist das freilich nicht, aber das Management sollte sich sicher sein, dass es beim Betrieb von IT-Infrastruktur bereits erfolgreich war und darin investieren möchte und dass es ausreichend qualifiziertes Personal im Unternehmen beschäftigt. Zweifelsfrei gibt es Unternehmen, die damit erfolgreich sind.

Fazit

Es gibt viele gute Kubernetes Distributionen und immer mehr Cloud Provider, die Kubernetes als Managed Service anbieten. Die von mir evaluierten Distributionen und Dienste stellen nur einen kleinen Ausschnitt aus dem tatsächlichen Angebot dar.

Der Aufbau und Betrieb einer Kubernetes-Infrastruktur mit Infrastructure as Code, GitOps und CI/CD erfordert zweifelsfrei einen hohen Lernaufwand. Man benötigt viel technisches Know-how und ein gutes Verständnis der spezifischen Anforderungen an die jeweilige Umgebung und Unternehmung.

Für mein Unternehmen und mich hat sich K3S in der Hetzner Cloud bislang als tragfähige Lösung erwiesen, die durch Werkzeuge wie Flux, Cloudflare Tunnel und External Secrets ergänzt wird. Dabei ist zu berücksichtigen, dass ich ganz bewusst viel Zeit investiere, um zukunftsfähige Technologien zu erlernen und zu evaluieren.

Zweifelsfrei stellen andere Kubernetes Distributionen und andere Cloud Provider sehr gute Alternativen dar. Managed Kubernetes bietet oft mehr Komfort, spart viel Arbeitszeit für die Systemadministration und für das Training, allerdings zu höheren Entgelten, die man an den Service Provider zahlt.

Die Kosten gegeneinander abzuwägen, ist eine Rechen-, Prognose- und Controlling-Aufgabe für Management und Spezialisten. Strategische Aspekte, beispielsweise der Umgang mit Vendor Lock-Ins oder die Frage, ob und welche Tätigkeiten man überhaupt outsourcen möchte, lassen sich meiner Meinung nach nicht alleine auf Basis von Kosten sinnvoll entscheiden.

Trotz der Komplexität von Kubernetes bieten jedenfalls alle o. g. Werkzeuge und Dienstleister nach meiner Einschätzung eine solide Grundlage für einen skalierbaren und effizienten Betrieb von containerisierten Anwendungen und Datenbanken.