Einheit 6.1: Kubernetes Plattform-Design

Einführung

Die Entscheidung, die ein Managed Kubernetes-Design bestimmt, lautet nicht "welches Kubernetes", sondern "wo hört IONOS auf, zu verwalten, und wo fangen Sie an". IONOS führt die Steuerungsebene für Sie aus und berechnet sie nicht; Sie besitzen die Arbeitskapazität, die Lastverteilungskante, die Netzwerkrichtlinie innerhalb des Cluster und die Compliance-Postur aller Komponenten, die darauf ausgeführt werden. Die genaue Beachtung dieser Grenze ist es, was ein Design, das sich in der Produktion verhält, von einem unterscheidet, das die Bequemlichkeiten eines Hyperscalers annimmt, die die Plattform nicht bereitstellt.

Diese Einheit ist rein designorientiert. Sie etabliert die Architektur und die Kompromisse; das öffentliche Cluster wird im Data Center Designer in Einheit 6.2 und die private Variante in Einheit 6.3 aufgebaut. Lesen Sie diese Einheit für die Grenzen, dann bauen Sie gegen sie.

1. Die Gesteuerte Grenze: Kostenlosen Steuerungsebene, Bezahlt Node Pools

Managed Kubernetes ist in zwei Schichten mit unterschiedlichem Besitz, unterschiedlicher Abrechnung und unterschiedlichen SLAs strukturiert.

Die Steuerungsebene (kube-apiserver, kube-scheduler, kube-controller-manager, etcd) wird vollständig von IONOS gemanagt und ist verborgen: ihre Komponenten sind für Sie nicht sichtbar und können nicht direkt modifiziert werden, und der kube-apiserver ist nur über seine REST API erreichbar. Der Matrixwert für das Abrechnungsmodell ist einfach: die Steuerungsebene ist kostenlos. Die Qualifizierung ist wichtig und muss mit dem Anspruch verbunden werden: die Dienstschicht ist kostenlos, aber Sie zahlen immer noch für die zugrunde liegende Node-Pool-Rechenressourcen und -Speicher. Eine Aussage, dass "Managed Kubernetes kostenlos ist", ohne diese Qualifizierung, ist irreführend.

Die Node Pools sind die Arbeitskapazitäten. Ihre Server sind normale Compute Engine-Instanzen, die in Ihr Virtuelles Rechenzentrum bereitgestellt werden; innerhalb eines Node-Pools sind alle Server in ihrer Konfiguration identisch. Sie wählen den Server-Typ pro Pool aus Dedicated Core oder vCPU. Die CPU-Zuordnung ist konsistent über beide hinweg: ein bereitgestellter Kern entspricht zwei Managed Kubernetes-CPUs (zwei logische Threads pro CPU-Einheit).

Die beiden Schichten haben separate SLAs, und dies ist ein häufiger Design-Blindpunkt:

Die Steuerungs-ebene-SLA ist auf die Kubernetes API der Steuerungsebene nur beschränkt, nicht auf Ihre Workloads und nicht auf die Node-Verfügbarkeit. Die Node Pools, die auf Compute Engine basieren, erben die Compute Engine-SLA als separate, zusätzliche Verpflichtung. Das Designen für Verfügbarkeit bedeutet daher, Ihre Node Pools und Ihre Workload für Widerstandsfähigkeit zu entwerfen; die gemanagte Steuerungs-ebene-SLA erstreckt sich nicht auf eine davon.

Betrieblich hält IONOS die Steuerungsebene aktuell: unterstützte Kubernetes-Versionen sind 1.34, 1.33, 1.32 und 1.31, mit einem maximalen Minor-Version-Abstand von einem zwischen der Steuerungsebene und den Node Pools. Das CNI ist Calico, fest, mit keiner Option, ein anderes CNI zu wählen, und es ist die Grundlage für die Netzwerkpolicies, die in Abschnitt 4 diskutiert werden.

2. Node Pools als Immutable, Autoskalierende Kapazität

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

Knoten sind unveränderlich. Knoten werden nie vor Ort 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 erstellt: Ein alter Node wird durch einen neuen ersetzt. Zwei Planungsfakten ergeben sich daraus. Erstens kann eine Neu-Erstellung während der Ersetzung ein zusätzliches aktives Node hinzufügen, sodass das Server-Quoten-Vertrag headroom benötigt, oder die Neu-Erstellung stockt. Zweitens muss alles, was einen Node überleben muss, außerhalb des Node existieren: persistenter Zustand gehört auf Block Storage-persistenten Volumes über den CSI-Bereitsteller (cloud.ionos.com), niemals auf lokaler Festplatte. Das Wartungsfenster ist auf vier Stunden pro Durchlauf begrenzt; dimensionieren Sie Ihre PodDisruptionBudget und Replikazahlen so, dass eine rollierende Ersetzung nie den Workload unter den Quorum bringt.

Node Pools-Skalierung, aber keine Skalierung auf Null. Der Cluster-Autoscaler vergrößert einen Pool, wenn Pods aufgrund fehlender CPU oder Arbeitsspeicher nicht geplant werden können, und verkleinert ihn, wenn Knoten unterausgelastet sind und ihre Pods woanders verschoben werden können. Er überschreitet nicht das Maximum, das Sie festgelegt haben (noch die Vertragsquote), und kann einen Pool nicht auf Null reduzieren. Die praktische Untergrenze ist ein warmer Node: Ein Cluster, das existiert, kostet mindestens einen Node pro Pool, den Sie am Leben erhalten. Architektieren Sie die Kosten um diese Untergrenze herum, indem Sie intermittierende Workloads auf einen gemeinsamen Pool konsolidieren, anstatt viele einzelne Pools mit jeweils einem warmen Node zu behalten.

Größenbeschränkungen, um innerhalb davon zu entwerfen (empfohlene versus harte Obergrenzen sind unterschiedlich und dürfen nicht verwechselt werden):

Das Muster ist ein Node-Pool pro Workload-Klasse (zum Beispiel ein Pool für allgemeine Dienste und ein separater Pool für arbeitsspeicherintensive oder Dedicated-Core-gebundene Workloads), jeder mit seinem eigenen Autoskalierungsband, das auf einer Untergrenze von einem Node basiert.

3. Die Vier Grenzen

Dies sind die Substanz der Einheit. Jede ist ein Ort, an dem Managed Kubernetes nicht wie ein hyperscaler-gesteuerter Angebot verhält, und jede hat ein natives Muster, um es zu komponieren.

3.1 Ein LoadBalancer-Service ist ein einzelner statischer Node IP, nicht ein gemanagter Load Balancer

Dies ist die Grenze, die am ehesten zu einem Ausfall führen kann, wenn sie missverstanden wird. Die aktuelle Implementierung eines Dienstes vom Typ LoadBalancer stellt keinen wahren Load Balancer vor dem Cluster bereit. Stattdessen reserviert IONOS eine statische öffentliche IP-Adresse und weist sie als sekundäre IP einem einzelnen Worker-Node** zu, der dann als Eingangs-Node** fungiert. Wenn der Ziel-Pod nicht auf diesem Node läuft, leitet kube-proxy den Datenverkehr dorthin, wo der Pod lebt.

Drei Konsequenzen ergeben sich direkt:

• Keine Hochverfügbarkeit vom Dienst selbst. Ein Node trägt die IP. Wenn es ausfällt, ist dieser Endpunkt bis zur Neuzuweisung der IP nicht verfügbar.
• Die Quell-IP geht verloren, es sei denn, Sie setzen externalTrafficPolicy: Local, da kube-proxy den Datenverkehr leitet.
• Die Durchsatzleistung ist durch die öffentliche Schnittstelle dieses einen Node begrenzt, die bis zu 2 Gbit/s beträgt. Sie erhalten keine aggregierte Cluster-Bandbreite am Dienst-IP.

Das native Muster ist, nur den Eingangs-Controller als LoadBalancer-Dienst zu exponieren und alles andere durch Ingress im Cluster zu leiten. Um über die Obergrenze eines Node hinaus zu skalieren, reservieren Sie mehrere statische IPs und verteilen Sie sie auf mehrere Eingangs-Knoten (eine IP pro Node, verteilt durch DNS), indem Sie diese IPs außerhalb des Cluster reservieren, damit sie die Neuerstellung von Node überleben. Beachten Sie auch, dass der LoadBalancer-Diensttyp nur auf öffentlichen Node Pools unterstützt wird; private Node Pools unterstützen ihn nicht und haben keine statischen Node-IPs. Wo Sie echte gemanagte Layer-7-Routing mit TLS-Beendigung benötigen, ist das separat bereitgestellte Managed Application Load Balancer aus Modul 3, das vor dem Cluster platziert wird; es wird nicht automatisch von einem Manifest bereitgestellt. Einheit 6.2 behandelt die Verdrahtung dieses gemanagten Eingangs.

3.2 Steuerungs-Pläne-Ereignisse erreichen nicht die Logging Service

Node-Pool-Logs fließen zum IONOS-Logging Service (Export zu Object Storage wird unterstützt), aber die Ereignisse des gemanagten Steuerungs-Planes erreichen es nicht. Da der Steuerungs-Pläne verborgen und von IONOS betrieben wird, liegen seine Komponenten-Logs außerhalb Ihrer Telemetrie-Ebene. Sie werden keine kube-apiserver- oder Scheduler-Ereignisse in Ihrer Logging-Pipeline finden.

Entwerfen Sie um dies herum, indem Sie das instrumentieren, was Sie besitzen: Anwendungs- und Node-Ebene-Logs durch den internen Cluster-Logging-Stack zum Logging Service oder Object Storage, und Kubernetes API-Prüfbarkeit, die aus Ihren eigenen Ressourcen aufgebaut wird. Entwerfen Sie keine Alarm- oder Forensik-Workflows, die davon ausgehen, dass Steuerungs-Pläne-Ereignis-Logs verfügbar sind; sie sind es nicht, und Einheit 7.2 behandelt dies als eine der Plattformen festen Beobachtungslücken.

3.3 Sicherheitsgruppen können nicht auf Managed Kubernetes Worker Nodes angewendet werden

NIC-Ebene-Feuerwände und Network Security Groups können nicht auf Managed Kubernetes Worker Nodes angewendet werden: Node-Pool-Knoten sind explizit von NSG-Mitgliedschaft ausgeschlossen, und NSGs gelten ebenfalls nicht für den gemanagten Steuerungs-Pläne oder für gemanagte Lastenausgleich. Eine Sicherheitsgruppe hat keinen Angriffspunkt auf Cluster-Infrastruktur.

Das einzige Segmentierungsmechanismus, der auf der Pod- und Namespace-Ebene verfügbar ist, ist interne Cluster-Kubernetes-Netzwerkrichtlinien, die durch die feste Calico CNI durchgesetzt werden; NIC-Feuerwände und Network Security Groups sind keine Option für Node-Ebene-Perimeter-Kontrolle auf Managed Kubernetes. Der Datenverkehr zwischen Knoten und Steuerungs-Pläne ist selbst durch gegenseitige TLS gesichert, sodass Node-zu-Steuerungs-Pläne-Vertraulichkeit durch die Plattform gehandhabt wird; Ihre Aufgabe ist die Ost-West-Workload-Richtlinie innerhalb des Cluster.

3.4 Compliance-Attribution umfasst Infrastruktur, nicht Workloads

Managed Kubernetes befindet sich innerhalb des ISO 27001-Zertifikats basierend auf IT-Grundschutz (verliehen durch das BSI am 14.09.2022, deutsche Rechenzentren). Es befindet sich nicht innerhalb des BSI-C5-Attests: C5 (ein Typ-1-Testat, verliehen am 07.11.2023) umfasst Compute Engine, Cloud Cubes und S3 Object Storage, aber nicht Managed Kubernetes. Stellen Sie den Umfang genau dar und verallgemeinern Sie nie zu "die Plattform ist zertifiziert".

Der tiefere Punkt ist die Attributions-Grenze. Diese Anmeldedaten umfassen nur die IONOS-Infrastruktur-Ebene: den gemanagten Dienst, die Rechenzentren, die operativen Kontrollen. Sie bestätigen nicht Ihre Workloads. Ihre Container-Images, RBAC-Konfiguration, Netzwerkrichtlinien, Geheimnis-Handhabung und Anwendungsdaten bleiben Ihre Verantwortung und Ihre Beweise, die Sie in jedem Audit produzieren müssen. IONOS verschlüsselt Geheimnis-Daten auf REST und sichert den Node-zu-Steuerungs-Pläne-Kanal mit gegenseitiger TLS, die Infrastruktur-Kontrollen sind; die Sicherheit dessen, was im Pods läuft, ist die des Kunden. Für einen regulierten Workload ist der IT-Grundschutz-Umfang die untere Grenze der geteilten-Verantwortung-Linie, nicht die ganze Compliance-Geschichte.

4. Control-Plane-Platzierung und Souveränität

Wo die Control-Plane ausgeführt wird, ist eine Souveränitätsentscheidung und hängt von der Cluster-Art ab. Für ein öffentliches Cluster läuft die von IONOS gemanagte Control-Plane in Frankfurt oder in einem der drei US-Rechenzentren (Lenexa, Newark, Las Vegas). Für ein privates Cluster kann die Control-Plane in jedem Rechenzentrum erstellt werden, also in der vom Kunden gewählten Region.

Die Souveränität folgt der gewählten Lage. Wählen Sie die deutsche (Frankfurt) Control-Plane und die Control-Plane-Daten bleiben in Deutschland, wodurch die EU- und deutsche Souveränität erhalten bleiben. Wählen Sie eine US-Control-Plane und die Control-Plane-Metadaten befinden sich in den USA, so dass die deutsche Souveränität für diese Metadaten nicht erlangt wird. In allen Fällen bleiben die Node-Pool-Workloads und ihre Daten in der vom Kunden gewählten Region, unabhängig davon, wo die Control-Plane sitzt.

Für ein reguliertes deutsches Workload ist dies entscheidend: Ein öffentliches Cluster, das der Standardplatzierung überlassen wird, kann Control-Plane-Metadaten in einem US-Rechenzentrum platzieren, was eine US-gerichtliche Haftung mit sich bringt, obwohl die Worker-Daten niemals Deutschland verlassen. Die Designantwort besteht darin, die Control-Plane für ein öffentliches Cluster auf Frankfurt zu pinnen oder ein privates Cluster (Control-Plane in der gewählten deutschen Region) zu verwenden, wenn die Anforderung ist, dass keine Control-Plane-Metadaten das Land verlassen. Dies verbindet sich direkt mit der Souveränitätsgrundlage in Einheit 1.4: Souveränität ist eine Eigenschaft davon, wo Daten operiert werden, und wird als Filter über jede Platzierungsentscheidung, einschließlich dieser, angewendet.

Unternehmensfallstudie (FinCorp)

FinCorp, das deutsche Finanzdienstleistungsunternehmen unter GDPR und BSI-Vorschriften, baut seine Container-Plattform für die neuen künstliche-Intelligenz-nahen Dienste auf. Die oben genannten Grenzen prägen das Design.

Da das erste Cluster eine kundenorientierte API-Schnittstelle darstellt, handelt es sich um eine öffentliche Cluster, sodass die Architekten die Steuerungsebene in Frankfurt anstelle der Standardplatzierung festlegen, die Metadaten in einem US-Rechenzentrum landen lassen könnte; die Node Pools befinden sich in der deutschen Region mit den Workloads.

Sie definieren zwei Node Pools: einen Allgemeindienst-Pool (vCPU, Autoskalierung 1 bis 6) und einen Dedicated-Core-Pool für einen latenzsensiblen Dienst (Autoskalierung 1 bis 4). Beide berücksichtigen die Mindestanforderung von einem warmen Node, und FinCorp akzeptiert zwei immer-eingeschaltete Knoten als Preis für die Isolierung der beiden Workload-Klassen. Der persistente Zustand wird auf CSI-Block Storage-Volumen gespeichert, und Quoten-Kopffreiheit wird reserviert, damit ein Wartungs-Neuaufbau mit extra berechneten Node nie ins Stocken gerät.

Am Rand stellt FinCorp nur einen Ingress-Controller bereit und platziert einen separat bereitgestellten Managed Application Load Balancer davor für die Hochverfügbarkeit und TLS-Beendigung, die ein einzelner Node-Ingress-IP nicht bieten kann. Innerhalb der Cluster segmentieren Calico-Netzwerkpolicies den kundenorientierten Namensraum von internen Diensten; NIC-Ebene-Network Security Groups kann nicht auf die Worker Nodes angewendet werden, da Node-Pool-Knoten von der NSG-Mitgliedschaft ausgeschlossen sind. Für die Überwachung zeichnet FinCorp auf, dass IT-Grundschutz die Managed Kubernetes-Infrastruktur abdeckt, während seine eigenen Images, RBAC und Anwendungsdaten FinCorps Beweismittel bleiben, und es leitet Anwendungs- und Node-Protokolle an Object Storage weiter, wobei es weiß, dass Steuerungsebene-Ereignisse dort nicht erscheinen werden.

Entscheidungszusammenfassung

Zusammenfassung

Managed Kubernetes bietet Ihnen eine kostenlose, vollständig gemanagte Steuerungsebene unter ihrer eigenen 99,95% API-SLA und überlässt Ihnen die abrechnungsfähigen Node Pools (mit ihrer geerbten Compute Engine-SLA), die Lastverteilung am Rand, die Netzwerkpolicen innerhalb von Cluster, die Beobachtbarkeit dessen, was Sie ausführen, und die Compliance Ihrer Workloads. Entwerfen Sie die Node Pools als unveränderliche, autoskalierende Kapazität mit einem ein-Warm-Node-Boden und architektonieren Sie absichtlich um die vier Grenzen herum, da jede davon ein Ort ist, an dem die Annahme von Hyperscaler-Verhalten zu einem Ausfall, einem blinden Fleck oder einem fehlgeschlagenen Audit führt.

Wichtige Punkte:

• Die Steuerungsebene ist kostenlos und gemanagt unter einer 99,95% API-only-SLA; Node Pools sind abrechnungsfähige Compute Engine-Kapazitäten unter einer separaten geerbten 99,95% SLA. Behalten Sie den "Sie zahlen für die Infrastruktur"-Qualifizierer bei jedem "kostenlosen" Anspruch bei.
• Knoten sind unveränderlich und bei jedem Upgrade oder wöchentlichen Wartungslauf neu aufgebaut; behalten Sie den Zustand auf CSI-Block Storage-Volumen und behalten Sie Server-Quoten-Spielraum für den extra abrechnungsfähigen Neuaufbau-Node.
• Es gibt kein Skalieren auf Null; der autoskalierende Boden ist ein warmer Node pro Pool, daher konsolidieren Sie intermittierende Workloads anstelle von vielen einzelnen Pools.
• Ein LoadBalancer-Dienst ist ein einzelner statischer IP (nur öffentliche Pools, bis zu 2 Gbit/s, keine Hochverfügbarkeit, Quell-IP verloren ohne externalTrafficPolicy: Local); verwenden Sie einen Ingress-Controller hinter einem separat bereitgestellten Managed ALB für echtes Randverhalten.
• Steuerungsebene-Ereignisse erreichen nie die Logging Service, NIC-Ebene-Sicherheitsgruppen können nicht auf Worker Nodes angewendet werden (verwenden Sie Calico-Netzwerkpolicen für Workload-Segmentierung), und der IT-Grundschutz-Umfang umfasst die Infrastrukturschicht, nicht Ihre Workloads. C5 umfasst nicht Managed Kubernetes.
• Die Steuerungsebene-Platzierung ist Cluster-Typ-abhängig und entscheidet über die Souveränität: pinnen Sie Frankfurt (öffentlich) oder verwenden Sie ein privates Cluster in der gewählten deutschen Region, um die Steuerungsebene-Metadaten im Land zu behalten.

Wichtige Begriffe:

• Node-Pool: Eine Menge identisch konfigurierter Worker Nodes, die als Compute Engine-Instanzen in Ihr VDC bereitgestellt werden; die Einheit der Kapazität, des Server-Typs und der Autoskalierung, und unveränderlich, da Knoten ersetzt werden, anstatt gepatcht zu werden.
• Ingress-Node: Der einzelne Arbeiter-Node, an den ein LoadBalancer-Dienstes statischer IP als sekundärer IP angehängt ist; es trägt den externen Datenverkehr dieses Dienstes und kube-proxy-NATs zum Ziel-Pod.

Weiterführende Literatur

• Einheit 6.2: Bereitstellung eines öffentlichen Cluster (der Aufbau des öffentlichen Designs hier)
• Einheit 6.3: Bereitstellung eines privaten Cluster (privates Steuerungsebene, netzwerkorientiert)
• Einheit 1.4: Souveränität und Compliance als Design-Eingaben
• Einheit 7.2: Beobachtbarkeit und Betrieb (die Lücke im Kontext der Steuerungsebenen-Protokollierung)