Seminar Cloudogu EcoSystem: Intensivseminar MultiNode, Migration und Automatisierung

MultiNode erfordert die Verbindung von Kubernetes-Kompetenz und Cloudogu-spezifischer Plattformlogik. Direkte Clusteraktionen werden deshalb stets auf ihre Auswirkungen auf Dogus und gemeinsame Dienste geprüft.

Der Intensivpfad fasst die Einzelthemen MultiNode, Blueprints und Migration zusammen. Eine Testmigration verbindet Zielaufbau, Versionsgleichheit, Datentransfer, Abnahme und Rückfallplanung.

Inhaltsübersicht

1. Zielgruppe
2. Lernziele
3. Seminarinhalte
4. Praxisübungen
5. Arbeitsweise

Zielgruppe

Kubernetes-Administration, Cloudogu-Plattformbetrieb, DevOps Engineering, Infrastrukturarchitektur und Migrationsleitung

Lernziele

• Teilnehmende können eine MultiNode-Zielarchitektur planen und technisch validieren.
• Teilnehmende können Plattform und Dogus Kubernetes-gerecht betreiben und überwachen.
• Teilnehmende können Blueprints für reproduzierbare Rollouts einsetzen.
• Teilnehmende können eine Migration von CES-VM zu MultiNode testen, durchführen und abnehmen.

Seminarinhalte

1. Kubernetes-Grundlagen für den Plattformbetrieb

Nur die für den MultiNode-Betrieb erforderlichen Kubernetes-Konzepte werden vertieft. Der Schwerpunkt liegt auf Namespace, Workloads, Services, Ingress, Storage und Zuständen.

1. Cluster, Knoten, Namespace und deklarativen Sollzustand voneinander abgrenzen.
2. Pods, Deployments, Stateful Workloads, Services und Ingress im Plattformkontext zuordnen.
3. ConfigMaps, Secrets, Persistent Volumes und Storage Classes einordnen.
4. Mit kontrollierten kubectl-Abfragen Zustand und Ereignisse lesen, ohne unzulässige Änderungen vorzunehmen.

2. MultiNode-Architektur und Fehlerdomänen

Die Kubernetes-basierte Variante verteilt Plattformkomponenten und Dogus auf mehrere Knoten. Verfügbarkeit entsteht nur durch passende Infrastruktur, Speicher und Betriebsprozesse.

1. Control Plane, Worker, Plattformnamespace, Dogus und Komponenten im Zielbild eintragen.
2. Ausfall von Knoten, Netzwerk, Storage, Ingress und Identitätsdiensten getrennt bewerten.
3. Ressourcenanforderungen, Platzierungsregeln und Skalierungsgrenzen festlegen.
4. Verfügbarkeitsziel mit realistischen Wartungs- und Wiederherstellungsverfahren abgleichen.

3. Cluster-, Netzwerk- und Speicheranforderungen

Vor der Installation werden Kubernetes-Version, Namensauflösung, Zertifikate, Ingress, Storage und Zugriffskonzepte verbindlich geprüft.

1. Clusterzustand, Knotenressourcen, Zeitsynchronisation und Administrationszugang verifizieren.
2. Ingress, DNS, Load Balancing, Zertifikatsbereitstellung und ausgehende Verbindungen testen.
3. Storage Classes, Zugriffsmuster, Sicherungsfähigkeit und Kapazitätsgrenzen bewerten.
4. Abweichungen vor Installationsbeginn beseitigen und in einer Freigabecheckliste nachweisen.

4. MultiNode-Installation und Erstvalidierung

Die Plattform wird deklarativ installiert und schrittweise geprüft. Frühzeitige Validierung verhindert, dass Infrastrukturfehler erst auf Anwendungsebene sichtbar werden.

1. Zielnamespace und benötigte Plattformkomponenten nach freigegebenem Stand bereitstellen.
2. Konfiguration und Geheimnisse mit klarer Trennung zwischen Umgebung und Anwendung anlegen.
3. Dogus beziehungsweise Komponenten installieren und Rolloutzustände beobachten.
4. Ingress, Anmeldung, Persistenz, Monitoring und repräsentative Workflows vollständig testen.

5. Netzwerk, Ingress, Storage und Persistenz

Viele MultiNode-Störungen entstehen an den Grenzen zwischen Plattform und Infrastruktur. Datenpfade und Netzwerkpfade werden deshalb getrennt geprüft.

1. Anfrageweg vom Client über DNS, Load Balancer und Ingress bis zum Dogu verfolgen.
2. Interne Services, Netzwerkregeln und notwendige ausgehende Verbindungen kontrollieren.
3. Volume-Zuordnung, Zugriffsmuster, Bindung, Kapazität und Wiederanbindung prüfen.
4. Störungsszenarien für Ingress und Storage mit klaren Beobachtungspunkten nachstellen.

6. MultiNode-Betrieb, Skalierung und Wartung

Knotenwartung, Rollouts und Ressourcenänderungen werden mit den Dogu-Abhängigkeiten abgestimmt. Kubernetes-Aktionen ersetzen nicht die Plattformlogik.

1. Zustand von Plattformkomponenten, Dogus, Pods und Knoten gemeinsam bewerten.
2. Ressourcenänderungen und Skalierung mit Lastprofil und Persistenzanforderung begründen.
3. Knotenwartung, Drain, Wiederaufnahme und Funktionsprüfung als geregelten Ablauf durchführen.
4. Änderungen an Dogus möglichst über die vorgesehenen Plattformverfahren und nicht als Direktmanipulation ausführen.

7. Observability mit Monitoring und Ereignissen

Metriken, Logs, Kubernetes-Ereignisse und Plattformzustände werden zu einem Diagnosebild zusammengeführt.

1. Grafana-Dashboards und Prometheus-Signale für Knoten, Plattform und Dogus einordnen.
2. Kubernetes-Ereignisse, Pod-Zustände und Containerlogs zeitlich korrelieren.
3. Alarmgrenzen für Ressourcen, Verfügbarkeit, Neustarts und Volume-Nutzung festlegen.
4. Vom Alarm über Diagnose und Behebung bis zur Dokumentation einen vollständigen Vorfall bearbeiten.

8. Blueprints entwerfen und versionieren

Blueprints beschreiben standardisierte Tool-Sets mit definierten Dogu-Versionen. Sie werden als kontrollierte Plattformartefakte behandelt.

1. Zielgruppe, Funktionsumfang und verbindliche Dogus des Tool-Sets bestimmen.
2. Versionen, Abhängigkeiten, optionale Bestandteile und Namensräume festlegen.
3. Blueprint eindeutig versionieren und Änderungshistorie führen.
4. Freigabekriterien für technische Prüfung, Sicherheit und fachliche Abnahme definieren.

9. Rollout-Automatisierung und Variantensteuerung

Standardisierung wird mit kontrollierten Varianten verbunden. Masken, Parameter und Umgebungswerte dürfen die Nachvollziehbarkeit nicht aufheben.

1. Unveränderliche Basis und zulässige Umgebungsvarianten voneinander trennen.
2. Blueprint-Masken oder Parameter mit klarer Gültigkeit und Validierung entwerfen.
3. Test-, Abnahme- und Produktionsstufe als wiederholbaren Freigabeprozess aufbauen.
4. Rolloutnachweise, Abweichungen und Rückfallstände automatisiert dokumentieren.

10. Quellinstanz inventarisieren und Migrationsreife prüfen

Die Migration beginnt mit einem vollständigen Bild der Quellinstanz. Dogus, Versionen, Daten, Integrationen und Sonderkonfigurationen müssen bekannt sein.

1. Installierte Dogus, Versionen, Datenvolumen, Benutzerquellen und externe Integrationen erfassen.
2. Gesundheitszustand, offene Updates, Sicherungsfähigkeit und Altlasten bewerten.
3. Kompatibilität der Dogus mit der Zielplattform und notwendige Ersatzkomponenten prüfen.
4. Migrationsumfang, Ausschlüsse, Ausfallfenster und Abnahmekriterien verbindlich festlegen.

11. Zielinstanz und Versionsgleichheit herstellen

Die Zielumgebung wird vor dem Datentransfer technisch fertiggestellt. Quell- und Zielbestand werden kontrolliert angeglichen.

1. MultiNode-Ziel gemäß Cluster-, Netzwerk-, Storage- und Sicherheitsvorgaben installieren.
2. Benötigte Dogus und Komponenten in kompatiblen Versionen bereitstellen.
3. Zielkonfiguration, Geheimnisse, Mailzugang und Migrationszugriffe vorbereiten.
4. Gleichheit und bekannte Ausnahmen mit einer maschinenlesbaren und einer fachlichen Liste nachweisen.

12. Testmigration, Cutover und Datentransfer

Mindestens eine vollständige Testmigration dient der Zeitmessung und Fehlerbereinigung. Der produktive Cutover folgt einem freigegebenen Ablaufplan.

1. Importer und erforderliche Geheimnisse im Ziel kontrolliert einrichten.
2. Testlauf durchführen, Laufzeiten messen und Fehlermeldungen bis zur Ursache bearbeiten.
3. Produktiven Freeze auslösen, letzte Sicherung erstellen und Datenübertragung starten.
4. Fortschritt überwachen, Abbruchkriterien beachten und Umschaltentscheidung dokumentieren.

13. Abnahme, Rückfall und Nacharbeiten

Nach dem Datentransfer werden technische und fachliche Funktionen geprüft. Die Quelle bleibt bis zur formalen Abnahme unverändert verfügbar.

1. Anmeldung, Rollen, Dogu-Daten, Repositories, Jobs, Artefakte und Integrationen prüfen.
2. Datenmengen, Stichproben und Protokolle zwischen Quelle und Ziel vergleichen.
3. Bei Abnahmekriterien außerhalb der Toleranz den vorbereiteten Rückfall auslösen.
4. Nach Freigabe DNS beziehungsweise Zugangsweg umstellen, Monitoring schärfen und Quelle kontrolliert stilllegen.

14. Sicherungsumfang, Ziele und Richtlinien

Ein Plattformbackup umfasst mehr als Anwendungsdateien. Dogu-Daten, Metadaten, Instanzkonfiguration und Registry-Inhalte werden gemeinsam betrachtet.

1. Schutzbedarf, Wiederanlaufzeit und maximal tolerierbaren Datenverlust festlegen.
2. Zu sichernde Datenbereiche und ausgeschlossene temporäre Daten dokumentieren.
3. Externes Sicherungsziel, Verschlüsselung, Aufbewahrung und Löschfristen bestimmen.
4. Sicherungsrichtlinie mit Zeitplan, Verantwortlichkeit und Prüfverfahren freigeben.

15. Schutzbedarf, Bedrohungen und Sicherheitszonen

Sicherheit wird von Daten und Geschäftsprozessen aus geplant. Plattformdienste, Dogus und Verwaltungszugänge erhalten getrennte Schutzmaßnahmen.

1. Datenarten, Kritikalität, regulatorische Vorgaben und Angreifermodelle erfassen.
2. Vertrauensgrenzen zwischen Nutzenden, Administration, Dogus und Infrastruktur markieren.
3. Schutzmaßnahmen für Identitäten, Netzwerk, Daten, Updates und Protokolle zuordnen.
4. Restrisiken, Verantwortliche und Prüffrequenzen in einem Sicherheitskonzept festhalten.

Praxisübungen

• Entwurf und Review einer MultiNode-Referenzarchitektur
• Diagnose von Ingress-, Pod- und Volume-Störungen
• Erstellung eines versionierten Blueprint-Rollouts
• Durchführung einer vollständigen Testmigration
• Abnahme mit technischen und fachlichen Prüfkriterien

Arbeitsweise

Ein durchgängiges Labor verbindet Clusterprüfung, Plattforminstallation, Rollout und Migration. Jede Phase endet mit einer formalen Abnahme.