Training Module

GitLab auf Kubernetes betreiben — Helm-Deployment, Backup/Restore & Runner-Skalierung

In diesem 210-Minuten-Aufbaumodul betreibt ihr eine echte GitLab-Instanz über den offiziellen gitlab/gitlab-Helm-Chart auf Kubernetes statt über Docker Compose. Ihr startet mit der zentralen Tatsache, die den ganzen Kurs prägt: Seit Chart-Version 10.0.0 sind PostgreSQL und Redis nicht mehr optional bundlebar, seit GitLab 19.0 gilt dasselbe für Object Storage (die bundled MinIO wurde entfernt) – für jedes Deployment ist heute alles drei zwingend extern anzubinden, die Entscheidung “Bundled vs. extern” gibt es nicht mehr, nur noch “welches externe Postgres/Redis/Object Storage”. Ihr bringt dafür schlanke Trainings-Instanzen im Cluster mit und verdrahtet sie über global.psql.host, global.redis.host und die Object-Storage-Connection-Secrets. Danach deployt ihr GitLab mit reduzierten Replica-Werten, ordnet Gitalys persistente Repository-Storage als StatefulSet-PVC ein (Namenskonvention, StorageClass-Wahl, Reclaim Policy), übt ein vollständiges Backup/Restore über den Toolbox-Pod inklusive separat gesicherter Rails-Secrets, installiert GitLab Runner als eigenständige Kubernetes-Executor-Workloads – jeder CI-Job bekommt seinen eigenen, kurzlebigen Pod statt eines Docker-Containers auf dem Host – und ordnet zum Abschluss Zero-Downtime-Upgrade-Konfiguration (RollingUpdate, maxSurge/maxUnavailable) sowie Registry-Readiness-/Liveness-Checks als Konzept-Block ein. Die komplette Session läuft lokal über Minikube, ohne Cloud-Account und ohne Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

3 Stunden 30 Minuten, live (remote oder vor Ort), Input & vier Hands-on-Blöcke

Teilnehmende

DevOps-/Platform-Engineers, die GitLab künftig als Kubernetes-Workload statt als VM/Docker-Host betreiben wollen

Voraussetzungen

Abgeschlossene Module Helm — Paketmanagement, Kubernetes Storage und Kubernetes Administration. Minikube mit mindestens 4 CPU/10 GB RAM, kein Cloud-Account nötig.

Warum dieses Training für deine Organisation wirkt

Kein Bundled-Irrtum mehr

Wer eine ältere GitLab-Chart-Anleitung googelt, stößt oft auf ein “Bundled PostgreSQL/Redis” von vor Chart-Version 10.0.0. Teilnehmende verdrahten die aktuelle, zwingend externe Anbindung selbst und wissen danach, warum ein helm install ohne global.psql.host heute mit einer klaren Fehlermeldung abbricht statt einfach durchzulaufen.

Backup/Restore vor dem Ernstfall geübt

Der Toolbox-Pod, die separat zu sichernden Rails-Secrets und der komplette Restore-Ablauf mit Skalierung auf 0 Replicas sind Dinge, die im Ernstfall unter Zeitdruck stattfinden – hier laufen sie einmal geübt und mit echtem Datenintegritäts-Nachweis ab.

Runner, der mitskaliert statt zu blockieren

Statt eines Docker-Executors auf einem festen Host bekommt jeder CI-Job seinen eigenen, kurzlebigen Kubernetes-Pod – Teilnehmende sehen live, wie mehrere Jobs parallel eigene Pods bekommen und wieder verschwinden, statt sich einen Runner zu teilen.

Was Teilnehmende mitnehmen

  • Einordnen, warum PostgreSQL und Redis seit Chart v10.0.0 und Object Storage seit GitLab 19.0 für jedes GitLab-Helm-Deployment zwingend extern sind, und den gitlab/gitlab-Chart über global.psql./global.redis./Object-Storage-Connection-Secrets an schlanke Trainings-Instanzen im Cluster anbinden.
  • GitLab mit reduzierten Replica-Werten (Minikube-tauglich) per helm upgrade –install deployen, den Rollout mit kubectl get pods verfolgen und das automatisch generierte Root-Passwort aus dem Kubernetes-Secret auslesen.
  • Gitalys Git-Repository-Persistenz als StatefulSet-PVC einordnen: Namenskonvention repo-data-<statefulset>-<index>, Default-Größe, StorageClass-Empfehlungen (SSD, reclaimPolicy: Retain) und dynamische vs. statische Provisionierung.
  • Ein vollständiges Backup über den Toolbox-Pod (backup-utility) fahren, die Rails-Secrets separat sichern und einen kompletten Restore-Ablauf inklusive Herunter-/Hochskalieren der Datenbank-Clients durchführen.
  • GitLab Runner über den eigenständigen gitlab-runner-Helm-Chart mit Kubernetes-Executor installieren, RBAC-Minimalrechte verstehen und live beobachten, wie jeder CI-Job einen eigenen, temporären Pod bekommt.
  • Die Konfiguration für Zero-Downtime-Upgrades (RollingUpdate, maxSurge/maxUnavailable, terminationGracePeriodSeconds) sowie Registry-Readiness-/Liveness-Checks als Cluster-seitiges Betriebskonzept einordnen.

Für wen dieses Modul ideal ist

  • • DevOps-/Platform-Engineers, die eine selbstgehostete GitLab-Instanz aus Docker Compose oder VM-Betrieb nach Kubernetes migrieren wollen
  • • Teams, die GitLab Runner statt als Docker-Executor auf einem festen Host als skalierende Kubernetes-Workloads betreiben wollen
  • • Alle, die vor dem ersten produktiven GitLab-auf-Kubernetes-Betrieb Backup/Restore und Storage-Entscheidungen einmal komplett durchgespielt haben wollen

Rahmendaten

  • • Dauer: 3 Stunden 30 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, vier vollständige Hands-on-Blöcke
  • • Voraussetzungen: abgeschlossene Module Helm — Paketmanagement, Kubernetes Storage und Kubernetes Administration; Minikube mit mindestens 4 CPU/10 GB RAM; keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. Vorbereitung & Architekturüberblick (15 min): Minikube mit mindestens 4 CPU/10 GB RAM starten, helm repo add gitlab https://charts.gitlab.io/, Kernaussage vorweg: seit Chart v10.0.0 sind externe PostgreSQL/Redis Pflicht, seit GitLab 19.0 gilt das auch für Object Storage – kein Bundled-Betrieb mehr für keins der drei.

  2. Hands-on 1: Fundament — Postgres/Redis/Object Storage im Cluster (30 min): schlanke, nicht-produktive PostgreSQL- und Redis-Pods samt Secrets als Ersatz für Managed-Services, MinIO als S3-kompatibles Object Storage samt Bucket für Backups, Registry und Artefakte.

  3. Hands-on 2: Helm-Chart-Deployment (40 min): offizielle values-minikube-minimum.yaml als Ausgangspunkt, Anpassung an die aktuelle Chart-Version (Gateway-API-Pfad deaktivieren), Verdrahtung mit global.psql./global.redis./Object-Storage-Connection-Secrets, helm upgrade –install, Rollout verfolgen, Root-Passwort auslesen.

  4. Persistenter Storage vertiefen (20 min): Gitaly als StatefulSet mit PVC-Namenskonvention repo-data-<statefulset>-<index>, Default-Größe und AccessMode, StorageClass-Empfehlungen (SSD, reclaimPolicy: Retain), dynamische vs. statische Provisionierung.

  5. Hands-on 3: Backup/Restore (40 min): Toolbox-Pod identifizieren, backup-utility ausführen, Tarball im Object Storage prüfen, Rails-Secrets separat sichern, vollständiger Restore-Ablauf inklusive Herunter-/Hochskalieren der Datenbank-Clients, Datenintegritäts-Nachweis.

  6. Hands-on 4: GitLab-Runner-Skalierung (35 min): Abgrenzung Docker-Executor (Vorwissen aus “GitLab & Container-Registry selbst hosten mit Docker”) vs. Kubernetes-Executor, eigenständiger gitlab-runner-Helm-Chart mit RBAC-Minimalrechten, Job-Pods live beobachten, Skalierung über concurrent.

  7. Zero-Downtime-Upgrade & Health-Checks (25 min, Konzept- und Konfigurationsblock): RollingUpdate-Einstellungen (maxSurge/maxUnavailable/terminationGracePeriodSeconds) für Webservice/Sidekiq/Registry, Registry-Readiness-/Liveness-Probe als Beispiel, kubectl rollout pause/status.

  8. Aufräumen & Abschluss (5 min): helm uninstall, minikube delete, offene Fragen.

Hands-on Inhalte (Auszug)

Fundament: Postgres/Redis/Object Storage

  • Schlanke PostgreSQL-/Redis-Pods samt Kubernetes-Secrets für global.psql.password.secret/global.redis.auth.secret
  • MinIO als S3-kompatibles Object Storage, Bucket für Backups/Registry/Artefakte anlegen
  • Bewusst als Trainings-Ersatz für Managed-Services markiert, nicht produktionsreif

Helm-Chart-Deployment

  • helm upgrade –install gitlab gitlab/gitlab -n gitlab -f values.yaml mit reduzierten Replica-Werten
  • kubectl get pods -n gitlab -w während des Rollouts
  • kubectl get secret gitlab-gitlab-initial-root-password -o jsonpath=‘{.data.password}’ | base64 –decode

Backup/Restore

  • kubectl exec <toolbox-pod> -it – backup-utility
  • kubectl get secrets | grep rails-secret, Secret als YAML sichern
  • kubectl scale deploy -l app=sidekiq,release=gitlab –replicas=0, dann backup-utility –restore -t <backup_ID>

Runner-Skalierung

  • helm install –namespace gitlab-runner gitlab-runner -f runner-values.yaml gitlab/gitlab-runner
  • gitlabUrl, runnerToken, rbac.create: true in runner-values.yaml
  • kubectl get pods -n gitlab-runner -w während ein CI-Job läuft – ein eigener Pod pro Job

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zum ersten funktionierenden Deployment, Ergebnis der Restore-Übung) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Explizit nicht Teil dieses Kurses

  • • Produktive Cloud-Managed-Anbindung (AWS RDS, Cloud SQL, ElastiCache, echte S3-Buckets) – hier ausschließlich Trainings-Instanzen im Cluster als Platzhalter für die zwingend externen Abhängigkeiten.
  • • Reference-Architecture-Sizing für Produktivlast und Multi-Node-HA-Betrieb von GitLab selbst – dafür verweisen wir auf die offizielle GitLab-Reference-Architecture-Dokumentation.
  • • etcd-Backup/Restore und Cluster-Recovery des Kubernetes-Clusters selbst – Thema von Kubernetes Cluster-Recovery — etcd Backup & Restore.
  • • Vertiefte Docker-Executor-Praxis – Thema von GitLab & Container-Registry selbst hosten mit Docker, hier nur als Abgrenzungsfolie zum Kubernetes-Executor.
  • • GitOps-gesteuertes Deployment von GitLab selbst (ArgoCD/Flux auf diesen Helm-Chart angewendet) – Thema der GitOps-Module, z. B. Kubernetes GitOps — Deklaratives Deployment mit ArgoCD.
  • • Chart-interne Templating-Vertiefung (eigene Subcharts schreiben, Go-Template-Debugging) – Thema von Helm — Paketmanagement für Kubernetes.

Bereit, das Modul zu buchen?

Wir passen die Hands-on-Übungen auf euren Erfahrungsstand und eure Zielumgebung an.

Academy Briefing anfragen