Cluster API: Kubernetes-Cluster deklarativ verwalten

TL;DR

Cluster API (CAPI) verwaltet Kubernetes-Cluster wie normale Kubernetes-Ressourcen. Ein Management-Cluster steuert dabei beliebig viele Workload-Cluster über Custom Resources. Cluster-Erstellung, Upgrades und Skalierung funktionieren deklarativ per kubectl apply - unabhängig vom Cloud-Provider.

Was ist Cluster API?

Cluster API dreht die gewohnte Perspektive um: Statt Kubernetes-Cluster über Cloud-Konsolen oder CLI-Tools zu erstellen, nutzen Sie einen bestehenden Kubernetes-Cluster, um weitere Cluster zu verwalten. Das Prinzip: Kubernetes verwaltet Kubernetes.

┌─────────────────────────────┐
│    Management Cluster       │
│                             │
│  ┌───────────┐ ┌──────────┐│
│  │ CAPI      │ │ Infra    ││
│  │ Controller│ │ Provider ││
│  └─────┬─────┘ └────┬─────┘│
└────────┼─────────────┼──────┘
         │             │
    ┌────▼──┐    ┌─────▼───┐
    │Cluster│    │ Cluster  │
    │  Dev  │    │   Prod   │
    └───────┘    └──────────┘

Der Management-Cluster enthält die CAPI-Controller und Infrastructure Provider. Diese Controller beobachten Custom Resources und erstellen daraus echte Cluster bei AWS, Azure, vSphere oder anderen Anbietern.

CAPI installieren

Voraussetzungen

Sie brauchen einen bestehenden Kubernetes-Cluster als Management-Cluster. Ein lokaler Kind-Cluster reicht für den Einstieg:

# Kind-Cluster als Management-Cluster erstellen
kind create cluster --name capi-management

# clusterctl installieren (CAPI CLI)
curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.9.0/clusterctl-linux-amd64 \
  -o /usr/local/bin/clusterctl
chmod +x /usr/local/bin/clusterctl

# CAPI mit AWS-Provider initialisieren
export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)

clusterctl init --infrastructure aws

Nach der Initialisierung laufen die CAPI-Controller im Management-Cluster. Prüfen Sie den Status:

kubectl get pods -n capi-system
kubectl get pods -n capa-system

Workload-Cluster erstellen

Ein Cluster wird als Custom Resource definiert. CAPI nutzt mehrere zusammenhängende Ressourcen:

Cluster-Definition

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: production
  namespace: default
spec:
  clusterNetwork:
    pods:
      cidrBlocks: ["192.168.0.0/16"]
    services:
      cidrBlocks: ["10.96.0.0/12"]
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta2
    kind: KubeadmControlPlane
    name: production-control-plane
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
    kind: AWSCluster
    name: production
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSCluster
metadata:
  name: production
  namespace: default
spec:
  region: eu-central-1
  sshKeyName: my-ssh-key
---
apiVersion: controlplane.cluster.x-k8s.io/v1beta2
kind: KubeadmControlPlane
metadata:
  name: production-control-plane
  namespace: default
spec:
  replicas: 3
  version: v1.31.0
  machineTemplate:
    infrastructureRef:
      apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
      kind: AWSMachineTemplate
      name: production-control-plane

Anwenden und beobachten:

kubectl apply -f cluster-production.yaml

# Status verfolgen
kubectl get cluster production -o yaml
clusterctl describe cluster production

Worker Nodes mit MachineDeployment

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: production-workers
  namespace: default
spec:
  clusterName: production
  replicas: 3
  selector:
    matchLabels: {}
  template:
    spec:
      clusterName: production
      version: v1.31.0
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: production-workers
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
        kind: AWSMachineTemplate
        name: production-workers

Das MachineDeployment funktioniert wie ein Kubernetes Deployment: Sie ändern die gewünschte Replica-Anzahl, und CAPI kümmert sich um das Rolling Update der Nodes.

Cluster-Upgrades mit CAPI

Kubernetes-Version-Upgrades werden zur einzeiligen Änderung. Aktualisieren Sie einfach das version-Feld:

# Control Plane upgraden
kubectl patch kubeadmcontrolplane production-control-plane \
  --type merge \
  -p '{"spec": {"version": "v1.32.0"}}'

# Worker Nodes upgraden
kubectl patch machinedeployment production-workers \
  --type merge \
  -p '{"spec": {"template": {"spec": {"version": "v1.32.0"}}}}'

# Upgrade-Fortschritt beobachten
kubectl get machines -w

CAPI führt ein Rolling Update durch: Neue Nodes mit der neuen Version werden erstellt, Workloads migriert, alte Nodes entfernt. Das Control Plane wird Node für Node aktualisiert, um die Verfügbarkeit zu gewährleisten.

Infrastructure Provider im Vergleich

CAPI unterstützt zahlreiche Provider. Die Wahl hängt von Ihrer Zielumgebung ab:

Wechseln Sie den Provider, ändern sich nur die Infrastructure-spezifischen Ressourcen. Die Cluster- und MachineDeployment-Definitionen bleiben identisch.

Wann CAPI statt Terraform?

CAPI eignet sich besonders, wenn Sie viele gleichartige Cluster verwalten - etwa in Multi-Tenant-Szenarien oder bei Platform Teams, die Self-Service-Cluster für Entwickler bereitstellen. Der Vorteil gegenüber Terraform: Cluster-Operationen wie Upgrades und Skalierung laufen als Controller-Loops kontinuierlich, nicht nur bei explizitem apply.

Terraform bleibt die bessere Wahl für heterogene Infrastruktur, bei der Kubernetes nur ein Baustein neben Datenbanken, DNS und Netzwerk ist.

FAQ

Brauche ich einen dedizierten Management-Cluster?

Für Produktion ja. Der Management-Cluster sollte stabil und separat von Workload-Clustern laufen. Für Tests reicht ein lokaler Kind-Cluster.

Kann ich bestehende Cluster in CAPI importieren?

Ja, mit clusterctl move können Sie Cluster-Ressourcen zwischen Management-Clustern verschieben. Der Import bestehender, nicht von CAPI erstellter Cluster ist jedoch begrenzt möglich und erfordert manuelle Ressourcen-Erstellung.

Wie sicher ist der Management-Cluster?

Der Management-Cluster hat Cloud-Credentials und kann Infrastruktur erstellen und löschen. Schützen Sie ihn mit RBAC, Network Policies und beschränktem Zugriff. Nur Platform-Admins sollten Zugang haben.

Unterstützt CAPI GitOps-Workflows?

Ja. Die CAPI-Ressourcen sind normale Kubernetes-Manifeste und lassen sich mit ArgoCD oder Flux aus einem Git-Repository synchronisieren. Cluster-Änderungen durchlaufen dann den üblichen PR-Review-Prozess.

Wie lange dauert die Erstellung eines Clusters?

Je nach Provider 10-20 Minuten. AWS-EKS-Cluster brauchen typischerweise 12-15 Minuten, vSphere-basierte Cluster können schneller sein, da keine Cloud-API-Limits greifen.