9 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Einen öffentlichen Managed Kubernetes-Cluster und einen Node-Pool von Anfang bis Ende im Data Center Designer bereitstellen, wobei Sie den Servertyp, die Version und die persistente Speicherklasse bewusst auswählen.
  • Die kubeconfig-Datei des Clusters abrufen und verwenden sowie eine IONOS CLOUD CSI-Speicherklasse für dynamisch bereitgestellte persistente Volumes definieren.
  • Ingress korrekt konzipieren, da Manifeste keinen verwalteten Load Balancer automatisch bereitstellen, indem Sie einen separat bereitgestellten Load Balancer mit einem Ingress-Controller im Cluster kombinieren.
  • Häufige Fehler bei der Bereitstellung vermeiden, insbesondere im Zusammenhang mit dem unveränderlichen Node-Pool-Typ, reservierten IPs, dem Verlust der Quell-IP und der Platzierung der Control Plane.

Einheit 6.2: Bereitstellung eines öffentlichen Clusters

Einführung

Einheit 6.1 hat die Designentscheidungen festgelegt: eine kostenlose verwaltete Steuerungsebene anstelle kostenpflichtiger Node-Pools, keine Skalierung auf null, Sicherheitsgruppen, die an die Worker-NICs und nicht an den Cluster gebunden sind, sowie die harte Tatsache, dass ein LoadBalancer-Service kein verwalteter externer Load Balancer ist. In dieser Einheit wird ein öffentlicher Cluster im Data Center Designer umgesetzt. Der Aufbau ist kurz; die entscheidenden Entscheidungen betreffen den Servertyp und die Version des Node-Pools (die Dinge festlegen, die später nicht mehr geändert werden können), die Bereitstellung des persistenten Speichers über den CSI-Treiber und den tatsächlichen Weg, über den Traffic Ihre Pods erreicht. FinCorp benötigt einen öffentlich zugänglichen Cluster, um die zustandslose API-Ebene zu hosten, die die neue KI-Funktion bedient, daher bauen wir genau das.

1. Die Entscheidungen, die der Build festlegt

Zwei im Erstellungswizard getroffene Entscheidungen sind faktisch dauerhaft. Der Node-Pool-Typ kann nach der Erstellung nicht zwischen öffentlich und privat umgestellt werden, und ein öffentlicher Node-Pool ist die Voraussetzung dafür, dass überhaupt ein LoadBalancer Service-Typ möglich ist (private Pools unterstützen ihn nicht). Die API-Ebene von FinCorp ist internetzugewandt, daher ist ein öffentlicher Pool hier korrekt; die regulierte Datenebene verbleibt auf dem privaten Cluster, der in Einheit 6.3 aufgebaut wurde.

Der Server-Typ wird pro Node-Pool aus Dedicated Core oder vCPU gewählt. Die Zuordnung der CPU-Ressourcen ist festgelegt: ein provisionierter Core entspricht zwei Managed Kubernetes CPUs. Die empfohlene Obergrenze beträgt 20 Nodes pro Node-Pool (harte Höchstgrenze 100), und ein Node trägt bis zu 110 Pods und bis zu 20 angehängte Volumes. FinCorp verwendet Dedicated Core für die API-Ebene, um einen exklusiven Core und planbare Scheduling-Eigenschaften unter Last zu erhalten.

Die Platzierung der Steuerungsebene bestimmt die Souveränität. Für einen öffentlichen Cluster läuft die von IONOS CLOUD verwaltete Steuerungsebene in Frankfurt oder in einem von drei US-Rechenzentren (Lenexa, Newark, Las Vegas); die Wahl von Frankfurt hält die Daten der Steuerungsebene in Deutschland, die einzige akzeptable Option für FinCorp nach BSI und DSGVO. Workloads und Daten der Node-Pools verbleiben unabhängig davon stets in der gewählten Kundenregion. Beachten Sie auch die ehrlichen Grenzen aus 6.1: BSI-Zertifizierungen decken die IONOS CLOUD Infrastruktur-Ebene ab, nicht die Workloads auf dem Cluster, und Kubernetes-Steuerungsereignisse fließen nicht durch den IONOS CLOUD Logging Service.

2. Persistenter Speicher über den CSI-Treiber

Das Cluster provisioniert Block Storage Volumes als Kubernetes Persistent Volumes über den IONOS CLOUD CSI-Treiber, dessen Provisioner cloud.ionos.com ist. Sie steuern die Platzierung und den Typ, indem Sie eine StorageClass definieren. Das folgende Beispiel bindet SSD-Speicher an eine Verfügbarkeitszone und aktiviert 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 eingeplant ist, sodass das Volume in derselben Zone wie der verbrauchende Knoten platziert wird. Dynamisch bereitgestellte Volumes werden vom CSI-Treiber verwaltet: Bei der Retain-Wiederaufnahmestrategie überlebt ein Volume die Löschung des PV und erscheint als verwaistes Volume im VDC. Daher ist die Wiederaufnahmestrategie eine bewusste Lifecycle-Entscheidung und kein Standardwert, der ignoriert werden kann.

3. Ingress: Es gibt keinen automatisch verwalteten Load Balancer

Dies ist die Grenze, die Teams, die von einem Hyperscaler kommen, am häufigsten überrascht. Ein Service vom Typ LoadBalancer deployt keinen echten externen Load Balancer vor dem Cluster. IONOS CLOUD weist eine statische öffentliche IP zu und ordnet sie als sekundäre IP einem einzelnen Worker-Knoten zu, der zum Ingress-Knoten wird; wenn das Ziel-Pod woanders läuft, NATet kube-proxy den Verkehr dorthin. Zwei Konsequenzen ergeben sich daraus. Die Durchsatzrate ist durch die öffentliche Obergrenze dieses einen Knotens begrenzt, sodass man mehrere IPs reserviert und sie auf mehrere Ingress-Knoten verteilt, um darüber hinaus zu skalieren (DNS-basierte Lastverteilung). Und das NAT ersetzt die Quell-IP, sodass die Client-Adresse verloren geht, es sei denn, man setzt externalTrafficPolicy: Local.

Das Produktionsmuster besteht daher darin, einen einzelnen Ingress-Controller im Cluster als LoadBalancer Service freizugeben und ihn HTTP innerhalb des Clusters routen zu lassen, anstatt jeden Anwendungsservice einzeln freizugeben. Die Ingress-IP sollte in der IP-Verwaltung außerhalb von Kubernetes reserviert werden, damit sie nicht freigegeben wird, wenn der Service gelöscht wird, und anschließend einem dedizierten Ingress-Knoten zugewiesen werden.

Wo FinCorp einen echten verwalteten Layer-7-Load Balancer vor dem Cluster benötigt, ist die Antwort ein separat bereitgestellter Managed Application Load Balancer (Einheit 3.3), nicht ein Manifest. Der ALB erfordert eine reservierte öffentliche IP, terminiert TLS (sein Listener akzeptiert genau ein Blattzertifikat, optional mit seiner CA-Kette in derselben Datei) und ist mit den Cluster-Knoten als Ziele verbunden. Nichts in einem Kubernetes-Manifest provisioniert oder konfiguriert ihn; er ist ein eigenständiges Resource, das man baut und auf die Ingress-Knoten zeigt.

DCD-Implementierung: Schritt-für-Schritt-Anleitung

Sie erstellen einen öffentlichen Managed Kubernetes-Cluster mit einem Node-Pool für Dedicated Core, rufen dessen kubeconfig ab, definieren eine CSI-Speicherklasse und setzen einen Ingress-Controller davor, der über eine reservierte IP freigegeben wird. Voraussetzung: die Create Kubernetes Clusters-Berechtigung (Vertragsinhaber, Administratoren und berechtigte Benutzer) sowie eine reservierte öffentliche IPv4 in IP Management für den Ingress-Endpunkt.

Bauziel: Einen öffentlichen Cluster von Anfang bis Ende erstellen.

Schritte (im Data Center Designer):

  1. Gehen Sie zu Menü > Container > Managed Kubernetes und wählen Sie dann + Cluster erstellen. Geben Sie einen Cluster-Namen ein, der den Benennungsregeln von Kubernetes entspricht, und wählen Sie die Kubernetes-Version. Für FinCorp wählen Sie eine in Frankfurt gehostete Steuerungsebene, um die Daten der Steuerungsebene in Deutschland zu halten.
  2. Öffnen Sie den neuen Cluster und gehen Sie zum Tab Node pools in Cluster, dann wählen Sie Node-Pool erstellen.
  3. Geben Sie in Pool-Einstellungen einen Pool-Namen ein, wählen Sie das Rechenzentrum, in dem die Nodes liegen (erstellen Sie vorher eines, falls erforderlich), wählen Sie die Node-Pool-Version und setzen Sie die Node-Anzahl.
  4. Aktivieren Sie optional Autoscale und geben Sie eine minimale und maximale Node-Anzahl an. Der Mindestwert ist ein warmer Node; es gibt keine Skalierung auf null.
  5. Setzen Sie in der Node-Vorlage Server type auf Dedicated Core (Standard) oder vCPU und wählen Sie dann Cores, RAM und Verfügbarkeitszone. Beachten Sie, dass ein provisionierter Core zwei Managed Kubernetes-CPU entspricht.
  6. Fügen Sie unter Reserved IPs die reservierte öffentliche IP hinzu, die den Ingress-Endpunkt versorgen soll, und fügen Sie alle erforderlichen privaten LANs hinzu. Provisionieren Sie den Node-Pool und warten Sie, bis die Nodes den Status ACTIVE erreichen.
  7. Rufen Sie den Zugriff ab: Laden Sie im Tab Cluster Settings die Datei kubeconfig.yaml (oder .json) herunter oder verwenden Sie die CLI: ionosctl k8s kubeconfig get --cluster-id CLUSTERID. Verweisen Sie mit kubectl auf die Datei.
  8. Wenden Sie die CSI StorageClass aus Abschnitt 2 (provisioner: cloud.ionos.com) an, deployen Sie dann einen Ingress-Controller und geben Sie nur dessen Service als Typ LoadBalancer frei, fest auf Ihre reservierte IP. Platzieren Sie Anwendungsservices hinter diesem Controller, nicht direkt im Internet.

Häufige Fehler:

  • Einen LoadBalancer-Service als verwalteten LB zu behandeln. Es handelt sich um eine statische IP für einen einzelnen Node mit kube-proxy NAT, begrenzt auf die Durchsatzleistung eines Nodes. Geben Sie nur den Ingress-Controller auf diese Weise frei; verwenden Sie einen separat provisionierten Managed ALB für echtes Layer 7 vor dem Cluster.
  • externalTrafficPolicy: Local zu vergessen, wenn die Anwendung die echte Client-IP benötigt. Der Standard-NAT-Pfad verwirft die Quelladresse.
  • Kubernetes zu erlauben, die Ingress-IP automatisch zu reservieren. Reservieren Sie sie zuerst in IP Management, damit das Löschen des Services die Adresse nicht freigibt (und Ihre DNS-Einträge nicht bricht).
  • Den falschen Node-Pool-Typ zu wählen. Öffentlich und privat können nach der Erstellung nicht umgestellt werden; ein privater Pool würde den LoadBalancer-Service überhaupt nicht unterstützen.
  • Die Steuerungsebene für einen regulierten Workload in einem Rechenzentrum in den USA zu platzieren. Wählen Sie für einen öffentlichen Cluster Frankfurt, um die Daten der Steuerungsebene in Deutschland zu halten.
  • Cluster-Logs und Ereignisse der Steuerungsebene im Logging Service zu erwarten. Ereignisse der Steuerungsebene fließen dorthin nicht; planen Sie eine separate Weiterleitung ein.

Zusammenfassung

Ein öffentlicher Managed Kubernetes-Cluster ist ein kurzer Aufbau, dessen Gewicht in einigen unwiderruflichen Entscheidungen liegt: Typ des Node-Pools und Servertyp, Platzierung der Steuerungsebene für Souveränität und wie persistente Speicherung und Ingress tatsächlich umgesetzt werden. Die Speicherung ist dynamisch über den cloud.ionos.com CSI-Treiber über eine von Ihnen definierte StorageClass; Ingress ist nicht automatisch, daher setzen Sie einen Ingress-Controller im Cluster auf einer reservierten IP vor und greifen auf einen separat bereitgestellten Managed ALB zurück, wenn Sie ein echtes verwaltetes Layer 7 benötigen. FinCorp hat nun seine öffentliche API-Ebene bereit, um sie mit der privaten Datenebene zu kombinieren, die als Nächstes aufgebaut wird.

Wichtige Punkte:

  • Ein öffentlicher Node-Pool erlaubt den Service-Typ LoadBalancer; private Pools erlauben dies nicht, und der Typ ist nach der Erstellung nicht änderbar.
  • Der IONOS CLOUD CSI-Treiber (provisioner: cloud.ionos.com) provisioniert Block Storage als Persistent Volumes; die StorageClass legt Typ, Zone, Erweiterung und Reclaim-Verhalten fest.
  • Ein LoadBalancer Service ist eine statische IP auf einem einzelnen Knoten mit kube-proxy NAT, kein verwalteter externer LB; skalieren Sie über mehrere Ingress-IPs und reservieren Sie diese außerhalb von Kubernetes.
  • Die Quell-IP geht ohne externalTrafficPolicy: Local verloren; ein separat provisionierter Managed ALB bietet echtes Layer 7 und TLS-Terminierung vor dem Cluster.
  • Wählen Sie eine Steuerungsebene in Frankfurt für öffentliche Cluster, um Steuerungsdaten in Deutschland zu halten; Steuerungsereignisse erreichen den Logging Service nicht.

Wichtige Begriffe:

  • CSI-Treiber: das Container Storage Interface-Plugin (cloud.ionos.com), das IONOS CLOUD Block Storage dynamisch als Kubernetes Persistent Volumes provisioniert.
  • Ingress-Knoten: der einzelne Worker-Knoten, der die statische IP eines LoadBalancer Services als sekundäre IP empfängt und den Verkehr über kube-proxy weiterleitet.
  • StorageClass: das Kubernetes-Objekt, das definiert, wie persistente Volumes provisioniert werden (Typ, Verfügbarkeitszone, Dateisystem, Erweiterung, Bindungsmodus).

Weitere Lektüre

  • Einheit 6.1: Kubernetes Platform Design (die Designentscheidungen, die dieser Build umsetzt)
  • Einheit 6.3: Provisioning eines privaten Clusters (die netzwerkzentrierte private Variante)
  • Einheit 3.3: Lastverteilung - Layer 7 (Anwendung) (die Managed ALB Front)