[Seite 1]
Leistungsbeschreibung
Konzeption, Aufbau und Übergabe einer On-Premises-Kubernetes-Plattform
1. Gegenstand der Ausschreibung
1.1 Beschaffungsgegenstand
Gegenstand der Ausschreibung ist die Erbringung von Beratungs- und Implementierungsleistung für den Entwurf, den Aufbau und die dokumentierte Übergabe einer sicheren, produktionsreifen Kubernetes-Plattform im On- Premises-Betrieb des Auftraggebers.
Beschafft wird eine Dienstleistung (fachliche Unterstützung durch qualifiziertes Personal des Auftragnehmers). Die Beschaffung von Hard- oder Software, Lizenzen oder Betriebsmitteln ist nicht Gegenstand dieser Ausschreibung. Die Zielinfrastruktur wird vollständig durch den Auftraggeber bereitgestellt.
1.2 Leistungsumfang
Der Auftragnehmer unterstützt den Auftraggeber insbesondere bei:
• Analyse und Bewertung der bestehenden technischen und organisatorischen Ausgangssituation (Assessment) • Erarbeitung und Freigabe einer tragfähigen Zielarchitektur gemeinsam mit dem Auftraggeber • Implementierung der Plattform einschließlich Härtung nach anerkannten Best Practices und CIS-Benchmarks • Integration in das bestehende DevOps-Ökosystem (Git, CI/CD, Container Registry, Terraform, Ansible) und in die bestehende IAM-Landschaft (Keycloak) • Bewertung und Begleitung der Migration geeigneter Anwendungen • Stabilisierung (Hypercare), Betriebsvorbereitung und dokumentierte Übergabe • Wissenstransfer an das Team des Auftraggebers
1.3 Funktionale Zielvorgabe
Die konkrete technische Zielarchitektur ist nicht vorgegeben. Diese Leistungsbeschreibung ist funktional formuliert. Sie gibt Ziele, Ergebnisse und verbindliche Rahmenbedingungen vor, lässt den technischen Lösungsweg jedoch offen. Die Zielarchitektur wird durch den Auftragnehmer gemeinsam mit dem Auftraggeber in der Assessment- und Designphase erarbeitet und durch den Auftraggeber formal freigegeben.
Sofern Bestandsprodukte des Auftraggebers benannt sind, erfolgt dies ausschließlich als Interoperabilitätsanforderung. Gleichwertige Lösungen sind zugelassen. Die Auswahl weiterer Komponenten (z. B. Loadbalancer, CNI) ist Ergebnis der Designphase.
2. Projektziele
2.1 Plattformziele
Ziel ist der Aufbau einer produktionsreifen, gehärteten Kubernetes-Plattform für den On-Premises-Betrieb.
Die Plattform soll:
[Seite 2]
• containerisierte Anwendungen zuverlässig betreiben können • hochverfügbar ausgelegt sein (insbesondere ausfalltolerante Control Plane) und horizontal skalieren • mandantenfähige Nutzung mit wirksamer Trennung der Mandanten unterstützen • bestehende DevOps-Prozesse integrieren • getrennte Umgebungen für DEV, TEST und PROD abbilden • moderne Deploymentverfahren (Blue-Green-Deployment, Rolling Updates, kontrollierte Rollbacks) ermöglichen • perspektivisch auch Integration VM-basierter Workloads (z. B. mittels KubeVirt oder gleichwertig) offenhalten
2.2 Betriebsziele
Die Plattform soll einen nachhaltigen Betrieb ermöglichen durch:
• standardisierte, dokumentierte Betriebsprozesse • Automatisierung wiederkehrender Tätigkeiten (Infrastructure as Code) • reproduzierbare, nachvollziehbare Bereitstellung und Konfiguration • definierte und getestete Backup- und Restore-Verfahren • durchgängiges Monitoring, Alarmierung und zentrale Logaggregation • Wissenstransfer, der den Auftraggeber zum selbständigen Betrieb befähigt
Sicherheits- und Compliance-Ziele
Die Plattform ist unter Berücksichtigung folgender Anforderungen zu planen und umzusetzen:
• ISMS nach ISO 27001 • TISAX Assessment Level 3 relevante Anforderungen • lokale Sicherheitsrichtlinien des Auftraggebers • Security-by-Design als durchgängiges Gestaltungsprinzip • Least-Privilege-Prinzip und rollenbasierte Zugriffskontrolle • Härtung der Plattform- und Clusterkomponenten nach anerkannten Best Practices (z. B. CIS Kubernetes Benchmark oder gleichwertig) • wirksame Mandantentrennung • Auditierbarkeit und Nachvollziehbarkeit sicherheitsrelevanter Vorgänge • sichere Integration in die bestehende IAM-Landschaft (Keycloak oder gleichwertig)
Es besteht ein Verbot der Nutzung öffentlicher KI-Dienste für die Projektdurchführung (siehe auch 4.5) Details zu internen Richtlinien werden nach Auftragsvergabe zugänglich gemacht.
3. Ausgangssituation
3.1 Infrastruktur
Der Auftraggeber betreibt eine On-Premises-Infrastruktur, in die die Kubernetes-Plattform einzubetten ist. Die Zielinfrastruktur wird vollständig durch den Auftraggeber bereitgestellt. Die nachfolgenden Angaben beschreiben den derzeitigen Stand. Die verbindliche Detailaufnahme erfolgt in der Assessment-Phase
• On-Premises-Infrastruktur • physische Serversysteme als Grundlage der Virtualisierungs- und Container-Plattform • bestehende Virtualisierungsumgebungen (KVM)
[Seite 3]
• NAS-basierte Speichersysteme (NetApp mit Trident) • S3-kompatible Objektspeicherlösungen • segmentierte Netzwerkarchitektur mit internen Netzen und DMZ • bestehende Firewall-Infrastruktur mit Segmentierung
Für den Betrieb der Plattform besteht bereits Hardware für eine hochverfügbare Auslegung. Die konkrete Ausgestaltung der Control-Plane-Hochverfügbarkeit ist funktional gefordert und nicht auf ein festes Node-Setup festgelegt. Sie ist Ergebnis der Design-Phase.
3.2 Anwendungen
Die bestehende Anwendungslandschaft ist heterogen. Sie umfasst insbesondere:
• bereits containerisierte Anwendungen bzw. Docker-/Container-Workloads • auf virtuellen Maschinen betriebene Anwendungen • einzelne Legacy-Anwendungen • Anwendungen mit noch unklarer Migrationsfähigkeit
Umfang, Anzahl und Kritikalität der Anwendungen werden im Rahmen der Assessment-Phase erhoben und bewertet. Eine Migration erfolgt nur für geeignete Anwendungen und nach gemeinsamer Bewertung mit dem Auftraggeber.
Für einzelne Anwendungen ist derzeit noch offen, ob:
• eine Containerisierung sinnvoll ist, • ein Betrieb mittels Kubernetes möglich ist, • ein Betrieb mit KubeVirt oder vergleichbaren Technologien sinnvoll ist, • ein Weiterbetrieb außerhalb der Kubernetes-Plattform erforderlich bleibt, • oder eine Modernisierung bzw. Ablösung notwendig ist.
3.3 Bestehendes DevOps-Ökosystem
Der Auftraggeber betreibt ein bestehendes DevOps-Ökosystem, das zu berücksichtigen und soweit technisch sinnvoll zu integrieren ist. Ziel ist ein durchgängig automatisierter, nachvollziehbarer und weitgehend deklarativ (Infrastructure as Code, GitOps) betriebener Plattformbetrieb.
Dazu gehören insbesondere:
• Versionsverwaltung und CI/CD auf Basis von GitLab • Container Registry / Docker Registry • Terraform zur Bereitstellung von Infrastruktur • Ansible zur Konfiguration und Automatisierung
3.4 Bestehendes IAM
Der Auftraggeber betreibt eine bestehende Keycloak-Umgebung als zentrales Identity- und Access-Management, die als Grundlage für Single Sign-On (SSO) über OIDC dient.
Die Kubernetes-Plattform ist in diese IAM-Landschaft zu integrieren. Eine eigenständige, parallele Benutzerverwaltung ist zu vermeiden. Das konkrete Authentifizierungs- und Autorisierungsmodell, einschließlich
[Seite 4]
der Abbildung bestehender Rollen- und Gruppenmodelle auf die Zugriffskontrolle der Plattform, ist im Projekt zu bewerten und festzulegen.
4. Projektorganisation
4.1 Schlüsselrollen des Auftragnehmers
Der Auftragnehmer benennt mit Angebotsabgabe mindestens die folgenden zwei festen Schlüsselpersonen. Beide sind namentlich zu benennen. Ihre Qualifikationen und Projekterfahrungen sind nachzuweisen.
Lead Architect Zentraler technischer Ansprechpartner des Auftraggebers und verantwortlich für die technische Gesamtlinie.
Aufgaben und Verantwortung: • technische Gesamtarchitektur der Plattform • Moderation und Vorbereitung von Architekturentscheidungen • Erstellung von Entscheidungsvorlagen • Abstimmung mit Fachbereichen, Betrieb, Security und Netzwerkteam • Unterstützung bei der Architekturfreigabe durch den Auftraggeber • Steuerung der technischen Gesamtlinie über alle Projektphasen
Lead Engineer Verantwortlich für die technische Umsetzung der freigegebenen Architektur zusammen mit den IT-Mitarbeitenden des Auftraggebers
Aufgaben und Verantwortung: • technische Implementierung der Plattform • Automatisierung (Infrastructure as Code) • Plattformintegration (Netzwerk, Storage, IAM, Monitoring, Logging, Backup) • Unterstützung bei Migrationen • technische Dokumentation • Wissenstransfer an das IT-Teams des Auftraggebers
4.2 Ressourcenkontinuität
Die benannten Schlüsselpersonen sind grundsätzlich über die gesamte Projektlaufzeit vorzusehen.
Ein Austausch ist nur nach vorheriger Zustimmung des Auftraggebers und nur gegen eine mindestens gleichwertig qualifizierte Person zulässig. Der Auftragnehmer stellt eine angemessene Übergabe sicher, sodass kein projektrelevantes Wissen verloren geht.
4.3 Vor-Ort-Präsenz
Der Auftragnehmer stellt eine regelmäßige Vor-Ort-Präsenz beim Auftraggeber sicher.
Mindestanforderung: • durchschnittlich mindestens 2 Arbeitstage pro Woche vor Ort • die konkrete Abstimmung erfolgt mit dem Projektteam des Auftraggebers
[Seite 5]
Während der folgenden Phasen erwartet der Auftraggeber eine erhöhte Präsenz insbesondere des Lead Architects:
• Assessment • Architekturphase • Migrationsplanung • wesentliche Architektur- und Security-Workshops
4.4 Integration in agiles Projektmanagement
Die Leistungserbringung erfolgt im bestehenden agilen Projektmanagement des Auftraggebers.
Der Auftragnehmer integriert sich in die vorhandenen Prozesse und Termine, insbesondere:
• Sprint Planning • Backlog Refinement • Sprint Review • Retrospektiven • Architekturworkshops • technische Abstimmungen • Regeltermine nach Bedarf
4.5 Einsatz von KI
Die Nutzung öffentlicher KI-Dienste zur Verarbeitung von Informationen des Auftraggebers ist unzulässig. • Projektinformationen dürfen nicht in externe und nicht durch den Auftraggeber freigegebene KI-Systeme eingebracht werden. • Der Auftragnehmer hat organisatorisch sicherzustellen, dass diese Vorgabe eingehalten wird.
5. Bereitstellungen durch den Auftraggeber
Der Auftraggeber stellt dem Auftragnehmer die zur Leistungserbringung erforderlichen Mittel und Zugänge bereit.
Dazu gehören insbesondere:
• Arbeitsmittel und Endgeräte, soweit für die Leistungserbringung erforderlich • die erforderlichen technischen Zugänge und Netzwerkzugänge • die eingesetzten Projekt- und Kollaborationswerkzeuge • die gesamte Zielinfrastruktur einschließlich der Entwicklungs-, Test- und Produktivumgebungen • interne Ansprechpartner aus Netzwerk, Security, Betrieb und DevOps mit dem erforderlichen Fachwissen
Die Bereitstellung dieser Leistungen ist eine Mitwirkungspflicht des Auftraggebers. Der Auftraggeber stellt sie in dem für einen ungestörten Projektfortschritt erforderlichen Umfang und rechtzeitig zur Verfügung. Verzögerungen, die der Auftraggeber zu vertreten hat, berechtigen den Auftragnehmer zu einer angemessenen Anpassung der betroffenen Termine.