9 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Präzise erklären, was ein privater Cluster isoliert (die Knoten-Daten-Ebene) und was er nicht (den Kubernetes-API-Endpunkt), und die API korrekt schützen.
  • Die zwei Netzwerkabhängigkeiten (ein NAT-Gateway und, für Knotenverkehr zwischen VDCs, ein Private Cross Connect) sequenzieren, die vor der Erstellung des Clusters vorhanden sein müssen.
  • Die Steuerungsebene innerhalb der Region für Souveränität platzieren und die Felder, die bei der Erstellung dauerhaft werden, begründen.
  • Einen privaten Cluster und einen privaten Knotenpool im Data Center Designer bereitstellen und das Muster des öffentlichen Clusters aus Einheit 6.2 wiederverwenden.

Einheit 6.3: Bereitstellung eines privaten Clusters

Einführung

Ein privater Cluster ist der Standard für Produktion in einem regulierten Umfeld: Die Worker Nodes verfügen über keine öffentlichen NICs, sodass die Daten-Ebene nur über das private Netzwerk erreichbar ist. Diese Isolation ist real, aber enger gefasst, als der Name vermuten lässt, und genau in diesem Unterschied liegen die typischen Problemstellen für Teams. Diese Einheit macht die Grenze transparent, stellt die Netzwerkvoraussetzungen klar, die zuerst erfüllt sein müssen, und baut anschließend die private Variante im Data Center Designer auf dem Muster des öffentlichen Clusters aus Einheit 6.2 auf.

1. Was „Private" isoliert und was nicht

Die Entscheidung für private Knotenpools gilt für den Knotenpool, nicht für den gesamten Dienst. Ein privater Knotenpool wird in einem privaten LAN hinter einem NAT-Gateway bereitgestellt: ausgehender Traffic ins Internet wird über das Gateway zugelassen, eingehender Traffic wird nicht zugelassen. Die Knoten haben keine öffentlichen Adressen, und der Traffic von Knoten zu Kubernetes-Diensten verbleibt in Ihrem privaten Netzwerk. Das ist die Isolierung der Datenebene, die FinCorp für Workloads benötigt, die unter DSGVO- und BSI-Vorgaben mit Kontodaten umgehen.

Was „private" nicht tut, ist das Verbergen des Kubernetes-API-Servers. Die Steuerungsebene wird von IONOS CLOUD verwaltet, und der API-Endpunkt bleibt unabhängig vom Typ des Knotenpools internetzugänglich. Die Annahme, ein „privater Cluster" würde auch die API durch eine Firewall absichern, ist das zentrale Missverständnis dieser Einheit. Die Plattform bietet dafür eine separate Steuerung: Der Cluster verfügt über eine IP-Zulassungsliste für die API (die Einstellung „Zugriff per IP einschränken"), sodass Sie die API schützen, indem Sie die Quellbereiche auflisten, die Zugriff darauf haben dürfen, beispielsweise die CI/CD-Ausgangs-IPs von FinCorp und der VPN-Ausgangspunkt des Betriebsteams. Die Isolierung der Knoten und die Zulassungsliste für die API sind unabhängige Entscheidungen; ein konformer privater Cluster benötigt beides.

Zwei Grenzen aus Einheit 6.1 sind hier von größerer Bedeutung. Der Service-Typ LoadBalancer ist auf privaten Knotenpools nicht verfügbar, daher entfällt das Muster mit einem einzelnen Ingress-Knoten; Ingress ist ein separat bereitgestellter Load Balancer plus ein Ingress-Controller im Cluster (das Muster aus Einheit 6.2). Und Netzwerk-Sicherheitsgruppen sind den Worker-NICs zugeordnet, nicht der Cluster-Abstraktion, daher bleiben Netzwerkrichtlinien im Cluster Ihre Steuerungsebene auf Pod-Ebene.

2. Die zwei Netzwerkabhängigkeiten (zuerst aufbauen)

Ein privater Cluster ist netzwerkzentriert: Der Dialog für die Cluster-Erstellung verlangt eine Gateway-IP, die bereits vorhanden sein muss. Daher muss das Netzwerk vor dem Cluster aufgebaut werden.

NAT Gateway für den Ausgangsverkehr. Private Nodes benötigen weiterhin ausgehenden Internetzugang für das Abrufen von Images, für Paket- und Sicherheitsupdates, für NTP und für Backup Service-Verkehr. Dieser Pfad ist das Managed NAT Gateway, das ausschließlich SNAT unterstützt: Es bietet keinen eingehenden Verkehr (kein DNAT), was genau die Eigenschaft ist, die die Daten-Ebene privat hält. Das Gateway erfordert eine reservierte öffentliche IPv4-Adresse, und diese reservierte IP wird zur Gateway-IP des Clusters. Ein entscheidendes Detail: Die Standardroute zum Gateway wird nicht automatisch injiziert. Für private VMs muss die Routing-Tabelle so angepasst werden, dass die Standardroute (oder eine dedizierte Route pro Ziel) auf das NAT Gateway zeigt. Die Integration des privaten Node-Pools regelt den Ausgangsverkehr der Nodes über das Gateway, aber die reservierte IP und die Routing-Intention liegen in Ihrer Verantwortung. Ein einzelnes NAT Gateway kann bis zu sechs private LANs bedienen.

Privater Cross Connect für Node-Verkehr zwischen VDCs. Wenn Nodes Ressourcen in einem anderen Virtuellen Rechenzentrum erreichen müssen (bei FinCorp die private Daten-Ebene aus Modul 5 in einem separaten VDC), ist dieser Ost-West-Pfad ein Private Cross Connect. Seine Einschränkungen sind Berechtigungsregeln, keine Optionen: Er ist nur innerhalb derselben Region und desselben Vertrags möglich (kein Cross-Region, kein Cross-Contract), jede NIC in jedem verbundenen VDC muss denselben IP-Bereich teilen, und jedes LAN kann nur einer Cross Connect-Verbindung zugeordnet werden. Die Bandbreite ist vergleichbar mit einer normalen privaten NIC, und er ist nicht kostenlos. Er muss vor dem Hochfahren der Node-Pools eingerichtet werden, die von der Erreichbarkeit über VDC-Grenzen abhängen, da sich diese Nodes sonst in einem Netzwerk einrichten, das ihre Abhängigkeiten nicht sehen kann.

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

Ziel der Erstellung: Erstellen der privaten Variante unter Wiederverwendung der Muster für öffentliche Cluster, beginnend mit der Netzwerkarchitektur.

Sie erstellen ein privates Cluster und einen privaten Node-Pool im Data Center Designer für die Container-Plattform von FinCorp. Dabei wird der Ablauf für öffentliche Cluster aus Einheit 6.2 wiederverwendet; die Unterschiede liegen in den Netzwerkvoraussetzungen und drei Feldern, die dauerhaft festgelegt werden. Die Schritt-für-Schritt-Anleitung für den Node-Pool selbst (Pool-Einstellungen, Node-Vorlage, Server-Typ, Speicher, zugewiesenes LAN und reservierte IPs) ist identisch mit 6.2 und wird hier nicht wiederholt.

Voraussetzungen: eine reservierte IPv4-Adresse für das NAT Gateway (DCD > Menü > Netzwerkdienste > IP-Verwaltung); ein an das private LAN angeschlossenes NAT Gateway, bei dem der Standardroute des LANs auf dieses zeigt; und, falls Nodes ein anderes VDC benötigen, ein eingerichtetes Private Cross Connect. Das VDC und seine Region werden aus früheren Modulen übernommen.

Schritte (im Data Center Designer):

  1. Reservieren Sie eine IPv4-Adresse unter Menü > Netzwerkdienste > IP-Verwaltung. Diese wird zur Gateway-IP, daher muss sie vor dem Öffnen des Cluster-Dialogs reserviert werden.
  2. Erstellen Sie das NAT Gateway: Wählen Sie das Rechenzentrum, stellen Sie sicher, dass ein privates Netzwerk mit dem Worker-LAN vorhanden ist, fügen Sie das NAT Gateway hinzu, verbinden Sie dessen Quell-Schnittstelle mit dem privaten LAN und weisen Sie die reservierte öffentliche IP im Inspector > Einstellungen-Tab zu. Setzen Sie die Standardroute des privaten LANs so, dass sie auf das Gateway zeigt.
  3. Gehen Sie zu Menü > Container > Managed Kubernetes und wählen Sie + Cluster erstellen. Geben Sie einen Namen gemäß der Kubernetes-Namenskonvention ein (maximal 63 Zeichen, alphanumerischer Anfang und Schluss).
  4. Wählen Sie die Kubernetes-Version aus dem Dropdown-Menü.
  5. Wählen Sie im Feld für den Node-Pool-Typ Privat.
  6. Wählen Sie eine Region aus dem Dropdown-Menü. Die VDCs des privaten Clusters können nur in derselben Region wie das Cluster erstellt werden, daher wird die Souveränitätsplatzierung hier nun festgelegt.
  7. Wählen Sie unter Gateway-IP die reservierte IP aus, die Ihrem NAT Gateway zugewiesen wurde.
  8. (Optional) Definieren Sie ein Subnetz für das private LAN: ein /16-CIDR, das die Pod- und Service-Netzwerke des Clusters nicht überschneiden darf (für Kubernetes 1.30 und höher: 100.96.0.0/12 und 100.64.0.0/18; für ältere Versionen: 10.208.0.0/12 und 10.233.0.0/18).
  9. Wählen Sie + Cluster erstellen. Sobald das Cluster aktiv ist, fügen Sie den privaten Node-Pool exakt wie in Einheit 6.2 hinzu: Ein Node-Pool erfordert ein Rechenzentrum am selben Ort wie das Cluster, sowie ein angeschlossenes privates LAN und reservierte IPs.
  10. Setzen Sie die IP-Allowlist der API (Zugriff nach IP einschränken) auf die Quellbereiche, die Zugriff auf die Kubernetes-API haben dürfen, und rufen Sie anschließend das kubeconfig ab, um mit kubectl zu verbinden.

Häufige Fehler:

  • „Privat" so zu behandeln, als schütze es die API. Es schützt die Nodes; die API bleibt verwaltet und über das Internet erreichbar. Die IP-Allowlist muss separat gesetzt werden, da die Steuerungsebene andernfalls für die Welt offen ist.
  • Das Cluster vor dem NAT Gateway zu erstellen. Das Feld Gateway-IP benötigt eine reservierte IP, die bereits auf einem bereitgestellten Gateway existiert.
  • Annahme, dass der Egress automatisch funktioniert. Die NAT-Standardroute wird nicht automatisch injiziert; setzen Sie die Standardroute des privaten LANs auf das Gateway, da sich sonst Image-Pulls und Updates stillschweigend als fehlgeschlagen melden.
  • Die Wahl einer US-Region für die Steuerungsebene bei einer an Souveränität gebundenen Arbeitslast. Bei einem privaten Cluster wird die Steuerungsebene im gewählten Rechenzentrum erstellt, daher ist die Regionswahl die Entscheidung zur Souveränität.
  • Verlass auf einen LoadBalancer-Service. Dieser ist auf privaten Node-Pools nicht verfügbar; verwenden Sie einen separat bereitgestellten Load Balancer sowie einen Ingress-Controller im Cluster.
  • Vergessen, dass die Felder dauerhaft sind. Region, Gateway-IP und Subnetz können nach der Bereitstellung nicht geändert werden, und der Node-Pool-Typ kann nicht zwischen privat und öffentlich umgestellt werden.

3. Platzierung und Unveränderlichkeit der Steuerungsebene

Für einen privaten Cluster wird die Steuerungsebene im von Ihnen gewählten Rechenzentrum erstellt, sodass die Metadaten der Steuerungsebene in der gewählten Region verbleiben. Die Auswahl des Standorts Deutschland (Frankfurt) stellt sicher, dass die Daten der Steuerungsebene von FinCorp in Deutschland verbleiben und die Souveränität der EU bzw. Deutschlands gewahrt bleibt; Workloads und Daten der Node-Pools verbleiben unabhängig davon immer in der gewählten Region. Dies ist der praktische Hebel hinter dem Prinzip „Souveränität als Platzierung“ aus Einheit 1.4 und unterscheidet sich von einem öffentlichen Cluster, dessen verwaltete Steuerungsebene in Frankfurt oder in einem von drei Rechenzentren in den USA ausgeführt wird.

Verschiedene Entscheidungen zum Zeitpunkt der Erstellung sind dauerhafte Designentscheidungen und keine Standardwerte der Konsole. Der Typ des Node-Pools (privat vs. öffentlich) ist nach der Erstellung unveränderlich, und die Region, die Gateway-IP und das Subnetz eines privaten Clusters können nach der Bereitstellung nicht mehr geändert werden. Sie können den Servertyp eines Node-Pools weiterhin zwischen Dedicated Core und vCPU umstellen, aber der Typ und die Netzwerkverankerung sind festgelegt. Stellen Sie sicher, dass Region und die Netzwerkvoraussetzungen vor dem Klick auf „Erstellen“ korrekt festgelegt sind; das einzige Mittel danach ist der Neuaufbau des Clusters.

Zusammenfassung

Ein privater Cluster isoliert die Knoten-Daten-Ebene hinter einem NAT Gateway mit ausschließlich SNAT, während der von IONOS CLOUD verwaltete API-Endpunkt weiterhin über das Internet erreichbar bleibt. Ein konformer Aufbau kombiniert daher private Knotenpools mit einer expliziten IP-Allowlist für die API. Der Aufbau ist netzwerkzentriert: Eine reservierte IP und ein NAT Gateway (mit festgelegter Standardroute) sowie ein Private Cross Connect in derselben Region und unter demselben Vertrag für Knotenverkehr zwischen VDCs müssen vor der Erstellung des Clusters vorhanden sein. Die Platzierung der Steuerungsebene in der gewählten deutschen Region wahrt die Souveränität. Da der Typ des Knotenpools, die Region, die Gateway-IP und das Subnetz bei der Erstellung festgelegt werden, sind die hier getroffenen Entscheidungen dauerhaft.

Wichtige Punkte:

  • Private isoliert die Knoten, nicht die API; der API-Endpunkt muss als separater, obligatorischer Schritt mit der IP-Allowlist geschützt werden.
  • Das NAT Gateway (Egress, ausschließlich SNAT, reservierte IP, manuelle Standardroute) und der Private Cross Connect (zwischen VDCs, nur in derselben Region und unter demselben Vertrag) sind Voraussetzungen und keine nachträglichen Ergänzungen.
  • Bei einem privaten Cluster befindet sich die Steuerungsebene in der gewählten Region, daher ist die Regionsauswahl die Entscheidung für die Souveränität.
  • Region, Gateway-IP, Subnetz und der Typ des Knotenpools sind nach der Erstellung nicht mehr änderbar; die Durchführung des Knotenpools selbst entspricht der Einheit 6.2.