Kubernetes vs. Shared Hosting: Wann lohnt sich der Umstieg?

Shared Hosting ist der Einstieg für die meisten Webprojekte, und das aus gutem Grund. Für 5–15 €/Monat bekommt man eine Laufzeitumgebung, eine Datenbank und ein Webinterface. Kein Terminal, kein DevOps, kein Stress.

Aber irgendwann kommt der Punkt, an dem ein Projekt aus Shared Hosting herauswächst. Die Frage ist: Wann genau ist dieser Punkt erreicht, und ist Kubernetes dann wirklich die richtige Antwort?

Wann ein Projekt aus Shared Hosting herauswächst

Shared Hosting funktioniert hervorragend für WordPress-Seiten, klassische PHP-Anwendungen, kleine Node- oder Python-Apps und statische Websites. Interessant wird ein Wechsel, wenn eines dieser Szenarien zutrifft:

1. Deine Laufzeitumgebung wird nicht angeboten

Modernes Shared Hosting ist längst nicht mehr PHP-only. Bei ITSH laufen im Webhosting PHP 8.2 bis 8.5 sowie rein statische Seiten. Eng wird es, sobald du eine andere Laufzeit brauchst: Node.js, Python, Go, Rust, Java oder eine Anwendung, die eigene Systempakete und Binaries mitbringt. Dann führt der Weg über ein Container-Image, und damit über Kubernetes oder zumindest einen VPS.

2. Du brauchst mehrere langlebige Prozesse

Ein modernes SaaS-Produkt besteht selten aus einer einzigen Anwendung. Typisch ist:

• API-Backend
• Frontend (SPA oder SSR)
• Background Worker
• Datenbank
• Redis/Cache

Auf Shared Hosting bildest du davon in der Regel die Web-Anwendung, Cronjobs und die Datenbank ab. Für einen dauerhaft laufenden Queue-Worker, einen eigenen Cache oder einen Message Broker ist dort kein Platz. Das braucht eigene Server und damit eigene Verwaltung.

3. Deployments sind nicht reproduzierbar

Wenn dein Deployment aus einem FTP-Upload oder ein paar Klicks im Webpanel besteht, fehlt dir Reproduzierbarkeit. Was passiert, wenn das Deployment fehlschlägt? Wie rollst du zurück? Wer hat wann was deployt? Viele Hoster bieten inzwischen Git-Deployments an, das löst den Upload, aber nicht den deklarativen Zustand: Es gibt keine Deployment-History, kein Rollback per Kommando und keine Umgebung, die sich aus einem Repository vollständig neu aufbauen lässt.

4. Skalierung stößt an die Tarifgrenze

Shared Hosting teilt sich die Ressourcen eines Servers mit anderen Kunden. Die Site skaliert innerhalb der Grenzen deines Tarifs, aber du entscheidest nicht, wie viele Instanzen eines bestimmten Dienstes laufen, und du kannst Last nicht gezielt auf einzelne Komponenten verteilen. Ein Horizontal Pod Autoscaler, der genau den einen überlasteten Service repliziert, ist im Shared Hosting nicht vorgesehen.

5. Vendor Lock-in durch proprietäre Tools

Viele Hoster bieten eigene Deployment-Tools, Datenbank-Panels und Konfigurationsoberflächen. Eine Migration zu einem anderen Anbieter bedeutet oft, Teile der Infrastruktur neu aufzubauen.

Was ändert sich mit Kubernetes?

Kubernetes löst diese Probleme, allerdings auf Kosten von Komplexität. Hier ein ehrlicher Vergleich:

Kriterium	Shared Hosting	Kubernetes
Unterstützte Sprachen	PHP, Node.js, Python (je nach Hoster)	Alles, was in einem Container läuft
Mehrere Services	Begrenzt (Web-App + Cronjobs)	Ja, beliebig viele
Deployments	FTP / Git / Webpanel	kubectl apply / GitOps
Rollbacks	Manuell	Automatisch (Deployment-History)
Skalierung	Vertikal, im Rahmen des Tarifs	Horizontal Pod Autoscaler
Reproduzierbarkeit	Gering	Vollständig (Infrastructure as Code)
Einstiegshürde	Sehr niedrig	Hoch (ohne Managed Service)
Preis	5–15 €/Monat	Ab 3 €/Monat (ITSH PAYG)

Der entscheidende Punkt: Kubernetes ist nicht automatisch teurer als Shared Hosting. Die Kosten hängen davon ab, wie man es betreibt.

Der Zwischenschritt, den viele überspringen

Zwischen Shared Hosting und Kubernetes gibt es einen logischen Zwischenschritt: einen VPS mit Docker. Für viele Szenarien reicht das, und es ist ein guter Weg, Container-Grundlagen zu lernen.

# Auf einem VPS: Docker Compose für ein einfaches Setup
docker compose up -d

Das Problem: Ab dem Moment, wo man Hochverfügbarkeit, automatische Restarts, Rolling Updates oder Skalierung braucht, baut man sich stückweise Kubernetes nach, nur schlechter.

Wann Kubernetes Sinn macht

Kubernetes lohnt sich, wenn mindestens zwei dieser Punkte zutreffen:

1. Du betreibst mehr als einen langlebigen Service (API + Worker + Frontend)
2. Ausfallzeiten bei Deployments sind nicht akzeptabel (Rolling Updates nötig)
3. Du willst Infrastructure as Code (reproduzierbare Umgebungen)
4. Deine Anwendung muss horizontal skalieren (mehr Replicas bei Last)
5. Du hast mehrere Umgebungen (Staging + Production)

Wenn nur Punkt 1 zutrifft, reicht vermutlich Docker Compose auf einem VPS. Ab zwei Punkten wird Kubernetes interessant.

Wenn du noch unsicher bist, ob Kubernetes die richtige Antwort für dich ist, ist der billigste Weg, das herauszufinden, es einfach auszuprobieren: ITSH bietet einen dauerhaft kostenlosen Namespace, ohne Kreditkarte, ohne Verpflichtung. Deploy deine echte App eine Woche lang darauf, bevor du irgendetwas entscheidest.

Der Umstieg in der Praxis

Schritt 1: Anwendung containerisieren

Jede Komponente bekommt ein Dockerfile. Ein typisches Node.js-Beispiel:

FROM node:24-alpine AS build
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile
COPY . .
RUN yarn build

FROM node:24-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/server.js"]

Schritt 2: Kubernetes-Manifeste schreiben

Ein einfaches Deployment mit Service:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:latest
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 3000

Schritt 3: GitOps einrichten

Bei ITSH ist ArgoCD bereits vorkonfiguriert. Du verknüpfst ein Git-Repository mit deinem Namespace, und jeder Push auf den Main-Branch wird automatisch ausgerollt.

# Deployment-Status prüfen
kubectl get pods -n mein-namespace
kubectl rollout status deployment/api -n mein-namespace

Schritt 4: DNS und TLS

ITSH kümmert sich automatisch um TLS-Zertifikate. Du musst lediglich eine HTTPRoute anlegen und deinen DNS-Eintrag konfigurieren.

Was du nicht brauchst

Der häufigste Fehler beim Kubernetes-Einstieg: zu viel auf einmal. Folgendes brauchst du am Anfang nicht:

• Helm Charts: Einfache YAML-Manifeste reichen für den Start.
• Service Mesh (Istio/Linkerd): Erst relevant bei dutzenden Services.
• Custom Operators: Standardressourcen decken 95 % der Anwendungsfälle ab.
• Multi-Cluster-Setup: Ein Namespace reicht für die meisten KMU-Workloads.

Mit einem Managed Namespace bei ITSH entfällt zusätzlich die gesamte Cluster-Administration: kein etcd, keine Nodes, keine Ingress-Controller-Konfiguration.

Kostenvergleich: Shared Hosting vs. ITSH Namespace

Für eine typische Webanwendung (API + Frontend + Datenbank):

	Shared Hosting	ITSH Namespace S (15,00 € brutto/Monat)
Preis	10 €/Monat	15,00 €/Monat
Sprachen	PHP, Node.js, Python	Alles, was in einem Container läuft
Services	Web-App + Cronjobs	Beliebig viele
Deployments	FTP / Git	GitOps (ArgoCD)
TLS	Ja	Ja (automatisch)
Skalierung	Vertikal, im Rahmen des Tarifs	Horizontal (HPA)
Backups	Täglich (DB)	Täglich (Wiederherstellung über den Support)
Standort	Variiert	Deutschland
DSGVO	Anbieterabhängig	Inklusive

Für 5 € mehr im Monat bekommt man eine fundamental andere Infrastruktur: reproduzierbar, horizontal skalierbar und unabhängig davon, welche Laufzeitumgebungen ein Hoster gerade anbietet. Storage ist im Fixtarif nicht enthalten, PVCs werden separat abgerechnet.

Fazit

Shared Hosting ist nicht schlecht, es ist für einen bestimmten Anwendungsfall gemacht und erfüllt den sehr gut. Wenn dein Projekt über diesen hinauswächst, ist Kubernetes der logische nächste Schritt. Und dank Managed Namespaces muss dieser Schritt weder teuer noch kompliziert sein.

Du brauchst kein DevOps-Team und kein Cloud-Zertifikat. Du brauchst ein Dockerfile und ein paar YAML-Manifeste.

Managed Kubernetes Namespace ab 3 €/Monat testen →