Zurück zum Blog

Container Deployment ohne DevOps-Team

·7 Min. Lesezeit·von Giovanni Harting
Container Hosting EuropaDevOpsKubernetes Hosting günstigManaged Kubernetes DeutschlandGitOps

Container Deployment ohne DevOps-Team

Kubernetes hat ein Reputationsproblem. Wer den Begriff hört, denkt an YAML-Dateien in dreistelliger Zahl, an mehrtägige Cluster-Setups und an Stellenausschreibungen, die drei Jahre Kubernetes-Erfahrung voraussetzen.

Diese Wahrnehmung ist nicht falsch, wenn man einen Cluster von Grund auf selbst betreibt. Aber sie ist irreführend, wenn es nur darum geht, Container zuverlässig in Produktion zu bringen.

Dieser Artikel zeigt, wie ein Managed Kubernetes Namespace den Ops-Aufwand auf nahezu null reduziert, und warum das gerade für Teams ohne dediziertes DevOps-Personal relevant ist.

Was ein DevOps-Team tatsächlich tut

Um zu verstehen, was man einsparen kann, muss man wissen, wofür ein DevOps-Team im Kubernetes-Kontext zuständig ist:

Cluster-Administration (entfällt komplett bei Managed Namespace):

  • Kubernetes-Version aktualisieren
  • etcd-Cluster warten und sichern
  • Node-Pool verwalten (Scaling, OS-Updates, Kernel-Patches)
  • Netzwerk-Policies und CNI-Plugin konfigurieren
  • Ingress-Controller / Gateway-API betreiben
  • Zertifikatsverwaltung (cert-manager)
  • Monitoring-Stack (Prometheus, Grafana, Alertmanager)
  • Log-Aggregation (Loki, ELK, Fluentd)
  • Backup-Strategie implementieren

Anwendungs-Deployment (bleibt bei dir, aber vereinfacht):

  • Dockerfiles schreiben
  • Kubernetes-Manifeste pflegen
  • CI/CD-Pipelines konfigurieren
  • Secrets verwalten

Bei einem Managed Namespace entfällt die gesamte erste Liste. ITSH betreibt den Cluster, die Nodes, das Monitoring, die Backups und die Zertifikate. Was bleibt, ist das, was ohnehin zum Entwicklungsprozess gehört: die eigene Anwendung paketieren und deployen.

Eine Abgrenzung dazu: Der Monitoring-Stack gehört zur Plattform, nicht zu deinem Namespace. ITSH überwacht Cluster und Nodes rund um die Uhr, aber du bekommst weder Grafana-Zugang noch einen eigenen Ingest-Endpunkt, und ServiceMonitors oder PrometheusRules kannst du nicht anlegen. Für deine eigenen Workloads siehst du Pods, Logs, Events und Verbrauch im Kundenportal.

Vom Code zum Deployment in 30 Minuten

Angenommen, du hast eine Go-API, die du als Container deployen willst. Der gesamte Weg vom Code zur laufenden Anwendung auf einem ITSH-Namespace. Und ja, du kannst das Ganze auf dem Free Tier ohne Kreditkarte mitmachen, falls du den Workflow nur einmal ausprobieren willst, ohne dich zu verpflichten.

1. Dockerfile erstellen (5 Minuten)

FROM golang:1.27-alpine AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -buildmode=pie -ldflags="-s -w" -trimpath -o /app ./cmd/server

FROM alpine:3.24
COPY --from=build /app /app
EXPOSE 8080
ENTRYPOINT ["/app"]

2. Container-Image bauen und pushen (5 Minuten)

# Image bauen und in eine Container Registry pushen (z.B. GitHub Container Registry)
docker build -t ghcr.io/mein-org/api:1.0.0 .
docker push ghcr.io/mein-org/api:1.0.0

3. Kubernetes-Manifest schreiben (10 Minuten)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: ghcr.io/mein-org/api:1.0.0
          ports:
            - containerPort: 8080
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: app-secrets
                  key: database-url
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
          readinessProbe:
            httpGet:
              path: /readyz
              port: 8080
            initialDelaySeconds: 3
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  parentRefs:
    - name: default
      namespace: nginx-gateway
      sectionName: https-api-mein-projekt-de
  hostnames:
    - "api.mein-projekt.de"
  rules:
    - backendRefs:
        - name: api
          port: 80

Die Annotation cert-manager.io/cluster-issuer an der HTTPRoute ist ein Opt-in für automatisches TLS. Der Controller, der die Gateway-Listener anlegt, prüft nur, ob sie gesetzt ist, ihr Wert wählt keinen Issuer aus. Welcher ClusterIssuer die Zertifikate ausstellt, bestimmt die Annotation am Gateway.

4. Deployen (2 Minuten)

kubectl apply -f k8s/ -n mein-namespace

Oder, wenn ArgoCD eingerichtet ist: einfach den Code nach Git pushen. ArgoCD erkennt die Änderung und rollt automatisch aus.

5. Prüfen (2 Minuten)

# Pods laufen?
kubectl get pods -n mein-namespace

# Logs anschauen
kubectl logs -n mein-namespace deployment/api

# Deployment-Status
kubectl rollout status deployment/api -n mein-namespace

Das war’s. Kein Terraform. Kein Ansible. Keine Node-Konfiguration. Keine Ingress-Klassen. Kein cert-manager-Setup.

GitOps: Deployments per Git-Push

Die manuelle Anwendung von kubectl apply funktioniert, ist aber nicht ideal für Teams. ArgoCD (bei ITSH bereits integriert) macht den Deployment-Prozess deklarativ und nachvollziehbar.

So funktioniert es:

  1. Kubernetes-Manifeste liegen in einem Git-Repository
  2. ArgoCD überwacht das Repository
  3. Bei jeder Änderung auf dem konfigurierten Branch synchronisiert ArgoCD den Cluster-Zustand

Vorteile für Teams ohne DevOps:

  • Audit-Trail: Jedes Deployment ist ein Git-Commit mit Autor, Zeitstempel und Diff.
  • Rollback per Git: git revert stellt den vorherigen Zustand wieder her.
  • Kein Cluster-Zugang nötig: Entwickler pushen Manifeste, ArgoCD übernimmt den Rest.
  • Drift Detection: ArgoCD erkennt, wenn der Cluster-Zustand vom Git-Stand abweicht.
# Neues Image-Tag in der Manifest-Datei aktualisieren
# (oder per CI/CD-Pipeline automatisieren)
sed -i 's|api:1.0.0|api:1.1.0|' k8s/deployment.yaml
git add k8s/deployment.yaml
git commit -m "chore: update api to 1.1.0"
git push
# ArgoCD rollt automatisch aus

Typische Bedenken und warum sie bei Managed Namespaces nicht greifen

“Kubernetes ist zu komplex für unser Team”

Ein vollständiger Cluster: ja. Ein Namespace: nein. Du brauchst drei Konzepte zu verstehen: Deployment, Service, HTTPRoute. Das lässt sich an einem Nachmittag erlernen.

“Wir haben niemanden, der Kubernetes-Probleme debuggen kann”

Die häufigsten Probleme bei Anwendungs-Deployments sind:

  • Image kann nicht gepullt werden → Registry-Credentials prüfen
  • Pod startet nicht → kubectl logs und kubectl describe pod
  • Anwendung ist nicht erreichbar → Service-Selector und Port prüfen

Das sind Anwendungsprobleme, keine Cluster-Probleme. Cluster-Probleme (Node-Ausfälle, Netzwerk-Partitionen, etcd-Korruption) behebt das ITSH-Team.

“Was ist mit Secrets und sensiblen Daten?”

Kubernetes Secrets sind im Namespace isoliert. Du erstellst sie einmal per kubectl:

kubectl create secret generic app-secrets \
  --from-literal=database-url='postgres://user:pass@db:5432/mydb' \
  -n mein-namespace

Für einen zusätzlichen Layer können Secrets über ein Git-Repository mit Sealed Secrets oder SOPS verschlüsselt verwaltet werden.

“Brauchen wir eine Container Registry?”

Jede öffentliche oder private Registry funktioniert: GitHub Container Registry (ghcr.io), Docker Hub oder eine selbst gehostete Lösung. Für private Images einfach ein Image-Pull-Secret im Namespace hinterlegen.

Was Entwickler statt Ops-Aufgaben tun können

Die Zeit, die ein Team nicht für Cluster-Wartung aufwendet, fließt in Produktentwicklung. Eine konservative Schätzung:

Aufgabe Zeitaufwand/Monat (Self-Hosted) Zeitaufwand/Monat (Managed)
Kubernetes-Updates 4–8 h 0 h
Node-Wartung 2–4 h 0 h
Monitoring-Setup 4–8 h (initial), 2 h (laufend) 0 h
Zertifikatsverwaltung 1–2 h 0 h
Backup-Verifizierung 2–4 h 0 h
Incident Response (Cluster) 2–8 h 0 h
Summe 15–34 h 0 h

Bei einem Stundensatz von 90 € sind das 1.350 bis 3.060 € pro Monat an eingesparter Arbeitszeit, zusätzlich zu den niedrigeren Infrastrukturkosten. 90 € ist dabei das untere Ende der aktuellen deutschen Freelancer-Sätze, Agenturen liegen eher bei 120 bis 150 € pro Stunde.

Ein realistisches Setup für ein Drei-Personen-Team

Szenario: Eine Agentur betreibt eine Kunden-Plattform mit API, Frontend und Hintergrund-Jobs.

Infrastruktur auf ITSH:

  • 1 Namespace mit PAYG-Abrechnung
  • 3 Deployments (API, Frontend, Worker)
  • 1 PostgreSQL-Datenbank (als StatefulSet oder externer Service)
  • ArgoCD für automatische Deployments
  • Tägliche Backups der Namespace-Ressourcen (Wiederherstellung über den Support, kein Self-Service). Eigene Datensicherungen ersetzt das nicht.

Workflow:

  1. Entwickler schreibt Code und pusht zu GitHub
  2. GitHub Actions baut das Container-Image
  3. Image wird in die Registry gepusht
  4. Manifest-Datei wird mit neuem Tag aktualisiert (manuell oder automatisch)
  5. ArgoCD deployed die Änderung
  6. Pods, Logs und Events im Kundenportal zeigen, ob der Rollout durchgelaufen ist

Kein einziger Schritt in diesem Workflow erfordert Cluster-Administrationswissen.

Monatliche Kosten:

  • ITSH Namespace: ~30–50 €/Monat (je nach Ressourcenverbrauch)
  • GitHub Actions: Free Tier reicht für die meisten KMU
  • Gesamtkosten: unter 50 €/Monat für eine produktionsreife Kubernetes-Umgebung

Fazit

Container-Deployments auf Kubernetes erfordern kein DevOps-Team, sondern eine Plattform, die den Cluster-Betrieb übernimmt. Die eigentliche Arbeit liegt im Anwendungs-Deployment: Dockerfiles schreiben, Manifeste pflegen, CI/CD einrichten. Das sind Aufgaben, die jede Entwicklerin und jeder Entwickler beherrschen kann.

Ein Managed Namespace bei ITSH reduziert den Einstieg auf drei Schritte:

  1. Anwendung in einen Container packen
  2. Kubernetes-Manifest schreiben
  3. Deployen, per kubectl apply oder GitOps

Alles andere (Cluster-Updates, Monitoring, Backups, TLS, Skalierung) läuft im Hintergrund.

Jetzt starten: Managed Kubernetes Namespace ab 3 €/Monat →