LB-02 – Managed Kubernetes

1. Leistungsgegenstand

Der Auftragnehmer betreibt für den Auftraggeber ein Managed Kubernetes Cluster auf Basis der b’nerd.cloud unter Nutzung von Gardener als Cluster-Automatisierungs- und Management-Framework.

Der Schwerpunkt dieser Leistung liegt auf:

• der Bereitstellung,

• der Überwachung

• und dem Lifecycle-Management

Diese Leistungsbeschreibung umfasst nicht die Konfiguration oder den Betrieb von Anwendungen innerhalb des Clusters.
Diese Leistungen können im Rahmen von LB-03 Managed Add-Ons und/oder LB-06 DevOps as a Service zusätzlich beauftragt werden.

1. Nutzungsvoraussetzungen

Der Auftraggeber nutzt das bereitgestellte Kubernetes-Cluster ausschließlich innerhalb des vorgesehenen Betriebs- und Supportmodells.

Konfigurationen und Komponenten der Cluster-Grundinfrastruktur, insbesondere Control Plane, etcd, Netzwerk-, Security- und Node-Konfigurationen, dürfen vom Auftraggeber nicht verändert oder ersetzt werden.

Eigene Eingriffe in Cluster-Systemkomponenten (z. B. CNI, CSI, Ingress Controller, Core-DNS, Kubelet, Runtime, Node-Images) sind ausschließlich nach vorheriger Abstimmung und schriftlicher Freigabe durch den Auftragnehmer zulässig.

1. Leistungsumfang des Auftragnehmers

Der Auftragnehmer übernimmt:

2.1 Bereitstellung & Lifecycle-Management

• Erstellung, Skalierung und Aktualisierung des Clusters über deklarative Gardener-Konfigurationen (z.B. Shoot Templates)

• Aktualisierung der Kubernetes-Version entsprechend des Gardener-Lifecycle-Plans

• Automatisierte Zertifikatsverwaltung innerhalb der Clusterkomponenten

• Monitoring des Zustands von Control Plane, Kubelet und Worker Nodes

2.2 Betriebsüberwachung & Incident Handling

• Fortlaufende Überwachung über zentrale Monitoring- und Alerting-Systeme

• Analyse und Eingrenzung von Störungen

• Einleitung von Wiederherstellungsmaßnahmen im Rahmen des SLA-Incident-Managements

2.3 Sicherheit & Compliance

Der Auftragnehmer betreibt das Kubernetes-Cluster nach dem jeweils aktuellen Stand der Technik bezüglich Betriebssicherheit,

Systemhärtung und Sicherheitsupdates auf Infrastruktur- und Cluster-Ebene. Hierzu gehören insbesondere:

• Anwendung sicherheitsrelevanter Updates für Control-Plane- und Node-Komponenten (Minor- und Patch-Level),

• Absicherung der API-Endpunkte gemäß Kubernetes Best Practices,

• Bereitstellung einer RBAC-Baseline nach dem Least-Privilege-Prinzip.

Diese Maßnahmen beziehen sich ausschließlich auf die Plattform- und Cluster-Ebene.

Die Sicherheit und Compliance der im Cluster betriebenen Anwendungen, Container-Images, Konfigurationen, Workloads, CI/CD-Pipelines, Secrets und Daten liegen im Verantwortungsbereich des Auftraggebers, sofern nicht anderweitig schriftlich vereinbart (z. B. LB-03 oder LB-05).

2.4 Keine automatische Erfüllung regulatorischer Anforderungen

Diese Leistung stellt keine automatische Erfüllung regulatorischer Anforderungen wie NIS2, KRITIS, DSGVO-Compliance auf Datenverarbeitungsebene,

PCI-DSS oder branchenspezifischer Sicherheitsstandards dar.

Die Beurteilung, Planung und Umsetzung regulatorischer Anforderungen liegt beim Auftraggeber und kann bei Bedarf als gesonderte Beratungsleistung beauftragt werden.**

2.6 Änderungen am Clusterzustand**

Änderungen am Clusterzustand erfolgen ausschließlich:

• im Rahmen definierter Change-Prozesse (Anlage CR)

• über deklarative Konfigurationen

• nicht mittels manueller Ad-hoc-Eingriffe
  (außer in Störungsszenarien gemäß SLA Incident Response)

1. Update- & Release-Management

Der Auftragnehmer stellt neue Kubernetes-Versionen und Betriebssystem-Updates entsprechend den Release- und Wartungszyklen der verwendeten Managed Kubernetes Plattform (Gardener) bereit. Das Lifecycle- und Patch-Management erfolgt automatisiert anhand der vom Plattformanbieter veröffentlichten Versionstabellen und Wartungsfenster.

1. 3.1 Minor-Releases (Patch- und Zwischenversionen)

Sicherheitsupdates sowie Patch- und Minor-Releases werden im regulären Wartungszyklus automatisiert eingespielt, um Stabilität und Sicherheit der Plattform zu gewährleisten. Während dieser Vorgänge können kurzzeitige Unterbrechungen einzelner Komponenten auftreten.

1. 3.2 Major-Releases (Versionssprünge)

Major-Versionssprünge werden vom Auftragnehmer angekündigt und erst nach Freigabe durch den Auftraggeber durchgeführt.

Der Auftragnehmer informiert über erwartbare Auswirkungen auf Workloads und Konfigurationen. Die Bewertung, Anpassung und Funktionsprüfung von Anwendungen, Deployments, Operatoren und CI/CD-Konfigurationen liegt im Verantwortungsbereich des Auftraggebers.

Sofern im Zuge eines Major-Upgrades Migrations- oder Anpassungsaufwände erforderlich werden, werden diese als gesonderte Leistungen gemäß LB-06 (DevOps as a Service) oder nach Aufwand gemäß aktueller Preisliste erbracht und abgerechnet.

1. 3.3 Version-Support & End-of-Life (EOL)

Die Unterstützung von Kubernetes- und Plattformkomponenten richtet sich nach den offiziellen Release- und EOL-Zyklen der Upstream-Projekte.

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

• Eingeschränkte Unterstützung: 12 bis 24 Monate nach Release (Mehraufwand nach Preisliste).

• Kein Support: nach Erreichen des Upstream-EOL oder älter als 24 Monate.

Erreicht eine Version das Upstream-EOL, ist der Auftraggeber verpflichtet, die Durchführung des erforderlichen Major-Upgrades zu ermöglichen.

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

1. 3.4 Pflicht zur Mitwirkung des Auftraggebers

• Der Auftraggeber ist verpflichtet, seine Deployments, Operatoren, CI/CD-Pipelines und Applikationskomponenten so zu warten, dass diese mit den jeweiligen Kubernetes-Versionen kompatibel sind.

• Wird ein notwendiges Major-Upgrade über den von Kubernetes vorgesehenen Supportzeitraum hinaus verzögert, kann der Auftragnehmer den Support für das betroffene Cluster aussetzen, bis die Aktualisierung erfolgt.

1.  **3.5 Sicherheitsrelevante Updates**

• Kritische Sicherheitsupdates (CVE) an Control Plane und Worker-Komponenten können außerplanmäßig eingespielt werden.

• Der Auftragnehmer informiert den Auftraggeber so früh wie möglich.

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 Plattform bei Standortausfall oder kritischen Störungen zu ermöglichen.

Die Wiederherstellung erfolgt:

• gemäß SLA

• in Abstimmung mit dem Auftraggeber

• ohne gewährleistete Wiederherstellungszeit (RTO) oder Datenverlustgrenze (RPO)

Diese Leistungsbeschreibung umfasst ausschließlich den Betrieb und die Wiederherstellbarkeit der Cluster-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

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

1. Bezug zur Preisübersicht

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

„Anlage – Preisliste (2026)“

1.