LB-03 – Managed Add-ons

1. Leistungsgegenstand

Der Auftragnehmer übernimmt den technischen Betrieb ausgewählter Cluster-Komponenten („Managed Add-Ons“) innerhalb eines Kubernetes-Clusters des Auftraggebers.

Diese Leistung umfasst:

• Bereitstellung und laufenden Betrieb der jeweiligen Komponente

• Monitoring und Störungsbehandlung gemäß SLA

• Einspielen sicherheitsrelevanter Patches und Minor-Upgrades

• Wiederherstellung des Funktionszustands der Komponente bei Störungen

Diese Leistung umfasst nicht:

• Applikationslogik oder Nutzungsmodelle der Komponente

• Dateninhalte, Datenhaltung oder Datenwiederherstellung

• Backup-Strategien und Restore-Durchführung (außer separat vereinbart)

• Entwicklung oder Pflege von Deployment-Konfigurationen des Auftraggebers

Kurzform: b’nerd stellt den Betrieb sicher, sofern sich der Auftraggeber an die Nutzungsvoraussetzung der technischen Systeme hält. Der Auftraggeber ist für die Nutzung verantwortlich.

1. Nutzungsvoraussetzungen

Der Auftraggeber verwendet die bereitgestellte Cloud- und Storage-Umgebung ausschließlich im vorgesehenen Betriebsmodell.

Konfigurationen oder Komponenten der zugrunde liegenden Infrastruktur (Compute-Nodes, Netzwerk, Storage-Cluster, Replikation, Images) dürfen nicht verändert oder umgangen werden.

Eigene Eingriffe in Plattformkomponenten sind ausschließlich nach vorheriger Abstimmung und Freigabe durch den Auftragnehmer zulässig.

1. Leistungsumfang

   1. 2.1 Minor-/ Patch Updates

und ohne vorherige Zustimmung des Auftraggebers eingespielt.

Sicherheitsupdates und Minor-Releases (Patch- und Maintenance-Level) werden vom Auftragnehmer automatisiert und ohne vorherige Zustimmung des Auftraggebers eingespielt, sofern dies zur Gewährleistung von Sicherheit, Stabilität oder Funktionsfähigkeit erforderlich ist.

1. 2.2 Major-Upgrades

Major-Versionssprünge (z. B. Wechsel des Kubernetes-Major-Release oder grundlegende Änderungen in Kernkomponenten) werden vom Auftragnehmer vorab angekündigt und erst nach Freigabe durch den Auftraggeber durchgeführt.

Der Auftragnehmer informiert den Auftraggeber vorab über erwartbare Auswirkungen auf Workloads, Operatoren, Deployments, Container-Images und CI/CD-Konfigurationen. Die Analyse und Anpassung dieser Komponenten liegt im Verantwortungsbereich des Auftraggebers.

Sofern im Zuge eines Major-Upgrades zusätzliche Anpassungen, Migrationsmaßnahmen oder Funktionsprüfungen erforderlich werden, werden diese als gesonderte Leistung gemäß LB-06 (DevOps as a Service) bzw. aktueller Preisliste beauftragt und nach dem dort vereinbarten Preis- und Aufwandsmodell abgerechnet.

Wird ein notwendiges Major-Upgrade nicht innerhalb eines angemessenen Zeitraums freigegeben, kann der Auftragnehmer den Support für die betroffene Version einschränken oder einstellen.

*2.3 Version-Support & End-of-Life (EOL)
*Die Unterstützung von Kubernetes- und Komponenten-Versionen und Addons richtet sich grundsätzlich nach den offiziellen Release- und End-of-Life-Zyklen des jeweiligen Herstellers oder Open-Source-Projekts (Upstream-Support).

Der Auftragnehmer unterstützt Plattform- und Komponenten-Versionen innerhalb folgender Zeiträume, sofern diese sich noch im Upstream-Support befinden:

• Reguläre Unterstützung: bis zu 12 Monate nach Release.

• Eingeschränkte Unterstützung: 12 bis 24 Monate nach Release (zusätzlicher Aufwand gemäß Preisübersicht).

• Kein Support: älter als 24 Monate oder nach Erreichen des Upstream-End-of-Life (EOL).

Erreicht eine eingesetzte Version das Upstream-End-of-Life (EOL), ist der Auftraggeber verpflichtet, die Durchführung des erforderlichen Major-Upgrades zu ermöglichen. Wird ein notwendiges Upgrade nicht freigegeben, kann der Auftragnehmer den Support für die betroffene Version einschränken oder einstellen. Eine Haftung für daraus resultierende

Sicherheits- oder Betriebsrisiken ist ausgeschlossen.

Der Betrieb von Versionen im Zeitraum „eingeschränkte Unterstützung“ sowie jeglicher Betrieb nach Upstream-EOL kann zu erhöhtem Wartungs-, Migrations- oder Anpassungsaufwand führen. Dieser Aufwand wird gemäß LB-06 (DevOps as a Service) bzw. nach Aufwand (Preisliste) abgerechnet.

Sicherheitstechnisch notwendige Upgrade müssen aus gesetzlichen Gründen durchgeführt werden.

1. Wiederherstellbarkeit / Disaster Readiness (DR-Standard)

Der Auftragnehmer hält Konfigurationen und Infrastrukturartefakte in Form von Infrastructure-as-Code / GitOps vor, um den Wiederaufbau der Addons bei Standortausfall oder kritischen Störungen zu ermöglichen.

Die Wiederherstellung erfolgt:

• gemäß SLA

• in Abstimmung mit dem Auftraggeber

• ohne garantierte Wiederherstellungszeit (RTO) oder Datenverlustgrenze (RPO)

Diese Leistungsbeschreibung umfasst ausschließlich den Betrieb und die Wiederherstellbarkeit der Addon-Konfiguration.

Die Sicherung, Wiederherstellung und Integrität von Anwendungs- und Nutzdaten sind nicht Bestandteil dieser Anlage.

Backup-, Restore- und Archivierungsleistungen ergeben sich ausschließlich aus Anlage LB-04 oder gesonderten Vereinbarungen.

1. Abgrenzung der Verantwortung

Bereich	b’nerd	Auftraggeber
Betrieb, Verfügbarkeit & Lifecycle der Komponente	✔
Monitoring & Störungshandling gemäß SLA	✔
Nutzung, Konfiguration & Einsatz im Anwendungsworkflow		✔
Datenmodelle, Queries, Inhalte, Persistenzstrategien		✔
Backup / Restore von Daten (sofern nicht LB-04)		✔

Kurzform:
Software, Daten und Workloads verbleiben im Verantwortungsbereich des Auftraggebers.
b’nerd übernimmt Betrieb, Wartung, Monitoring & Incident Response der Addons selbst.

1. Verzeichnis der Managed Addons

Eine Liste der beauftragbaren Managed Addons können der jeweils gültigen Preisliste entnommen werden.

1. Bezug zur Preisübersicht

Die Preise für Leistungen dieser Anlage ergeben sich aus:

„Anlage – Preisliste (2026)“

1.