Die Checkliste für Lock-in-freies Kubernetes

Die meisten Argumente gegen Vendor Lock-in bei einer Kubernetes-Plattform kommen von einem Anbieter. Das ist die schwächste denkbare Quelle für diese Aussage, denn du hast keinen Grund, ihr mehr zu glauben als der Aussage jedes anderen Anbieters.

Schweizer öffentliche Beschaffungsstellen haben begonnen, genau dieses Argument als verbindliche Anforderung festzuhalten, nicht als Verkaufsargument. Im Folgenden findest du diese Anforderung in einfacher Sprache, damit du sie in deine eigene Evaluation übernehmen kannst, egal ob du selbst eine öffentliche Ausschreibung durchführst.

Was "kein Lock-in" bedeutet, wenn es eine Beschaffungsstelle definiert und nicht ein Anbieter

Eine Schweizer Ausschreibung für Container-Plattformen im öffentlichen Sektor verlangt ein konsistentes Set technischer Anforderungen für eine Lock-in-freie Kubernetes-Plattform. Generisch formuliert, als gängige Praxis der Schweizer öffentlichen Beschaffung und nicht als Wortlaut dieser einen Ausschreibung:

• Eine CNCF-zertifizierte Kubernetes-Distribution. Schliesst einen Fork oder eine "Kubernetes-kompatible" API aus, die die Conformance-Testsuite nicht durchlaufen hat, wie nah sie auf dem Papier auch wirkt.
• Keine proprietäre Orchestrierung, die die Kubernetes-API verändert oder die Migration erschwert. Schliesst eine verwaltete Ebene aus, die eigene Controller, CRDs oder Scheduling-Logik hinzufügt, die du anderswo neu bauen müsstest, um zu wechseln.
• OCI-konforme Container-Runtimes. Schliesst eine Runtime aus, die nur für sie gebaute Images ausführt.
• Sowohl Horizontal Pod Autoscaling als auch Cluster-Autoscaling. Schliesst eine Plattform aus, die deine Pods skaliert, dich aber die Worker-Kapazität von Hand provisionieren und bezahlen lässt, oder umgekehrt.
• Ein CNI mit NetworkPolicy-Unterstützung. Schliesst Netzwerkisolation aus, die nur als anbieterspezifische Security Group existiert, die du auf einer anderen Plattform neu entwerfen müsstest.
• Pod Security Standards. Definiert Standard-Sicherheitsprofile für Pods, die Pod Security Admission, der eingebaute Kubernetes-Mechanismus, oder eine andere Policy-Engine durchsetzen kann, statt Profile aus einem proprietären Admission-Schema.
• Sowohl Ingress als auch die Gateway API. Schliesst Routing aus, das nur über die Load-Balancer-Konfiguration eines bestimmten Anbieters funktioniert.
• RBAC mit Namespace-basierter Mandantentrennung. Schliesst Identitäts- und Zugriffskontrolle aus, die ausserhalb von Kubernetes liegt und nicht mit deinen Workloads mitwandern würde.
• GitOps-basiertes Deployment. Schliesst eine Deployment-Pipeline aus, die in die Konsole eines bestimmten Anbieters verdrahtet ist, statt als Code deklariert zu sein, den du selbst behältst.

Keiner dieser Punkte ist aussergewöhnlich. Zusammen ergeben sie eine praktische Definition von "du kannst deine Workloads mitnehmen und wechseln", die du bei jeder Plattform prüfen kannst, die du evaluierst, auch bei unserer.

Interesse anmelden

Der Einwand, dem das vorgreift: "dann braucht es dedizierte Hardware, und das wird teuer"

Einer Plattform, die diese Checkliste erfüllt, wird manchmal unterstellt, sie brauche dedizierte Hardware pro Kunde, weil das die einfachste Vorstellung von strikter Mandantentrennung ist. Schweizer öffentliche Beschaffungsstellen haben auch klargestellt, dass diese Annahme falsch ist. Als eine Beschaffungsstelle in diesem Bereich gefragt wurde, was "getrennte" Mandantenfähigkeit voraussetzt, lautete die dokumentierte Antwort, dass getrennte Ressourcenpools auf gemeinsam genutzter Hardware dafür ausreichen; dedizierte Hardware ist nicht erforderlich.

Dieselbe Klarstellung erlaubt gemeinsam genutzte Plattformkomponenten, Monitoring, Logging, Backup, Schlüsselverwaltung, die Management-Ebene und Deployment-Pipelines, über Mandanten hinweg, sofern Audit-Daten mandantenspezifisch bleiben und Verschlüsselungsschlüssel pro Mandant getrennt gespeichert werden. Das macht eine Lock-in-freie, standardbasierte Plattform überhaupt bezahlbar: Die Teile, die keine Trennung brauchen, werden nicht getrennt, und die Teile, die es brauchen, schon.

Was das für dich heisst

Nimm die Checkliste in deine eigene Evaluation, egal wen du evaluierst. Eine Plattform, die nicht ohne Vorbehalt zu einem Punkt Ja sagen kann, hat mindestens eine Achse, die API, die Runtime, das Netzwerk, die Sicherheit, die Zugriffskontrolle oder das Deployment, die nicht unverändert mitwandert; prüfe vor der Unterschrift, nicht danach, was genau diese Lücke für deine Workloads und Konfiguration bedeutet.

Managed Kubernetes baut genau auf diesen offenen Standards: durchgängig native Kubernetes-APIs, Gateway API und Ingress für das Routing, Cilium als CNI, und nichts in deinen Workloads, das gegen eine Schnittstelle geschrieben ist, die nur wir anbieten. Wie sich der Stack im Vergleich zum restlichen Markt schlägt, zeigen die Seiten Plattformvergleich und Souveränität.

Melde dein Interesse an und bring deine eigene Checkliste mit. Prüfe die Plattform direkt daran, statt an dem, was wir selbst darüber sagen.