Seminar ApeiroRA – Bare Metal und IaaS mit IronCore

Seminarbeschreibung

IronCore überträgt deklarative Steuerungsmodelle auf physische Server und virtualisierte Infrastruktur. Im Seminar werden die Bare-Metal-Verwaltung und die IaaS-Ebene zunächst getrennt betrachtet und anschließend an ihren Übergängen verbunden. Damit wird erkennbar, welche Zustände von der Hardware, einem Controller oder einem Infrastrukturprovider verantwortet werden.

Die praktischen Aufgaben verfolgen den Weg von einer Ressourcenanforderung bis zur nutzbaren Maschine. Compute, Netzwerk und Storage werden mit ihren Abhängigkeiten untersucht. Besonderes Gewicht liegt auf Zustandsmeldungen, wiederholbarer Konfiguration und der Unterscheidung zwischen einer angenommenen API-Anforderung und einer tatsächlich bereitgestellten Ressource.

Der Kurs arbeitet mit einem abgegrenzten Labor und einer vorab festgelegten Komponentenfassung. Ein lokaler Demonstrationsaufbau veranschaulicht die APIs; vollständige Hypervisor-, Netzwerk- und Storage-Abläufe setzen passende Backend-Systeme voraus. Firmwareänderungen und physische Neuinstallation erfolgen ausschließlich auf dafür freigegebenen Testsystemen.

Seminarinhalte

1. Architektur und Laboraufbau

• Bare-Metal-Management, IronCore-IaaS-APIs und ausführende Provider den zuständigen Systemen und Kubernetes-Clustern zuordnen.
• Die Laborumgebung auf benötigte CRDs, Controller, Berechtigungen und erreichbare Provider prüfen.
• Ressourcenstatus, Events und Controller-Logs gemeinsam lesen und daraus einen nachvollziehbaren Prüfablauf entwickeln.

2. Hardwareverwaltung und Provisionierung

• Serverinventar, BMC-Zugriff und Redfish-basierte Steuerung in den Bereitstellungsprozess einordnen.
• Betriebssystembereitstellung und initiale Konfiguration anhand eines freigegebenen Testservers oder einer Simulation untersuchen.
• Wiederholbare Änderungen, Hardwarezustände und Abhängigkeiten zwischen Managementzugang und ausführendem Betriebssystem nachvollziehen.

3. Compute-Ressourcen und Provider

• Eine Machine-Anforderung mit zulässigen Parametern erstellen und ihre Umsetzung im konfigurierten Compute-Backend verfolgen.
• Rolle von Maschinenpools und Provider-Zuordnung sowie die Abgrenzung zwischen IronCore-API und Hypervisor verstehen.
• Fehlende Kapazität, unpassende Parameter und nicht erreichbare Backend-Dienste als unterschiedliche Fehlerklassen erkennen.

4. Netzwerk und Storage

• Netzwerkressourcen und Adressierung für einen isolierten Testworkload planen und die Ressourcenzuordnung kontrollieren.
• Ein Volume bereitstellen, einer Maschine zuordnen und die Zustandsübergänge bis zur Nutzung nachvollziehen.
• Netzwerk- und Storage-Fehler unabhängig von Compute-Problemen eingrenzen und Löschabhängigkeiten berücksichtigen.

5. Kubernetes-Anbindung und Betriebsabläufe

• Die Aufgaben von CSI, Cloud Controller Manager, Cluster API und Gardener-Integration voneinander abgrenzen.
• Änderungen an bestehenden Ressourcen mit dem vom Labor unterstützten Funktionsumfang durchführen und Rückmeldungen kontrollieren.
• Inventarisierung, Zugriffsverwaltung und Wartungsfenster in einen betrieblichen Ablauf für die Infrastruktur einbetten.

6. Fehlerwerkstatt und Wiederanlauf

• Eine unterbrochene Provider-Verbindung und eine fehlerhafte Ressourcenanforderung gezielt im Labor untersuchen.
• Wiederanlauf und erneute Abstimmung von Soll- und Ist-Zustand beobachten, ohne Zustandsdaten unkontrolliert zu überschreiben.
• Testressourcen in der richtigen Reihenfolge entfernen und den verbleibenden Infrastrukturzustand überprüfen.

Praktische Übungen

• Eine Testmaschine mit Netzwerk- und Storage-Abhängigkeiten deklarativ anfordern und die Bereitstellung vollständig verfolgen.
• Einen Hardware-Lifecycle anhand einer vorbereiteten BMC-Schnittstelle oder Simulation nachvollziehen.
• Drei vorbereitete Fehlerbilder über Events, Status und Provider-Logs eingrenzen und einen Wiederanlauf dokumentieren.

Arbeitsumgebung

Kundenseitig bereitgestelltes Kubernetes-Labor mit abgestimmten IronCore-Providern. Für echte VM-Übungen werden KVM-fähige Hosts oder geeignete Nested-Virtualisierung sowie Netzwerk- und Storage-Backends benötigt. Physische Server mit BMC/Redfish sind für reale Bare-Metal-Übungen erforderlich; ersatzweise werden diese Abläufe simuliert.