Managed Kubernetes ist nicht gleich Managed Kubernetes

Jeder grosse Cloud-Anbieter bietet "Managed Kubernetes" an. Azure hat AKS. Google hat GKE. Und wenn Sie eines starten, bekommen Sie eine Control Plane, ein paar Nodes und ein kubeconfig. Herzlichen Glückwunsch, Sie haben Kubernetes.

Was Sie nicht haben, ist eine Plattform.

Wir betreiben Managed Kubernetes für Schweizer Unternehmen seit 2021, auf unserer eigenen Infrastruktur und auf Kunden-Hyperscalern. Die wichtigste Erkenntnis: Der Abstand zwischen einem laufenden Cluster und einer produktionsbereiten Plattform ist enorm. Dieser Beitrag erklärt, was wir tatsächlich liefern, wenn wir "Managed Kubernetes" sagen, wie unsere Plattform über verschiedene Infrastruktur-Ziele funktioniert, und welche Batteries-Included wir mitbringen, die Sie sonst monatelang selbst aufbauen würden.

Der Cluster ist 20% der Arbeit

Wenn die meisten Leute "Managed Kubernetes" hören, denken sie an die Control Plane. Jemand anders betreibt etcd, den API Server, den Scheduler. Nodes werden provisioniert. Updates werden eingespielt. Dieser Teil ist gelöst. AKS macht das, GKE macht das, wir machen das auf Natron Cloud.

Aber ein Cluster ohne Platform Services ist wie ein Server ohne Betriebssystem. Man kann Dinge darauf laufen lassen, aber man verbringt die meiste Zeit damit, Probleme zu lösen, die nichts mit der eigentlichen Applikation zu tun haben:

• Wer verwaltet TLS-Zertifikate? Wer rotiert sie, bevor sie um 2 Uhr morgens am Samstag ablaufen?
• Wohin gehen Logs? Können Sie tatsächlich den Fehler finden, der den Ausfall letzte Nacht verursacht hat?
• Was passiert, wenn jemand einen Container als Root deployt, ohne Resource Limits?
• Wie stellen Sie einen Stateful Workload wieder her, nachdem jemand versehentlich kubectl delete ausgeführt hat?
• Wer wird benachrichtigt, wenn einem Node der Speicherplatz ausgeht?

Das sind keine Randfälle. Das ist Alltag.

Eine Plattform, drei Infrastruktur-Ziele

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

Natron Cloud ist unsere eigene Infrastruktur. Schweizer Rechenzentren, Proxmox VE Virtualisierung, Ceph Storage, volle Datensouveränität. Wir provisionieren den Cluster von Bare Metal aufwärts. Hier haben wir die meiste Kontrolle, und hier starten die meisten unserer Schweizer Kunden.

Natron Flex Stack nimmt denselben Stack und deployt ihn auf dedizierter Hardware, entweder in unserem Rechenzentrum oder bei Ihnen. Gleiches Proxmox, gleiches Ceph, gleiche Kubernetes-Plattform obendrauf. Der Unterschied: Ihre Hardware, Ihre Isolation, planbare Kosten. Wir haben Kunden in regulierten Branchen, die dieses Mass an physischer Trennung brauchen.

Bring Your Own Cloud ist für Kunden, die bereits Azure- oder GCP-Verträge haben. Hier nutzen wir AKS oder GKE als Basis-Cluster. Der Kunde behält seine bestehende Cloud-Beziehung und Abrechnung. Wir deployen unseren kompletten Platform Stack darauf.

Und hier wird es interessant.

Warum Managed Kubernetes beim Hyperscaler nicht reicht

Wenn wir einen Kunden mit AKS oder GKE onboarden, hören wir zuerst: "Wir haben ja schon Managed Kubernetes, wir brauchen nur Hilfe beim Betrieb." Dann schauen wir uns den Cluster an und finden:

• Kein zentrales Logging. Logs gehen in den Log-Sink des Cloud-Anbieters, der bei Scale 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 manuell verwaltet oder mit einem Cronjob, den jemand vor zwei Jahren geschrieben hat.
• Keine Network Policies. Jeder Pod kann mit jedem anderen Pod sprechen. Ein kompromittierter Container bedeutet Lateral Movement über den gesamten Cluster.
• Monitoring ist "wir haben das Dashboard des Cloud-Anbieters", das CPU und Memory zeigt, aber nichts Applikationsspezifisches.

Das "Managed" des Cloud-Anbieters bedeutet: Wir betreiben die Control Plane, der Rest ist Ihr Problem. Unser "Managed" bedeutet: Wir betreiben alles, was Sie brauchen, um nachts ruhig schlafen zu können.

Die Batteries, die wir mitbringen

Jeder Kubernetes-Cluster, den wir managen, unabhängig vom Infrastruktur-Ziel, wird mit demselben Platform Stack ausgeliefert. Wir organisieren ihn in drei Tiers: Basic, Premium und Enterprise.

Basic (in jedem Cluster enthalten)

Nicht verhandelbar. Jeder Cluster bekommt das ab Tag eins:

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

Ingress: NGINX Ingress Controller + cert-manager. Automatisiertes TLS mit Let's Encrypt oder internen CAs. Zertifikats-Rotation ist automatisch. Keine abgelaufenen Zertifikate mehr, die Ihre kundenorientierten Services lahmlegen.

Observability: Prometheus, Grafana, Loki, Alertmanager. Vollständiger Metrics-, Logging- und Alerting-Stack. Nicht das Pay-per-Query-Angebot des Cloud-Anbieters. Ein dedizierter Stack, der im Cluster läuft, mit sinnvollen Defaults, vorgebauten Dashboards und Alert Rules, die tatsächlich etwas bedeuten.

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

Externes Monitoring: Blackbox Exporter. Wir proben Ihre Endpoints von ausserhalb des Clusters. Wenn Ihr Ingress ausfällt, wissen wir es, bevor Ihre Kunden es merken.

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

ArgoCD. GitOps-basierte Continuous Delivery. Jede Änderung geht durch Git, wird reviewed und automatisch reconciled. Drift Detection erkennt manuelle Änderungen und revertiert sie. Das ist kein optionales Tooling. So managen wir die Plattform selbst.

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

Kyverno. Policy Engine für Admission Control, Mutation und Resource Generation. Wir haben einen ganzen Blogbeitrag darüber geschrieben, warum wir Kyverno statt OPA Gatekeeper gewählt haben. Es erzwingt Security Baselines, Resource Constraints und organisatorische Policies, ohne dass Ihre Entwickler wissen müssen, dass sie existieren.

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

Custom Integrations für nicht-standardmässige Anforderungen. Bestehende Observability-Systeme (Datadog, Splunk, Dynatrace), die gefüttert werden müssen. Spezifische Storage Backends. Komplexe Netzwerk-Topologien. Multi-Tenant-Setups, bei denen verschiedene Teams unterschiedliche Policies, Quotas und Zugriffskontrollen brauchen.

Hier kommt unser Platform Design-Engagement ins Spiel. Wir designen das Tenancy-Modell, die Guardrails und den Onboarding-Workflow für Ihre spezifische Organisation.

Gleiche Automatisierung, andere Basis

Die zentrale Architekturentscheidung: Unsere Platform-Schicht ist von der Infrastruktur-Schicht entkoppelt. Wir verwenden dieselben Helm Charts, dieselben ArgoCD Apps, 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 onboarden:

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

Das bedeutet auch, dass Migration zwischen Infrastruktur-Zielen realistisch ist. Wir haben Kunden von selbstverwalteten Clustern zu Natron Cloud migriert, von Natron Cloud zu Flex Stack (als sie dedizierte Hardware brauchten), und von Hyperscaler-Managed zu unserer eigenen Infrastruktur (als Datensouveränität zur Anforderung wurde). Die Workloads ziehen um. Die Platform-Schicht bleibt gleich.

Wie das in der Praxis aussieht

Ein reales Beispiel: Ein Schweizer Finanzdienstleister kam zu uns mit drei selbstverwalteten Kubernetes-Clustern auf Azure. Jeder Cluster war von einem anderen Team zu einem anderen Zeitpunkt aufgesetzt worden. Einer nutzte Flannel für Networking, einer Azure CNI, einer Calico. Logging war inkonsistent. Backups existierten für einen Cluster. Monitoring war "wir schauen manchmal in Azure Monitor".

Wir konsolidierten auf zwei AKS-Cluster mit unserem vollständigen Platform Stack. Standardisiertes Networking auf Cilium. Konsistente Observability deployed. Velero Backups auf Azure Blob Storage eingerichtet. Kyverno Policies für ihre Compliance-Anforderungen implementiert. External Secrets Operator mit ihrem bestehenden Azure Key Vault verbunden.

Sechs Monate später verbringt ihr Team null Zeit mit Cluster-Betrieb. Sie deployen über ArgoCD, verwalten Namespaces und Zugriffe self-service über unser Plattform-Tooling und prüfen Dashboards in Grafana. Wenn sie auf ein komplexes Problem stossen, ein Netzwerkproblem, das sie nicht erklären können, eine Performance-Degradation unter Last, ein Deployment, das in Production fehlschlägt aber in Staging funktioniert, wenden sie sich an uns für 3rd-Level-Support. Unsere Engineers bringen jahrelange Erfahrung im Betrieb und Troubleshooting von Container-Plattformen über Dutzende von Clustern mit. Das ist, was Managed Kubernetes bedeutet.

Was alle unterschätzen: die langfristige Wartung

Das ist das Gespräch, das wir am häufigsten führen. Ein Team evaluiert unsere Plattform und sagt: "Wir können Cilium und cert-manager selbst installieren. Dafür brauchen wir keinen Managed Service." Sie haben Recht. Installation ist der einfache Teil. Die Frage ist, was in Monat 6, Monat 12, Monat 36 passiert.

Das initiale Setup ist ein Wochenend-Projekt. Die Wartung ist ein Vollzeit-Job, für den sich niemand angemeldet hat.

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

Deprecations überraschen Sie. Kubernetes depreciert APIs mit jedem Release. Ihre Ingress-Manifeste brechen, weil networking.k8s.io/v1beta1 weg ist. cert-manager v1.12 ändert, wie ClusterIssuers funktionieren. Der Prometheus Operator benennt seine CRDs um. Jede dieser Änderungen erfordert Changelogs lesen, Manifeste aktualisieren, testen und ausrollen. Über wie viele Cluster? Mit welcher Testabdeckung?

Security Patches stauen sich an. Ein CVE trifft Cilium. Ein weiterer trifft ingress-nginx. Ein dritter betrifft die Go-Runtime, auf der die Hälfte Ihrer Operators läuft. Jeder Patch braucht Bewertung (betrifft er uns?), Test (bricht er etwas?) und Rollout (koordiniert, nicht alles-auf-einmal). Wenn Sie für 15 Plattform-Komponenten verantwortlich sind, jede mit ihrem eigenen Release-Zyklus, wächst der Patch-Rückstand schneller als erwartet.

Niemand hat Ownership. Der Engineer, der Prometheus aufgesetzt hat, ist seit sechs Monaten weg. Die Person, die Velero Backups konfiguriert hat, wechselte in ein anderes Team. Der Ingress Controller wurde von einem Berater während des initialen Setups installiert. Jetzt gibt es einen Incident, das Dashboard ist leer, und niemand weiss, welche Helm Values verwendet wurden oder warum genau diese Konfiguration gewählt wurde. Es gibt kein Runbook, weil niemand eines geschrieben hat.

Incidents legen die Lücken offen. Wenn Production um 2 Uhr morgens brennt, untersucht Ihr Team die Applikation. Aber die Root Cause ist eine Plattform-Komponente. Das PersistentVolume ist voll, weil niemand Loki Retention konfiguriert hat. Der Ingress liefert 502s, weil die cert-manager Renewal vor drei Tagen stillschweigend fehlschlug. Die Network Policy blockiert Traffic, weil das letzte Cilium-Upgrade das Standardverhalten geändert hat. Das sind keine Applikations-Bugs. Das sind Platform-Operations-Fehler.

Migration wird unmöglich. Sie haben Pod Security Policies 2022 installiert. Kubernetes hat sie zugunsten von Pod Security Standards depreciert. Sie haben Traefik als Ingress Controller installiert, aber jetzt brauchen Ihre Anforderungen Features, die nur NGINX oder Envoy bieten. Sie nutzen Calico als CNI, brauchen aber Cilium für eBPF-basierte Network Policies. Jede dieser Migrationen ist ein Projekt, das Planung, Testing und Umsetzung erfordert. Aber niemand im Team hat Kapazität, weil alle mit Feature-Entwicklung beschäftigt sind. Also wächst die technische Schuld, und die Plattform wird langsam zur Belastung statt zum Enabler.

Die echten Kosten sind nicht die Tools. Es sind die operativen Prozesse drumherum. Patch Management. Upgrade-Planung. Deprecation-Tracking. Incident Runbooks. Backup-Testing. Monitoring des Monitorings. Das sind die Dinge, die "wir haben es installiert" von "wir betreiben es" unterscheiden. Und es sind die Dinge, die stillschweigend auseinanderfallen, wenn das Team, das sie aufgesetzt hat, sich anderen Prioritäten zuwendet.

Ein reales Beispiel, das gerade passiert: der NGINX Ingress Controller. Das community-maintained Projekt ingress-nginx, das seit Jahren der Standard-Ingress-Controller für die meisten Kubernetes-Cluster ist, wird depreciert. Das Projekt kämpft mit Maintainer-Kapazität, langsamen CVE-Reaktionszeiten und einer zunehmend veralteten Architektur. F5 hat mit dem F5 NGINX Ingress Controller einen kommerziell unterstützten, aktiv gewarteten Ersatz bereitgestellt, mit besserer Performance, nativem Support für NGINX Plus Features und einer klaren langfristigen Roadmap.

Wenn Sie Ihren Ingress Controller selbst verwalten, landet diese Deprecation auf Ihrem Schreibtisch. Sie müssen den Ersatz evaluieren, die Konfigurationsunterschiede verstehen (es ist kein 1:1-Mapping), den Migrationspfad planen, jede Ingress-Ressource und Annotation testen, die Ihre Applikationen nutzen, den Cutover mit Ihren Entwicklungsteams koordinieren und die Migration ohne Downtime durchführen. Für ein Team, das bereits mit Feature-Entwicklung beschäftigt ist, bedeutet das Wochen ungeplanter Arbeit.

Für unsere Kunden ist das unser Problem, nicht ihres. Wir planen und führen die Migration zum F5 NGINX Ingress Controller bereits über unsere gesamte Flotte durch. Wir evaluieren, welche Kunden-Konfigurationen angepasst werden müssen, testen den neuen Controller gegen die spezifischen Ingress-Ressourcen und Annotations jedes Clusters und koordinieren den Migrationszeitplan mit jedem Kunden. Manche Cluster haben ein einfaches Setup und migrieren schnell. Andere haben Custom Annotations, Rate-Limiting-Regeln oder komplexes Routing, das sorgfältige Aufmerksamkeit braucht. Wir übernehmen beides. Der Kunde bekommt eine Benachrichtigung, ein Migrationsfenster und ein validiertes Ergebnis. Keine Überraschung, wenn der Ingress nicht mehr funktioniert, weil ein Community-Projekt nicht mehr gewartet wird.

Das ist genau die Art von Migration, die nie passiert, wenn niemand die Plattform besitzt. Die Deprecation-Ankündigung wandert in einen Backlog. Jemand erstellt ein Ticket. Das Ticket liegt sechs Monate, weil es immer etwas Dringenderes gibt. Dann trifft ein CVE den alten Controller, es gibt keinen Patch, und jetzt ist es eine Notfall-Migration statt einer geplanten.

Wir tracken Deprecations, CVEs und Breaking Changes über unsere gesamte Flotte. Wenn cert-manager v1.15 die ClusterIssuer-Spec ändert, aktualisieren wir es über jeden Cluster, den wir managen, testen es gegen die Konfiguration jedes Kunden und rollen es in einer koordinierten Welle aus. Wenn ein Cilium CVE erscheint, bewerten, patchen und deployen wir innerhalb unseres SLA-Fensters. Nicht weil ein einzelner Cluster speziell ist, sondern weil das alles ist, was wir tun.

Der echte Differenzierungsfaktor: Betrieb, nicht Installation

Diese Tools zu installieren ist nicht schwer. Die meisten haben Helm Charts. Man kann Prometheus und Grafana an einem Nachmittag aufsetzen. Der schwierige Teil ist alles, was danach kommt:

• Worauf alertet man? Wir haben unsere Alert Rules über vier Jahre hinweg über Dutzende von Clustern verfeinert. Wir wissen, welche Alerts Noise sind und welche bedeuten, dass sofort jemand hinschauen muss.
• Was passiert um 3 Uhr morgens? Wir haben ein Operations-Team. Kein Ticketing-System. Keinen Chatbot. Engineers, die Ihren Cluster, Ihre Workloads und Ihre Architektur kennen.
• Wie wird upgradet? Kubernetes released alle vier Monate. Jedes Upgrade muss gegen Ihre Workloads, Ihre Operators, Ihre Policies getestet werden. Das machen wir kontinuierlich.
• Was ist mit den Platform-Komponenten? Cilium, cert-manager, ArgoCD, Kyverno und jede andere Komponente hat ihren eigenen Release-Zyklus, ihre eigenen Breaking Changes, ihre eigenen CVEs. Wir tracken und applyen diese über unsere gesamte Flotte.
• Wer plant die Migration, wenn eine Komponente End of Life erreicht? Wir. Wir haben Kunden von Calico zu Cilium migriert, von Pod Security Policies zu Kyverno, von selbstverwaltetem Prometheus zu unserem standardisierten Observability-Stack, und wir migrieren aktuell unsere gesamte Flotte vom deprecateten Community ingress-nginx zum F5 NGINX Ingress Controller. Jede Migration wird geplant, getestet und ohne Downtime umgesetzt.

Wir managen die langweiligen Teile, damit Ihr Team Features shippen kann.

Loslegen

Wenn Sie Managed-Kubernetes-Anbieter in der Schweiz evaluieren, oder Schwierigkeiten haben, den Cluster zu operationalisieren, den Sie bereits haben, sollten wir reden. Wir bieten eine kostenlose Erstberatung an, bei der wir Ihr aktuelles Setup anschauen und besprechen, wie eine Managed-Plattform für Ihre spezifischen Anforderungen aussehen könnte.

Schauen Sie sich unsere Kubernetes-Plattform-Tiers an, um zu sehen, was auf jeder Stufe enthalten ist. Prüfen Sie unsere Kundenreferenzen, um zu sehen, wer heute auf unserer Plattform läuft. Oder vereinbaren Sie direkt einen Termin.