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

KomponenteBeschreibungGemanagt durch
Control PlaneAPI-Server, Scheduler, Controller-Manager, etcdvon uns (vollständig gemanagt)
Worker NodesKVM-separierte VMs mit kubelet und Container Runtimevon uns (vollständig gemanagt)
CNICilium – eBPF-basiertes Networkingvorinstalliert
CSIhochperformante NVMEoF-basierte Persistent Volumesvorinstalliert
BackupsVelero-basierte Cluster-Backupsoptionales Addon
MetricsGrafana Dashboards mit Cluster-Metrikenoptionales Addon
ApplikationenIhre Workloads und Deploymentsdurch 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.

ParameterBeschreibung
NameName
ProduktDefiniert vCPU und RAM der Worker Nodes
AutoscaleJa: 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?

RessourceBeschreibung
Deploymenttraefik/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.