GitOps und Continuous Delivery

Für Entwicklung, DevOps und Plattformteams: Sie üben nachvollziehbare Auslieferung über Git. Auf Kubernetes folgen Helm oder Kustomize, GitLab CI/CD und Argo CD oder Flux; Vorbereitung und fortgeschrittenes Monitoring sind optional.

Einstieg in 3 Fragen bestimmenRoute, Dauer & Preise ansehen

DER LERNPFAD IM ÜBERBLICK

GitOps und Continuous Delivery: Stufen, Umfang und Reihenfolge

Die Route führt in 5 Stufen von „Vorwissen“ bis „Rollenfokus“. Workshops, Trainingstage und Preis beziehen sich auf die Kernroute.

  • 4 Workshops · Kernroute
  • 10–11 Trainingstage · Kernroute
  • 5.550 bis 6.105 € netto · Kernroute

  1. Vorwissen

    Bestehende Erfahrung kann einzelne Stationen ersetzen.

  2. Container-Fundament

    Eine der beiden Container-Grundlagen führt in den gemeinsamen Kubernetes-Einstieg.

  3. Kubernetes-Einstieg

    Praktische Grundlage für spätere Rollenaufgaben und Zertifizierungsziele mit praktischer Prüfung.

  4. Betriebspraxis

    Sie vertiefen Anwendungsbetrieb, Skalierung, Zugriffs- und Netzregeln, Betriebssignale und Konfiguration je Umgebung.

  5. Rollenfokus

    Dieser Lernpfad folgt einem Rollenpfad, den optionale Themen vertiefen.

Ihre Route durch den Lernpfad

EIGENER LERNPFAD

Was Sie bereits mitbringen

Prüfen Sie, welche Lernschritte Sie noch benötigen.

Einstieg mit 3 Fragen finden

TEAMROUTE: OPTIONAL

Ein gemeinsames Schulungsprogramm planen

Rollen → Kompetenzlücken → gemeinsamer Plan

Ergebnis: eine nachvollziehbare Route für das gesamte Team.

Ihre Selbsteinschätzung

Wählen Sie jeweils die Antwort, die Ihre aktuelle Situation am besten beschreibt.

Prüfungsvorbereitung nur auf Anfrage, außerhalb aller Summen.

Empfehlung ohne Kontaktdaten oder Anmeldung

Ziel durch diesen Lernpfad festgelegt

Kompetenzen, Reihenfolge, Workshops

Welche Kubernetes-Kompetenzen bauen aufeinander auf?

Die Lernschritte zeigen die empfohlene Reihenfolge dieses Pfads. Je nach Ziel kommen Spezialisierungen, optionale Vertiefungen oder Zertifizierungsziele hinzu. Zu jedem Lernschritt sehen Sie, welche Workshops die Inhalte abdecken.

So lesen Sie den Lernpfad
  • Pflicht oder empfohlen
  • Auswahl
  • Optionale Vertiefung
  • Weiterführender Lernpfad

Vorbereitung

Vorab bei Bedarf; nicht in Workshopzahl, Tagen und Preis eingerechnet.

6 Kompetenzen anzeigen

  • Vorwissen

    Bestehende Erfahrung kann einzelne Stationen ersetzen.

    • VORWISSENOptionalBEI BEDARF
      Linux und Netzwerkzugriff

      Kommandozeile, Prozesse, Dateisystem, Erreichbarkeit, Ports, SSH-Zugriff

      Sie üben Linux-Befehle, Prozesse und Dateirechte, prüfen Netzwerkschnittstellen, Erreichbarkeit und offene Ports und verbinden sich per SSH mit entfernten Rechnern. Der Linux-Workshop ist bei fehlenden Kenntnissen sinnvoll; YAML als Konfigurationsformat führen die Docker- und Podman-Workshops ein.

      Danach können Sie im Linux-Terminal Dateien, Rechte und Prozesse prüfen, Netzwerkprobleme eingrenzen und per SSH auf entfernten Rechnern arbeiten.

      Linux-Kommandozeilenpraxis brauchen Sie für GitLab CI/CD und Argo CD sowie für den Kubernetes-Einstieg; auch Helm und Kustomize setzen sicheren Umgang mit dem Terminal voraus. Wenn Ihnen diese Praxis fehlt, bauen Sie sie im Linux-Workshop auf; mit vorhandener Erfahrung können Sie ihn auslassen.

      4 Lernschritte

      1. Im Dateisystem navigieren

        Mit Shell-Befehlen navigieren Sie durch Verzeichnisse und suchen Dateiinhalte, um sich auf einem Linux-System zurechtzufinden.

      2. Rechte und Prozesse prüfen

        Sie prüfen Dateirechte und laufende Prozesse, um Zugriffsgrenzen zu verstehen und hängende Prozesse gezielt zu beenden.

      3. Netzwerkzugang untersuchen

        Netzwerkschnittstellen, Erreichbarkeit und offene Ports prüfen Sie getrennt, um Verbindungsprobleme einzugrenzen.

      4. Entfernte Rechner per SSH erreichen

        Über SSH verbinden Sie sich mit einem entfernten Rechner, um die Arbeit im Terminal auf ein anderes System zu übertragen.

      • Voraussetzung: Der Kubernetes-Einstieg setzt Linux- und Terminal-Grundlagen voraus; bringen Sie diese bereits mit, benötigen Sie den Linux-Workshop nicht.
    • VORWISSENOptionalBEI BEDARF
      Git und Zusammenarbeit

      Commits, Branches, Merges, Remotes, Reviews

      Sie versionieren Änderungen mit Git und üben die Zusammenarbeit über Branches und Reviews. Wählen Sie die Einführung in Git oder den Workshop mit GitLab als Plattform.

      Danach können Sie Änderungen mit Git versionieren, über Branches und Remotes teilen sowie nach einem Review zusammenführen und Merge-Konflikte lösen.

      GitLab CI/CD setzt Git-Grundlagen voraus; für Argo CD und Flux gehört auch die Zusammenarbeit mit Branches und Pull Requests dazu. Fehlt Ihnen diese Praxis, wählen Sie Git oder Git mit GitLab; mit vorhandener Erfahrung ist der Vorbereitungskurs optional.

      4 Lernschritte

      1. Änderungen als Commits festhalten

        Sie verfolgen Änderungen vom Arbeitsverzeichnis über die Staging Area bis zum Commit, um gezielt einen Stand zu versionieren.

      2. Arbeit auf Branches aufteilen

        Auf eigenen Branches bearbeiten Sie Änderungen getrennt und vergleichen sie, bevor Sie die Arbeit wieder zusammenführen.

      3. Änderungen über Remotes austauschen

        Mit Remote-Repositories teilen Sie Commits und unterscheiden das Abrufen fremder Änderungen von deren Integration.

      4. Änderungen prüfen und zusammenführen

        Im Review besprechen Sie Änderungen anhand ihrer Unterschiede und lösen Merge-Konflikte, um Beiträge abgestimmt zusammenzuführen.

      1 von 2 wählen

      Wählen Sie den Git-Workshop als Einstieg, bei GitLab im Team den GitLab-Workshop.

      • Voraussetzung: Die Arbeit an GitLab-Pipelines setzt Git-Grundlagen voraus; vorhandene Erfahrung kann den Grundlagenworkshop ersetzen.
      • Voraussetzung: Argo CD und Flux setzen Git-Kenntnisse mit Branches und Pull Requests voraus; ein zusätzlicher Workshop ist bei vorhandener Erfahrung nicht nötig.
      • Voraussetzung: Die Policy-Workshops setzen den Umgang mit Git-Branches voraus; vorhandene Erfahrung genügt.

  • Container-Fundament

    Eine der beiden Container-Grundlagen führt in den gemeinsamen Kubernetes-Einstieg.

    1 von 2 wählen

    Wählen Sie Podman bei Podman im Team oder auf der Zielplattform oder wenn Container ohne Root-Rechte laufen müssen, sonst Docker.

    • CONTAINEROptionalWAHL
      Docker-Grundlagen

      Images, Container, Volumes, Netzwerke

      Sie bauen Container-Images mit Dockerfiles, auch mit getrennten Bauphasen, und starten Container mit dauerhaftem Speicher und Netzwerkverbindungen. Mit Docker Compose betreiben Sie zusammengehörige Anwendungsdienste.

      Danach können Sie eigene Images bauen, Container mit dauerhaftem Speicher vernetzen und zusammengehörige Anwendungsdienste mit Docker Compose betreiben.

      Diese optionale Vorbereitung führt Sie in Container-Images und YAML ein. Container-Erfahrung hilft beim Kubernetes-Einstieg, ist aber nicht erforderlich; Helm und Flux erwarten YAML-Kenntnisse, Kustomize zusätzlich Praxis mit einfachen Kubernetes-Manifesten.

      4 Lernschritte

      1. Images und Container unterscheiden

        Sie starten Container aus Images und untersuchen ihren Zustand, um die Vorlage von der laufenden Anwendung zu unterscheiden.

      2. Eigene Images bauen

        Beim Image-Bau trennen Sie Bauphasen und Laufzeitbestandteile, damit benötigte Bauwerkzeuge nicht im fertigen Image bleiben müssen.

      3. Speicher und Netzwerke anbinden

        Mit Volumes erhalten Sie Daten über Container-Neustarts hinweg und verbinden Container über Netzwerke für den Datenaustausch.

      4. Dienste mit Compose zusammenführen

        In Docker Compose beschreiben Sie Dienste, Speicher und Netzwerke mit YAML und prüfen deren Zusammenspiel in einer Anwendung.

      • Empfohlene Folge: Container-Erfahrung erleichtert den Kubernetes-Einstieg, ist für den Grundlagenworkshop aber keine Voraussetzung.
      • Ersatzroute: Das Bündel verbindet Docker und Kubernetes durchgängig mit gemeinsamer Buchung und Lerngruppe statt getrennten Terminen. Es setzt mehr Vorwissen voraus: Linux-Kommandozeile sowie Grundlagen der Entwicklung oder Systemadministration.
    • CONTAINERAlternativeWAHL
      Podman-Grundlagen

      Rootless Container, Pods, Images

      Sie bauen Container-Images mit Podman und betreiben Container ohne Root-Rechte mit dauerhaftem Speicher und Netzwerkverbindungen. Zusammengehörige Container fassen Sie in Pods zusammen.

      Danach können Sie Podman-Images bauen, Container ohne Root-Rechte mit Netzwerk und dauerhaftem Speicher betreiben und in Pods gruppieren.

      Wählen Sie Podman statt Docker als optionale Vorbereitung, wenn Ihr Team bereits mit Podman oder Containern ohne Root-Rechte arbeitet.

      4 Lernschritte

      1. Rootless-Betrieb verstehen

        An Podmans Architektur verstehen Sie, wie Container ohne zentralen Daemon unter Ihrem Benutzerkonto laufen.

      2. Images bauen und verwalten

        Sie bauen Images und verwalten sie in Registries, um Anwendungen als wiederverwendbare Grundlage für Container bereitzustellen.

      3. Netzwerk und Speicher anbinden

        Mit Netzwerken und Volumes verbinden Sie Container und erhalten Daten, wobei Sie Dateirechte im Rootless-Betrieb prüfen.

      4. Container in Pods zusammenführen

        In Pods fassen Sie zusammengehörige Container zusammen und prüfen ihre Kommunikation über das gemeinsam genutzte Netzwerk.

      • Empfohlene Folge: Container-Erfahrung erleichtert den Kubernetes-Einstieg, ist für den Grundlagenworkshop aber keine Voraussetzung.

  • Betriebspraxis

    Sie vertiefen Anwendungsbetrieb, Skalierung, Zugriffs- und Netzregeln, Betriebssignale und Konfiguration je Umgebung.

    BEIDE OPTIONAL

    Diese Kompetenzen vertiefen den Lernpfad und sind optional.

    • BETRIEBSPRAXISOptionalOPTIONAL
      Workloads und Skalierung

      StatefulSets, Datenbank-Operatoren, Scheduling, Ressourcenmanagement, HPA, VPA, KEDA

      Sie untersuchen zustandsbehaftete Workloads mit StatefulSets und setzen Datenbank-Operatoren ein. Mit Ressourcenangaben und Scheduling-Vorgaben steuern Sie die Platzierung von Pods. Autoscaling konfigurieren Sie mit HPA, VPA und KEDA.

      Danach können Sie StatefulSets untersuchen, Datenbank-Operatoren einsetzen, die Pod-Platzierung steuern und Autoscaling mit HPA, VPA und KEDA konfigurieren.

      In dieser optionalen Vertiefung lernen Sie mehr über Anwendungen mit dauerhaft gespeicherten Daten, die Platzierung von Pods, Ressourcenverteilung und automatische Skalierung.

      4 Lernschritte

      1. Zustandsbehaftete Workloads verstehen

        An einer Datenbank als StatefulSet untersuchen Sie, warum stabile Pod-Identitäten und dauerhafter Speicher zusammengehören.

      2. Datenbank-Operatoren einsetzen

        Sie richten Datenbank-Operatoren ein und betrachten ihre Vor- und Nachteile, um ihren Beitrag zum Datenbankbetrieb einzuschätzen.

      3. Ressourcen und Platzierung steuern

        Mit Ressourcenanforderungen und Scheduling-Vorgaben steuern Sie, auf welchen Nodes Pods laufen können, und beobachten ihre Platzierung.

      4. Skalierungsansätze unterscheiden

        Sie konfigurieren HPA, VPA und KEDA und unterscheiden dabei Pod-Anzahl, Ressourcenanpassung und Ereignisse als Skalierungsgrundlage.

    • BETRIEBSPRAXISOptionalOPTIONAL
      Netzwerk, Zugriff und Betrieb

      Ingress und Gateway API im Überblick, Service Mesh im Überblick, Network Policies, RBAC, Monitoring, Logging

      Sie ordnen Ingress, Gateway API und Service Mesh ein und üben RBAC und Network Policies. Mit Prometheus und Grafana richten Sie grundlegendes Monitoring ein, mit Loki das Logging. Gateway-API-Migration und Controller-Portabilität gehören nicht zum praktischen Umfang.

      Danach können Sie Netzwerkansätze einordnen, API-Zugriff und Kommunikation begrenzen sowie grundlegendes Monitoring und Logging für Kubernetes einrichten.

      Sie ordnen Netzwerkoptionen ein, üben Zugriffsregeln und richten grundlegendes Monitoring und Logging ein.

      4 Lernschritte

      1. Routing und Service Mesh einordnen

        Sie vergleichen die Aufgaben von Ingress, Gateway API und Service Mesh, um deren Einsatzbereiche und Grenzen einzuordnen.

      2. API-Zugriff und Kommunikation begrenzen

        Mit RBAC begrenzen Sie API-Aktionen und mit Network Policies die Kommunikation, um diese Schutzaufgaben getrennt zu bearbeiten.

      3. Metriken erfassen und darstellen

        Sie richten Prometheus und Grafana per Operator ein, um Cluster-Metriken zu sammeln und in Dashboards sichtbar zu machen.

      4. Logs bündeln und Benachrichtigungen setzen

        Mit Loki bündeln Sie Cluster-Logs und ergänzen grundlegende Benachrichtigungen, damit Hinweise auf Betriebsprobleme zusammenkommen.

Kernroute

Jede Nummer steht für einen eingerechneten Workshop, der mehrere Kompetenzen abdecken kann.

  1. Workshop-Schritt 1 von 4:

    Kubernetes-Einstieg

    Praktische Grundlage für spätere Rollenaufgaben und Zertifizierungsziele mit praktischer Prüfung.

    • KUBERNETES-EINSTIEGKernschrittSelbstangabeKERN
      Kubernetes-Einstieg

      Architektur, Pods, Deployments, Deployment-Strategien, Services, Namespaces, CoreDNS, Storage und CSI, ConfigMaps, Secrets, kubectl

      Sie stellen Anwendungen mit Kubernetes bereit, machen sie erreichbar und konfigurieren und untersuchen sie mit kubectl, dem Befehlswerkzeug für Kubernetes. Dazu richten Sie grundlegenden dauerhaften Speicher für Anwendungen ein.

      Danach können Sie Anwendungen in Kubernetes bereitstellen, erreichbar machen, mit Konfiguration und dauerhaftem Speicher versorgen und mit kubectl untersuchen.

      Sie lernen, eine Anwendung mit Pods, Deployments und Services auf Kubernetes auszuführen, ihren Zustand mit kubectl zu prüfen und sie zu ändern.

      5 Lernschritte

      1. Architektur und Pods verstehen

        Sie verfolgen das Zusammenspiel von Control Plane, Nodes und Pods und untersuchen mit kubectl den Zustand Ihrer ersten Pods.

      2. Anwendungen bereitstellen und aktualisieren

        Mit Deployments stellen Sie Anwendungen bereit und vergleichen Aktualisierungsstrategien, um deren Risiken einzuordnen.

      3. Erreichbarkeit und Namensauflösung

        Services machen Pods erreichbar, während Sie mit Namespaces Ressourcen gliedern und mit CoreDNS die Namensauflösung prüfen.

      4. Konfiguration vom Image trennen

        Über ConfigMaps und Secrets binden Sie Konfiguration und sensible Werte in Pods ein, damit diese getrennt vom Image bleiben.

      5. Dauerhaften Speicher prüfen

        Sie binden Volumes an Pods, ordnen CSI und StorageClasses ein und prüfen, ob Daten einen Pod-Neustart überstehen.

      • Voraussetzung: Die Arbeit mit Helm oder Kustomize setzt Kubernetes-Grundlagen voraus: Deployments, Services und einfache YAML-Manifeste.
  2. Workshop-Schritt 2 von 4:

    Betriebspraxis

    Sie vertiefen Anwendungsbetrieb, Skalierung, Zugriffs- und Netzregeln, Betriebssignale und Konfiguration je Umgebung.

    • BETRIEBSPRAXISKernschrittSelbstangabeWAHL
      Manifeste verwalten

      Umgebungskonfiguration, Wiederverwendung, Helm oder Kustomize

      Sie strukturieren Kubernetes-Konfigurationen für unterschiedliche Umgebungen. Wählen Sie Helm mit Charts und Values oder Kustomize mit Bases, Overlays und Patches. Die Wahl umfasst die Arbeit mit einem Werkzeug, nicht mit beiden.

      Danach können Sie mit Helm oder Kustomize wiederverwendbare Kubernetes-Konfigurationen strukturieren, für Umgebungen anpassen und die erzeugten Ressourcen prüfen.

      Helm oder Kustomize bleibt Pflicht in der Kernroute: Sie schreiben und versionieren Charts oder Overlays, also wiederverwendbare Konfigurationen für Test und Produktion. Die späteren Workshops zu Argo CD oder Flux zeigen, wie die Werkzeuge diese Konfigurationen ausliefern.

      4 Lernschritte

      1. Gemeinsamkeiten und Unterschiede erkennen

        Sie unterscheiden gemeinsame Konfiguration von Umgebungsunterschieden, um wiederverwendbare Teile Ihrer Manifeste zu erkennen.

      2. Wiederverwendbare Struktur aufbauen

        Mit Helm oder Kustomize strukturieren Sie gemeinsame Ressourcen, damit Umgebungsvarianten auf derselben Grundlage aufbauen.

      3. Umgebungsvarianten umsetzen

        Im gewählten Werkzeug setzen Sie gezielte Anpassungen für Staging und Produktion um, damit jede Umgebung ihre eigene Konfiguration erhält.

      4. Erzeugte Ressourcen prüfen

        An den erzeugten Ressourcen prüfen Sie, wie gemeinsame Vorgaben und Anpassungen zusammenwirken, um Konfigurationsfehler zu erkennen.

      1 von 2 wählen

      Helm paketiert, versioniert und liefert Software als Charts; Kustomize passt vorhandene Manifeste je Umgebung per Overlay ohne Vorlagen an.

      • Empfohlene Folge: Charts oder Overlays bilden eine Grundlage für die Konfiguration, die Argo CD oder Flux abgleicht.
  3. Workshop-Schritt 3 von 4:

    Rollenfokus

    Dieser Lernpfad folgt einem Rollenpfad, den optionale Themen vertiefen.

    • ROLLENPFADKernschrittROLLENPFAD
      GitOps

      Änderungen über Git ausliefern: vom gespeicherten und geprüften Änderungsstand bis zur laufenden Anwendung.

      Sie verbinden die Schritte von einer Änderung in Git bis zur laufenden Anwendung, wobei Git festhält, welche Version mit welcher Konfiguration laufen soll.

    • ROLLENKOMPETENZKernschrittSelbstangabeROLLENPFAD
      Container-Images automatisiert bauen

      GitLab CI/CD: Bauen, Prüfen und Ausliefern, Pipelines, Runner zur Job-Ausführung, Build-Ergebnisse, Sicherheitsprüfungen, Testumgebungen

      Sie erstellen GitLab-Pipelines, steuern Jobs und bauen und veröffentlichen Container-Images. Dazu ergänzen Sie Scans und Deployment-Schritte und untersuchen Pipelinefehler. Git-Grundlagen werden vorausgesetzt.

      Danach können Sie GitLab-Pipelines zum Bauen, Prüfen und Veröffentlichen von Container-Images erstellen, Testumgebungen einbinden und Job-Fehler eingrenzen.

      Mit GitLab CI/CD bauen, prüfen und veröffentlichen Sie Container-Images bei Git-Änderungen automatisch. Ablaufphasen, Aufgaben, ausführende Dienste (Runner), Image-Bau und Prüfungen sowie Zielumgebungen sind auf andere CI-Systeme übertragbar; Argo CD oder Flux können Sie ohne diesen Kurs besuchen.

      4 Lernschritte

      1. Jobs und Runner zuordnen

        Sie gliedern eine GitLab-Pipeline in Jobs und Stages und ordnen Runner zu, damit Ablauf und Ausführungsort nachvollziehbar werden.

      2. Images und Build-Ergebnisse bereitstellen

        Sie bauen Container-Images für die Registry und geben Build-Ergebnisse als Artefakte weiter, damit nachfolgende Jobs sie nutzen können.

      3. Prüfungen und Testumgebungen einbinden

        Mit Scan-Jobs und Deployments in Testumgebungen prüfen Sie Images und Anwendungen innerhalb des Auslieferungsablaufs.

      4. Pipelinefehler eingrenzen

        Syntaxprüfung und Job-Logs helfen Ihnen, Konfigurationsfehler von Runner-, Image-Zugriffs- und Berechtigungsproblemen zu unterscheiden.

      4 weitere Beziehungen
      • Empfohlene Folge: Mit GitLab automatisieren Sie das Bauen und Prüfen von Container-Images als Grundlage für die anschließende Auslieferung über Git.
      • Empfohlene Folge: Eine Pipeline oder Flux Image Automation schreibt die Referenz der neuen Image-Version nach Git; Argo CD oder Flux liefert die Anwendung anhand dieses Git-Stands aus.
      • Empfohlene Folge: Wenn Ihnen CI-Praxis fehlt, können Sie diese vor den Policy-Tests in GitLab aufbauen. Die Policy-Workshops sind nicht auf GitLab beschränkt.
      • Optionale Vertiefung: Für Bau- und Prüfabläufe direkt im Kubernetes-Cluster können Sie eine Tekton-Einführung anfragen; diese Alternative zur Ausführung ersetzt keine GitLab-CI/CD-Kompetenz.
  4. Workshop-Schritt 4 von 4:
    • ROLLENKOMPETENZKernschrittSelbstangabeROLLENPFAD
      Auslieferung automatisieren

      Zustandsabgleich, Abweichungen, Umgebungen, Secrets ohne Klartext in Git, Argo CD oder Flux

      Mit Argo CD oder Flux liefern Sie Anwendungen aus Git aus und gleichen die verwalteten Kubernetes-Ressourcen mit ihrem Sollzustand ab. Sie erkennen und korrigieren Abweichungen von der Konfiguration in Git.

      Danach können Sie mit Argo CD oder Flux Anwendungen aus Git ausliefern, Umgebungen unterscheiden, Secrets ohne Klartext in Git einbinden und Abweichungen korrigieren.

      Wählen Sie Argo CD oder Flux: Git gibt vor, was im Cluster laufen soll (deklarativ). Die neue Image-Referenz schreibt bei Argo CD die Pipeline nach Git, bei Flux Image Automation. Drift, etwa manuelle Abweichungen von Git im Cluster, erkennen und korrigieren Sie.

      4 Lernschritte

      1. Git als Sollzustand verstehen

        Sie verfolgen, wie Argo CD oder Flux Konfiguration aus Git abruft und verwaltete Ressourcen mit diesem Sollzustand abgleicht.

      2. Konfiguration nach Umgebung trennen

        Gemeinsame Basiskonfiguration und gezielte Anpassungen trennen Unterschiede zwischen Umgebungen, ohne alle Manifeste zu kopieren.

      3. Secrets ohne Klartext bereitstellen

        Sie vergleichen Verschlüsselung im Repository mit externem Secret-Bezug, damit vertrauliche Werte nicht im Klartext in Git stehen.

      4. Abweichungen und Fehler untersuchen

        Anhand von Git-Konfiguration und Controller-Rückmeldungen untersuchen Sie fehlgeschlagene Abgleiche und korrigieren Abweichungen.

      1 von 2 wählen

      Teamwerkzeug nutzen; Argo CD für Canary und Blue-Green mit Argo Rollouts samt Browserübersicht, Flux für automatische Image-Updates in Git.

      • Voraussetzung: Die Auslieferung aus Git und der Abgleich mit dem Cluster bilden die Grundlage für nachvollziehbare Softwareauslieferung.
      3 weitere Beziehungen
      • Optionale Vertiefung: Wenn Sie mit Argo CD arbeiten, ergänzt Kargo die kontrollierte Weitergabe von Versionen zwischen Umgebungen; diese Vertiefung baut nicht auf Flux auf.
      • Optionale Vertiefung: CGOA ergänzt Argo CD oder Flux um werkzeugneutrale GitOps-Prinzipien; CAPA verlangt Wissen zum gesamten Argo-Projekt, das der Argo-CD-Workshop nicht abdeckt und Flux nicht vermittelt.
      • Optionale Vertiefung: Ein zentraler Secrets-Speicher ergänzt die Synchronisierung oder Verschlüsselung für GitOps um Speicherung, Rotation und Ausgabe; Einführungen in Vault und OpenBao können Sie anfragen.

Mögliche Ziele

Dieser Pfad baut die fachlichen Grundlagen für diese Ziele auf.

  • ZielNachvollziehbare SoftwareauslieferungSie richten die Auslieferung Ihrer Anwendungen so ein, dass nur geprüfte Git-Änderungen übernommen werden und nachvollziehbar bleiben. Abweichungen der verwalteten Ressourcen vom Git-Stand machen Sie sichtbar und korrigieren sie.
  • ZielBetriebssignale einrichten und auswertenSie konfigurieren Metriken, Protokolle und Alarmierung und werten diese Betriebssignale aus. Diese Vertiefung geht über den GitOps-Kern hinaus; der Workshop zur Betriebsüberwachung setzt Erfahrung in der Kubernetes-Clusteradministration voraus.

Vertiefung

Optional weiterlernen; nicht in Workshopzahl, Tagen und Preis eingerechnet.

7 Kompetenzen anzeigen

  • Rollenfokus

    Dieser Lernpfad folgt einem Rollenpfad, den optionale Themen vertiefen.

    Erweitert den Pfad, ist aber kein Pflichtschritt.

    • VERTIEFUNGSKOMPETENZOptionalAUF ANFRAGE
      Pipelines mit Tekton

      Tekton, Automatisiertes Bauen und Prüfen, Kubernetes-Ressourcen, Aufgaben, Pipelines

      Tekton führt Abläufe zum automatisierten Bauen und Prüfen als Kubernetes-Ressourcen im Cluster aus und bietet damit eine alternative Ausführung für kontinuierliche Integration (CI). Eine Einführung in Tekton können Sie anfragen; sie ersetzt die GitLab-CI/CD-Kompetenz nicht.

      Tekton ist ein Anschluss für Teams, die ihre CI-Pipelines innerhalb von Kubernetes statt mit GitLab CI ausführen möchten. Die Einführung ergänzt diesen Schwerpunkt und ersetzt die GitLab-CI/CD-Station der Route nicht.

      • DW51 Einführung in TektonWorkshop auf AnfrageAnfragen
    • VERTIEFUNGSKOMPETENZOptionalWAHL
      Policy as Code

      Admission Control, Validierung, Mutation, Ausnahmen, Policy-Tests, CI

      Sie entwickeln und testen Kubernetes-Policies mit Kyverno oder OPA Gatekeeper und Rego. Dabei untersuchen Sie Validierung, Mutation und den Umgang mit Ausnahmen und integrieren Tests in CI. Git- und CI-Grundlagen werden vorausgesetzt; der Funktionsumfang hängt vom gewählten Werkzeug ab.

      Danach können Sie Kubernetes-Policies mit dem gewählten Werkzeug entwickeln, in CI testen und ihre Durchsetzung mit begrenzten Ausnahmen vorbereiten.

      Nach dem Pipeline-Schritt wählen Sie optional Kyverno oder OPA Gatekeeper, wenn Ihr GitOps-Team Regeln in Pipelines und bei der Zulassung zum Cluster prüfen muss. Die buchbaren Workshops setzen Kubernetes-Praxis, Git-Branches und Erfahrung mit kontinuierlicher Integration voraus; diese Vertiefung bleibt außerhalb jeder Summe. KCA-Vorbereitung auf Anfrage betrifft ausschließlich Kyverno.

      4 Lernschritte

      1. Admission und Bestandsprüfung einordnen

        Sie unterscheiden die Prüfung neuer API-Anfragen von der Prüfung vorhandener Ressourcen, um die Reichweite einer Policy zu verstehen.

      2. Validierung und Mutation gestalten

        Mit dem gewählten Werkzeug formulieren Sie Validierungsregeln und begrenzte Änderungen, um Vorgaben zu prüfen oder fehlende Werte zu ergänzen.

      3. Regeln testen und in CI prüfen

        Erlaubte, verletzende und ausgenommene Ressourcen werden zu Testfällen in CI, damit unbeabsichtigtes Policy-Verhalten vor dem Einsatz auffällt.

      4. Ausnahmen und Durchsetzung begrenzen

        Eng begrenzte Ausnahmen und ausgewertete Prüfergebnisse helfen Ihnen, den Wechsel vom Beobachten zum Blockieren nachvollziehbar zu gestalten.

      1 von 2 wählen

      Gatekeeper mit Open Policy Agent (OPA) bei bestehendem Einsatz oder bewusster Rego-Wahl, sonst Kyverno für YAML-Regeln; nur Kyverno passt fachlich zur anfragbaren Vorbereitung auf Kyverno Certified Associate.

      • DW30 Einführung in KyvernoKyverno und CEL; zusätzlich Prüfung von Image-Signaturen und AttestierungenEinsteiger3 TageOnline, Unterrichtssprache: Deutsch
      • DW31 Einführung in OPA Gatekeeper und RegoOPA Gatekeeper und Rego; ConstraintTemplates, Constraints und gatorAufbau3 TageOnline, Unterrichtssprache: Deutsch
      • DW45 Kyverno Certified Associate (KCA)Prüfungsvorbereitung auf AnfrageKCA: Multiple-Choice, 90 Min., Prüfungsanmeldung USD 250 (ein Wiederholungsversuch inklusive), Stand 16. September 2026; separat bei der Linux Foundation buchen und bezahlen, nicht in angezeigten Preisen enthalten.Anfragen
    • VERTIEFUNGSKOMPETENZOptionalAUF ANFRAGE
      Versionen durch Umgebungen führen

      Kargo, Versionsfreigaben, Entwicklung, Vorproduktion, Produktion, Argo CD

      Kargo steuert die Weitergabe von Versionen aus der Entwicklung über die Vorproduktion bis in die Produktion. Diese Vertiefung baut auf Argo CD auf, nicht auf Flux; eine Einführung in Kargo können Sie anfragen.

      Wenn Ihr Team Argo CD gewählt hat, schließt Kargo daran an: Im Mittelpunkt steht die kontrollierte Übernahme von Versionen aus der Testumgebung über Staging in die Produktion. Für Teams mit Flux ist dieser Anschluss nicht vorgesehen.

      • DW50 Einführung in KargoWorkshop auf AnfrageAnfragen
    • VERTIEFUNGSKOMPETENZOptionalAUF ANFRAGE
      Secrets zentral verwalten

      HashiCorp Vault, OpenBao, Zentrale Speicherung, Regelmäßiger Wechsel, Dynamische Ausgabe

      HashiCorp Vault und OpenBao speichern, rotieren und erzeugen Secrets wie Passwörter zentral; das ergänzt Kubernetes Secrets, die Synchronisierung per External Secrets Operator und Verschlüsselung mit SOPS oder Sealed Secrets. OpenBao ist eine quelloffene Abspaltung von Vault. Einführungen in Vault und OpenBao können Sie anfragen.

      Wenn Ihr Team Zugangsdaten zentral verwalten möchte, wählen Sie HashiCorp Vault oder OpenBao als Anschluss an die Secrets-Ansätze aus dem Argo-CD- oder Flux-Workshop. Der dort behandelte External Secrets Operator kann Zugangsdaten aus einem solchen zentralen Speicher beziehen.

      Wählen Sie Vault bei bestehendem Betrieb oder Lizenzierung, OpenBao bei geforderter quelloffener Lizenz oder gemeinschaftlicher Steuerung.

      • DW56 Einführung in HashiCorp VaultWorkshop auf AnfrageAnfragen
      • DW57 Einführung in OpenBaoWorkshop auf AnfrageAnfragen
    • VERTIEFUNGSKOMPETENZOptionalAUF ANFRAGE
      GitOps und Argo (CGOA, CAPA)

      GitOps-Prinzipien, Zustandsabgleich, Argo CD, Argo Rollouts, Argo Workflows, Argo Events

      Certified GitOps Associate (CGOA) prüft werkzeugneutrale Prinzipien und passt nach Argo CD oder Flux. Certified Argo Project Associate (CAPA) umfasst das Argo-Projekt inklusive Workflows und Events, die weder der Argo-CD- noch der Flux-Workshop behandelt. Vorbereitungen auf Anfrage; Prüfungen buchen und bezahlen Sie separat bei der Linux Foundation.

      Die Vorbereitung zum Certified GitOps Associate (CGOA) vertieft nach Argo CD oder Flux werkzeugunabhängige GitOps-Prinzipien. Certified Argo Project Associate (CAPA) passt zu Argo-CD-Teams: Die Prüfung umfasst Argo Workflows, Argo CD, Argo Rollouts und Argo Events. Der Argo-CD-Workshop behandelt davon nur Argo CD und Argo Rollouts; die buchbaren Workshops bereiten nicht systematisch auf Prüfungen vor. Vorbereitung auf Anfrage; Prüfungen buchen und bezahlen Sie separat bei der Linux Foundation.

      • DW44 Certified GitOps Associate (CGOA)Prüfungsvorbereitung auf AnfrageCGOA: Multiple-Choice, 90 Min., Prüfungsanmeldung USD 250 (ein Wiederholungsversuch inklusive), Stand 16. September 2026; separat bei der Linux Foundation buchen und bezahlen, nicht in angezeigten Preisen enthalten.Anfragen
      • DW43 Certified Argo Project Associate (CAPA)Prüfungsvorbereitung auf AnfrageCAPA: Multiple-Choice, 90 Min., Prüfungsanmeldung USD 250 (ein Wiederholungsversuch inklusive), Stand 16. September 2026; separat bei der Linux Foundation buchen und bezahlen, nicht in angezeigten Preisen enthalten.Anfragen
    • SPEZIALISIERUNGOptionalVERTIEFUNG
      Observability

      Metriken, Protokolle und Alarmregeln konfigurieren und die erfassten Betriebssignale auswerten.

      Diese optionale Vertiefung führt über die Softwareauslieferung dieses Pfads hinaus und richtet sich an Teams, die ihre Anwendungen auch betreiben und deren Verhalten überwachen.

    • VERTIEFUNGSKOMPETENZOptionalVERTIEFUNG
      Metriken, Logs & Alerting

      Prometheus, Grafana, Loki, Dashboards, Alerting

      Mit Prometheus, Grafana und Loki erfassen und analysieren Sie Metriken und Logs aus Kubernetes. Sie erstellen Dashboards, konfigurieren Alarme und definieren messbare Serviceziele. Bei Störungen führen Sie Signale zusammen und untersuchen auch Datenlücken und Ressourcenprobleme des Monitoring-Stacks.

      Danach können Sie Kubernetes-Metriken und Logs mit Prometheus, Grafana und Loki auswerten, Dashboards und Alarme einrichten und Störungen systematisch untersuchen.

      Der fortgeschrittene Monitoring-Kurs mit Prometheus, Grafana und Loki setzt Kubernetes-Administrationspraxis, Linux-Kommandozeile und YAML voraus; Kubernetes Advanced allein genügt nicht. Benachrichtigungen und grundlegendes Monitoring von Argo CD oder Flux behandeln bereits die Workshops.

      4 Lernschritte

      1. Metriken und Logs erfassen

        Sie erfassen Metriken mit Prometheus und Logs mit Loki, um Messwerte und Ereignisse als unterschiedliche Informationsquellen zu verstehen.

      2. Daten abfragen und zusammenführen

        Mit PromQL und LogQL wählen Sie relevante Daten aus und verbinden sie in Grafana-Dashboards, um Auffälligkeiten im Kontext zu betrachten.

      3. Alarme und Serviceziele definieren

        Sie formulieren messbare Serviceziele und richten Alarmregeln sowie Empfänger ein, damit kritische Zustände sichtbar werden.

      4. Störungen anhand von Signalen untersuchen

        Vom Alarm über das Dashboard bis zu den Logs verfolgen Sie Störungen und prüfen auch Datenlücken sowie Ressourcenprobleme im Monitoring.

      • DW10 Kubernetes Monitoring und Observabilityoptionale VertiefungFortgeschritten4 TageOnline, Unterrichtssprache: Deutsch
      • DW41 Prometheus Certified Associate (PCA)Prüfungsvorbereitung auf AnfragePCA: Multiple-Choice, 90 Min., Prüfungsanmeldung USD 250 (ein Wiederholungsversuch inklusive), Stand 16. September 2026; separat bei der Linux Foundation buchen und bezahlen, nicht in angezeigten Preisen enthalten.Anfragen
      2 weitere Beziehungen
      • Optionale Vertiefung: Die Spezialisierung Observability erweitert den Pfad um diese Kompetenz.
      • Optionale Vertiefung: Mit der Vertiefung konfigurieren und interpretieren Sie Metriken, Protokolle und Alarmierung; Erfahrung in der Clusteradministration wird vorausgesetzt.

Welche Workshops umfasst die Beispielroute GitOps und Continuous Delivery?

Die Beispielroute umfasst DW2, DW14, wahlweise DW9 oder DW22 und wahlweise DW27 oder DW28. Sie deckt folgende Kompetenzen ab: Kubernetes-Einstieg, Manifeste verwalten, Container-Images automatisiert bauen und Auslieferung automatisieren.

BEISPIELROUTE (ROLLENPFAD: DELIVERY)

GitOps und Continuous Delivery

Für Entwicklung, DevOps und Plattformteams: Sie üben nachvollziehbare Auslieferung über Git. Auf Kubernetes folgen Helm oder Kustomize, GitLab CI/CD und Argo CD oder Flux; Vorbereitung und fortgeschrittenes Monitoring sind optional.

Routenumfang
4
Trainingstage
10–11
Listenpreisbasis, netto p. P.
5.550–6.105 €
Einstiegsworkshop ansehen für Einführung in Kubernetes (DW2)

Eingerechnet: DW2, DW9 oder DW22 (ein Workshop), DW14 und DW27 oder DW28 (ein Workshop). Zusätzliche Workshops sind nicht eingerechnet.

Workshops dieser Beispielroute

Jeder Workshop zeigt Rolle, abgedeckte Kompetenzen und Planungsdaten.

4 Workshops, fachlich empfohlene Reihenfolge

Vorbereitung

Vorbereitung bei Bedarf

Nicht in Workshopzahl, Tagen und Preis eingerechnet.

Kernroute

  1. STARTPUNKT (KUBERNETES-EINSTIEG)

    DW2 Einführung in Kubernetes

    Sie lernen, eine Anwendung mit Pods, Deployments und Services auf Kubernetes auszuführen, ihren Zustand mit kubectl zu prüfen und sie zu ändern.

    ABGEDECKTE KOMPETENZEN

    Architektur, Pods, Deployments, Deployment-Strategien, Services, Namespaces, CoreDNS, Storage und CSI, ConfigMaps, Secrets, kubectl

    3 Tage, 1.665 € netto

    Termin auswählen

    Inhalte & Termine für Einführung in Kubernetes (DW2)

  2. WAHLSCHRITT

    Manifeste verwalten

    Wählen Sie 1 von 2

    Helm oder Kustomize bleibt Pflicht in der Kernroute: Sie schreiben und versionieren Charts oder Overlays, also wiederverwendbare Konfigurationen für Test und Produktion. Die späteren Workshops zu Argo CD oder Flux zeigen, wie die Werkzeuge diese Konfigurationen ausliefern.

    ABGEDECKTE KOMPETENZEN

    Umgebungskonfiguration, Wiederverwendung, Helm oder Kustomize

  3. ROLLENKOMPETENZ

    DW14 Einführung in GitLab CI/CD

    Mit GitLab CI/CD bauen, prüfen und veröffentlichen Sie Container-Images bei Git-Änderungen automatisch. Ablaufphasen, Aufgaben, ausführende Dienste (Runner), Image-Bau und Prüfungen sowie Zielumgebungen sind auf andere CI-Systeme übertragbar; Argo CD oder Flux können Sie ohne diesen Kurs besuchen.

    ABGEDECKTE KOMPETENZEN

    GitLab CI/CD: Bauen, Prüfen und Ausliefern, Pipelines, Runner zur Job-Ausführung, Build-Ergebnisse, Sicherheitsprüfungen, Testumgebungen

    2 Tage, 1.110 € netto

    Termin auswählen

    Inhalte & Termine für Einführung in GitLab CI/CD (DW14)

  4. WAHLSCHRITT

    Auslieferung automatisieren

    Wählen Sie 1 von 2

    Wählen Sie Argo CD oder Flux: Git gibt vor, was im Cluster laufen soll (deklarativ). Die neue Image-Referenz schreibt bei Argo CD die Pipeline nach Git, bei Flux Image Automation. Drift, etwa manuelle Abweichungen von Git im Cluster, erkennen und korrigieren Sie.

    ABGEDECKTE KOMPETENZEN

    Zustandsabgleich, Abweichungen, Umgebungen, Secrets ohne Klartext in Git, Argo CD oder Flux

Vertiefung

Optionale Vertiefung

Nicht in Workshopzahl, Tagen und Preis eingerechnet.
  • Policy as Code

    Bei Bedarf: 1 von 2

    Nach dem Pipeline-Schritt wählen Sie optional Kyverno oder OPA Gatekeeper, wenn Ihr GitOps-Team Regeln in Pipelines und bei der Zulassung zum Cluster prüfen muss. Die buchbaren Workshops setzen Kubernetes-Praxis, Git-Branches und Erfahrung mit kontinuierlicher Integration voraus; diese Vertiefung bleibt außerhalb jeder Summe. KCA-Vorbereitung auf Anfrage betrifft ausschließlich Kyverno.

  • DW10 Kubernetes Monitoring und Observability

    Der fortgeschrittene Monitoring-Kurs mit Prometheus, Grafana und Loki setzt Kubernetes-Administrationspraxis, Linux-Kommandozeile und YAML voraus; Kubernetes Advanced allein genügt nicht. Benachrichtigungen und grundlegendes Monitoring von Argo CD oder Flux behandeln bereits die Workshops.

    4 Tage, 2.220 € netto

    Inhalte & Termine für Kubernetes Monitoring und Observability (DW10)

Warum ist diese Route so aufgebaut?

Die Route folgt Lernfragen: Jede Station baut auf der vorherigen auf. Hier erfahren Sie, warum die Übergänge sinnvoll sind.

Fachlich empfohlene Reihenfolge, keine formale Prüfungszulassung.

Das Routenprinzip

Jede Station beantwortet eine andere Lernfrage.

  1. Kubernetes verstehen

    Wie läuft eine Anwendung im Cluster?

  2. Manifeste schreiben und pflegen

    Wie schreiben und pflegen Sie Manifeste für verschiedene Umgebungen?

  3. Container-Images automatisiert bauen

    Wie baut und prüft GitLab CI/CD versionierte Container-Images?

  4. Auslieferung automatisieren

    Wie kommt ein geprüftes Image aus der Pipeline über Git zum Cluster?

Die fachliche Logik im Detail

Kurze Begründungen machen die Übergänge nachvollziehbar, ohne die Route erneut abzubilden.

  1. DW2 danach DW9 / DW22: Kompetenzvoraussetzung

    Warum stehen Kubernetes-Grundlagen vor Helm oder Kustomize?

    Helm und Kustomize strukturieren Kubernetes-Manifeste: Sie müssen die darin beschriebenen Ressourcen verstehen, mit kubectl arbeiten und sich im Terminal sicher bewegen können. Helm setzt Kenntnisse der YAML-Syntax voraus, Kustomize zusätzlich Praxis im Schreiben einfacher YAML-Manifeste. Gleichwertige Erfahrung genügt; der Grundlagenworkshop ist keine formale Zugangsvoraussetzung.

  2. DW9 / DW22 danach DW14: Empfohlene Reihenfolge

    Warum folgen die Pipelines auf Helm oder Kustomize?

    Nach den Manifesten lernen Sie, wie GitLab CI/CD deren Images baut, prüft und veröffentlicht. Später aktualisiert die Pipeline für Argo CD die Konfiguration in Git; bei Flux übernimmt das Image Automation. Der Einsteigerkurs braucht Git-Grundlagen und die Linux-Kommandozeile, weder Kubernetes noch Helm oder Kustomize: Sie können die Stationen auch umgekehrt besuchen oder auf parallel lernende Teammitglieder verteilen.

  3. DW14 danach DW27 / DW28: Empfohlenes Zusammenspiel

    Wie übergibt die Pipeline neue Images an Argo CD oder Flux?

    CI veröffentlicht Images, ändert aber nicht den Cluster: Im Argo-CD-Kurs schreibt eine vorbereitete GitLab-Pipeline die Image-Referenz nach Git, bei Flux übernimmt Image Automation den Commit. Anschließend gleichen die Werkzeuge den Cluster mit Git ab. Sie brauchen solide Kubernetes-Praxis und Git-Grundlagen, für Argo CD auch die Linux-Kommandozeile, für Flux YAML-Syntax; ein CI-Kurs ist nicht nötig, auch ein anderes CI-System passt.

Was ist fest, was flexibel?

Der Status zeigt, welche Kernstationen in den Gesamtwerten berücksichtigt sind und wo Vorwissen oder Lernziel Spielraum lassen. Optionale Ergänzungen zählen erst bei Auswahl dazu.

  • In dieser Route berücksichtigt

    Diese Station ist mit einem Workshop fest in Ihrer Route eingeplant.

  • Auswahl gleichwertiger Workshops

    Hier wählen Sie passend zum Werkzeug Ihres Teams einen Workshop: Die Optionen vermitteln dieselbe Kompetenz mit unterschiedlichen Werkzeugen und Schwerpunkten.

  • Gleichwertige Alternative

    Podman steht hier anstelle von Docker zur Wahl, wenn Ihr Team bereits Podman oder Container ohne Root-Rechte nutzt; beide dienen als optionale Container-Vorbereitung.

  • Optional

    Die Kernsumme zählt nur die Kernroute. Fehlt laut Pfadfinder Linux- oder Git-Praxis, zählt die persönliche Summe diese Vorbereitung mit; Container-Vorbereitung und Vertiefung bleiben außerhalb jeder Summe.

  • Auf Anfrage

    Workshops und Prüfungsvorbereitung auf Anfrage: keine öffentlichen Termine oder Preise, außerhalb aller Summen; Umfang, Sprache, Format und Preis vereinbaren Sie nach einem Vorgespräch. Eine Anfrage ist weder Buchung noch Prüfungsanmeldung; Prüfungen buchen und bezahlen Sie separat bei der Linux Foundation.

Quellen dieser Route

Agenda · Referenz · Übungsumgebung · Prüfungsstelle · geprüft am

Methodik und Quellen ansehen

Wie wird aus der Roadmap praktische Erfahrung?

Die Roadmap ordnet Kompetenzziel und Reihenfolge; die Workshopagenda zeigt die Inhalte. In Praxisworkshops wenden Sie das Wissen im browserbasierten Dojo an. Die Teilnahmebescheinigung dokumentiert die Workshopteilnahme und ist keine Zertifizierung.

Vom Lernziel zur Anwendung

4 nachvollziehbare Schritte

  1. Kompetenzziel

    Das Lernziel beschreibt eine konkrete Tätigkeit.

  2. Workshopagenda

    Inhalte und Reihenfolge sind nachvollziehbar.

  3. Dojo-Praxis

    In Praxisworkshops wenden Sie das Wissen in Dojo-Übungen an.

  4. Transfer & Einordnung

    Die Teilnahmebescheinigung dokumentiert Teilnahme, keine Zertifizierung.

Was „abgedeckt“ bedeutet und wie wir es belegen

4 Kriterien: direkt belegt

  • Sichtbar

    Inhalte sind nachvollziehbar

    „Abgedeckt“ ist eine redaktionelle Einordnung der sichtbaren Workshopagenda, kein Nachweis geprüfter Kompetenz.

  • Geordnet

    Reihenfolge ist begründet

    Die Agenda ordnet Themen in einer nachvollziehbaren Lernfolge.

  • Angewendet

    Wissen wird praktisch angewendet

    In Praxisworkshops wenden Sie das Wissen in Übungen im browserbasierten Dojo an.

  • Abgegrenzt

    Nachweise bleiben getrennt

    Die Teilnahmebescheinigung und der Prüfungsnachweis bleiben klar voneinander getrennt.

Fachlich geprüft vom Expertenteam der DevNinjas GmbH

Quellen geprüft am

Welcher Kubernetes-Lernpfad passt zu Ihrem Ziel?

Vergleichen Sie die verwandten Pfade nach Kompetenzen und fachlichem Schwerpunkt. Prüfen Sie vor der Buchung die Voraussetzungen des jeweiligen Workshops.

Kubernetes Administrator

Für Administratoren und Betriebsteams mit Linux-Praxis: Sie üben, Kubernetes-Cluster aufzubauen, zu warten und Fehler zu beheben. Der Pfad bereitet auf die Certified Kubernetes Administrator (CKA) Prüfung vor, separat bei der Linux Foundation buchbar. Optionale Vertiefungen richten sich nach Ihrer Teamverantwortung.

  • ROLLENSPEZIFISCHE ALTERNATIVE
  • Kernroute 12 Tage
  • 4 Workshops
  • ROLLENPFAD: OPERATIONS

Passt, wenn Sie dieselbe Basis nutzen, aber einen anderen fachlichen Schwerpunkt setzen möchten.

Kernrouten im Vergleich

In beiden Kernrouten

  • Kubernetes-EinstiegEinstieg

Nur in dieser Kernroute

  • Workloads und Skalierung
  • Netzwerk, Zugriff und Betrieb
  • Software mit Helm verwalten
  • Clusterbetrieb & Troubleshooting
Zum Lernpfad Kubernetes Administrator
Alle Kubernetes-Lernpfade vergleichen

Häufige Fragen zum Kubernetes-Lernpfad

Ein Lernpfad ist eine empfohlene Reihenfolge, keine Buchungspflicht. Welche Workshops sinnvoll sind, hängt von Ihren Container-Grundlagen, Ihrer Zielrolle und vorhandener Praxiserfahrung ab. Die angezeigte Dauer und der Preis beziehen sich auf die Kernroute.

Brauche ich Helm-Vorkenntnisse für Argo CD oder Flux?

Die Workshops zu Argo CD und Flux setzen keine Vorkenntnisse in Helm oder Kustomize voraus; den nötigen Umgang lernen Sie im Workshop.

Für die Argo-CD-Schulung und die Flux-CD-Schulung brauchen Sie Kubernetes- und Git-Praxis. Die Lernpfad-Übersicht erklärt die Buchung einzelner Vorbereitungsschritte. Einen Vergleich von Argo CD und Flux bietet der GitOps-Überblick.

Kann ich ohne GitLab-Erfahrung in den GitLab-CI/CD-Workshop einsteigen?

Der GitLab-CI/CD-Workshop setzt keine GitLab-Erfahrung voraus, aber Git-Grundkenntnisse. Sie sollten mit Commits, Branches und Merges arbeiten können sowie einen Texteditor und grundlegende Linux-Befehle beherrschen.

In der GitLab-CI/CD-Einführung lernen Sie die Plattform und CI/CD kennen; vorherige CI/CD- oder Docker-Kenntnisse sind nicht erforderlich.

Wie ausführlich behandelt der GitOps-Lernpfad Canary und Blue-Green?

Der Argo-CD-Workshop enthält praktische Canary- und Blue-Green-Übungen im Cluster; der Flux-Workshop behandelt Progressive Delivery als Ausblick mit Flagger.

Die Argo-CD-Schulung hat dafür einen Praxisblock mit Argo Rollouts. Die Flux-CD-Schulung nutzt eine Beispielanwendung für den Flagger-Ausblick.

Vincent Sturm, Key Account Manager

Mit Vincent Ihre Teamroute besprechen

Mit Vincent besprechen Sie Ziele, Rollen, Zeitrahmen, Format und passende Workshopfolgen. Technische Fragen können Sie anschließend bei Bedarf mit unserem Trainerteam vertiefen.
Öffentliche Termine ansehen