Was ist kcp? Kubernetes ohne Pods

Einführung

Mit Plattform-Engineering lösen die meisten Unternehmen das Problem, dass „jedes Team seinen eigenen Kubernetes-Cluster benötigt“. Das Standardverfahren ist einfach: Man richtet pro Team einen Cluster ein, fügt RBAC hinzu, richtet eine GitOps-Pipeline ein und ist damit fertig. Das funktioniert zwar, ist aber kostspielig. Jeder Cluster verursacht den Overhead einer Control Plane, einer Reihe von Knoten, Überwachungsmaßnahmen und Upgrades sowie den betrieblichen Aufwand, all dies am Laufen zu halten.

kcp verfolgt einen grundlegend anderen Ansatz. Was wäre, wenn man jedem Team so etwas wie einen eigenen Kubernetes-Cluster zur Verfügung stellen könnte – mit eigenen CRDs, eigenem RBAC und eigenen Ressourcen –, ohne dabei Rechenleistung bereitzustellen? Nur die API-Infrastruktur.

Genau das macht kcp. Es handelt sich um ein CNCF-Sandbox-Projekt, das eine Kubernetes-ähnliche API-Infrastruktur – die Control Plane – bereitstellt, jedoch ohne Pods, Nodes oder Container-Orchestrierung. Man erhält die Teile von Kubernetes, die den Status und die APIs verwalten, ohne die Teile, die die Rechenleistung verwalten.

Was ist kcp?

kcp ist eine quelloffene, horizontal skalierbare Steuerungsebene für Kubernetes-ähnliche APIs. Das Projekt wurde am 19. September 2023 in die CNCF Sandbox aufgenommen, wobei der erste Commit bereits im Juli 2020 erfolgte.

Im Kern bietet kcp Arbeitsbereiche — Jeder fungiert wie ein eigenständiger Kubernetes-API-Server. Sie können CRDs erstellen, RBAC-Richtlinien anwenden, Admission-Webhooks ausführen und Ressourcen innerhalb jedes Workspaces verwalten. Von außen betrachtet fühlt sich die Interaktion mit einem Workspace genau so an wie die Interaktion mit einem Kubernetes-Cluster. Sie verwenden kubectl. Sie erstellen Standard-YAML-Manifeste. Ihre vorhandenen Tools funktionieren ohne Anpassungen.

Der entscheidende Unterschied: Es gibt keine Pods. Keine Nodes. Keine Container-Laufzeitumgebung. Kein Scheduler, der entscheidet, wo Workloads platziert werden. kcp ist die auf das Wesentliche reduzierte Kubernetes-API-Infrastruktur – CRDs, RBAC, Zulassungskontrolle und Ressourcenmanagement – ohne die Scheduling- und Rechenebene. Wie das Projekt selbst es formuliert: kcp „ersetzt Kubernetes nicht, sondern ergänzt es als Backend, um Kubernetes-ähnliche APIs als SaaS zu hosten.“

Da ein Workspace auf einem logischen Cluster basiert, der in einem eigenen etcd-Präfixbereich gespeichert ist, sind Workspaces kostengünstig. Eine einzige kcp-Instanz kann viele Tausende davon hosten – jeder mit eigenen CRDs, eigenem RBAC und eigenem storage , anstatt für jeden Mandanten eine vollständige Kubernetes-Steuerungsebene einzurichten.

Inwiefern unterscheidet sich kcp von Kubernetes?

Am einfachsten lässt sich kcp verstehen, wenn man sich ansieht, was es aus Kubernetes beibehält und was es weglässt:

Die wichtigste Erkenntnis dabei: kcp nutzt nur die Teile von Kubernetes, die den Status und die APIs verwalten, und verzichtet auf die Teile, die die Rechenleistung verwalten. Das ist keine Einschränkung – es ist eine bewusste Designentscheidung. Die Steuerungsebene und die Rechenebene sind getrennte Bereiche, und kcp ermöglicht es Ihnen, sie auch so zu behandeln.

kcp selbst führt keine Container aus und plant keine Workloads auf physischen Kubernetes-Clustern ein. Frühere Versionen von kcp enthielten zu diesem Zweck einen Syncer- und einen Transparent-Multi-Cluster-Code (TMC), doch beide wurden im Mai 2023 aus dem Projekt entfernt, um kcp wieder auf das reine API-Management zu konzentrieren. Wenn Workloads benötigt werden, führen API-Anbieter ihre eigenen Multi-Tenant-Operatoren aus, die aus kcp-Workspaces (über APIBindings) lesen und die Daten mit echten Kubernetes-Clustern oder einem beliebigen anderen Backend abgleichen. kcp ist die Steuerungsebene; die Rechenleistung verbleibt dort, wo sie bereits vorhanden ist.

Kernbegriffe

Drei Konzepte bilden die Grundlage von kcp. Wenn man diese versteht, erhält man das mentale Modell für alles andere.

Arbeitsbereiche

Arbeitsbereiche sind die grundlegende Isolationseinheit in kcp. Jeder Arbeitsbereich ist ein Kubernetes-Cluster-ähnlicher HTTPS-Endpunkt, der von einem eigenen logischen Cluster in etcd mit voneinander getrennten storage unterstützt wird. Das bedeutet, dass ein Arbeitsbereich über eigene CRDs, ein eigenes RBAC und einen eigenen storage verfügt storage ohne gemeinsame Nutzung mit anderen Arbeitsbereichen. Wenn Namespaces in Kubernetes Zimmer in einem Mehrfamilienhaus sind, dann sind Workspaces in kcp völlig separate Häuser.

Arbeitsbereiche sind hierarchisch aufgebaut. Ein Arbeitsbereich kann untergeordnete Arbeitsbereiche enthalten, die wiederum eigene untergeordnete Arbeitsbereiche enthalten können, die in einer Baumstruktur angeordnet sind. Die Arbeitsbereichstypen legen fest, welche übergeordneten Arbeitsbereiche welche untergeordneten Arbeitsbereiche enthalten können, sodass sich die Hierarchie auf natürliche Weise auf Organisationsstrukturen abbilden lässt: einen Arbeitsbereich auf oberster Ebene für Ihr Plattformteam, untergeordnete Arbeitsbereiche für jedes Produktteam und weiter untergeordnete Arbeitsbereiche für einzelne Umgebungen wie Staging und Produktion.

Tipp: Aus Sicht eines Entwicklers unterscheidet sich die Interaktion mit einem Workspace nicht von der Interaktion mit einem Kubernetes-Cluster. Punkt kubectl, client-gooder helm am Endpunkt des Arbeitsbereichs, und alles funktioniert.

APIExport

Ein APIExport So veröffentlicht ein Anbieter-Arbeitsbereich APIs, die von anderen Arbeitsbereichen genutzt werden können. Er verweist auf einen oder mehrere APIRessourcenschemata — die CRD-ähnlichen Schemata, die die Struktur der exportierten APIs definieren — und stellt sie für die Anbindung bereit.

Stellen Sie sich das wie einen Eintrag im Servicekatalog vor. Ein Datenbankteam erstellt einen APIExport um zu sagen: „Ich biete eine Datenbank Ressource. Hier ist ihr Schema. So erreichen Sie den Controller, der sie abgleichen.“

APIBinding

Ein APIBinding beschreibt, wie ein Verbraucher-Arbeitsbereich eine veröffentlichte API importiert und nutzt. Er verweist auf eine APIExport und bindet jede dort definierte API in den Arbeitsbereich des Verbrauchers ein. Nach der Einbindung kann der Verbraucher kubectl apply a Datenbank so, als wäre das CRD lokal installiert – doch der Controller, der die Abstimmung vornimmt, befindet sich im Arbeitsbereich des Anbieters, nicht in dem des Verbrauchers.

Gemeinsam, APIExport und APIBinding Erstellen Sie einen dezentralen Servicekatalog. Anbieter veröffentlichen ihr Angebot. Nutzer binden sich an das, was sie benötigen. Das Plattformteam legt über die Workspace-Hierarchie und RBAC fest, welche Exporte für welche Workspaces sichtbar sind. Keine Tickets. Keine manuelle Bereitstellung. Nur APIs.

Flussdiagramm LR
    Teilgraph Provider["Provider-Arbeitsbereich (db-team)"]
        Schema[APIResourceSchema
databases.v1.example.io]
        Export[APIExport
database-service]
        Controller[Multi-tenant
operator]
        Schema --> Export
    Ende

    Teilgraph Consumer["Consumer Workspace (app-team)"]
        Bindung[APIBinding
→ database-service]
        DB[Database
my-app-prod]
        Bindung --> DB
    end

    Export -. veröffentlicht .-> Bindung
    Controller -. gleicht ab .-> DB
    DB -. bereitstellt .-> Backend[(Real DB
auf k8s / Cloud)]

Ausführen von Workloads mit kcp

kcp selbst führt keine Container aus. Um APIs, die an einen Arbeitsbereich gebunden sind, zum Laufen zu bringen, führt ein Anbieter in der Regel einen Betreiber mit mehreren Mandanten das über die Arbeitsbereiche wacht, die es verbinden APIExport und lässt sich mit jedem beliebigen Backend integrieren – sei es ein oder mehrere physische Kubernetes-Cluster, ein Cloud-Anbieter oder ein maßgeschneidertes System. Die kcp-Community bezeichnet dieses Muster als „APIs as a Service“: kcp bildet die Steuerungsebene, der Operator eines anderen Anbieters die Recheninstanz.

Wann sollte man kcp verwenden?

kcp ist kein universeller Ersatz für Kubernetes. Es löst bestimmte Probleme sehr gut. Hier sind drei konkrete Anwendungsfälle, in denen kcp seine Stärken ausspielen kann.

Interne Entwicklerplattformen

Bieten Sie jedem Team einen Arbeitsbereich, der wie ein Kubernetes-Cluster aussieht und sich auch so anfühlt. Entwickler arbeiten mit Standard- kubectl Befehle ausführen, Standard-Manifeste erstellen und die ihnen bereits bekannten Tools nutzen. Hinter den Kulissen betreiben Sie jedoch eine einzige KCP-Instanz anstelle von Dutzenden separater Cluster.

Die Kosteneinsparungen sind beträchtlich. Sie vermeiden den Verwaltungsaufwand für die einzelnen Cluster, verringern den Arbeitsaufwand für die Verwaltung von Upgrades und Patches über viele Cluster hinweg und zentralisieren die Durchsetzung von Richtlinien.

SaaS-Steuerungsebenen

Wenn Sie ein mandantenfähiges SaaS-Produkt entwickeln, bietet Ihnen kcp ein nahtloses Isolationsmodell. Jeder Kunde erhält einen eigenen Arbeitsbereich mit maßgeschneiderten APIs, die genau auf seine Bedürfnisse zugeschnitten sind. Arbeitsbereiche gewährleisten eine strenge Isolation – ein Kunde kann die Ressourcen eines anderen Kunden weder einsehen noch beeinflussen.

Dieses Modell eignet sich besonders gut für Infrastrukturprodukte: verwaltete Datenbanken, CI/CD-Plattformen, Überwachungsdienste oder alles, wofür Kunden einen eigenen Ressourcen-Namespace mit API-gesteuerter Verwaltung benötigen.

API-orientiertes Plattform-Engineering

Nutzen Sie APIExport und APIBinding, um eine Self-Service-Plattform aufzubauen, auf der Serviceteams ihre Angebote veröffentlichen und Nutzerteams die für sie relevanten Dienste auswählen können. So entsteht ein dezentraler, API-gesteuerter Servicekatalog, der mit Ihrem Unternehmen mitwächst.

Anstatt dass ein zentrales Plattformteam als Engpass bei der Bearbeitung von Anfragen fungiert, stellt jedes Team seine Funktionen als APIs zur Verfügung. Die Nutzer finden diese und binden sich daran. Das Plattformteam regelt den Zugriff über RBAC und die Arbeitsbereichshierarchie, ohne bei jeder Anfrage als kritischer Knotenpunkt zu fungieren.

kcp im Vergleich zur herkömmlichen Mandantenfähigkeit

Die Mehrmandantenfähigkeit in Kubernetes stellt seit jeher eine Herausforderung dar. Hier ein Vergleich der wichtigsten Ansätze:

• Namensräume: Schwache Isolierung innerhalb eines gemeinsamen Clusters. Alle Mandanten nutzen dieselben CRDs, denselben API-Server und dieselbe Steuerungsebene. Das ist für vertrauenswürdige Teams innerhalb einer einzigen Organisation in Ordnung, doch die Grenzen sind fließend.

• vcluster: Virtuelle Kubernetes-Cluster, die als Workloads innerhalb eines Host-Clusters ausgeführt werden – jeder vcluster verfügt über einen eigenen API-Server (in der Regel k3s oder k8s) und einen eigenen Datenspeicher. Die Isolation ist stärker als bei Namespaces, und die Workloads werden tatsächlich ausgeführt. Allerdings beansprucht jeder vcluster weiterhin Rechenressourcen auf dem Host, und Sie sind nach wie vor für den Host-Cluster verantwortlich.

• kcp Workspaces: Vollständige Isolierung auf API-Ebene ohne Rechenaufwand. Jeder Workspace ist ein eigenständiger API-Bereich. Keine gemeinsam genutzten CRDs, keine gemeinsam genutzten Ressourcen, kein gemeinsam genutzter Status der Steuerungsebene. Ideal für die Entwicklung von Plattformen, bei denen eine starke Isolierung in großem Maßstab erforderlich ist.

Jeder Ansatz eignet sich für unterschiedliche Situationen. Namespaces eignen sich für einfache Fälle. vcluster ist die richtige Wahl, wenn Sie virtuelle Cluster-Semantik mit vorhandener Rechenleistung benötigen. kcp ist die richtige Wahl, wenn Sie API-Isolation ohne Rechenkosten benötigen.

Einen ausführlicheren Vergleich finden Sie unter „kcp-Arbeitsbereiche vs. Namensräume vs. vcluster“.

Das große Ganze

kcp bildet die Grundlage der Kubermatic Developer Platform (KDP). Es stellt die mandantenfähige, API-gesteuerte Steuerungsebene bereit, auf der die KDP aufbaut, um ein umfassendes Entwicklerplattform-Erlebnis zu bieten.

Dies entspricht einem allgemeinen Trend innerhalb der Plattform-Engineering-Bewegung. Die Branche verlagert sich hin zu einer API-gesteuerten Self-Service-Infrastruktur, in der Plattformteams Produkte für ihre internen Entwickler erstellen. kcp steht für ein spezifisches Architekturmuster innerhalb dieses Wandels: die Steuerungsebene als eigenständiges Produkt und nicht als Nebeneffekt des Containerbetriebs.

Durch die Trennung der Steuerungsebene von der Recheneinheit ermöglicht kcp Ihnen, die API-Ebene Ihrer Plattform unabhängig von der Recheneinheit zu skalieren. Sie können Tausende von Mandanten über eine einzige kcp-Instanz bedienen und Rechencluster nur dort und dann hinzufügen, wo und wann Sie sie benötigen.

Warnung: kcp ist ein CNCF-Sandbox-Projekt. Es befindet sich in aktiver Entwicklung und wird ohne sorgfältige Prüfung noch nicht für Produktionsumgebungen empfohlen. Die API-Oberfläche kann sich von Version zu Version ändern.

Nächste Schritte

Sind Sie bereit, selbst loszulegen? Das nächste Tutorial dieser Reihe führt Sie durch die Installation von kcp und die Erstellung Ihres ersten Arbeitsbereichs:

• kcp installieren und Ihren ersten Arbeitsbereich erstellen

Wenn Sie verschiedene Multi-Tenancy-Optionen prüfen und einen detaillierteren Vergleich der oben genannten Ansätze wünschen, lesen Sie den speziellen Vergleichsleitfaden:

• kcp-Arbeitsbereiche vs. Namensräume vs. vcluster

Zusammenfassung

kcp ist Kubernetes ohne die Rechenschicht – eine reine API-Infrastruktur zum Aufbau mandantenfähiger Plattformen. Es bietet Arbeitsbereiche zur Isolierung und APIExport/APIBinding für einen dezentralen Servicekatalog. Die Rechenleistung verbleibt bei demjenigen, der die Operatoren hinter den APIs betreibt. Ganz gleich, ob Sie eine interne Entwicklerplattform oder ein mandantenfähiges SaaS-Produkt aufbauen – kcp bietet Ihnen Kubernetes-kompatible Isolation zu einem Bruchteil der Kosten, die beim Betrieb separater Cluster anfallen würden.