Virtual Clusters

Teil von Runtimes

Dies ist ein detaillierter Leitfaden für Virtual Clusters (Cloud Native Deployments). Eine Übersicht über alle Runtime-Typen und wie man zwischen ihnen wählt, findet sich unter Runtimes-Übersicht.

Virtual Clusters ermöglichen es, Kubernetes-Workloads innerhalb der Codesphere-Infrastruktur auszuführen. Jeder Virtual Cluster stellt eine dedizierte Kubernetes-Umgebung für die eigene Resource Group bereit und unterstützt Standard-Kubernetes-Workloads und -Tools.

Jeder Virtual Cluster ist isoliert und verfügt über eine eigene Control Plane sowie eigene Ressourcenlimits. Workloads können unabhängig von anderen Resource Groups und sicher deployt, aktualisiert und entfernt werden.

Virtual Clusters sind als Managed Services innerhalb von Codesphere implementiert. Jeder Virtual Cluster läuft als verwaltete Kubernetes-Umgebung. Codesphere verwaltet die zugrunde liegende Infrastruktur, während Virtual Clusters die Vorteile der Kubernetes-APIs bieten und native Workloads sowie Abhängigkeiten unterstützen.

hinweis

Diese Funktion richtet sich an fortgeschrittene Nutzer mit Kubernetes-Erfahrung. Wenn kein direkter Zugriff auf Kubernetes-Primitive benötigt wird, empfiehlt sich für einfachere Workflows die Nutzung anderer Codesphere-Runtimes.

Kompatibilität

Virtual Clusters sind für Kubernetes-native Workloads konzipiert. Kubernetes-Abhängigkeiten können mitgebracht und vertraute Tools wie Helm-Charts genutzt werden, um Anwendungen und Dienste direkt im Codesphere-Ökosystem zu deployen.

Virtual Clusters folgen standardmäßig den Kubernetes-Pod Security Standards auf der Ebene restricted. Das bedeutet, dass Workloads privilegierte oder Host-Level-Zugriffsmuster vermeiden und gehärtete Pod- und Container-Sicherheitseinstellungen einhalten müssen. Manche Helm-Charts oder Manifeste von Drittanbietern erfordern möglicherweise Konfigurationsänderungen, bevor sie ausgeführt werden können.

Übliche Anpassungen sind:

• Container als Non-Root-Nutzer ausführen
• Privilegierte Container und Privilege Escalation deaktivieren
• Host-Namespaces, Host-Pfade und Host-Ports vermeiden
• Ein explizites Seccomp-Profil festlegen, z. B. RuntimeDefault

tipp

Zum Beispiel lässt sich Apache Superset in nur wenigen Schritten aus der Codesphere IDE oder der Landscape heraus deployen, direkt im Virtual Cluster:

helm repo add superset https://apache.github.io/superset
helm repo update
kubectl create namespace superset
helm install superset superset/superset --namespace superset

Konnektivität

Virtual Clusters sind eng in die Codesphere-Plattform integriert, wodurch sich Kubernetes-Workloads einfach mit anderen Codesphere-Ressourcen verbinden lassen. Als Teil des Codesphere-Host-Clusters können Virtual Clusters nahtlos mit Landscapes, Managed Services und anderen Ressourcen innerhalb desselben Teams kommunizieren. Diese Integration vereinfacht komplexe Architekturen und ermöglicht leistungsstarke Workflows über die gesamte Cloud-Infrastruktur hinweg.

Entsprechende barrierefreie Textbeschreibung

Nur IPv4

Das Virtual-Cluster-Netzwerk unterstützt derzeit nur IPv4. IPv6 wird nicht unterstützt.

Zugriff auf Cluster-Ressourcen

Kubernetes-Pods und -Dienste, die innerhalb des Virtual Clusters laufen, sind von jedem Workspace innerhalb derselben Resource Group aus erreichbar. Das bedeutet, dass Anwendungen und Dienste direkt aus den Codesphere-Workspaces heraus angesprochen werden können, was Entwicklung und Fehlerbehebung effizienter macht.

info

Um auf einen im Virtual Cluster laufenden Dienst zuzugreifen, wird Folgendes benötigt:

1. Der Ressourcenname (z. B. superset)
2. Der Namespace-Name (z. B. default)
3. Die Codesphere-Resource-Group-ID (z. B. 180312) Mit diesen Informationen lässt sich der Dienst über eine URL im folgenden Format erreichen:

http://[RESOURCE_NAME]-x-[VIRTUAL_NAMESPACE]-x-k8s.rg-[RESOURCE_GROUP_NAME]

Load-Balancer-Ingress zulassen

Standardmäßig sind Pods innerhalb des Virtual Clusters nicht von externen Load Balancern erreichbar. Um eingehenden Load-Balancer-Traffic zu einem Pod zuzulassen, fügt man dem Pod (oder dessen Pod-Template) folgendes Label hinzu:

codesphere.com/allow-ingress-traffic: "true"

Wenn dieses Label vorhanden ist, wendet die Plattform eine Network Policy an, die eingehenden Traffic aus den vom Cluster-Administrator konfigurierten Subnetzen erlaubt. Pods ohne dieses Label sind davon nicht betroffen und bleiben von Load-Balancer-Traffic isoliert.

Bei Verwendung von Envoy Gateway im vCluster muss dieses Label der EnvoyProxy-Ressource hinzugefügt werden, um eingehenden Traffic zu allen vom Envoy Gateway verwalteten Routen zuzulassen:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: demo-envoyproxy
  namespace: demo
spec:
  provider:
    type: Kubernetes
    kubernetes:
      envoyDeployment:
        pod:
          labels:
            codesphere.com/allow-ingress-traffic: "true"

hinweis

Hierfür muss der Private-Cloud-Administrator die zulässigen Quell-Subnetze über den Helm-Wert global.vcluster.ingressFromSubnets konfiguriert haben. Sind keine Subnetze konfiguriert, wird die Network Policy nicht erstellt und das Label hat keine Wirkung.

Zugriff aus dem Virtual Cluster

Der Virtual Cluster kann auch auf andere Codesphere-Ressourcen zugreifen, etwa Landscapes und Managed Services (zum Beispiel Managed Postgres) innerhalb derselben Resource Group. Dies erleichtert den Aufbau komplexer Multi-Service-Anwendungen, die sowohl Kubernetes als auch Codesphere-Lösungen umfassen.

info

Um auf ein Reactive eines Workspace aus dem Virtual Cluster zuzugreifen, wird Folgendes benötigt:

1. Der Name des Landscape-Reactive-Dienstes
2. Die ID des Workspace, in dem das Reactive deployt ist Anschließend kann folgendes URL-Format verwendet werden:

http://ws-server-[WORKSPACE_ID]-[REACTIVE_NAME].workspaces

Mögliche Anwendungsfälle

1. Superset als Helm-Chart deployen
2. Grafana deployen und mit einem in Codesphere laufenden Managed-Postgres-Dienst verbinden
3. Prometheus deployen und mit in Codesphere laufenden Anwendungen verbinden, um benutzerdefinierte Metriken zu überwachen
4. Eine Custom Resource Definition und Controller hinzufügen (z. B. JSPolicy)

Cluster-Zugriff

Der primäre Weg, mit dem Virtual Cluster zu interagieren, führt über die kubeconfig-Datei, die direkt in das Dateisystem des Workspace eingebunden wird. Diese Konfigurationsdatei ermöglicht es, kubectl- und helm-Befehle direkt im Workspace-Terminal sowie in den Ausführungsschritten der Landscape zu verwenden.

Die Konfigurationsdatei wird automatisch als ~/.kube/config in das Dateisystem des Workspace eingebunden. kubectl und helm verwenden sie standardmäßig als Konfigurationsdatei, um sich mit dem Virtual Cluster zu verbinden.

tipp

Releases lassen sich in der Prepare- oder Run-Stage einer Landscape automatisieren und versionieren, indem Folgendes ausgeführt wird:

helm upgrade --install my-release my-charts/my-app --version 2.1.0

Shell-Alias

Wer häufig kubectl eintippt, kann dem eigenen Shell-Profil einen kürzeren Alias hinzufügen, z. B. alias k=kubectl.

Konfigurationsaktualisierung auslösen

Die Kubeconfig-Datei wird (erneut) in den Workspace eingebunden, wenn eines der folgenden Ereignisse eintritt:

1. Die Liste der Workspace-Umgebungsvariablen wird geändert
2. Der Workspace wird gestartet
3. Workspace-Ressourcen werden aktualisiert (z. B. Plan wird geändert, Landscape wird synchronisiert)

info

Wir arbeiten an einer verbesserten Synchronisierung der Kubeconfig-Datei für Landscapes und lang laufende Workspaces. Bei Problemen mit einer veralteten oder fehlenden Kubeconfig empfiehlt es sich vorerst, eine Umgebungsvariable zu ändern oder den Workspace neu zu starten, um eine erneute Einbindung der Konfigurationsdatei auszulösen.

Abhängigkeiten

Die Binärdateien kubectl und helm sind im Standard-Codesphere-Workspace-Image vorinstalliert. Bei Verwendung eines benutzerdefinierten Images sollte sichergestellt werden, dass diese Abhängigkeiten vorhanden sind, falls mit dem Virtual Cluster interagiert werden soll.

kubectl-Version prüfen

Mit kubectl version lassen sich sowohl die Client- als auch die Server-Version prüfen. Gemäß der Kubernetes-Version-Skew-Policy sollte der kubectl-Client innerhalb einer Minor-Version der Kubernetes-Server-Version des Virtual Clusters bleiben, um Kompatibilitätsprobleme zu vermeiden.

Cluster verwalten

Virtual Clusters sind als Managed Service in Codesphere verfügbar. Der Lebenszyklus der Cluster wird über die Managed-Services-Oberfläche verwaltet, über die Cluster nach Bedarf erstellt, aktualisiert und gelöscht werden können.

Weitere Details finden sich in der Managed-Services-Dokumentation.

Einen Virtual Cluster erstellen

info

Derzeit kann jede Resource Group aufgrund der Namespace-Beschränkungen der Resource Group nur einen Virtual Cluster besitzen. Vor dem Erstellen eines neuen Clusters sollte geprüft werden, ob die Resource Group bereits einen enthält.

Um einen Virtual Cluster zu erstellen, folgt man diesen Schritten:

1. Im Codesphere-Workspace zum Tab Managed Services wechseln.

2. Virtual Kubernetes Cluster aus dem Servicekatalog auswählen. Mit dieser Option lässt sich ein neuer Cluster für das Team einrichten.

3. Einen Namen eingeben und die entsprechenden Eingaben nutzen, um die Ressourcen-Quota des Virtual Clusters nach Bedarf zu konfigurieren:

   • vCPU
   • Arbeitsspeicher
   • Speicherplatz
   • Ephemeraler Speicher

   Jede Eingabe legt das entsprechende Ressourcenlimit (Quota) für den gesamten Cluster fest — der Regler Arbeitsspeicher legt beispielsweise den maximal verfügbaren, kumulierten Arbeitsspeicher für alle im Cluster laufenden Pods fest, nicht den Arbeitsspeicher eines einzelnen Pods. Da die Quota auch die Abrechnung bestimmt, sollten diese Werte an den tatsächlichen Bedarf des Workloads angepasst und nicht von Beginn an maximiert werden.

4. Bestätigen und warten, bis der Cluster bereit ist. Die Bereitstellung kann einen Moment dauern.

Den Virtual Cluster ändern

1. Zum Tab Managed Services wechseln.
2. Auf Settings klicken und den Tab Configuration des Clusters öffnen.
3. Auf Edit Configuration klicken und die Ressourcen-Quota-Werte nach Bedarf anpassen.
   
4. Bestätigen und warten, bis die Änderungen wirksam werden. Der Cluster aktualisiert seine Ressourcen entsprechend.

Virtual-Cluster-Ressourcen-Quotas

Virtual Clusters setzen Ressourcengrenzen mithilfe von Kubernetes-ResourceQuota- und LimitRange-Objekten durch. Diese Einstellungen steuern den maximal verfügbaren Arbeitsspeicher, die CPU, den Speicherplatz und den ephemeralen Speicher innerhalb des Clusters.

• Pods müssen Ressourcen-Requests und Limits angeben, um eine faire Nutzung und Planung zu gewährleisten
• Werden diese nicht angegeben, wird der Standard-LimitRange durchgesetzt

hinweis

Die Ressourcen-Quota des Virtual Clusters begrenzt derzeit die kumulierten Ressourcenlimits über alle Pods hinweg, nicht die tatsächliche Ressourcennutzung. Wenn Pods nicht eingeplant werden können, sollten die Limits einzelner Pods verringert werden, um innerhalb der Quota zu bleiben.

Der aktuelle LimitRange lautet:

Typ	Ressource	Standard-Request	Standard-Limit
Container	memory	128Mi	2Gi
Container	cpu	100m	500m
Container	ephemeral-storage	500Mi	6Gi

Wie die Abrechnung funktioniert

Virtual Clusters werden auf Basis der konfigurierten Ressourcen-Quota abgerechnet (die vCPU-, Arbeitsspeicher-, Speicherplatz- und ephemeralen Speicherlimits, die beim Erstellen oder Ändern des Clusters festgelegt werden) — nicht auf Basis dessen, was die Workloads zu einem gegebenen Zeitpunkt tatsächlich verbrauchen.

Das bedeutet, dass eine Erhöhung eines Quota-Werts die Kosten steigert, selbst wenn Pods im Leerlauf sind oder diese Quota nur teilweise nutzen, und eine Verringerung eines Quota-Werts die Kosten senkt, solange die Workloads weiterhin innerhalb der Quota Platz finden.

Beispiel: Wird ein Virtual Cluster mit 40 vCPU und 80 GiB Arbeitsspeicher konfiguriert, werden 40 vCPU und 80 GiB Arbeitsspeicher abgerechnet, unabhängig davon, ob die Pods im Leerlauf sind oder diese Ressourcen vollständig auslasten. Um Kosten zu senken, sollte die Quota an den tatsächlichen Bedarf des Workloads angepasst werden, anstatt für ungenutzten Spielraum überzuprovisionieren.

Jeder Quota-Parameter (vCPU, Arbeitsspeicher, Speicherplatz, ephemeraler Speicher) wird als separate Einheit abgerechnet. Die genauen Parameterbereiche finden sich in der Referenz für den Virtual-Kubernetes-Cluster-Provider.

Ephemeralen Speicher richtig dimensionieren

Neue Virtual Clusters verwenden standardmäßig eine Quota von 30 GiB ephemeralem Speicher, was Pod-Scheduling-Fehler von Anfang an zuverlässig vermeidet, aber für die meisten Workloads mehr als nötig ist. Wenn die Pods nicht auf große temporäre Dateien, Caches oder Container-Image-Layer angewiesen sind, empfiehlt es sich, die Ephemeral-storage-Quota beim Erstellen oder Ändern des Clusters zu senken, um Kosten zu reduzieren.

Fehlerbehebung bei Quota-Fehlern

Problem	Ursache	Lösung
Pods können aufgrund von Quota-Fehlern nicht eingeplant werden	Die Ressourcen-Quota des Virtual Clusters ist zu klein, oder die kumulierten Pod-Requests und -Limits überschreiten die konfigurierte Quota	Die Virtual-Cluster-Konfiguration unter Managed Services → eigener Virtual Cluster → Settings → Configuration aktualisieren oder die Requests und Limits einzelner Pods verringern

Einen Virtual Cluster löschen

Wenn ein Cluster nicht mehr benötigt wird:

1. Zum Tab Managed Services wechseln.
2. Auf Actions klicken und Delete für den zu entfernenden Cluster auswählen. Diese Aktion kann nicht rückgängig gemacht werden.
3. Bestätigen und warten, bis der Cluster entfernt wurde.