Technischer Kubernetes-Support: Den Cluster aufzusetzen ist die einfachste Etappe

WebDisk-Blog · Kategorie: Public Cloud · Lesezeit: ~7 Minuten

Kurz gefasst:- Ein Kubernetes-Cluster sieht am Tag der Inbetriebnahme am besten aus. Die eigentliche Arbeit beginnt später: drei Releases pro Jahr, Sicherungen der etcd-Datenbank, Monitoring, Sicherheit und jemand, der nachts den Alarm entgegennimmt.- Guter technischer Support ist nicht „Hilfe, wenn etwas nicht mehr funktioniert“, sondern ein kontinuierlicher Prozess: Updates, ein getestetes Backup, Einblick in das, was im Cluster geschieht (Observability), und klare Regeln für die Reaktion.- In der WebDisk-Cloud starten Sie einen verwalteten Kubernetes-Cluster (WebDisk K8s) oder bauen einen eigenen auf der IaaS-Infrastruktur – und bei der Planung der Migration und der Konfiguration hilft unser Team. >Sie arbeiten nicht mit dem Terminal? Überspringen Sie den einzigen Befehlsblock im Artikel – der ganze Rest kommt ohne ihn aus.

Kubernetes ist zum Standard für den Betrieb von Anwendungen aus Microservices geworden – kleinen, unabhängig bereitgestellten Diensten – auch in Unternehmen, die keineswegs „mit der Cloud“ angefangen haben. Das typische Bild in Firmen, die ihre Software seit Jahren weiterentwickeln, sieht so aus: Ein Teil der Systeme läuft auf klassischen virtuellen Maschinen, ein Teil in Docker-Containern oder in Docker Swarm (einer älteren, einfacheren Methode, Container auf mehreren Servern zu betreiben), und erst die neuesten Projekte laufen in einem Kubernetes-Cluster. Eine solche hybride Umgebung ist kein Rückstand, der aufgeholt werden müsste, sondern das natürliche Ergebnis aufeinanderfolgender, vernünftiger Entscheidungen über Jahre hinweg.

Darin steckt jedoch eine Falle, über die seltener gesprochen wird als über die Migration selbst: ein aufgesetzter Cluster ist nicht dasselbe wie ein gewarteter Cluster. Kubernetes in Betrieb zu nehmen war nie einfacher; ihn über die kommenden Jahre gesund zu halten, erfordert nach wie vor Arbeit, Wissen und Bereitschaftsdienste. In diesem Artikel zeigen wir, worin diese Arbeit besteht, was guter technischer Kubernetes-Support umfassen sollte und wie Kubernetes in der WebDisk-Cloud aussieht.

Der Text richtet sich sowohl an Teams, die eine Migration erst erwägen, als auch an jene, die bereits einen Cluster haben – und sich ehrlich die Frage beantworten wollen, wer eigentlich auf ihn aufpasst.

Warum ist das Aufsetzen eines Kubernetes-Clusters erst der Anfang?

Das Aufsetzen eines Clusters ist heute eine Frage von Stunden – Installer und Cloud-Plattformen haben den Administratoren den Großteil der früheren Komplexität abgenommen. Die Schwierigkeit hat sich anderswohin verlagert: zu allem, was nach der Inbetriebnahme geschieht. Vier Beispiele:

• Der Release-Zyklus. Kubernetes veröffentlicht drei Releases pro Jahr, und jedes erhält etwa 14 Monate lang Korrekturen – darunter Sicherheitsupdates. Ein Cluster, der seit gut einem Jahr nicht aktualisiert wurde, fällt aus diesem Fenster heraus, und das Aufholen ist kein einzelner Sprung: Die Versionen werden der Reihe nach angehoben, ohne etwas zu überspringen.
• Auslaufende APIs. Aufeinanderfolgende Releases entfernen veraltete Schnittstellen. Ein Deployment-Manifest, das zwei Jahre lang einwandfrei funktioniert hat, kann sich nach einem Update nicht mehr anwenden lassen – deshalb ist die Überprüfung der verwendeten APIs Bestandteil jedes geplanten Updates.
• Zertifikate. Die Cluster-Komponenten authentifizieren sich gegenseitig mit TLS-Zertifikaten von begrenzter Gültigkeit – in typischen Installationen ist das ein Jahr. Ein abgelaufenes Zertifikat der Verwaltungsebene (Control Plane) kann die Administratoren an einem einzigen Morgen vom Cluster abschneiden.
• etcd. Das ist die Datenbank, in der der Cluster seinen gesamten Zustand speichert: Deployment-Definitionen, Konfiguration, Secrets. Ohne regelmäßige etcd-Sicherung – und ohne getestete Wiederherstellung – bedeutet ein schwerer Ausfall der Control Plane den Neuaufbau des Clusters von Grund auf.

Keiner dieser Punkte ist exotisch; das ist gewöhnliche, wiederkehrende Administration. Die Frage ist nur, ob jemand in der Organisation sie zu seinen Pflichten zählt – oder ob sie eher „nebenbei“ geschieht, solange sie geschieht.

Was sollte guter technischer Kubernetes-Support umfassen?

Wenn Sie ein Support-Angebot bewerten – ein externes oder die Möglichkeiten Ihres eigenen Teams –, prüfen Sie, ob es fünf Bereiche abdeckt:

1. Updates und Lebenszyklus. Geplante Update-Fenster für Control Plane und Nodes, die Überprüfung auslaufender APIs vor jeder Versionsanhebung, die Überwachung der Zertifikatsgültigkeit. Langweilig – und genau deshalb ist das das Erste, was aus dem Kalender eines überlasteten Teams fällt.
2. Backup und Wiederherstellungstest. Regelmäßige Sicherung von etcd sowie – separat – der Anwendungsdaten auf den Volumes. Ein Backup, das niemand je wiederhergestellt hat, ist kein Backup, sondern nur eine Hoffnung; die Grundsätze eines sinnvollen Backups beschreiben wir ausführlicher im Artikel Backup in der Cloud: das Fundament der IT-Sicherheit.
3. Monitoring und Alerting. Metriken der Control Plane, der Nodes und der Anwendungen selbst sowie Alerts, die den Bereitschaftsdienst erreichen – auf Seiten des Anbieters oder auf Ihrer; das ist einer der am häufigsten übergangenen Vertragspunkte, klären Sie ihn also rechtzeitig. Wichtig ist auch das Feintuning: Ein System, das hundertmal am Tag ohne Grund Alarm schlägt, bringt Menschen bei, Alarme zu ignorieren.
4. Sicherheit. Rollenbasierte Zugriffskontrolle (RBAC – der Kubernetes-Mechanismus, der entscheidet, wer welche Operation ausführen darf), Systemupdates auf den Nodes, das Scannen von Container-Images auf bekannte Schwachstellen, Netzwerkrichtlinien zwischen den Diensten. Wie wir selbst die Sicherheitsschichten unserer Plattform aufbauen, erzählen wir im Artikel Der Open-Source-Sicherheitsstack bei WebDisk.
5. Reaktion auf Vorfälle. Ein festgelegter Meldeweg, eine klare Aufteilung der Verantwortung zwischen Anbieter und Kunde sowie Prozeduren für Notfallszenarien – niedergeschrieben, bevor sie gebraucht werden.

Wenn Sie den Zustand Ihres eigenen Clusters schnell überprüfen möchten, beginnen Sie mit drei Befehlen:

# welche Version der API-Server hat — vergleichen Sie sie mit dem Release-Kalender von Kubernetes (Korrekturen ~14 Monate)
kubectl version

# Zustand der Nodes und Konsistenz ihrer Versionen
kubectl get nodes -o wide

# Warnungen aus dem gesamten Cluster
kubectl get events -A --field-selector type=Warning

Und eine Frage, die kein Befehl beantworten wird: Wann hat zuletzt jemand eine etcd-Sicherung in einer Testumgebung wiederhergestellt? Wenn die Antwort „nie“ lautet – dann ist das der erste Punkt für die Aufgabenliste, noch vor dem Gespräch über den Ausbau des Clusters.

Die Migration ist ein Prozess, kein Umzug übers Wochenende

Guter Support beginnt übrigens schon vor der Entstehung des Clusters. Die Migration zu Kubernetes ist selten ein einmaliger Sprung – sie ist eine Abfolge von Etappen: Bestandsaufnahme (was bereits in Containern läuft, was zustandsbehaftet ist, was auf virtuellen Maschinen bleibt), Auswahl der ersten Kandidaten, Umzug, Beobachtung, die nächste Tranche. Teil eines ehrlichen Plans ist auch eine Liste der Anwendungen, die man besser nicht migriert: Ein Monolith, der stabil auf einer einzelnen virtuellen Maschine läuft, wird durch die Containerisierung nicht plötzlich zu einem skalierbaren Microservice – er gewinnt stattdessen eine neue Schicht an Komplexität.

Wir helfen u. a. in zwei Szenarien: beim Umzug von Umgebungen von Docker Swarm zu Kubernetes sowie bei Migrationen ganzer Virtualisierungsumgebungen in unsere Cloud – das zweite Thema beschreiben wir im Artikel Migration von VMware zu WebDisk Cloud Computing.

Kubernetes bei WebDisk: verwalteter Cluster oder ein eigener auf IaaS

In unserer Public Cloud ist Kubernetes auf zwei Wegen verfügbar:

• Verwalteter Kubernetes-Cluster (WebDisk K8s) – ein Dienst, verfügbar für Nutzer von WebDisk Cloud. Die Plattform (aufgebaut auf Apache CloudStack) erstellt den Cluster automatisch, und die Anzahl der Nodes ändern Sie über das Panel (cloud.dco.webdisk.io), ohne jede Maschine manuell anzufassen; das Update der Cluster-Version planen wir gemeinsam mit Ihnen, denn Kubernetes wird der Reihe nach angehoben, Release für Release. „Verwaltet“ bedeutet hier: Die Plattform legt den Cluster an und skaliert ihn für Sie. Die etcd-Sicherung, die Erneuerung der Zertifikate, Systemupdates auf den Nodes und das Monitoring Ihrer Anwendungen bleiben Sache des Cluster-Eigentümers – sofern wir nichts anderes vereinbaren.
• Eigener Cluster auf IaaS – für Teams, die volle Kontrolle über Distribution und Konfiguration wollen. IaaS (Infrastructure as a Service) bedeutet, dass Sie von uns virtuelle Maschinen und das Netzwerk mieten und die Umgebung darauf mit den Werkzeugen aufbauen, die Sie kennen; fortgeschrittene Teams können zur Cluster API mit dem Provider für CloudStack greifen (automatisches Anlegen und Wiederherstellen von Clustern) oder zum CloudStack Kubernetes Provider, der einen fertigen Cluster mit dem Netzwerk und den Load Balancern der Plattform verbindet.

Unabhängig vom gewählten Weg können Sie die Hilfe unseres Teams in Anspruch nehmen – von der Beratung und dem Migrationsplan bis zur Konfiguration der Anwendungen. Den Umfang einer solchen Zusammenarbeit und ihre Bedingungen legen wir im Vertrag fest, sodass von Anfang an klar ist, was auf unserer Seite liegt und was auf Ihrer. Wie unser Support hinter den Kulissen aussieht – und über welche Kanäle Sie uns erreichen können – beschreiben wir im Artikel WebDisk-Support.

Was erledigt technischer Kubernetes-Support nicht?

Das Outsourcing der Kubernetes-Wartung nimmt dem Team eine reale Last ab, aber einige Dinge bleiben Sache des Systemeigentümers – und das weiß man besser vor der Vertragsunterzeichnung als danach:

• Die Entscheidung „ob überhaupt Kubernetes“. Nicht jede Anwendung profitiert von Container-Orchestrierung. Für viele Workloads bleibt die virtuelle Maschine die einfachere und operativ günstigere Wahl – über die Unterschiede zwischen den Cloud-Servicemodellen schreiben wir im Artikel Cloud als Service, und über die Kosten der Public Cloud – im Artikel Public Cloud zum vernünftigen Preis.
• Die Grenzen des Wortes „verwaltet“. Ein verwalteter Kubernetes-Dienst legt den Cluster an und skaliert ihn für Sie. Die etcd-Sicherung, die Erneuerung der Zertifikate, Systemupdates auf den Nodes und das Monitoring Ihrer Anwendungen geschehen nicht von selbst – jemand muss sie zu seinen Pflichten zählen: Ihr Team oder unseres, auf Grundlage des Vertrags.
• Änderungen an der Anwendung selbst. Der Support hält den Cluster am Laufen, schreibt aber nicht die Architektur einer Anwendung um, die für den Betrieb in Containern nicht bereit ist.
• Verantwortung für die Daten. Das Backup der Cluster-Infrastruktur ist nicht dasselbe wie eine Backup-Richtlinie für die Anwendungsdaten – Letztere muss bewusst entworfen und regelmäßig getestet werden.
• Die Komplexität als solche. Kubernetes fügt eine Abstraktionsschicht hinzu, die ihre Kosten hat. Guter Support verwaltet diese Komplexität – beseitigt sie aber nicht.

Häufige Fragen

Muss ich Kubernetes verwenden, um die WebDisk-Cloud zu nutzen? Nein. Kubernetes ist eine der Optionen – neben klassischen virtuellen Maschinen, VPS und Dateidiensten. Wenn Ihre Workloads auf VMs gut laufen, ist die Migration zu Containern keine Voraussetzung für die Nutzung unserer Plattform.

Ich habe den Cluster selbst aufgesetzt. Kann ich mit Support rechnen? Ja – die Hilfe können Sie in jeder Phase in Anspruch nehmen: bei der Planung der Migration, nach einer eigenständigen Bereitstellung und auch für Anwendungen, die von Anfang an in unserer Cloud laufen. Den Umfang legen wir individuell im Vertrag fest.

Was bedeutet ein „verwalteter“ Kubernetes-Cluster und was bleibt auf meiner Seite? Bei WebDisk K8s bedeutet „verwaltet“: Die Plattform legt den Cluster an und skaliert ihn für Sie – die Anzahl der Nodes ändern Sie über das Panel. Die etcd-Sicherung, die Erneuerung der Zertifikate, Systemupdates auf den Nodes und das Monitoring Ihrer Anwendungen bleiben Sache des Cluster-Eigentümers, sofern wir nichts anderes vereinbaren. Diese Aufteilung der Verantwortung sollte im Vertrag festgehalten sein, bevor sie gebraucht wird.

Wie oft muss ein Kubernetes-Cluster aktualisiert werden? Kubernetes veröffentlicht drei Releases pro Jahr, und jedes erhält etwa 14 Monate lang Korrekturen – darunter Sicherheitsupdates. Ein Cluster, der seit gut einem Jahr nicht aktualisiert wurde, fällt aus diesem Fenster heraus, und Rückstände werden Version für Version aufgeholt, ohne etwas zu überspringen. Bestandteil jedes geplanten Updates sollte auch die Überprüfung auslaufender APIs sein.

Ist eine etcd-Sicherung ein vollständiges Backup des Clusters? Nein. Die etcd-Sicherung schützt den Zustand des Clusters: Deployment-Definitionen, Konfiguration, Secrets. Anwendungsdaten – Datenbanken, Dateien auf Volumes – erfordern eine eigene Backup-Strategie mit einem eigenen Wiederherstellungstest.

Womit beginnt man die Migration aus einer hybriden Umgebung? Mit einer Bestandsaufnahme: was bereits in Containern läuft, was zustandsbehaftet ist, was auf virtuellen Maschinen bleiben soll. Danach die Auswahl der ersten, unkritischen Anwendung, Migration, Beobachtung – und erst dann die nächsten Etappen. Ein Plan „alles auf einmal“ ist eine häufige Ursache gescheiterter Migrationen.

Zusammenfassung

Kubernetes ist seine Popularität wert – aber mit ihm kaufen Sie sich Pflichten ein: Updates, Backups, Monitoring, Sicherheit und Reaktionsbereitschaft. Wenn Ihr Team das alles im Griff hat – großartig. Wenn nicht, lohnt es sich, darüber zu sprechen, bevor der erste Ausfall daran erinnert. Schreiben Sie uns – wir helfen Ihnen, die Migration zu planen oder zu überprüfen, wie Ihr aktueller Cluster gewartet wird.