8 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Eine öffentliche Managed Kubernetes Cluster und Node-Pool von Anfang bis Ende im Data Center Designer bereitzustellen, wobei Sie den Server-Typ, die Version und die Klasse des persistenten Speichers bewusst wählen.
  • Die Cluster-Kubeconfig abzurufen und zu verwenden, und eine IONOS CSI-Speicherklasse für dynamisch bereitgestellte persistente Volumes zu definieren.
  • Ingress korrekt zu entwerfen, vorausgesetzt, dass Manifeste keinen gemanagten Load Balancer automatisch bereitstellen, indem Sie einen separat bereitgestellten Load Balancer mit einem Ingress-Controller innerhalb der Cluster kombinieren.
  • Gängige Bereitstellungsfehler im Zusammenhang mit unveränderlichen Node-Pool-Typen, reservierten IPs, Quell-IP-Verlust und der Platzierung der Steuerungsebene zu vermeiden.

Einheit 6.2: Bereitstellung eines öffentlichen Cluster

Einführung

Die Einheit 6.1 hat die Designentscheidungen geklärt: ein kostenloses gemanagtes Steuerungsebene über ein bezahltes Node Pools, keine Skalierbarkeit auf Null, Sicherheitsgruppen sind an die Worker-NICs und nicht an das Cluster gebunden, und die harte Wahrheit, dass ein LoadBalancer-Dienst kein gemanagter externer Load Balancer ist. Diese Einheit realisiert ein öffentliches Cluster im Data Center Designer. Der Build ist kurz, die folgenden Entscheidungen sind jedoch die Node-Pool-Server-Typ und -Version (die Dinge festlegen, die Sie später nicht mehr ändern können), wie persistenter Speicher über den CSI-Treiber bereitgestellt wird, und wie der Datenverkehr tatsächlich Ihre Pods erreicht. FinCorp benötigt ein öffentlich zugängliches Cluster, um die zustandslose API-Ebene zu hosten, die seine neue KI-Fähigkeit vorbereitet, also bauen wir genau das.

1. Die Entscheidungen der Build-Fixes

Zwei Auswahlmöglichkeiten im Create-Wizard sind effektiv permanent. Der Node-Pool-Typ kann nicht zwischen öffentlich und privat umgeschaltet werden, nachdem er erstellt wurde, und ein öffentlicher Node-Pool ist das, was einen LoadBalancer-Service-Typ überhaupt ermöglicht (private Pools unterstützen ihn nicht). FinCorps API-Tier ist internetfacing, daher ist ein öffentlicher Pool hier korrekt; das regulierte Daten-Tier bleibt auf dem privaten Cluster, das in Einheit 6.3 erstellt wurde.

Der Server-Typ wird pro Node-Pool aus Dedicated Core oder vCPU gewählt. Die CPU-Ressourcen-Zuordnung ist festgelegt: ein provisionierter Core entspricht zwei Managed Kubernetes-CPUs. Die empfohlene Obergrenze beträgt 20 Knoten pro Node-Pool (harte Obergrenze 100), und ein Node kann bis zu 110 Pods und bis zu 20 angehängte Volumes tragen. FinCorp verwendet Dedicated Core für das API-Tier, um einen exklusiven Core und eine vorhersehbare Planung unter Last zu erhalten.

Die Platzierung der Control-Plane entscheidet über die Souveränität. Für ein öffentliches Cluster läuft die von IONOS gemanagte Control-Plane in Frankfurt oder einem der drei US-Rechenzentren (Lenexa, Newark, Las Vegas); die Wahl von Frankfurt hält die Control-Plane-Daten in Deutschland, die einzige akzeptable Option für FinCorp unter BSI und GDPR. Die Node-Pool-Workloads und -Daten bleiben immer in der gewählten Kunden-Region, unabhängig davon. Beachten Sie auch die ehrlichen Grenzen aus 6.1: BSI-Atteste decken die IONOS-Infrastruktur-Ebene ab, nicht die Workloads auf dem Cluster, und Kubernetes-Control-Plane-Ereignisse fließen nicht durch die IONOS-Logging Service.

2. Persistenter Speicher durch den CSI-Treiber

Das Cluster bereitstellt Block Storage-Volumen als Kubernetes-Persistente Volumen durch den IONOS CSI-Treiber, dessen Provisionierer cloud.ionos.com ist. Sie kontrollieren die Platzierung und den Typ, indem Sie eine StorageClass definieren. Das folgende Beispiel bindet den SSD-Speicher an eine Verfügbarkeitszone und ermöglicht die Online-Erweiterung:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ionos-enterprise-ssd-zone-1
provisioner: cloud.ionos.com
parameters:
  type: SSD
  fstype: ext4
  availabilityZone: ZONE2
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

WaitForFirstConsumer verzögert die Bindung, bis ein Pod geplant ist, sodass der Volume in der gleichen Zone landet wie der konsumierende Node. Dynamisch bereitgestellte Volumes werden vom CSI-Treiber verwaltet: mit der Retain-Rückgewinnungspolitik überlebt ein Volume das Löschen von PV und erscheint als übrig gebliebener Volume im VDC, sodass die Rückgewinnungspolitik eine bewusste Entscheidung über den Lebenszyklus und nicht eine Standardvorgabe zum Ignorieren ist.

3. Ingress: Es gibt keine automatisch gemanagte Load Balancer

Dies ist die Grenze, die Teams, die von einem Hyperscaler kommen, am häufigsten überrascht. Ein Service vom Typ LoadBalancer deployt nicht einen wahren externen Load Balancer vor dem Cluster. IONOS weist eine statische öffentliche IP zu und ordnet sie als sekundäre IP einem einzelnen Worker-Node zu, der zum Ingress-Node wird. Wenn der Ziel-Pod an einem anderen Ort ausgeführt wird, leitet kube-proxy den Datenverkehr dorthin um. Zwei Konsequenzen ergeben sich daraus. Die Durchsatzleistung ist durch die öffentliche Obergrenze dieses einen Node begrenzt, sodass Sie, um darüber hinaus zu skalieren, mehrere IPs reservieren und sie über mehrere Ingress-Knoten (DNS-Lastverteilung) verteilen müssen. Und die NAT ersetzt die Quell-IP, sodass die Client-Adresse verloren geht, es sei denn, Sie setzen externalTrafficPolicy: Local.

Das Produktionsmuster besteht daher darin, einen einzelnen Ingress-Controller als LoadBalancer-Dienst zu exponieren und ihn den Datenverkehr innerhalb des Cluster routen zu lassen, anstatt jeden Anwendungs-Dienst zu exponieren. Reservieren Sie die Ingress-IP in der IP-Verwaltung außerhalb von Kubernetes, damit sie nicht freigegeben wird, wenn der Dienst gelöscht wird, und binden Sie sie an einen dedizierten Ingress-Node.

Wenn FinCorp echte gemanagte Layer 7 vor dem Cluster benötigt, lautet die Antwort ein separat bereitgestelltes Managed Application Load Balancer (Einheit 3.3) und nicht ein Manifest. Der ALB erfordert eine reservierte öffentliche IP, beendet TLS (sein Listener akzeptiert genau ein Blattzertifikat, optional mit seiner CA-Kette in der gleichen Datei) und ist mit den Cluster-Knoten als Ziele verbunden. Nichts in einem Kubernetes-Manifest stellt es bereit oder konfiguriert es. Es ist eine separate Ressource, die Sie erstellen und auf die Ingress-Knoten verweisen.

DCD Implementierung Schritt-für-Schritt

Sie werden ein öffentliches Managed Kubernetes Cluster mit einem Dedicated Core Node-Pool erstellen, dessen kubeconfig abrufen, eine CSI-Speicherklasse definieren und es mit einem Ingress-Controller verbinden, der über eine reservierte IP zugänglich ist. Voraussetzung: die Create Kubernetes Clusters-Berechtigung (Vertragsinhaber, Administratoren und berechtigte Benutzer) und eine reservierte öffentliche IPv4 in IP-Verwaltung für den Ingress-Endpunkt.

Ziel: Ein öffentliches Cluster-Ende-zu-Ende erstellen.

Schritte (im Data Center Designer):

  1. Gehen Sie zu Menü > Container > Managed Kubernetes, dann wählen Sie + Cluster erstellen. Geben Sie einen Cluster-Namen ein, der den Kubernetes-Benennungskonventionen entspricht, und wählen Sie die Kubernetes-Version. Für FinCorp wählen Sie ein Frankfurt-basiertes Steuerungsebene, um die Steuerungsebenen-Daten in Deutschland zu behalten.
  2. Öffnen Sie das neue Cluster und gehen Sie zum Tab Node Pools in Cluster, dann wählen Sie Dedicated Core Node-Pool erstellen.
  3. Im Pool-Setup geben Sie einen Pool-Namen ein, wählen Sie das Rechenzentrum, in dem die Knoten leben (erstellen Sie eines, wenn erforderlich), wählen Sie die Node-Pool-Version und setzen Sie die Node-Anzahl.
  4. Aktivieren Sie optional Autoskalierung und geben Sie eine Mindest- und Höchst-Node-Anzahl an. Die Mindestanzahl ist ein warmer Node; es gibt keine Skalierung auf Null.
  5. Im Node-Template setzen Sie Server-Typ auf Dedicated Core (Standard) oder vCPU, dann wählen Sie Kerne, RAM und Verfügbarkeitszone. Beachten Sie, dass ein bereitgestellter Kern zwei Managed Kubernetes-CPUs entspricht.
  6. Unter Reservierte IPs fügen Sie die reservierte öffentliche IP hinzu, die den Ingress-Endpunkt unterstützen wird, und binden Sie erforderliche private LANs an. Stellen Sie den Node-Pool bereit und warten Sie, bis die Knoten den Status AKTIV erreichen.
  7. Abrufen des Zugriffs: im Tab Cluster-Einstellungen laden Sie kubeconfig.yaml (oder .json) herunter oder verwenden Sie die CLI: ionosctl k8s kubeconfig get --cluster-id CLUSTERID. Richten Sie kubectl auf die Datei aus.
  8. Wenden Sie die CSI-Speicherklasse aus Abschnitt 2 (provisioner: cloud.ionos.com) an, dann deployen Sie einen Ingress-Controller und exponieren Sie nur dessen Dienst als Typ LoadBalancer, der an Ihre reservierte IP gebunden ist. Platzieren Sie Anwendungsdienste hinter diesem Controller, nicht direkt im Internet.

Häufige Fehler:

  • Ein LoadBalancer-Dienst als gemanagtes Lastenausgleichs-System behandeln. Es handelt sich um eine einzelne Node-statische IP mit kube-proxy-NAT, die auf die Durchsatzleistung eines Node beschränkt ist. Exponieren Sie nur den Ingress-Controller auf diese Weise; verwenden Sie ein separat bereitgestelltes Managed ALB für echte Layer-7 vor dem Cluster.
  • externalTrafficPolicy: Local vergessen, wenn die Anwendung die tatsächliche Client-IP benötigt. Der Standard-NAT-Pfad verwirft die Quelladresse.
  • Kubernetes-Auto-Reservierung des Ingress-IP. Reservieren Sie es in IP-Verwaltung zuerst, damit die Löschung des Dienstes die Adresse nicht freigibt (und Ihre DNS-Aufzeichnungen nicht beschädigt).
  • Auswahl des falschen Node-Pool-Typs. Öffentliche und private Pools können nach der Erstellung nicht mehr gewechselt werden; ein privater Pool würde den LoadBalancer-Dienst nicht unterstützen.
  • Platzieren der Steuerungsebene in einem US-Rechenzentrum für eine regulierte Workload. Für ein öffentliches Cluster wählen Sie Frankfurt, um die Steuerungsebenen-Daten in Deutschland zu behalten.
  • Erwarten von Cluster-Protokollen und Steuerungsebenen-Ereignissen in der Logging Service. Steuerungsebenen-Ereignisse fließen nicht dorthin; planen Sie eine separate Weiterleitung.

Zusammenfassung

Ein öffentliches Managed Kubernetes Cluster ist ein kurzer Build, dessen Gewicht in einigen unumkehrbaren Entscheidungen liegt: Node-Pool-Typ und Server-Typ, Steuerungsebene-Platzierung für die Souveränität und wie persistenter Speicher und Ingress tatsächlich realisiert werden. Der Speicher ist dynamisch durch den cloud.ionos.com CSI-Treiber über eine StorageClass, die Sie definieren, zu erreichen; Ingress ist nicht automatisch, sodass Sie den Cluster mit einem Ingress-Controller auf einem reservierten IP vorne und reichen für einen separat bereitgestellten Managed ALB, wenn Sie echten Managed Layer 7 benötigen. FinCorp hat jetzt seine öffentliche API-Ebene bereit, um mit der privaten Daten-Ebene zu komponieren, die als nächstes erstellt wird.

Wichtige Punkte:

  • Ein öffentlicher Node-Pool ermöglicht den LoadBalancer Service-Typ; private Pools tun dies nicht, und der Typ ist nach der Erstellung unveränderlich.
  • Der IONOS CSI-Treiber (provisioner: cloud.ionos.com) bereitstellt Block Storage als persistente Volumes; die StorageClass fixiert den Typ, die Zone, die Erweiterung und das Verhalten bei der Rückgewinnung.
  • Ein LoadBalancer Service ist ein einzelner Node-statischer IP mit kube-proxy NAT, nicht ein externer Lastenausgleich; skaliert über mehrere Ingress-IPs und reserviert sie außerhalb von Kubernetes.
  • Die Quell-IP geht ohne externalTrafficPolicy: Local verloren; ein separat bereitgestellter Managed ALB bietet echte Layer 7 und TLS-Beendigung vor dem Cluster.
  • Wählen Sie eine Frankfurter Steuerungsebene für öffentliche Cluster, um Steuerungsebene-Daten in Deutschland zu halten; Steuerungsebene-Ereignisse erreichen die Logging Service nicht.

Wichtige Begriffe:

  • CSI-Treiber: das Container Storage Interface-Plugin (cloud.ionos.com), das dynamisch IONOS Block Storage als Kubernetes persistente Volumes bereitstellt.
  • Ingress Node: der einzelne Arbeiter-Node, der eine LoadBalancer Service-statische IP als sekundäre IP erhält und den Datenverkehr über kube-proxy weiterleitet.
  • StorageClass: das Kubernetes-Objekt, das definiert, wie persistente Volumes bereitgestellt werden (Typ, Verfügbarkeitszone, Dateisystem, Erweiterung, Bindungsmodus).

Weitere Lektüre

  • Einheit 6.1: Kubernetes Plattform-Design (die Design-Entscheidungen, die diese Konstruktion realisiert)
  • Einheit 6.3: Bereitstellung eines privaten Cluster (die netzwerkorientierte private Variante)
  • Einheit 3.3: Lastverteilung - Schicht 7 (Anwendung) (die Managed ALB-Vorderseite)