Übersicht & Architektur #
Willkommen in der Dokumentation für unser Managed-Kubernetes-Produkt. Auf dieser Seite erfahren Sie alles Wichtige über Architektur, Cluster-Verwaltung, Zugang und die ersten Schritte.
Beschreibung des Produktes
Das Produkt bietet Managed Kubernetes-as-a-Service: Sie erhalten einen vollständigen Kubernetes-Cluster, ohne sich um den Betrieb der Control Plane kümmern zu müssen. Die Infrastruktur wird vollständig von uns gemanagt – Sie konzentrieren sich auf Ihre Anwendungen.
k0s – CNCF-zertifizierte Kubernetes-Distribution
Das Produkt basiert auf k0s, einer leichtgewichtigen, CNCF-zertifizierten Kubernetes-Distribution. k0s ist vollständig konform zur Kubernetes-API. Das bedeutet: Alles, was Sie aus Standard-Kubernetes kennen, funktioniert auch hier.
Ihr eigener Cluster – isolierte Worker Nodes
Jeder Kunde erhält einen eigenen Cluster mit eigenen KVM-separierten Worker Nodes. Es gibt kein Shared-Tenancy auf Worker-Ebene – Ihre Workloads laufen vollständig isoliert.
Architekturüberblick
| Komponente | Beschreibung | Gemanagt durch |
|---|---|---|
| Control Plane | API-Server, Scheduler, Controller-Manager, etcd | von uns (vollständig gemanagt) |
| Worker Nodes | KVM-separierte VMs mit kubelet und Container Runtime | von uns (vollständig gemanagt) |
| CNI | Cilium – eBPF-basiertes Networking | vorinstalliert |
| CSI | hochperformante NVMEoF-basierte Persistent Volumes | vorinstalliert |
| Backups | Velero-basierte Cluster-Backups | optionales Addon |
| Metrics | Grafana Dashboards mit Cluster-Metriken | optionales Addon |
| Applikationen | Ihre Workloads und Deployments | durch Kunden verwaltet |
Die Control Plane wird hochverfügbar betrieben und ist vollständig durch uns gemanagt. Sie haben keinen direkten Zugriff auf Control-Plane-Nodes – alle Interaktionen erfolgen über den Kubernetes API-Server.
Cilium als CNI
Als Container Network Interface kommt Cilium zum Einsatz. Cilium nutzt eBPF im Linux-Kernel und bietet hochperformantes Networking ohne kube-proxy (eBPF statt iptables).
Weitere Details zu Cilium finden Sie im Abschnitt Besonderheiten – Cilium.
Cluster Lifecycle #
Cluster erstellen
Ein neuer Cluster wird über das Control Center erstellt:
- Ins Control Center einloggen
- Neuen Cluster anlegen – Name und Kubernetes-Version wählen
- Erste Worker Group konfigurieren (siehe unten)
- Optionale Addons hinzufügen
- Cluster erstellen bestätigen
Nach kurzer Wartezeit ist der Cluster bereit und Sie können die Kubeconfig herunterladen.
Cluster löschen
Im Control Center kann der Cluster über die Cluster-Detailseite gelöscht werden. Achtung: Alle darauf laufenden Workloads und gespeicherten Daten werden unwiderruflich gelöscht.
Worker Gruppen
Worker Gruppen definieren die Eigenschaften Ihrer Worker Nodes. Pro Cluster können Sie mehrere Worker Gruppen mit unterschiedlichen Konfigurationen anlegen.
| Parameter | Beschreibung |
|---|---|
| Name | Name |
| Produkt | Definiert vCPU und RAM der Worker Nodes |
| Autoscale | Ja: Min/Max-Anzahl Worker Nodes – der Cluster-Autoscaler skaliert automatisch zwischen diesen Werten. Nein: Fixe Anzahl an Worker Nodes. |
Das Autoscaling zwischen min und max erfolgt automatisch durch den Cluster-Autoscaler. Details dazu im Abschnitt Besonderheiten – Cluster-Autoscaler.
Addons bestellen
Zusätzlich zu den Worker Gruppen können Addons über das Control Center gebucht werden:
- Backups (Velero) – Optionales kostenpflichtiges Addon
- Metrics (Grafana Dashboards) – Optionales kostenpflichtiges Addon
Zugang & Authentifizierung #
Kubeconfig beziehen
Nach der Cluster-Erstellung können Sie die Kubeconfig über das Control Center herunterladen:
- Control Center öffnen
- Zum gewünschten Cluster navigieren
- Kubeconfig herunterladen
Die heruntergeladene Kubeconfig enthält ein Token mit wählbarer Gültigkeitsdauer: 1 Stunde, 1 Tag, 1 Woche oder 2 Wochen.
Kubeconfig einrichten
Speichern Sie die Kubeconfig-Datei und setzen Sie die Umgebungsvariable:
export KUBECONFIG=/home/User/Downloads/cluster-XXX.yamlOder kopieren Sie die Datei in das Standard-Verzeichnis:
mkdir -p ~/.kube
cp /home/User/Downloads/cluster-XXX.yaml ~/.kube/configTesten Sie die Verbindung:
kubectl get nodesErwartete Ausgabe:
NAME STATUS ROLES AGE VERSION
k8s100001-wg1-abcd-efgh Ready <none> 5m v1.33.9+k0s
k8s100001-wg1-ijkl-mnop Ready <none> 5m v1.33.9+k0sErste Schritte (Quickstart) #
In diesem Quickstart deployen wir eine einfache Web-Applikation und machen sie über einen LoadBalancer extern erreichbar.
Voraussetzungen
- Kubeconfig ist eingerichtet (siehe Zugang & Authentifizierung)
- kubectl ist installiert
Schritt 1: Namespace erstellen
kubectl create namespace demo
Schritt 2: Deployment anlegen
kubectl create deployment whoami --image=traefik/whoami --replicas=2 --port=80 --namespace=demoHinweis: Zugunsten der Einfachheit wurden Best-Practices wie Resource Limits und Pod-Anti-Affinity in diesem Beispiel weggelassen.
Schritt 3: Service vom Typ LoadBalancer anlegen
kubectl expose deployment whoami --type=LoadBalancer --port=80 --target-port=80 --namespace=demo
Schritt 4: Status prüfen
# Pods prüfen
kubectl get pods -n demo
# Service und externe IP prüfen
kubectl get svc -n demoSobald der Service eine externe IP erhalten hat, können Sie die Anwendung aufrufen:
curl http://<EXTERNAL-IP>Erwartete Ausgabe (Beispiel):
Hostname: whoami-7b6f8c9d5-x2k4p
IP: 127.0.0.1
IP: ::1
IP: 10.244.1.15
RemoteAddr: 10.244.2.8:43721
GET / HTTP/1.1
Host: 203.0.113.42
Was wurde provisioniert?
| Ressource | Beschreibung |
|---|---|
| Deployment | traefik/whoami mit 2 Replicas |
| Service (LoadBalancer) | Weist dem Service eine externe IP zu, über die die Applikation von außen erreichbar ist |
Schritt 5: Aufräumen
kubectl delete namespace demoHiermit werden alle Ressourcen im Namespace demo gelöscht.