4.1 KiB
ADR-0006 — Eine Laufzeitschicht für alle Nutzlasten; GAIA Lite wird ein Profil darauf
Stand: Angenommen, 21.08.2026 · Entscheidet: CIO Thomas Reitz
Setzt voraus: ADR-0005 (Geräteschicht aller Verkaufsvarianten)
Berührt: appliance/ADR-0014 — dort läuft alles oberhalb der Laufzeitschicht als Pod
Worum es geht
ADR-0005 hat GAIA Lite von einem Auslieferungsweg zu einer Nutzlast auf XinionOS gemacht. Sie
bringt dabei einen Plattform-Vertrag mit: k3s, containerd, Storage, Secrets, Ingress, dazu
PostgreSQL, einen Identitätsanbieter und Beobachtungswerkzeuge für die Anwendungen von OLYMPUS.
Wenige Tage später hat die Appliance dieselbe Entscheidung für sich getroffen: Auch dort läuft alles
oberhalb der Laufzeitschicht als Pod auf k3s (appliance/ADR-0014).
Damit stünden auf einem Gerät zwei k3s — eines aus GAIA Lite, eines aus der Appliance. Das ist
kein Entwurf, sondern ein Versehen, das aus zwei getrennt getroffenen Entscheidungen entstanden ist.
Genau derselbe Fall wie in ADR-0005, nur eine Schicht höher: zwei Vorhaben haben sich unabhängig
voneinander dieselbe Schicht gebaut.
Die Entscheidung
Es gibt genau eine Laufzeitschicht je Gerät. Sie heißt XinionCORE und ist Ebene 2.
Sie enthält die Grundausstattung, die jede Nutzlast braucht: k3s, containerd, Storage, Secrets, Ingress, GPU-Zuteilung. Mehr nicht.
Der Plattform-Vertrag von GAIA Lite wird zu einem Profil darauf. Wer OLYMPUS aufsetzt, schaltet zusätzlich PostgreSQL, den Identitätsanbieter und die Beobachtungswerkzeuge hinzu. XinionONE braucht diese Obermenge nicht und lässt sie weg — dieselbe Laufzeit, zwei Profile.
Der Name ist nicht neu erfunden: GAIA Lite nennt seine k3s-Knotenrollen seit jeher CORE und WRK.
XinionCORE verallgemeinert eine vorhandene Verwendung, statt eine zweite danebenzustellen.
Warum
Zwei Laufzeitschichten auf einem Blech sind zweimal derselbe Betrieb. Zwei Fassungsstände, zwei
Bauwege, zwei Sicherheitsaktualisierungen — und beim Cyber Resilience Act zwei Versorgungszusagen
für dieselbe Sache. Das ist die Begründung aus ADR-0001, angewandt auf einen dritten Fall.
Und der Selbstprüflauf müsste beide prüfen. Der Rücksprung entscheidet sich an der Frage, ob die Nutzlast hochgekommen ist. Bei zwei Laufzeitschichten wäre die Antwort teilweise — und teilweise ist bei einer A/B-Entscheidung keine Antwort.
Die Trennung in Grundausstattung und Profil ist kein Kompromiss, sondern die Einlösung dessen, was OLYMPUS selbst festgeschrieben hat: Layer 2 wird über den Plattform-Vertrag konsumiert, und welcher Träger ihn erfüllt, ist genau die Austauschbarkeit, die dort gefordert wird.
Was daraus folgt
- Was in der Wurzel liegt und was im Bestand, gilt für beide Profile gleich — Container-Abbilder in die Wurzel, Cluster-Zustand und persistente Datenträger in den Bestand. Sonst nimmt der Rücksprung die Software nicht mit.
- Der Selbstprüflauf prüft eine Laufzeitschicht, und ein k3s, das nicht hochkommt, ist ein misslungener Start — unabhängig davon, welches Profil darauf läuft.
- Die Grundausstattung ist die kleinste gemeinsame Menge. Was nur ein Profil braucht, gehört ins Profil. Bei jedem Zuwachs der Grundausstattung ist zu begründen, warum jede Nutzlast ihn braucht.
Was ausdrücklich nicht entschieden ist
- Wann der Umbau geschieht. OLYMPUS ist Konzept, die Appliance ist Konzept — hier kollidieren zwei Pläne und kein Bestand. Das ist der günstigste Zeitpunkt, den es dafür je geben wird.
- Ob GAIA Full ebenfalls so gebaut wird. Diese Entscheidung betrifft nur, was beim Kunden als Gerät steht.
- Zwei Registries und zwei Lizenzmechaniken bleiben bestehen — die von XinionONE für seine Module, die von OLYMPUS für seine Anwendungen. Sie werden nicht zusammengelegt, solange nicht jemand nachweist, dass sie dasselbe tun.
Grundlage: ADR-0001, ADR-0005 · appliance/ADR-0014 · Projekt OLYMPUS, Startseite vom
23.06.2026 · Nichts davon ist gebaut.