Kubernetes Container DevOps Docker Self-hosted

Kubernetes auf eigener Infrastruktur: Einstieg für Entwickler

Veröffentlicht am 4. Juni 2026

Managed Kubernetes (GKE, EKS, AKS) vereinfacht den Einstieg — aber mit hohen monatlichen Kosten und Vendor Lock-in. Self-hosted Kubernetes gibt dir Kontrolle über Kosten, Latenz und Daten. Dieser Guide zeigt, wie du einen K8s-Cluster aufsetzt, Deployments orchestrierst und Production-Ready bleibst.

📅 4. Juni 2026 ⏱ ~14 Min. Lesezeit 👤 Wunschdomain Redaktion

Warum Kubernetes? Die Alternative zu Managed Cloud

Kubernetes automatisiert Container-Management auf Cluster-Ebene: Scheduling, Service Discovery, Load Balancing, Rolling Updates, Auto-Scaling und Self-Healing. Der Reiz von Managed Kubernetes liegt in der Bequemlichkeit. Aber diehide Kosten summieren sich:

Aspekt	Managed K8s (GKE/EKS)	Self-hosted (k3s/kubeadm)
Monatliche Kosten	60–300 € pro Cluster	30–80 € (nur Hardware)
Control Plane	Google/AWS/Microsoft verwaltet	Du bist verantwortlich
Updates & Patches	Automatisch (teilweise)	Manuell oder via Farm
Vendor Lock-in	Hoch (Cloud-spezifische Features)	Keiner — portability
Latenz	Abhängig von Cloud-Region	Dein eigenes Rechenzentrum
Datenhoheit	Cloud-spezifisch	Vollständig auf eigener Hardware

Für kleine bis mittlere Workloads ist Self-hosted Kubernetes die wirtschaftlichere Wahl. Mit k3s (Lightweight Kubernetes von Rancher) kann ein einzelner Server als Control Plane + Worker fungieren — ideal für MVP und Prototypen.

K3s vs. kubeadm: k3s ist ein Single-Binary (< 100 MB), ARM-optimiert, SQLite als Default (Optional: etcd), und in unter 60 Sekunden installiert. kubeadm braucht deutlich mehr Konfiguration, ist dafür flexibler bei großen Clustern.

Schritt 1: Hardware und Netzwerk vorbereiten

Für einen Production-Cluster brauchst du mindestens 3 Nodes (etcd-Quorum braucht ungerade Zahlen). Empfohlene Specs:

Control Plane: 2 vCPUs, 4 GB RAM, 40 GB SSD (3 Nodes für HA)
Worker Nodes: 4 vCPUs, 8 GB RAM, 100 GB SSD (scale nach Bedarf)
Netzwerk: Alle Nodes im selben LAN-Segment; Ports 6443, 2379-2380, 10250-10252 offen intern
Load Balancer: Externer LB (z.B. Hetzner Cloud Load Balancer oder Metallb für intern) für API-Server-HA

Schritt 2: k3s auf dem Control Plane installieren

1 Control Plane initialisieren

curl -sfL https://get.k3s.io | sh -

Nach Installation: k3s --version prüfen. Die kubeconfig liegt in /etc/rancher/k3s/k3s.yaml.

2 Token für Worker-Join sichern

cat /var/lib/rancher/k3s/server/node-token

Diesen Token brauchst du für jeden neuen Worker-Node.

3 Worker Nodes hinzufügen

curl -sfL https://get.k3s.io | K3S_URL=https://:6443 K3S_TOKEN= sh -

Ersetze <CONTROL_PLANE_IP> und <TOKEN> mit deinen Werten.

4 Cluster-Status prüfen

kubectl get nodes
# Output: NAME     STATUS   ROLES           AGE
# web-node-1   Ready    control-plane   5m
# web-node-2   Ready    <none>          3m
# web-node-3   Ready    <none>          1m

Schritt 3: Dein erstes Deployment erstellen

Ein Deployment beschreibt, wie deine Anwendung in Pods läuft. Kubernetes kümmert sich um Restart, Skalierung und Rolling Updates.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: meine-webapp
  labels:
    app: meine-webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: meine-webapp
  template:
    metadata:
      labels:
        app: meine-webapp
    spec:
      containers:
      - name: webapp
        image: nginx:1.25-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 15
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10

kubectl apply -f deployment.yaml startet 3 Pods auf deinen Worker Nodes. kubectl get pods -o wide zeigt, wo jeder Pod läuft.

Schritt 4: Service und Ingress einrichten

Das Deployment allein ist intern. Ein Service macht die Pods erreichbar, ein Ingress verbindet sie mit der Außenwelt.

Service (ClusterIP)

apiVersion: v1
kind: Service
metadata:
  name: meine-webapp-svc
spec:
  selector:
    app: meine-webapp
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http

Ingress mit Cert-Manager (Let's Encrypt)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: meine-webapp-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - app.example.com
    secretName: meine-webapp-tls
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: meine-webapp-svc
            port:
              number: 80

Cert-Manager installieren: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.0/cert-manager.yaml. Der ClusterIssuer automatisiert SSL-Zertifikate — keine manuelle Erneuerung mehr.

Schritt 5: Auto-Scaling konfigurieren

Kubernetes Horizontal Pod Autoscaler (HPA) skaliert basierend auf CPU/Memory-Auslastung. Für nuanciertere Skalierung gibt es den KEDA-Operator (Event-driven Autoscaling).

# HPA: Skaliere zwischen 3 und 10 Pods bei >70% CPU-Auslastung
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: meine-webapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: meine-webapp
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Wichtige Kubernetes-Konzepte auf einen Blick

Konzept	Was es tut	Wann nutzen
Pod	Kleinste deploybare Einheit — ein oder mehrere Container	Immer (Pod ≠ Container)
Deployment	Stellt Pods bereit, managed Replicas, Rolling Updates	Stateful Apps mit Replicas
StatefulSet	Wie Deployment, aber mit stabiler Identität und persistentem Storage	Datenbanken, Kafka, etc.
DaemonSet	Ein Pod pro Node (z.B. Logs-Sammler, Monitoring Agent)	Node-Level-Agents
Service	Stabile IP/DNS für Pods (ClusterIP, NodePort, LoadBalancer)	Immer für interne/externe Erreichbarkeit
ConfigMap / Secret	Konfiguration und sensitive Daten als Dateien oder Env-Vars	Konfiguration, Credentials
PersistentVolume	Persistenter Storage, der über Pod-Neustarts hinaus existiert	Datenbanken, File-Uploads
NetworkPolicy	Firewall für Pod-Kommunikation	Zero-Trust-Networking

Namespaces für Umgebungslogik

Nutze Namespaces, um Produktion, Staging und Entwicklung logisch zu trennen. Das verhindert versehentliche Cross-Umgebungs-Deployments.

# Namespaces erstellen
kubectl create namespace production
kubectl create namespace staging
kubectl create namespace development

# In spezifischen Namespace deployen
kubectl apply -f deployment.yaml -n production

# Resource-Quotas pro Namespace
apiVersion: v1
kind: ResourceQuota
metadata:
  name: prod-quota
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    pods: "50"

Monitoring mit Prometheus + Grafana

Kubernetes bringt keine eingebaute Monitoring-Lösung. Ein Standard-Stack:

Prometheus: Metriken sammeln (CPU, Memory, Netzwerk, Pod-Health)
Grafana: Dashboards und Alerting
Alertmanager: Alerts via E-Mail, Slack, PagerDuty

Installiere alles mit kube-prometheus-stack via Helm:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install prometheus prometheus-community/kube-prometheus-stack \n  --namespace monitoring --create-namespace \n  --set prometheus.prometheusSpec.retentionTime=15d \n  --set grafana.persistence.enabled=true

Logs-Aggregation: Parallel zu Prometheus brauchst du einen zentralisierten Logging-Stack. Empfohlen: Grafana Loki (schlank) oder Elasticsearch + Kibana (mächtiger). Beide funktionieren auf Kubernetes.

Backup und Disaster Recovery

Auf Kubernetes-Ebene: etcd-Backups sind kritisch — sie enthalten den gesamten Cluster-State. Auf Anwendungsebene: Datenbank-Backups und Volume-Snapshots.

etcd-Backup: Automatisch per CronJob mit Velero oder einem simplen etcd-Snapshot-Script sichern
Velero: Backup/Restore von Kubernetes-Objekten und Volumes (inkl. PersistentVolumes)
Anwendung: Datenbank-Dumps vor jedem Deployment — mindestens täglich

Self-hosted vs. Managed: Die richtige Wahl

Kriterium	Go Self-hosted wenn...	Go Managed wenn...
Kosten	Budget < 100 €/Monat, mehr als 3 Cluster	Rapid Prototyping, kein Ops-Team
Latenz	Sub-5ms-Anforderung (Edge/Real-time)	Globale Failover nötig (Multi-Region)
Compliance	DSGVO/regulierte Branche, Daten müssen on-premise	Keine besonderen Auflagen
Skalierung	Skalierung vorhersagbar, stabile Last	Unvorhersehbare Burst-Traffic-Spitzen
Team	Du/Team hat Kubernetes-Erfahrung	Neueinsteiger, keine Zeit für Ops

Zusammenfassung: Dein K8s-Spickzettel

k3s ist der beste Einstieg für Self-hosted Kubernetes — ein Binary, 60-Sekunden-Installation
Mindestens 3 Nodes für etcd-Quorum (High Availability)
Nutze Helm für komplexe Deployments (Cert-Manager, Prometheus, Ingress-Controller)
Definiere Resource-Requests und Limits für jeden Container — kein Chaos beim Scheduling
Health Checks (Liveness + Readiness Probes) sind kein Optional — sie sind Voraussetzung für Auto-Scaling
Backup deinen etcd-State täglich — ohne ihn ist der Cluster nicht wiederherstellbar
Namespace-Struktur (prod/staging/dev) hilft bei Umgebungslogik und Resource Quotas

Weiterlesen: Observability-Stack mit Prometheus, Grafana und Loki — GitOps-Deployments mit ArgoCD und Flux — SSH-Zugang und sicherer Fernzugriff — VPS vs. Shared Hosting: Der vollständige Vergleich — Root-Server verwalten: Vom Anfänger zum Profi

Kubernetes auf eigener Infrastruktur: Einstieg für Entwickler

Warum Kubernetes? Die Alternative zu Managed Cloud

Schritt 1: Hardware und Netzwerk vorbereiten

Schritt 2: k3s auf dem Control Plane installieren

Schritt 3: Dein erstes Deployment erstellen

Schritt 4: Service und Ingress einrichten

Service (ClusterIP)

Ingress mit Cert-Manager (Let's Encrypt)

Schritt 5: Auto-Scaling konfigurieren

Wichtige Kubernetes-Konzepte auf einen Blick

Namespaces für Umgebungslogik

Monitoring mit Prometheus + Grafana

Backup und Disaster Recovery

Self-hosted vs. Managed: Die richtige Wahl

Zusammenfassung: Dein K8s-Spickzettel

Das könnte Sie auch interessieren

GitOps: Automatisierte Deployments mit ArgoCD und Flux

.htaccess & Nginx-Konfiguration: Perfekte Webserver-Einstellungen

API Gateway Hosting: Microservices richtig aufsetzen