Seminar Cloud&Heat Titan / SecuStack – Kubernetes und Yaook Lifecycle Management

Inhaltsübersicht

• Seminarprofil
• Lernziele
• Zielgruppe und Voraussetzungen
• Seminarinhalte
• Praxislabor
• Methoden und Arbeitsweise

Seminarprofil

Das Seminar vertieft Kubernetes als Orchestrierungsebene und Yaook als deklaratives Betriebsmodell für OpenStack-Dienste. Custom Resources, Reconciliation, Secrets, Zertifikate, Upgrades, Monitoring und Operator-Fehleranalyse stehen im Mittelpunkt.

Lernziele

• Kubernetes-Objekte und Controllerzustände systematisch auswerten
• Yaook-Custom-Resources und erzeugte Teilressourcen zuordnen
• Reconciliation-Prozesse ohne schädliche Direkteingriffe analysieren
• Konfiguration, Secrets und Zertifikate kontrolliert ändern
• Upgrades mit Abhängigkeiten, Barrieren und Nachtests durchführen

Zielgruppe und Voraussetzungen

Zielgruppe: Plattformadministration, Kubernetes-Betrieb, Cloud Operations, Site Reliability Engineering und technische Infrastrukturentwicklung.

Voraussetzungen: Sicherer Umgang mit Linux und grundlegende Kubernetes-Kenntnisse. OpenStack-Grundlagen werden empfohlen.

Seminarinhalte

Tag 1: Kubernetes-Basis, Konfiguration und Zertifikate

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Kubernetes-Grundlagen für den Plattformbetrieb

Kubernetes stellt die Orchestrierungsebene für die OpenStack-Kontrolldienste und die zugehörigen Operatoren bereit.

1. Schritt 1 – Objekte einordnen: Namespaces, Pods, Deployments, StatefulSets, Services, Jobs, ConfigMaps und Secrets werden nach Funktion unterschieden.
2. Schritt 2 – Zustand lesen: Desired State, aktueller Status, Conditions, Events und Controller-Verantwortung werden systematisch ausgewertet.
3. Schritt 3 – Scheduling verstehen: Node Labels, Taints, Affinitäten, Ressourcenanforderungen und PodDisruptionBudgets werden auf Platzierung und Verfügbarkeit bezogen.
4. Schritt 4 – Basisdiagnose durchführen: Podstatus, Logs, Events, Endpunkte und Ressourcenverbrauch werden in fester Reihenfolge geprüft.

Praxisbezug: Analyse einer Beispielanwendung mit Deployment, Service, ConfigMap, Secret und gestörtem Pod.

Konfiguration, Secrets und Zertifikate

Konfigurationsdaten, Geheimnisse und Zertifikate werden getrennt, versioniert und mit minimalem Zugriff verwaltet.

1. Schritt 1 – Daten klassifizieren: Öffentliche Konfiguration, vertrauliche Parameter, Passwörter, Schlüssel und Zertifikate werden eindeutig unterschieden.
2. Schritt 2 – Ablage festlegen: ConfigMaps, Kubernetes-Secrets, externe Schlüsselverwaltung und verschlüsselte Repositories werden nach Schutzbedarf gewählt.
3. Schritt 3 – Rotation planen: Gültigkeit, Erneuerung, Abhängigkeiten, Rollout und Rückfall werden für Zertifikate und Zugangsdaten festgelegt.
4. Schritt 4 – Verwendung prüfen: Mounts, Umgebungsvariablen, Dateirechte und unbeabsichtigte Ausgabe in Logs werden kontrolliert.

Praxisbezug: Planung einer Zertifikatsrotation mit betroffenen Diensten, Reihenfolge und Prüfschritten.

Monitoring-Architektur und Signalquellen

Monitoring verbindet Infrastruktur-, Kubernetes-, OpenStack- und Workload-Signale zu einer belastbaren Betriebsübersicht.

1. Schritt 1 – Signalquellen erfassen: Hardware-Sensoren, Betriebssysteme, Kubernetes, Operatoren, OpenStack-Dienste und externe Prüfungen werden inventarisiert.
2. Schritt 2 – Verantwortung zuordnen: Metriken werden einem Dienst, einer Fehlerdomäne und einem betrieblichen Eigentümer zugeordnet.
3. Schritt 3 – Erfassungswege prüfen: Exporter, ServiceMonitors, Scraping, Aufbewahrung und Zugriff werden auf Vollständigkeit und Ausfallsicherheit bewertet.
4. Schritt 4 – Lücken erkennen: Nicht überwachte Abhängigkeiten, unklare Grenzwerte und fehlende End-to-End-Prüfungen werden dokumentiert.

Praxisbezug: Erstellung einer Monitoring-Matrix für Hardware, Kubernetes, OpenStack und Beispielworkload.

Tag 2: Yaook-Operatoren und Reconciliation

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Yaook-Operatoren und deklarativer Betrieb

Yaook nutzt Kubernetes-Operatoren, um OpenStack-Dienste deklarativ bereitzustellen und fortlaufend auf den gewünschten Zustand abzugleichen.

1. Schritt 1 – Custom Resources identifizieren: Dienstspezifische Ressourcen und ihre Spezifikation werden den erzeugten Kubernetes-Objekten zugeordnet.
2. Schritt 2 – Reconciliation verfolgen: Änderung, Operator-Reaktion, erzeugte Teilressourcen und Statusbedingungen werden über mehrere Schleifen beobachtet.
3. Schritt 3 – Abhängigkeiten lesen: Datenbanken, Message Queues, Zertifikate, Secrets, Services und Jobs werden als verwaltete Teilressourcen verstanden.
4. Schritt 4 – Eingriffe begrenzen: Manuelle Änderungen an abgeleiteten Objekten werden vermieden oder als temporäre Diagnosemaßnahme klar dokumentiert.

Praxisbezug: Änderung einer Testkonfiguration über eine Custom Resource und Beobachtung der Operator-Reconciliation.

Custom Resources, Status und Reconciliation

Eine präzise Interpretation von Spec, Status und Conditions ist Voraussetzung für sichere Änderungen und zielgerichtete Fehleranalyse.

1. Schritt 1 – Spec prüfen: Gewünschte Version, Replikate, Ressourcen, Konfiguration, Zertifikate und Abhängigkeiten werden vollständig gelesen.
2. Schritt 2 – Status interpretieren: Observed Generation, Conditions, Teilressourcen und Fehlermeldungen werden dem aktuellen Änderungsstand zugeordnet.
3. Schritt 3 – Reconciliation beobachten: Events, Operator-Logs und Objektänderungen werden zeitlich korreliert, ohne den Prozess durch parallele Eingriffe zu verfälschen.
4. Schritt 4 – Stabilen Zustand bestätigen: Ready-Bedingungen, Replikatstatus, Endpunkte und Dienstfunktion werden nach Abschluss geprüft.

Praxisbezug: Auswertung einer nicht bereiten Custom Resource und Ableitung der zuerst zu prüfenden Abhängigkeit.

Operator- und Reconciliation-Fehleranalyse

Störungen werden vom Custom Resource Status über Operator-Logs bis zu abhängigen Kubernetes-Objekten eingegrenzt.

1. Schritt 1 – Fehlerbedingung sichern: Generation, Conditions, Events, Zeitstempel und letzte Konfigurationsänderung werden dokumentiert.
2. Schritt 2 – Operator-Log korrelieren: Objektname, Namespace und Reconciliation-Zeitfenster werden zur gezielten Logauswertung verwendet.
3. Schritt 3 – Teilressourcen prüfen: Jobs, Deployments, StatefulSets, Services, Secrets und Zertifikate werden auf blockierende Zustände untersucht.
4. Schritt 4 – Korrektur minimal halten: Die Ursache wird möglichst an der deklarativen Quelle behoben; direkte Änderungen an verwalteten Objekten bleiben Ausnahme.

Praxisbezug: Bearbeitung eines simulierten Operatorfehlers mit abgelaufenem Zertifikat oder fehlender Abhängigkeit.

Tag 3: Lifecycle, Upgrades und Betriebsverfahren

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Yaook-Lifecycle und kontrollierte Upgrades

Upgrades werden über deklarative Versionsänderungen gesteuert und mit Abhängigkeits-, Zustands- und Funktionstests abgesichert.

1. Schritt 1 – Kompatibilität prüfen: Zielversionen von Operatoren, OpenStack-Diensten, Kubernetes und abhängigen Komponenten werden vorab abgeglichen.
2. Schritt 2 – Änderungsreihenfolge festlegen: CRDs, Operatoren, gemeinsame Dienste und OpenStack-Komponenten werden in eine kontrollierte Upgrade-Sequenz gebracht.
3. Schritt 3 – Rollout überwachen: Conditions, Upgrade-Barrieren, Jobs, Pod-Restarts und Servicezustände werden während der Änderung beobachtet.
4. Schritt 4 – Nachprüfung durchführen: API, Authentifizierung, Netzwerk, Compute, Storage und ausgewählte Workloads werden nach dem Upgrade getestet.

Praxisbezug: Erstellung eines Upgrade-Runbooks mit Vorprüfung, Reihenfolge, Abbruchkriterien und Nachtests.

Release- und Versionsmanagement

Abhängige Versionen von Firmware, Betriebssystem, Kubernetes, Yaook und OpenStack werden als gemeinsame Plattform-Baseline verwaltet.

1. Schritt 1 – Baseline erfassen: Aktive Versionen, Build-Quellen, Konfigurationsstände und Abweichungen werden vollständig inventarisiert.
2. Schritt 2 – Zielrelease bewerten: Funktionen, Sicherheitskorrekturen, Inkompatibilitäten, Datenmigrationen und Supportzeiträume werden geprüft.
3. Schritt 3 – Freigabekette definieren: Labor, Vorproduktion, Pilot und Produktion erhalten definierte Eintritts- und Austrittskriterien.
4. Schritt 4 – Versionsnachweis pflegen: Sollstand, Iststand, Ausnahme, Frist und verantwortliche Stelle werden kontinuierlich aktualisiert.

Praxisbezug: Erstellung einer Plattform-Baseline und eines gestuften Freigabemodells.

Runbooks und Standardverfahren

Runbooks übersetzen bekannte Betriebsfälle in reproduzierbare Schritte mit Vorbedingungen, Prüfungen und Rückfall.

1. Schritt 1 – Auslöser beschreiben: Symptom, Alarm, Grenzwert oder Änderungsanlass wird eindeutig definiert.
2. Schritt 2 – Vorprüfung festlegen: Berechtigung, Ausgangszustand, betroffene Systeme, Backup und Wartungsfenster werden vor dem Eingriff geprüft.
3. Schritt 3 – Handlungsschritte ordnen: Befehle und Kontrollen werden in kleinste prüfbare Einheiten mit erwarteten Ergebnissen zerlegt.
4. Schritt 4 – Abschluss sichern: Funktionstest, Monitoring, Dokumentation, Ticketabschluss und gegebenenfalls Problem-Record werden festgelegt.

Praxisbezug: Erstellung eines Runbooks für den kontrollierten Neustart eines nicht reagierenden Plattformdienstes.

Praxislabor

• Analyse einer Beispielanwendung mit Deployment, Service, ConfigMap, Secret und gestörtem Pod.
• Erstellung einer Monitoring-Matrix für Hardware, Kubernetes, OpenStack und Beispielworkload.
• Änderung einer Testkonfiguration über eine Custom Resource und Beobachtung der Operator-Reconciliation.
• Bearbeitung eines simulierten Operatorfehlers mit abgelaufenem Zertifikat oder fehlender Abhängigkeit.
• Erstellung eines Upgrade-Runbooks mit Vorprüfung, Reihenfolge, Abbruchkriterien und Nachtests.
• Erstellung eines Runbooks für den kontrollierten Neustart eines nicht reagierenden Plattformdienstes.

Methoden und Arbeitsweise

Fachliche Einordnung, strukturierte Demonstrationen, geführte Systemübungen, technische Prüflisten und dokumentierte Störungsszenarien wechseln sich ab. Jeder Arbeitsschritt wird mit Ausgangszustand, erwarteter Wirkung, Prüfkriterium und Rückfallmöglichkeit beschrieben. Die Übungen verwenden realistische Rollen- und Fehlerbilder; produktive Zugangsdaten oder externe Verbindungen sind nicht erforderlich.