Managed Kubernetes ist nicht gleich Managed Kubernetes

Jeder grosse Cloud-Anbieter bietet "Managed Kubernetes" an. Azure mit AKS, Google mit GKE. Sie starten einen Cluster und erhalten eine Control Plane, ein paar Nodes und eine kubeconfig. Glückwunsch, Sie haben Kubernetes.

Was Sie nicht haben, ist eine Plattform.

Wir betreiben Managed Kubernetes für Schweizer Unternehmen seit 2021, sowohl auf eigener Infrastruktur als auch auf Hyperscalern unserer Kunden. Die wichtigste Erkenntnis aus dieser Zeit: Zwischen einem laufenden Cluster und einer produktionsreifen Plattform liegen Welten. Dieser Beitrag zeigt, was wir tatsächlich liefern, wenn wir von "Managed Kubernetes" sprechen, wie unsere Plattform über verschiedene Infrastruktur-Ziele hinweg funktioniert und welche Komponenten wir mitbringen, an denen Sie sonst monatelang selbst bauen würden.

Der Cluster ist 20 Prozent der Arbeit

Wer "Managed Kubernetes" hört, denkt meist an die Control Plane. Jemand anders betreibt etcd, den API-Server, den Scheduler. Nodes werden bereitgestellt, Updates eingespielt. Dieser Teil ist gelöst. AKS macht das, GKE macht das, wir machen das auf der Natron Cloud.

Ein Kubernetes-Cluster ohne Plattform-Dienste ist wie ein Wohnhaus im Rohbau – die Wände stehen, aber ohne Strom, Wasser und Küche kann niemand sinnvoll darin leben. Statt an Ihrer Anwendung arbeiten Sie hauptsächlich an Infrastrukturproblemen:

• Wer verwaltet die TLS-Zertifikate? Wer rotiert sie, bevor sie um zwei Uhr nachts am Samstag ablaufen?
• Wohin gehen Logs? Finden Sie damit den Fehler, der den Ausfall letzte Nacht verursacht hat?
• Was passiert, wenn jemand einen Container als Root und ohne Resource Limits deployt?
• Wie stellen Sie einen Stateful Workload wieder her, nachdem jemand versehentlich kubectl delete ausgeführt hat?
• Wer wird benachrichtigt, wenn einem Node der Speicher ausgeht?

Das sind keine Ausnahmen, das ist der ganz normale Betrieb.

Eine Plattform, drei Infrastruktur-Ziele

Wir haben unsere Plattform so gebaut, dass sie über drei Deployment-Modelle hinweg identisch läuft. Gleiches Tooling, gleiche Automatisierung, gleiche SLAs. Der einzige Unterschied liegt darin, wo der Basis-Cluster läuft.

Natron Cloud ist unsere eigene Infrastruktur. Schweizer Rechenzentren, Virtualisierung mit Proxmox VE, Storage auf Ceph, vollständige Datensouveränität. Wir richten den Cluster ab Bare Metal ein. Hier haben wir die meiste Kontrolle, und hier starten die meisten unserer Schweizer Kunden.

Natron Flex Stack nutzt denselben Stack auf dedizierter Hardware, entweder bei uns im Rechenzentrum oder bei Ihnen vor Ort. Gleiches Proxmox, gleiches Ceph, gleiche Kubernetes-Plattform darüber. Was sich unterscheidet: Ihre Hardware, Ihre Isolation, planbare Kosten. Diesen Grad an physischer Trennung brauchen Kunden in regulierten Branchen.

Bring Your Own Cloud richtet sich an Kunden, die bereits Verträge mit Azure oder GCP haben. Hier setzen wir auf AKS oder GKE als Basis-Cluster auf. Der Kunde behält seine bestehende Cloud-Beziehung und Abrechnung. Wir deployen unseren vollen Plattform-Stack darauf.

Und genau hier wird es spannend.

Warum Managed Kubernetes beim Hyperscaler nicht ausreicht

Wenn wir einen Kunden mit AKS oder GKE übernehmen, hören wir zuerst regelmässig: "Wir haben ja schon Managed Kubernetes, wir brauchen nur Hilfe beim Betrieb." Sobald wir uns den Cluster anschauen, finden wir typischerweise:

• Kein zentrales Logging. Logs gehen in den Log-Sink des Cloud-Anbieters, der bei zunehmender Last ein Vermögen kostet und mühsam abzufragen ist.
• Keine Backup-Strategie. Der Cloud-Anbieter sichert etcd (den Cluster-State), aber nicht Ihre PersistentVolumes, nicht Ihre Helm-Releases, nicht Ihre CRDs.
• Zertifikate, die manuell verwaltet werden, oder ein Cronjob, den jemand vor zwei Jahren geschrieben hat.
• Keine Network Policies. Jeder Pod kann mit jedem anderen sprechen. Ein kompromittierter Container bedeutet seitliche Bewegung quer durch den ganzen Cluster.
• Monitoring im Sinn von "wir haben das Dashboard des Cloud-Anbieters", das CPU und Memory zeigt, aber nichts Anwendungsspezifisches.
• Keine Patching Strategie der Plattform Komponenten. Veraltete Versionen von Operators und Ingress Controller.

"Managed" beim Cloud-Anbieter heisst: Wir betreiben die Control Plane, der Rest ist Ihre Sache. "Managed" bei uns heisst: Wir betreiben alles, was Sie brauchen, damit Sie nachts ruhig schlafen können.

Was wir mitbringen

Jeder Cluster, den wir betreuen, läuft unabhängig vom Infrastruktur-Ziel mit demselben Plattform-Stack. Wir gliedern ihn in drei Stufen: Basic, Premium und Enterprise.

Basic (in jedem Cluster enthalten)

Diese Komponenten sind nicht verhandelbar. Jeder Cluster bekommt sie ab Tag eins:

Networking: Cilium. eBPF-basiertes CNI mit Network Policies, transparenter Verschlüsselung und Observability. Nicht das Standard-kubenet oder Azure CNI. Cilium liefert uns L7-Sichtbarkeit und ein konsistentes Verhalten von Network Policies über alle Infrastruktur-Ziele hinweg.

Ingress: Ingress Controller und cert-manager. Automatisiertes TLS mit Let's Encrypt oder internen CAs. Zertifikate werden automatisch rotiert. Keine abgelaufenen Zertifikate mehr, die Ihre kundenseitigen Dienste lahmlegen.

Observability: Prometheus, Grafana, Loki, Alertmanager. Vollständiger Stack für Metriken, Logging und Alerting. Nicht das pay-per-query-Angebot des Cloud-Anbieters, sondern ein eigener Stack im Cluster, mit sinnvollen Defaults, vorgefertigten Dashboards und Alert Rules, die wirklich etwas aussagen.

Backup: Velero. Geplante Backups von Cluster-State, Persistent Volumes und Konfigurationen. Restore-Prozeduren, die wir testen. Wenn etwas schiefgeht, und das wird es, können Sie wiederherstellen, ohne raten zu müssen.

Externes Monitoring: Blackbox Exporter. Wir prüfen Ihre Endpunkte von ausserhalb des Clusters. Fällt Ihr Ingress aus, wissen wir es, bevor Ihre Kunden es merken.

Premium (für Teams, die GitOps und Policy Enforcement wollen)

ArgoCD. GitOps-basiertes Continuous Delivery. Jede Änderung läuft über Git, wird reviewt und automatisch abgeglichen. Drift Detection erkennt manuelle Änderungen und macht sie rückgängig. Das ist kein optionales Tooling, so verwalten wir die Plattform selbst.

External Secrets Operator. Anbindung an Vault, Azure Key Vault, GCP Secret Manager oder AWS Secrets Manager. Secrets bleiben dort, wo sie hingehören, und werden automatisch in den Cluster synchronisiert.

Kyverno. Policy Engine für Admission Control, Mutation und Resource Generation. Wir haben in einem eigenen Blogbeitrag erklärt, warum wir Kyverno gegenüber OPA Gatekeeper bevorzugen. Kyverno setzt Security Baselines, Resource Constraints und organisatorische Richtlinien durch, ohne dass Ihre Entwickler überhaupt davon wissen müssen.

Enterprise (für komplexe Multi-Team-Umgebungen)

Massgeschneiderte Integrationen für nicht-standardisierte Anforderungen. Bestehende Observability-Systeme wie Datadog, Splunk oder Dynatrace, die mit Daten versorgt werden müssen. Spezielle Storage-Backends. Komplexe Netzwerk-Topologien. Multi-Tenant-Setups, in denen verschiedene Teams unterschiedliche Policies, Quotas und Zugriffsrechte brauchen.

Hier kommt unser Platform Design-Engagement zum Zug. Wir entwerfen das Tenancy-Modell, die Guardrails und den Onboarding-Workflow für Ihre konkrete Organisation.

Gleiche Automatisierung, andere Basis

Die zentrale Architekturentscheidung ist klar: Unsere Plattform-Schicht ist von der Infrastruktur-Schicht entkoppelt. Wir verwenden dieselben Helm Charts, dieselben ArgoCD-Apps und dieselben Monitoring-Konfigurationen, egal ob der darunterliegende Cluster auf Natron Cloud, Flex Stack, AKS oder GKE läuft.

Wenn wir einen BYOC-Kunden auf Azure übernehmen, gehen wir so vor:

Ab diesem Punkt wird der Cluster gleich betreut wie jeder andere in unserer Flotte. Gleiche Runbooks, gleiche Eskalationswege, gleiches SLA.

Das macht auch den Wechsel zwischen Infrastruktur-Zielen zu einer realistischen Option. Wir haben Kunden von selbst betriebenen Clustern auf Natron Cloud migriert, von Natron Cloud auf Flex Stack (als sie dedizierte Hardware brauchten) und von Hyperscaler-Managed auf unsere eigene Infrastruktur (als Datensouveränität zur Anforderung wurde). Die Workloads ziehen um, die Plattform-Schicht bleibt gleich.

Wie das in der Praxis aussieht

Ein konkretes Beispiel: Ein Schweizer Finanzdienstleister kam zu uns mit drei selbst betriebenen Kubernetes-Clustern auf Azure. Jeder Cluster war zu einem anderen Zeitpunkt von einem anderen Team aufgesetzt worden. Einer nutzte Flannel fürs Networking, einer Azure CNI, einer Calico. Logging war uneinheitlich, Backups gab es nur für einen der drei Cluster, und Monitoring hiess "wir schauen ab und zu in Azure Monitor".

Wir haben auf zwei AKS-Cluster mit unserem vollständigen Plattform-Stack konsolidiert. Networking standardisiert auf Cilium, einheitliche Observability ausgerollt, Velero-Backups auf Azure Blob Storage eingerichtet, Kyverno Policies für die Compliance-Anforderungen umgesetzt und External Secrets Operator an den bestehenden Azure Key Vault angebunden.

Sechs Monate später wendet das Team keine Zeit mehr für den Cluster-Betrieb auf. Deployments laufen über ArgoCD, Namespaces und Zugriffe werden im Self-Service über unser Plattform-Tooling verwaltet, Dashboards prüfen sie in Grafana. Stossen sie auf ein komplexes Problem, etwa ein Netzwerkverhalten, das niemand erklären kann, eine Performance-Einbusse unter Last oder ein Deployment, das in Production fehlschlägt, in Staging aber funktioniert, melden sie sich bei uns für 3rd-Level-Support. Unsere Engineers bringen jahrelange Erfahrung im Betrieb und Troubleshooting von Container-Plattformen über Dutzende Cluster mit. Genau das verstehen wir unter Managed Kubernetes.

Was alle unterschätzen: der langfristige Betrieb

Dieses Gespräch führen wir am häufigsten. Ein Team evaluiert unsere Plattform und sagt: "Cilium und cert-manager können wir selbst installieren, dafür brauchen wir keinen Managed Service." Stimmt. Die Installation ist der einfache Teil. Die Frage ist, was im sechsten, im zwölften und im 36. Monat passiert.

Das initiale Setup ist ein Wochenend-Projekt. Der Betrieb darüber ist eine Vollzeitstelle, für die sich niemand gemeldet hat.

Das passiert tatsächlich, wenn Sie Plattform-Komponenten selbst pflegen:

Deprecations kommen unangekündigt. Kubernetes entfernt mit jedem Release APIs. Ihre Ingress-Manifeste brechen, weil networking.k8s.io/v1beta1 weg ist. cert-manager v1.12 ändert das Verhalten von ClusterIssuers. Der Prometheus-Operator benennt seine CRDs um. Jede dieser Änderungen verlangt Changelog lesen, Manifeste anpassen, testen und ausrollen. Über wie viele Cluster, mit welcher Testabdeckung?

Sicherheits-Patches stauen sich. Ein CVE betrifft Cilium, ein zweiter ingress-nginx, ein dritter die Go-Runtime, auf der die Hälfte Ihrer Operators basiert. Jeder Patch braucht eine Bewertung (sind wir betroffen?), einen Test (bricht etwas?) und einen Rollout (koordiniert, nicht alles auf einmal). Wer für 15 Plattform-Komponenten zuständig ist, jede mit eigenem Release-Zyklus, sieht den Patch-Rückstand schneller wachsen als geplant.

Niemand fühlt sich zuständig. Der Engineer, der Prometheus aufgesetzt hat, ist seit sechs Monaten nicht mehr im Unternehmen. Die Person, die Velero konfiguriert hat, ist in ein anderes Team gewechselt. Den Ingress Controller hat ein externer Berater beim Initialaufbau installiert. Jetzt gibt es einen Incident, das Dashboard ist leer, und niemand weiss, mit welchen Helm Values gearbeitet wurde oder warum genau diese Konfiguration gewählt wurde. Ein Runbook gibt es nicht, weil es nie jemand geschrieben hat.

Incidents legen die Lücken offen. Wenn die Produktion um zwei Uhr morgens brennt, untersucht Ihr Team zuerst die Anwendung. Die eigentliche Ursache liegt aber in einer Plattform-Komponente. Das PersistentVolume ist voll, weil niemand die Loki-Retention konfiguriert hat. Der Ingress liefert 502er, weil die cert-manager-Erneuerung vor drei Tagen still und unbemerkt fehlgeschlagen ist. Eine Network Policy blockiert Traffic, weil das letzte Cilium-Upgrade das Default-Verhalten verändert hat. Das sind keine Anwendungsfehler. Das sind Lücken im Plattform-Betrieb.

Migrationen werden unmöglich. Sie haben 2022 Pod Security Policies eingeführt. Kubernetes hat sie zugunsten der Pod Security Standards verworfen. Sie haben Traefik als Ingress Controller eingesetzt, brauchen heute aber Funktionen, die nur NGINX oder Envoy mitbringen. Sie fahren Calico als CNI, brauchen aber Cilium für eBPF-basierte Network Policies. Jede dieser Migrationen ist ein eigenes Projekt mit Planung, Tests und Umsetzung. Doch im Team hat niemand Kapazität, weil alle mit Feature-Entwicklung ausgelastet sind. Die technische Schuld wächst, und die Plattform wird nach und nach zur Belastung statt zum Beschleuniger.

Die wahren Kosten liegen nicht in den Tools, sondern in den operativen Prozessen darum. Patch Management. Upgrade-Planung. Deprecation-Tracking. Incident Runbooks. Backup-Tests. Das Monitoring des Monitorings. Genau diese Punkte unterscheiden "wir haben es installiert" von "wir betreiben es". Und genau diese Punkte zerfallen leise, sobald sich das Team, das alles aufgesetzt hat, anderen Themen zuwendet.

Ein konkretes Beispiel, das genau jetzt passiert: der NGINX Ingress Controller. Das community-betreute Projekt ingress-nginx, seit Jahren der Standard-Ingress-Controller in den meisten Kubernetes-Clustern, wird eingestellt. Dem Projekt fehlten zuletzt Maintainer-Ressourcen, CVE-Reaktionszeiten wurden langsamer, und die Architektur entspricht nicht mehr dem heutigen Stand. F5 stellt mit dem F5 NGINX Ingress Controller einen kommerziell unterstützten, aktiv gepflegten Ersatz zur Verfügung, mit besserer Performance, nativer Unterstützung für NGINX-Plus-Funktionen und einer klaren langfristigen Roadmap.

Wer den Ingress Controller selbst betreibt, bekommt diese Deprecation auf den Tisch. Sie müssen den Ersatz evaluieren, die Konfigurationsunterschiede verstehen (es ist kein 1:1-Mapping), den Migrationspfad planen, jede Ingress-Ressource und jede Annotation Ihrer Anwendungen testen, den Cutover mit Ihren Entwicklungsteams koordinieren und die Migration ohne Ausfall durchführen. Für ein Team, das ohnehin mit Feature-Entwicklung beschäftigt ist, sind das Wochen ungeplanter Arbeit.

Bei unseren Kunden ist das unsere Aufgabe, nicht ihre. Wir planen und führen die Migration auf den F5 NGINX Ingress Controller bereits über unsere gesamte Flotte hinweg durch. Wir prüfen, welche Kunden-Konfigurationen angepasst werden müssen, wir testen den neuen Controller gegen die spezifischen Ingress-Ressourcen und Annotations jedes Clusters, und wir stimmen den Migrationszeitpunkt mit jedem Kunden ab. Manche Cluster haben ein einfaches Setup und sind schnell migriert. Andere bringen eigene Annotations, Rate-Limiting-Regeln oder ein komplexes Routing mit, das sorgfältige Aufmerksamkeit braucht. Beides übernehmen wir. Der Kunde bekommt eine Ankündigung, ein Migrationsfenster und ein verifiziertes Resultat. Keine Überraschung, weil ein Community-Projekt nicht mehr gepflegt wird und der Ingress nicht mehr läuft.

Genau diese Migrationen finden nie statt, wenn niemand für die Plattform verantwortlich ist. Die Deprecation-Ankündigung verschwindet im Backlog. Jemand erfasst ein Ticket. Das Ticket liegt sechs Monate lang, weil immer etwas Dringenderes ansteht. Dann trifft ein CVE den alten Controller, einen Patch gibt es nicht mehr, und aus der geplanten Migration wird ein Notfall.

Wir verfolgen Deprecations, CVEs und Breaking Changes flottenweit. Wenn cert-manager v1.15 die ClusterIssuer-Spezifikation ändert, ziehen wir das Update über jeden Cluster hinweg, testen es gegen die Konfiguration jedes Kunden und rollen es in einer abgestimmten Welle aus. Erscheint ein CVE für Cilium, bewerten, patchen und deployen wir innerhalb unseres SLA-Fensters. Nicht weil ein einzelner Cluster speziell wäre, sondern weil das unser Hauptgeschäft ist.

Der eigentliche Unterschied: Betrieb statt Installation

Diese Tools zu installieren ist nicht schwer. Die meisten haben Helm Charts. Prometheus und Grafana hat man in einem Nachmittag aufgesetzt. Schwierig wird alles, was danach kommt:

• Worauf wird alarmiert? Wir haben unsere Alert Rules über vier Jahre und Dutzende Cluster verfeinert. Wir wissen, welche Alarme Rauschen sind und welche bedeuten, dass jemand sofort hinschauen muss.
• Was passiert um drei Uhr morgens? Wir haben ein Operations-Team. Kein Ticketing-System, keinen Chatbot. Engineers, die Ihren Cluster, Ihre Workloads und Ihre Architektur kennen.
• Wie wird auf eine neue Version gehoben? Kubernetes erscheint alle vier Monate. Jedes Upgrade muss gegen Ihre Workloads, Ihre Operators und Ihre Policies getestet werden. Das machen wir laufend.
• Und die Plattform-Komponenten? Cilium, cert-manager, ArgoCD, Kyverno und alle weiteren haben jeweils eigene Release-Zyklen, eigene Breaking Changes, eigene CVEs. Wir verfolgen sie und ziehen sie über unsere gesamte Flotte nach.
• Wer plant die Migration, wenn eine Komponente das Lebensende erreicht? Wir. Wir haben Kunden von Calico auf Cilium migriert, von Pod Security Policies auf Kyverno, von selbst betriebenem Prometheus auf unseren standardisierten Observability-Stack, und aktuell migrieren wir unsere ganze Flotte vom abgekündigten Community-ingress-nginx auf den F5 NGINX Ingress Controller. Jede dieser Migrationen wird geplant, getestet und ohne Ausfall umgesetzt.

Wir kümmern uns um die unauffälligen Teile, damit Ihr Team Features ausliefern kann.

Loslegen

Wenn Sie aktuell Anbieter für Managed Kubernetes in der Schweiz vergleichen oder mit dem Betrieb des Clusters kämpfen, den Sie schon haben, lohnt sich ein Gespräch. Wir bieten eine kostenlose Erstberatung an, in der wir Ihr Setup anschauen und mit Ihnen besprechen, wie eine Managed-Plattform für Ihre Anforderungen aussehen würde.

Einen Überblick zu unseren Kubernetes-Plattform-Stufen finden Sie hier. Wer heute auf unserer Plattform läuft, sehen Sie in unseren Kundenreferenzen. Oder vereinbaren Sie direkt einen Termin.