Einheit 6.1: Design der Kubernetes-Plattform

Einführung

Die Entscheidung, die ein Managed Kubernetes-Design bestimmt, lautet nicht „Welches Kubernetes?“, sondern „Wo hört das Management durch IONOS CLOUD auf und wo beginnt Ihr Verantwortungsbereich?“. IONOS CLOUD betreibt die Steuerungsebene für Sie und berechnet dafür keine Kosten; Ihnen gehören die Worker-Kapazität, die Load-Balancing-Kante, die Netzwerkrichtlinie innerhalb des Clusters sowie der Compliance-Status aller Komponenten, die darüber ausgeführt werden. Die präzise Festlegung dieser Grenze ist der entscheidende Faktor, der ein Design, das im Produktivbetrieb zuverlässig funktioniert, von einem Design unterscheidet, das Bequemlichkeiten eines Hyperscalers voraussetzt, die die Plattform nicht bereitstellt.

Diese Einheit behandelt ausschließlich das Design. Sie legt die Architektur und die Abwägungen fest; das öffentliche Cluster wird in Einheit 6.2 im Data Center Designer erstellt und die private Variante in Einheit 6.3. Lesen Sie diese Einheit, um die Grenzen zu verstehen, und bauen Sie anschließend darauf auf.

1. Die verwaltete Grenze: Kostenlose Steuerungsebene, kostenpflichtige Node Pools

Managed Kubernetes ist als zwei Ebenen strukturiert, die unterschiedliche Zuständigkeiten, unterschiedliche Abrechnungsmodelle und unterschiedliche SLAs aufweisen.

Die Steuerungsebene (kube-apiserver, kube-scheduler, kube-controller-manager, etcd) wird vollständig von IONOS CLOUD verwaltet und ist verborgen: Ihre Komponenten sind für Sie nicht sichtbar und können nicht direkt geändert werden, und der kube-apiserver ist nur über seine REST API erreichbar. Der Matrixwert für das Abrechnungsmodell ist eindeutig: Die Steuerungsebene ist kostenlos. Die Qualifizierung ist entscheidend und muss mit der Aussage verbunden werden: Die Service-Ebene ist kostenlos, aber Sie zahlen weiterhin für die zugrunde liegende Rechenleistung und den Speicher der Node Pools. Eine Aussage, dass „Managed Kubernetes kostenlos ist“, ohne diese Qualifizierung, ist irreführend.

Die Node Pools stellen die Worker-Kapazität dar. Ihre Server sind gewöhnliche Compute Engine-Instanzen, die in Ihr virtuelles Rechenzentrum provisioniert werden; innerhalb eines Node Pools sind alle Server identisch konfiguriert. Sie wählen den Servertyp pro Pool aus Dedicated Core oder vCPU. Die CPU-Zuordnung ist in beiden Fällen konsistent: Ein provisionierter Kern entspricht zwei Managed Kubernetes CPUs (zwei logische Threads pro CPU-Einheit).

Die beiden Ebenen unterliegen separaten SLAs, und dies ist ein häufiger Design-Blindspot:

Das SLA der Steuerungsebene ist auf die Kubernetes API der Steuerungsebene beschränkt und nicht auf Ihre Workloads oder die Verfügbarkeit der Nodes. Da die Node Pools auf Compute Engine basieren, übernehmen sie das Compute Engine SLA als separate, zusätzliche Verpflichtung. Das Design für Verfügbarkeit bedeutet daher, Ihre Node Pools und Ihre Workloads für Resilienz zu gestalten; das SLA der verwalteten Steuerungsebene erstreckt sich auf keines von beiden.

Operativ hält IONOS CLOUD die Steuerungsebene aktuell: Die unterstützten Kubernetes-Versionen sind 1.34, 1.33, 1.32 und 1.31, mit einer maximalen Abweichung von einer Minor-Version zwischen der Steuerungsebene und den Node Pools. Das CNI ist Calico, festgelegt, ohne Option, ein anderes CNI zu wählen, und es ist das Fundament für die in Abschnitt 4 besprochenen Netzwerkrichtlinien.

2. Node Pools als unveränderliche, automatisch skalierende Kapazität

Ein Node Pool ist die Einheit der Kapazität und die Einheit des Lebenszyklus. Zwei Eigenschaften prägen das Design.

Nodes sind unveränderlich. Nodes werden niemals an Ort und Stelle gepatcht. Wenn ein Node Pool aktualisiert wird, sei es automatisch während des wöchentlichen Wartungsfensters oder manuell ausgelöst für eine Versionsänderung, wird jeder Node im Pool neu aufgebaut: Ein alter Node wird durch einen neuen ersetzt. Zwei planerische Tatsachen ergeben sich daraus. Erstens kann ein Neuaufbau während des Austauschs einen zusätzlichen abrechenbaren aktiven Node hinzufügen, sodass die Serverquote des Vertrags Spielraum haben muss, andernfalls stockt der Neuaufbau. Zweitens muss alles, was einen Node überleben soll, außerhalb des Nodes liegen: Persistenter Zustand gehört auf persistente Volumes von Block Storage über den CSI-Provisioner (cloud.ionos.com), niemals auf lokale Datenträger. Das Wartungsfenster ist auf vier Stunden pro Lauf begrenzt; dimensionieren Sie Ihre PodDisruptionBudget und Replikatenzahlen so, dass ein rollender Austausch die Workload nie unterhalb der Quorum-Schwelle bringt.

Node Pools skalieren automatisch, aber es gibt kein Scale-to-Zero. Der Cluster-Autoscaler vergrößert einen Pool, wenn Pods aufgrund fehlender CPU oder Arbeitsspeicher nicht eingeplant werden können, und verkleinert ihn, wenn Nodes unterausgelastet bleiben und ihre Pods an einen anderen Ort verschoben werden können. Er überschreitet nicht das von Ihnen festgelegte Maximum (noch die Vertragsquote) und kann einen Pool nicht auf null reduzieren. Der praktische Mindestwert ist ein warmer Node: Ein existierender Cluster kostet mindestens einen Node pro Pool, den Sie aktiv halten. Planen Sie Kosten um diesen Mindestwert herum, indem Sie intermittierende Workloads auf einen gemeinsamen Pool konsolidieren, anstatt viele Einzweck-Pools zu betreiben, die jeweils bei einem warmen Node feststecken.

Dimensionierungsgrenzen, innerhalb derer Sie designen sollten (empfohlene und harte Obergrenzen sind unterschiedlich und dürfen nicht verwechselt werden):

Das Muster besteht aus einem Node Pool pro Workload-Klasse (zum Beispiel ein Pool für allgemeine Dienste und ein separater Pool für arbeitspeicherintensive oder an Dedicated-Core gebundene Workloads), jeweils mit eigener automatischer Skalierungsbreite und einem Mindestwert von einem Node.

3. Die vier Grenzen

Dies sind der Kerninhalt der Einheit. Jede Grenze bezeichnet einen Bereich, in dem Managed Kubernetes sich nicht wie ein von einem Hyperscaler verwaltetes Angebot verhält, und für jede gibt es ein natives Muster, um sie zu umgehen.

3.1 Ein LoadBalancer Service ist eine statische IP auf einem einzelnen Node, kein verwalteter Load Balancer

Diese Grenze ist am ehesten der Auslöser für einen Ausfall, wenn sie missverstanden wird. Die aktuelle Implementierung eines Service vom Typ LoadBalancer setzt keinen echten Load Balancer vor dem Cluster ein. Stattdessen reserviert IONOS CLOUD eine statische öffentliche IP-Adresse und weist sie als sekundäre IP einem einzelnen Worker-Node zu, der dann als Ingress-Node fungiert. Falls das Zielpod nicht auf diesem Node läuft, NATet kube-proxy den Verkehr dorthin, wo sich das Pod befindet.

Daraus folgen unmittelbar drei Konsequenzen:

• Keine Hochverfügbarkeit durch den Service selbst. Ein Node trägt die IP. Fällt er aus, ist dieser Endpunkt down, bis die IP neu zugewiesen wird.
• Die Quell-IP geht verloren, es sei denn, Sie setzen externalTrafficPolicy: Local, da kube-proxy den Verkehr NATet.
• Die Durchsatzrate ist durch die öffentliche Schnittstelle dieses einen Nodes begrenzt, die maximal 2 Gbit/s beträgt. Sie erhalten nicht die aggregierte Cluster-Bandbreite an der Service-IP.

Das native Muster besteht darin, nur den Ingress-Controller als LoadBalancer Service freizugeben und alles andere über den Ingress innerhalb des Clusters zu leiten. Um über die Obergrenze eines einzelnen Nodes hinauszuskalieren, reservieren Sie mehrere statische IPs und verteilen sie auf mehrere Ingress-Nodes (eine IP pro Node, verteilt über DNS). Diese IPs werden außerhalb des Clusters reserviert, damit sie Node-Rebuilds überstehen. Beachten Sie auch, dass der LoadBalancer Service-Typ nur auf öffentlichen Node-Pools unterstützt wird; private Node-Pools unterstützen ihn nicht und verfügen über keine statischen Node-IPs. Wo Sie echte verwaltete Layer-7-Routing-Funktionen mit TLS-Terminierung benötigen, ist das der separat bereitgestellte Managed Application Load Balancer aus Modul 3, der vor dem Cluster platziert wird; er wird nicht automatisch aus einem Manifest bereitgestellt. Einheit 6.2 behandelt die Verdrahtung dieses verwalteten Ingress.

3.2 Steuerungsebenen-Ereignisse erreichen den Logging Service nicht

Node-Pool-Protokolle fließen in den IONOS CLOUD Logging Service (Export in Object Storage wird unterstützt), aber die Ereignisse der verwalteten Steuerungsebene nicht. Da die Steuerungsebene verborgen ist und von IONOS CLOUD betrieben wird, liegen ihre Komponentenprotokolle außerhalb Ihrer Telemetrie-Ebene. Sie werden keine kube-apiserver- oder Scheduler-Ereignisse in Ihrer Protokollierungspipeline finden.

Gestalten Sie entsprechend, indem Sie das instrumentieren, was Sie besitzen: Anwendungs- und Node-Ebene-Protokolle über den In-Cluster-Protokollierungs-Stack in den Logging Service oder Object Storage, sowie Sichtbarkeit in Kubernetes API Audits, die aus Ihren eigenen Ressourcen aufgebaut wird. Gestalten Sie keine Alarmierungs- oder Forensik-Workflows, die davon ausgehen, dass Steuerungsebenen-Ereignisprotokolle verfügbar sind; sie sind es nicht, und Einheit 7.2 behandelt dies als eine der festen Observability-Lücken der Plattform.

3.3 Security Groups können nicht auf Managed Kubernetes Worker-Nodes angewendet werden

NIC-Ebene-Firewalls und Network Security Groups können auf Managed Kubernetes Worker-Nodes überhaupt nicht angewendet werden: Node-Pool-Nodes sind ausdrücklich von der NSG-Mitgliedschaft ausgeschlossen, und NSGs gelten ebenfalls nicht für die verwaltete Steuerungsebene oder für verwaltete Load Balancer. Eine Security Group hat keinerlei Anbindungspunkt an der Cluster-Infrastruktur.

Der einzige verfügbare Segmentierungsmechanismus auf Pod- und Namespace-Ebene sind In-Cluster-Kubernetes Network Policies, erzwungen durch den festen Calico CNI; NIC-Firewalls und Network Security Groups sind für die Perimeter-Kontrolle auf Node-Ebene bei Managed Kubernetes keine Option. Der Verkehr zwischen Nodes und der Steuerungsebene wird selbst durch gegenseitiges TLS gesichert, sodass die Vertraulichkeit von Node zu Steuerungsebene von der Plattform gehandhabt wird; Ihre Aufgabe ist die Ost-West-Workload-Policy innerhalb des Clusters.

3.4 Compliance-Zuordnung umfasst die Infrastruktur, nicht die Workloads

Managed Kubernetes befindet sich im Rahmen des ISO 27001 Zertifikats basierend auf IT-Grundschutz (verliehen vom BSI am 2022-09-14, deutsche Rechenzentren). Es befindet sich nicht im Rahmen der BSI C5 Attestation: C5 (ein Type 1 Testat, verliehen am 2023-11-07) umfasst Compute Engine, Cloud Cubes und S3 Object Storage, aber nicht Managed Kubernetes. Formulieren Sie den Umfang präzise und verallgemeinern Sie niemals zu „die Plattform ist zertifiziert“.

Der tiefere Punkt ist die Zuordnungsgrenze. Diese Qualifikationen decken nur die IONOS CLOUD Infrastruktur-Ebene ab: den verwalteten Service, die Rechenzentren, die operativen Kontrollen. Sie bezeugen nicht Ihre Workloads. Ihre Container-Images, RBAC-Konfiguration, Network Policies, Secrets-Handling und Anwendungsdaten bleiben Ihre Verantwortung und Ihr Nachweis in jeder Prüfung. IONOS CLOUD verschlüsselt Secrets-Daten bei der Ruhe und sichert den Kanal von Node zu Steuerungsebene mit gegenseitigem TLS, was Infrastruktur-Kontrollen sind; die Sicherheit dessen, was in den Pods läuft, liegt beim Kunden. Für eine regulierte Workload ist der IT-Grundschutz-Umfang der Boden der geteilten Verantwortungslinie, nicht die gesamte Compliance-Geschichte.

4. Platzierung der Steuerungsebene und Souveränität

Der Ort, an dem die Steuerungsebene ausgeführt wird, ist eine Entscheidung in Bezug auf die Souveränität und ist abhängig vom Clustertyp. Bei einem öffentlichen Cluster wird die von IONOS CLOUD verwaltete Steuerungsebene in Frankfurt oder in einem der drei Rechenzentren in den USA (Lenexa, Newark, Las Vegas) ausgeführt. Bei einem privaten Cluster kann die Steuerungsebene in jedem Rechenzentrum erstellt werden, das heißt in der vom Kunden gewählten Region.

Die Souveränität folgt dem gewählten Standort. Wird die deutsche (Frankfurt) Steuerungsebene gewählt, verbleiben die Daten der Steuerungsebene in Deutschland, was die EU- und deutsche Souveränität erhält. Wird eine US-Steuerungsebene gewählt, befinden sich die Metadaten der Steuerungsebene in den USA, sodass für diese Metadaten keine deutsche Souveränität erreicht wird. In allen Fällen verbleiben die Workloads der Node-Pools und deren Daten in der vom Kunden gewählten Region, unabhängig davon, wo die Steuerungsebene platziert ist.

Für einen regulierten deutschen Workload ist dies entscheidend: Ein öffentliches Cluster, das der Standardplatzierung überlassen wird, kann Metadaten der Steuerungsebene in einem US-Rechenzentrum ablegen, was eine juristische Aussetzung in den USA mit sich bringt, obwohl die Worker-Daten Deutschland nie verlassen. Die gestalterische Antwort besteht darin, die Steuerungsebene für ein öffentliches Cluster auf Frankfurt festzulegen oder ein privates Cluster (Steuerungsebene in der gewählten deutschen Region) zu verwenden, wenn die Anforderung lautet, dass keine Metadaten der Steuerungsebene das Land verlassen dürfen. Dies steht in direktem Zusammenhang mit dem Souveränitätsfundament in Einheit 1.4: Souveränität ist eine Eigenschaft davon, wo Daten betrieben werden, und wird als Filter über jede Platzierungsentscheidung angewendet, einschließlich dieser.

Unternehmens-Fallstudie (FinCorp)

FinCorp, ein deutsches Finanzdienstleistungsunternehmen mit DSGVO- und BSI-Pflichten, richtet seine Container-Plattform für die neuen, KI-nahen Dienste ein. Die oben genannten Grenzen bestimmen das Design.

Da der erste Cluster eine kundenorientierte API bedient, handelt es sich um einen öffentlichen Cluster. Deshalb verankern die Architekten seine Steuerungsebene in Frankfurt, anstatt die Standardplatzierung zu akzeptieren, bei der Metadaten in einem US-Rechenzentrum landen könnten. Die Node-Pools befinden sich in der deutschen Region, zusammen mit den Workloads.

Sie definieren zwei Node-Pools: einen Pool für allgemeine Dienste (vCPU, Autoscaling von 1 bis 6) und einen Dedicated-Core-Pool für einen latenzsensitiven Dienst (Autoscaling von 1 bis 4). Beide erfüllen den Mindestwert von einem warmen Node. FinCorp akzeptiert zwei dauerhaft aktive Nodes als Preis für die Isolierung der beiden Workload-Klassen. Der persistente Zustand wird auf CSI Block Storage-Volumes abgelegt, und Quotenpuffer werden reserviert, damit der zusätzliche, abrechenbare Node eines Wartungsaufbaus nie zu einem Stopp führt.

Am Rand des Netzwerks stellt FinCorp nur einen Ingress-Controller bereit und platziert einen separat provisionierten Managed Application Load Balancer davor, um die Hochverfügbarkeit und TLS-Terminierung bereitzustellen, die eine einzelne Ingress-IP nicht bieten kann. Innerhalb des Clusters segmentieren Calico-Netzrichtlinien den kundenorientierten Namespace von internen Diensten. Network Security Groups auf NIC-Ebene können den Worker-Nodes überhaupt nicht zugewiesen werden, da die Nodes der Node-Pools von der NSG-Mitgliedschaft ausgeschlossen sind. Für die Auditierung dokumentiert FinCorp, dass IT-Grundschutz die Managed Kubernetes-Infrastruktur abdeckt, während die eigenen Images, RBAC und Anwendungsdaten nachweisbar von FinCorp zu erbringen sind. Es leitet Anwendungs- und Node-Logs zu Object Storage weiter, in der Kenntnis, dass Steuerungsereignisse dort nicht erscheinen.

Zusammenfassung der Entscheidungen

Zusammenfassung

Managed Kubernetes bietet eine kostenlose, vollständig verwaltete Steuerungsebene unter einem eigenen API-SLA von 99,95 % und überlässt Ihnen die Verantwortung für die abrechenbaren Node Pools (mit ihrem geerbten Compute Engine SLA), die Load-Balancing-Kante, die Netzwerkrichtlinien innerhalb des Clusters, die Observability Ihrer ausgeführten Workloads und die Compliance Ihrer Workloads. Gestalten Sie die Node Pools als unveränderliche, automatisch skalierende Kapazität mit einem Mindestwert von einem warmen Node und planen Sie bewusst um die vier Grenzen herum, denn jede einzelne ist ein Punkt, an dem die Annahme eines Hyperscaler-Verhaltens zu einem Ausfall, einer Blindstelle oder einem gescheiterten Audit führt.

Wichtige Punkte:

• Die Steuerungsebene ist kostenlos und wird unter einem reinen API-SLA von 99,95 % verwaltet; die Node Pools sind abrechenbare Compute Engine Kapazität unter einem separaten, geerbten SLA von 99,95 %. Bewahren Sie die Qualifizierung „Sie zahlen für die Infrastruktur" bei jeder Aussage über „kostenlos" bei.
• Nodes sind unveränderlich und werden bei jedem Upgrade oder wöchentlichen Wartungslauf neu aufgebaut; halten Sie den Zustand auf CSI Block Storage Volumes und halten Sie Puffer für die Server-Quoten für den zusätzlichen abrechenbaren Rebuild-Node bereit.
• Es gibt kein Scale-to-Zero; der Untergrenzwert für das automatische Skalieren ist ein warmer Node pro Pool, daher sollten Sie intermittierende Workloads konsolidieren, anstatt viele Einzweck-Pools zu betreiben.
• Ein LoadBalancer-Service ist ein statisches IP auf einem einzelnen Node (nur öffentliche Pools, bis zu 2 Gbit/s, keine HA, Quell-IP geht ohne externalTrafficPolicy: Local verloren); verwenden Sie einen Ingress-Controller hinter einem separat bereitgestellten Managed ALB für echtes Edge-Verhalten.
• Ereignisse der Steuerungsebene erreichen den Logging Service nie, NIC-Ebene-Sicherheitsgruppen können Worker Nodes überhaupt nicht zugewiesen werden (verwenden Sie Calico Netzwerkrichtlinien für die Segmentierung von Workloads), und der IT-Grundschutz-Umfang deckt die Infrastrukturschicht ab, nicht Ihre Workloads. C5 deckt Managed Kubernetes nicht ab.
• Die Platzierung der Steuerungsebene ist abhängig vom Clustertyp und bestimmt die Souveränität: Fixieren Sie Frankfurt (öffentlich) oder verwenden Sie ein privates Cluster in der gewählten deutschen Region, um Metadaten der Steuerungsebene im Land zu halten.

Wichtige Begriffe:

• Node Pool: Eine Gruppe identisch konfigurierter Worker Nodes, die als Compute Engine Instanzen in Ihr VDC bereitgestellt werden; die Einheit für Kapazität, Servertyp und automatisches Skalieren, und unveränderlich, da Nodes ersetzt und nicht gepatcht werden.
• Ingress Node: Der einzelne Worker Node, an den die statische IP eines LoadBalancer-Services als sekundäre IP angehängt wird; er trägt den externen Traffic dieses Services und kube-proxy NATet zum Ziel-Pod.

Weitere Lektüre

• Einheit 6.2: Bereitstellung eines öffentlichen Cluster (hier der Aufbau des öffentlichen Designs)
• Einheit 6.3: Bereitstellung eines privaten Cluster (private Steuerungsebene, netzwerkorientiert)
• Einheit 1.4: Souveränität und Compliance als Designeingaben
• Einheit 7.2: Observability und Betrieb (die Lücke in der Protokollierung der Steuerungsebene im Kontext)