Managed Kubernetes – Übersicht und Architektur

Ü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.yaml

Oder kopieren Sie die Datei in das Standard-Verzeichnis:

mkdir -p ~/.kube
cp /home/User/Downloads/cluster-XXX.yaml ~/.kube/config

Testen Sie die Verbindung:

kubectl get nodes

Erwartete 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+k0s

Erste Schritte (Quickstart) #

In diesem Quickstart deployen wir eine einfache Web-Applikation und machen sie über einen LoadBalancer extern erreichbar.

 

Voraussetzungen

 

Schritt 1: Namespace erstellen

kubectl create namespace demo

 

Schritt 2: Deployment anlegen

kubectl create deployment whoami --image=traefik/whoami --replicas=2 --port=80 --namespace=demo

Hinweis: 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 demo

Sobald 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 demo

Hiermit werden alle Ressourcen im Namespace demo gelöscht.