kcp installieren und Ihren ersten Arbeitsbereich erstellen

Einführung

Im vorherigen Artikel haben Sie erfahren, was kcp ist und wozu es dient: ein Kubernetes-API-Server, der sich auf das Status- und API-Management konzentriert, ohne die Rechenebene. Das war die Theorie. Jetzt geht es ans Eingemachte.

In diesem Tutorial installieren Sie kcp auf Ihrem lokalen Rechner, starten einen Server, erstellen mehrere Arbeitsbereiche und erleben die Isolierung von Arbeitsbereichen in der Praxis. Am Ende werden Sie verstehen, wie kcp-Arbeitsbereiche unabhängige API-Bereiche bereitstellen – jeder mit eigenen Ressourcen, eigenen CRDs und einer eigenen Sicht auf die Welt. Außerdem werden Sie erkennen, warum dies für das Platform Engineering von Bedeutung ist: Arbeitsbereiche bieten Ihnen die Isolation separater Cluster, ohne den betrieblichen Aufwand, diese tatsächlich ausführen zu müssen.

Alles in diesem Tutorial läuft lokal. Du benötigst weder einen Kubernetes-Cluster noch ein Cloud-Konto oder eine spezielle Infrastruktur. Du brauchst lediglich ein Terminal und etwa fünfzehn Minuten Zeit.

Schritt 1: Installieren Sie kcp

Sie haben zwei Möglichkeiten, kcp zu installieren: Sie können entweder eine vorgefertigte Binärdatei herunterladen oder das Programm aus dem Quellcode kompilieren. Die vorgefertigte Binärdatei ist schneller und funktioniert bei den meisten Nutzern.

Option A: Eine vorgefertigte Binärdatei herunterladen (empfohlen)

Lade die neueste Version von GitHub herunter. Die folgenden Befehle ermitteln die neueste Version, laden sie herunter, entpacken sie und fügen die ausführbare Datei zu deinem PATH hinzu:

KCP_VERSION=$(curl -s https://api.github.com/repos/kcp-dev/kcp/releases/latest | grep tag_name | cut -d '"' -f 4)
curl -L -o kcp.tar.gz "https://github.com/kcp-dev/kcp/releases/download/${KCP_VERSION}/kcp_${KCP_VERSION}_linux_amd64.tar.gz"
tar xzf kcp.tar.gz
sudo mv bin/kcp /usr/local/bin/

Wenn Sie macOS verwenden, ersetzen Sie linux_amd64 mit darwin_amd64 (Intel) oder darwin_arm64 (Apple Silicon).

Option B: Aus dem Quellcode kompilieren

Wenn Sie lieber aus dem Quellcode kompilieren möchten oder mit der neuesten Entwicklungsversion arbeiten wollen, klonen Sie das Repository und kompilieren Sie:

git clone https://github.com/kcp-dev/kcp.git
cd kcp
make build
sudo mv bin/kcp /usr/local/bin/

Für die Kompilierung aus dem Quellcode ist Go 1.21 oder höher erforderlich. Sollte die Kompilierung aufgrund von Versionsfehlern fehlschlagen, überprüfe deine Go-Version mit go version und bei Bedarf aktualisieren.

Überprüfen Sie die Installation

Unabhängig davon, für welche Option Sie sich entschieden haben, überprüfen Sie bitte, ob kcp korrekt installiert ist:

kcp --version

Die Versionsnummer sollte auf dem Bildschirm angezeigt werden. Falls die Fehlermeldung „Befehl nicht gefunden“ erscheint, stellen Sie sicher, dass /usr/local/bin/ befindet sich in Ihrem PATH.

Schritt 2: Installieren Sie das kubectl-kcp-Plugin

kcp wird mit einem kubectl-Plugin ausgeliefert, das Befehle zur Verwaltung von Arbeitsbereichen bereitstellt. Dieses Plugin ist unverzichtbar – damit können Sie Arbeitsbereiche über die Befehlszeile erstellen, darin navigieren und sie verwalten.

Wenn Sie in Schritt 1 die vorgefertigte Binärdatei heruntergeladen haben, befindet sich das Plugin bereits im entpackten Archiv:

sudo mv bin/kubectl-kcp /usr/local/bin/

Wenn Sie das Plugin aus dem Quellcode kompiliert haben, befindet sich die ausführbare Datei im selben bin/ Verzeichnis als kcp-Binärdatei.

Überprüfen Sie, ob das Plugin installiert ist:

kubectl kcp --help

Es sollte eine Liste mit Unterbefehlen angezeigt werden, darunter Arbeitsbereich. Dieses Plugin erweitert kubectl um kcp-spezifische Funktionen – das Erstellen, Durchsuchen und Verwalten von Arbeitsbereichen – und bewahrt dabei die gewohnte kubectl-Benutzeroberfläche, die Sie bereits kennen.

Schritt 3: Starten Sie den kcp-Server

Öffne ein Terminal und starte den kcp-Server:

kcp starten

kcp startet schnell. Im Hintergrund startet es eine eingebettete etcd-Instanz für storage richtet die Kubernetes-API-Infrastruktur ein. Während der Initialisierung werden Log-Meldungen angezeigt. Sobald Zeilen erscheinen, die darauf hinweisen, dass der Server bereit ist und auf Verbindungen wartet, können Sie loslegen.

kcp erstellt eine Admin-Kubeconfig-Datei unter .kcp/admin.kubeconfig in dem Verzeichnis, in dem Sie den Befehl ausgeführt haben. Diese Datei verwenden Sie, um kubectl mit Ihrem kcp-Server zu verbinden.

Lassen Sie dieses Terminal geöffnet. Öffnen Sie für die folgenden Schritte ein neues Terminal.

Tipp: Um ganz von vorne anzufangen, kannst du --Stammverzeichnis um festzulegen, wo kcp seine Daten speichert. Dies ist nützlich, wenn Sie Ihre Experimente übersichtlich organisieren möchten. Um alles zurückzusetzen, löschen Sie einfach dieses Verzeichnis und beginnen Sie von vorne.

Schritt 4: Mit kubectl eine Verbindung zu kcp herstellen

Rufen Sie in Ihrem neuen Terminal mit der generierten kubeconfig-Datei über kubectl den kcp-Server auf:

export KUBECONFIG=$(pwd)/.kcp/admin.kubeconfig

Stellen Sie sicher, dass Sie diesen Befehl aus demselben Verzeichnis ausführen, in dem Sie kcp gestartet haben, da der Pfad in der kubeconfig relativ ist.

Führen Sie nun die verfügbaren API-Ressourcen auf:

kubectl api-resources

Sehen Sie sich die Ausgabe genau an. Sie werden bekannte Kubernetes-API-Ressourcen erkennen – ConfigMaps, Secrets, ServiceAccounts, Namespaces, CustomResourceDefinitions und mehr. Pods, Deployments, Services oder Nodes werden jedoch nicht angezeigt. Diese gehören zur Rechenschicht und werden von kcp nicht berücksichtigt.

Dies ist der Kernpunkt aus dem vorherigen Artikel, der sich nun in der Praxis zeigt: Sie kommunizieren mit einem Kubernetes-API-Server, der den Status und die APIs verwaltet, nicht die Rechenleistung.

Führen Sie noch einen Befehl aus, um zu überprüfen, ob alles funktioniert:

kubectl namespaces abrufen

Sie werden das sehen Standard Namespace, genau wie bei normalem Kubernetes. Die API verhält sich genau so, wie man es erwartet – es gibt lediglich keinen Scheduler und kein Kubelet dahinter.

Schritt 5: Den Root-Arbeitsbereich erkunden

kcp organisiert alles in einer Hierarchie von Arbeitsbereichen. Beim ersten Start des Servers befinden Sie sich im Stammarbeitsbereich – der obersten Ebene der Hierarchie.

Überprüfen Sie, wo Sie sich befinden:

kubectl kcp workspace .

Dadurch wird der aktuelle Arbeitsverzeichnispfad ausgegeben. Du solltest sehen, dass du dich im Stammverzeichnis befindest.

Nenne die verfügbaren Arten von Arbeitsbereichen:

kubectl get workspacetypes

Arbeitsbereichstypen legen fest, welche APIs und Funktionen in einem Arbeitsbereich bei dessen Erstellung verfügbar sind. Die universell Dieser Typ umfasst den Standardsatz an Kubernetes-APIs (mit Ausnahme der Rechenressourcen) und wird am häufigsten für allgemeine Arbeitsbereiche verwendet.

Stellen Sie sich den Stamm-Arbeitsbereich als die oberste Organisationseinheit vor. In einer realen Bereitstellung würden Sie hier untergeordnete Arbeitsbereiche für Teams, Projekte oder Umgebungen anlegen. Genau das werden Sie als Nächstes tun.

Schritt 6: Erstellen Sie Ihren ersten Arbeitsbereich

Erstellen Sie einen Arbeitsbereich mit dem Namen Team Alpha:

kubectl kcp workspace create team-alpha --type universal --enter

Die --Typ: Universal Das Flag weist kcp an, einen Arbeitsbereich mit den Standard-APIs zu erstellen. Das --Eingabe Das Flag wechselt Ihren kubectl-Kontext automatisch in den neuen Arbeitsbereich, sodass Sie nicht manuell dorthin navigieren müssen.

Überprüfen Sie, wo Sie sich befinden:

kubectl kcp workspace .

Du solltest sehen, dass du dich jetzt darin befindest Team Alpha. Von diesem Zeitpunkt an wird jeder von Ihnen ausgeführte kubectl-Befehl innerhalb dieses Arbeitsbereichs ausgeführt. Es ist, als hätten Sie zu einem völlig anderen Kubernetes-Cluster gewechselt – nur dass Sie das gar nicht getan haben. Sie kommunizieren weiterhin mit demselben kcp-Server.

Schritt 7: Ressourcen im Arbeitsbereich erstellen

Erstellen Sie eine ConfigMap innerhalb von Team Alpha:

kubectl create configmap app-config--from-literal=env=staging--from-literal=region=eu-west

Überprüfen Sie, ob es vorhanden ist:

kubectl get configmaps

Das solltest du dir ansehen App-Konfiguration neben der Standardeinstellung aufgeführt kube-root-ca.crt ConfigMap. Diese Ressource existiert nur in Team Alpha. Kein anderer Arbeitsbereich kann ihn sehen, ändern oder überhaupt von seiner Existenz erfahren. Das ist echte Isolation – nicht nur RBAC-Regeln, die den Zugriff verhindern, sondern eine vollständige Trennung auf API-Ebene.

Schritt 8: Erstellen Sie einen zweiten Arbeitsbereich und überprüfen Sie die Isolierung

Zurück zum Stamm-Arbeitsbereich navigieren:

kubectl kcp workspace ..

Erstellen Sie einen zweiten Arbeitsbereich:

kubectl kcp workspace create team-beta --type universal --enter

Führe nun die ConfigMaps in Team Beta:

kubectl get configmaps

Nein App-Konfiguration hier. Die einzige ConfigMap ist die Standard-ConfigMap kube-root-ca.crt. Der Arbeitsbereich Team Beta ist vollständig isoliert von Team Alpha. Es verfügt über eigene Ressourcen, eine eigene Namespace-Struktur und eine eigene Sicht auf die API.

Erstellen Sie eine ConfigMap mit dem gleicher Name in Team Beta:

kubectl create configmap app-config--from-literal=env=production--from-literal=region=us-east

Das funktioniert ohne Probleme. Beide Arbeitsbereiche verfügen nun über eine ConfigMap namens App-Konfiguration in der Standard Namensraum, jedoch mit unterschiedlichem Inhalt. Es gibt keine Namenskonflikte, keine Namenskonventionen und keine Präfix-Hacks.

Warnung: Arbeitsbereiche sind keine Namespaces. Zwei Arbeitsbereiche können Ressourcen mit demselben Namen und Namespace enthalten, ohne dass es zu Konflikten kommt. Dies stellt eine echte Isolation auf API-Server-Ebene dar. Im regulären Kubernetes können nicht zwei CRDs denselben Namen haben, selbst in unterschiedlichen Namespaces nicht, da CRDs auf Cluster-Ebene gelten. In kcp verfügt jeder Arbeitsbereich über einen eigenen CRD-Bereich. Dieser Unterschied ist für die Mandantenfähigkeit von enormer Bedeutung.

Schritt 9: Zwischen Arbeitsbereichen wechseln

Mit kcp ist der Wechsel zwischen Arbeitsbereichen ganz einfach. Navigieren Sie wie in einem Dateisystem in der Hierarchie nach oben und unten:

kubectl kcp workspace ..              # Zum übergeordneten (Root-)Workspace wechseln
kubectl kcp workspace use team-alpha  # Zu team-alpha wechseln
kubectl get configmaps                # ConfigMap von team-alpha anzeigen (env=staging)

kubectl kcp workspace use team-beta   # Zu team-beta wechseln
kubectl get configmaps                # ConfigMap von team-beta anzeigen (env=production)

Bei jedem Wechsel ändert sich Ihr kubectl-Kontext. Sie sehen nur die Ressourcen, die zum aktuellen Arbeitsbereich gehören, und nichts anderes. Der Vorgang entspricht dem Wechsel zwischen verschiedenen Kubernetes-Clustern, nur dass er sofort erfolgt – ohne Verbindung zu einem neuen API-Server und ohne umständliches Einrichten der kubeconfig-Datei.

Schritt 10: Anwenden eines CRD in einem Arbeitsbereich

Dieser Schritt veranschaulicht einen der wesentlichsten Unterschiede zwischen Arbeitsbereichen und Namensräumen: die CRD-Isolation.

Erstellen Sie zunächst eine Datei mit dem Namen database-crd.yaml mit folgendem Inhalt:

apiVersion: apiextensions.k8s.io/v1
Art: CustomResourceDefinition
Metadaten:
  name: databases.example.com
Spezifikation:
  Gruppe: example.com
  Namen:
    Plural: Datenbanken
    Singular: Datenbank
    Art: Datenbank
  Gültigkeitsbereich: Namespace-
  Versionen:
    - Name: v1
      bereitgestellt: true
      storage: true
      Schema:
        openAPIV3Schema:
          Typ: Objekt
          Eigenschaften:
            Spezifikation:
              Typ: Objekt
              Eigenschaften:
                Engine:
                  Typ: Zeichenkette
                Größe:
                  Typ: Zeichenkette

Wechseln zu Team Alpha und wenden Sie die CRD an:

kubectl kcp workspace use team-alpha
kubectl apply -f database-crd.yaml

Überprüfen Sie, ob die CRD in Team Alpha:

kubectl get crds

Das solltest du dir ansehen databases.example.com aufgeführt. Wechseln Sie nun zu Team Beta und überprüfen:

kubectl kcp workspace use team-beta
kubectl crds abrufen

Das CRD existiert nicht in Team Beta. Im regulären Kubernetes gelten CRDs für den gesamten Cluster – jeder Namespace im Cluster kann sie sehen, und jede Namenskollision bei CRDs wirkt sich auf den gesamten Cluster aus. In kcp verfügt jeder Workspace über einen eigenen CRD-Bereich. Team Alpha kann eine Datenbank CRD mit einem Schema, und Team Beta kann sein eigenes definieren Datenbank CRD mit einem völlig anderen Schema, und sie werden sich niemals gegenseitig beeinträchtigen.

Genau diese Isolationsfunktion macht kcp für das Platform Engineering so attraktiv. Sie können jedem Team die volle Kontrolle über seine API-Oberfläche gewähren – einschließlich der Möglichkeit, benutzerdefinierte Ressourcen zu definieren –, ohne sich Gedanken über Konflikte mit anderen Teams machen zu müssen.

Flussdiagramm TB
    Root["root"]

    Teilgraph A["team-alpha"]
        CM1["ConfigMap/app-config
env=staging"]
        CRD1["CRD: databases.example.com"]
    Ende

    Teilgraph B["team-beta"]
        CM2["ConfigMap/app-config
env=production"]
        NoCRD["(kein Datenbanken-CRD)"]
    end

    Root --> A
    Root --> B

    A -. gleicher Name, unterschiedliche Daten .- B

Häufige Probleme

Port 6443 wird bereits verwendet. Eine andere kcp-Instanz oder ein Kubernetes-Prozess (wie minikube oder kind) läuft bereits auf diesem Port. Beenden Sie entweder den anderen Prozess oder starten Sie kcp mit einem anderen Port:

kcp start--secure-port=6444

kubectl kcp: Befehl nicht gefunden. Die ausführbare Datei des Plugins „kubectl-kcp“ befindet sich nicht in Ihrem PATH. Überprüfen Sie, ob sie sich in /usr/local/bin/ oder wo auch immer sich Ihre Go-Binärdateien befinden. Sie können auch nachsehen unter ls /usr/local/bin/kubectl-kcp. Wenn Sie das Programm aus dem Quellcode kompiliert haben, befindet es sich möglicherweise im bin/ Verzeichnis des kcp-Repositorys.

Unstimmigkeit bei der Go-Version beim Kompilieren aus dem Quellcode. kcp erfordert Go 1.21 oder höher. Überprüfen Sie Ihre installierte Version mit go version und bei Bedarf aktualisieren. Unter macOS, brew upgrade go kümmert sich darum. Unter Linux laden Sie die neueste Version von der Zur Download-Seite.

kubeconfig nicht gefunden. Stellen Sie sicher, dass Sie das KUBECONFIG exportieren Befehl aus demselben Verzeichnis, in dem Sie kcp gestartet haben. Der .kcp/admin.kubeconfig Die Datei wird relativ zum Arbeitsverzeichnis der kcp starten Befehl.

Nächste Schritte

Sie verfügen nun über eine funktionierende KCP-Installation und wissen, wie Arbeitsbereiche für Isolation sorgen. Hier finden Sie die nächsten Schritte:

• Gemeinsame Nutzung von APIs über Arbeitsbereiche hinweg mit APIExport und APIBinding (in Kürze verfügbar) – der nächste Artikel dieser Reihe. Sie erfahren, wie Sie APIs aus einem Arbeitsbereich für einen anderen freigeben und dort nutzen können – dies bildet die Grundlage für das Service-Marktplatz-Modell von kcp.
• kcp-Arbeitsbereiche vs. Namespaces vs. vcluster – ein detaillierter Vergleich verschiedener Multi-Tenancy-Ansätze, falls Sie wissen möchten, wie sich kcp im Vergleich zu anderen Tools positioniert.

Zusammenfassung

Sie haben kcp installiert, einen lokalen Server gestartet, zwei isolierte Arbeitsbereiche erstellt und gezeigt, dass Ressourcen – einschließlich CRDs – in einem Arbeitsbereich für den anderen nicht sichtbar sind. Sie sind zwischen den Arbeitsbereichen gewechselt, haben überprüft, dass Ressourcen mit identischen Namen konfliktfrei nebeneinander existieren können, und festgestellt, dass die CRD-Isolation einer der deutlichsten Unterschiede zwischen kcp-Arbeitsbereichen und Kubernetes-Namespaces ist.

Dies ist die Grundlage des kcp-Ansatzes für Multi-Tenancy: vollständige Isolierung auf API-Ebene ohne den Aufwand, separate Cluster betreiben zu müssen. Jeder Workspace verhält sich wie ein eigener Kubernetes-API-Server, doch alle laufen auf einer einzigen kcp-Instanz. Für Plattformteams bedeutet dies, dass sie jedem Mandanten einen eigenen isolierten API-Bereich – mit eigenen CRDs, eigenem RBAC und eigenen Ressourcen – zu einem Bruchteil der Kosten dedizierter Cluster anbieten können.

Im nächsten Tutorial erfahren Sie, wie Sie diese Isolationsgrenzen mithilfe von APIExport und APIBinding gezielt aufheben können, sodass Arbeitsbereiche APIs gemeinsam nutzen können, ohne ihre Unabhängigkeit zu verlieren.