Evaluation und Betrieb von Kubernetes

Für mein Unternehmen und meine Arbeit als Consultant und Entwickler 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 verschiedene Kubernetes-Distributionen und Managed Kubernetes Services evaluiert. Diese Kubernetes-Angebote zähle ich nachfolgend in alphabetischer Reihenfolge ihrer Namen auf. Fast alle davon habe ich mehrere Monate lang verwendet.

• 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.

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 sowie der Kubernetes Software gegen monatliches Entgelt übernimmt, ggf. mit verschiedenen Optionen in Bezug auf Hochverfügbarkeit, Backups, Wiederherstellung, Updates, Monitoring und Skalierung.

Installiert man Kubernetes selbst, darf man einen Punkt nicht übersehen. Kubernetes muss immer an die spezifischen technischen Gegebenheiten der Systemumgebung des Rechenzentrums bzw. des Cloud Providers angepasst und darin integriert werden. Das verursacht Arbeit und das erfordert Expertise. 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.

Selbstbetrieb von Kubernetes: Pro & Contra

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 notwendig, 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 Argument gegen Kubernetes sollte man diese Tugenden professioneller Arbeit aber nicht bewerten.

Denn ordentliche Administratoren schreiben eine ordentliche Dokumentation, die sich an professionelle Administratoren richtet. Qualität ist dabei wichtiger als Quantität, denn ein gemeinsames technologisches Wissen darf und muss vorausgesetzt werden. Nachlässige Administratoren dokumentieren allerdings nichts oder nur formal ohne relevanten Inhalt. Wer gut organisiert, engagiert und diszipliniert arbeitet und wer ausreichend Erfahrung als Systemadministrator hat, der kann den Betrieb eines Kubernetes Clusters bewältigen.

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.

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.

Bewertung der Alternativen

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 zu entwickeln, dass sie in der Infrastruktur von Kunden reibungslos laufen. Ich gewinne so ein größeres Verständnis für die Anforderungen von Unternehmenskunden beim laufenden Betrieb ihrer ggf. sehr großen Anwendungslandschaft sowohl in eigenen Rechenzentren als auch in der Cloud.

Derzeit sind aus meiner Sicht die Kosten für viele Managed Services übertrieben hoch und aufgrund sehr komplexer Preismodelle schwer zu prognostizieren und noch schwerer zu senken. Einige Provider reichen die wirtschaftlichen Vorteile der Automatisierung beim Betrieb von Infrastruktur nicht an ihre Kunden weiter, sondern berechnen stattdessen enorm hohe Preise, als ob ihre Mitarbeiter jedes Kilobyte an Daten persönlich von Hand berechnen und an das Internet ausliefern würden.

Viele Managed Services bieten nicht unbedingt die beste Leistung, sondern vor allem mehr Komfort. Für mich ist es wichtig, dass mich hohe Preise für automatisierte Dienstleistungen nicht daran hindern, moderne Technologien zu nutzen. Hohe Preise sind ein negativer Anreiz. Mir sind Leistung, ein gutes Preis-Leistungs-Verhältnis und ein funktionierender Wettbewerb wichtig, wenn es um Outsourcing von Dienstleistungen geht. Sobald die Preise für Managed Services sinken, werde ich diese stärker in Anspruch nehmen, soweit sie meine Freiheit nicht einschränken.

Kubernetes in der Hetzner Cloud

Nach intensiven und langen Tests und Analysen habe ich mich dazu entschieden, 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. Das gilt noch nicht für alle Kubernetes Distributionen, weil Hetzner lange Zeit nur Rechenzentren in Deutschland betrieben hat und somit das internationale Interesse geringer war, sich mit der Integration von Kubernetes in die Hetzner Cloud zu befassen. Das ändert sich aber allmählich, weil Hetzner mittlerweile Rechenzentren in der EU, in Nordamerika und Asien betreibt. Hinzu kommt, dass Hetzner auch Open Source Software veröffentlicht, um den Betrieb von Kubernetes auf virtuellen Servern in der Hetzner Cloud zu unterstützen.

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.

Die Hetzner Cloud bietet den Vorteil, dass die Infrastruktur sowohl kostengünstig als auch performant und stabil 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.

Für mein Unternehmen betreibe ich mehrere Kubernetes Cluster in der Hetzner Cloud für Entwicklung, Test und Produktion. Der Control Plane jedes Kubernetes 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.

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. 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.

Flux unterstützt Werkzeuge wie Kustomize und Helm, was es erleichtert, Erweiterungen und Anwendungen auf dem Cluster zu installieren und zu aktualisieren. Der Infrastruktur-Code, auf den Flux zugreift, um die Kubernetes Cluster zu verwalten, verwalte ich in einem GitHub Repository, aber auch jedes andere Git Repository wäre für Flux 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 Git Repository. Flux liest diesen Code dann automatisch und installiert und konfiguriert entsprechend die darin spezifizierte Software.

Flux lässt sich über Webhooks, Container Repositories und Code 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 kubectl und K9s, aber im Grunde nur lesend, weil die eigentliche Administration der Cluster über Flux, OpenTofu und Ansible erfolgt, wie ich gerade 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.

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.