8 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Genau zu erklären, was ein privater Cluster isoliert (die Node-Daten-Ebene) und was nicht (den Kubernetes-API-Endpunkt), und den API korrekt schützen.
  • Die zwei Netzwerkabhängigkeiten (ein NAT-Gateway und, für den cross-VDC-Node-Verkehr, ein privates Cross Connect) zu sequenzieren, die vor der Erstellung des Cluster existieren müssen.
  • Die Steuerungsebene in der Region für die Datensouveränität zu platzieren und über die Felder nachzudenken, die bei der Erstellung permanent werden.
  • Einen privaten Cluster und einen privaten Node-Pool im Data Center Designer bereitzustellen, wobei das Muster des öffentlichen Cluster aus Einheit 6.2 wiederverwendet wird.

Einheit 6.3: Bereitstellung eines privaten Cluster

Einführung

Ein privates Cluster ist der Produktionsstandard für ein reguliertes Anwesen: Worker Nodes haben keine öffentlichen Netzwerk-Schnittstellen, sodass die Daten-Ebene nur über Ihr privates Netzwerk erreichbar ist. Diese Isolation ist real, aber enger als der Name vermuten lässt, und der Unterschied liegt darin, wo Teams Probleme bekommen. Diese Einheit macht die Grenze ehrlich, behebt die Netzwerk-Voraussetzungen, die zuerst existieren müssen, und baut dann die private Variante in der Data Center Designer auf der öffentlichen-Cluster-Muster aus Einheit 6.2 auf.

1. Was "Private" Isoliert und Was Nicht

Die private Entscheidung gilt für den Node-Pool, nicht für den gesamten Dienst. Ein privater Node-Pool wird in einem privaten LAN hinter einem NAT-Gateway bereitgestellt: der ausgehende Datenverkehr zum Internet ist über das Gateway erlaubt, der eingehende nicht. Die Knoten haben keine öffentlichen Adressen und der Node-zu-Kubernetes-Dienst-Datenverkehr bleibt in Ihrem privaten Netzwerk. Das ist die Daten-Plane-Isolation, die FinCorp für Workloads benötigt, die mit Kontodaten unter GDPR und BSI-Steuerungen in Berührung kommen.

Was "private" nicht tut, ist die Verbergung des Kubernetes API-Servers. Die Steuerungsebene wird von IONOS gemanagt und der API-Endpunkt bleibt internetfähig, unabhängig von der Node-Pool-Art. Die Behandlung von "privatem Cluster" als ob es auch das API feuert, ist der zentrale Missverständnis dieser Einheit. Die Plattform bietet Ihnen eine separate Steuerung dafür: der Cluster verfügt über eine API IP-Zulassungsliste (die "Zugriff beschränken durch IP"-Einstellung), sodass Sie den API schützen, indem Sie die Quellbereiche auflisten, die ihn erreichen dürfen, beispielsweise die Egress-IPs von FinCorps CI/CD und die Exit-IPs des Operations-Teams von VPN. Die Isolation der Knoten und die Zulassungsliste für den API sind unabhängige Entscheidungen; ein konformes privates Cluster benötigt beides.

Zwei Grenzen aus Einheit 6.1 sind hier wichtiger. Der Diensttyp LoadBalancer ist nicht auf privaten Node Pools verfügbar, sodass das single-ingress-Node-Muster verschwunden ist; der Eingang ist ein separat bereitgestellter Load Balancer plus ein in-Cluster-Ingress-Controller (das Muster aus Einheit 6.2). Und Network Security Groups binden an die worker-NICs, nicht an die Cluster-Abstraktion, sodass in-Cluster-Netzwerkrichtlinien Ihre pod-ebene Steuerung bleiben.

2. Die zwei Netzwerkabhängigkeiten (Bauen Sie diese zuerst)

Ein privates Cluster ist netzwerkerst: Der Erstellungsdialog für Cluster fragt nach einem Gateway-IP, das bereits existieren muss, sodass das Netzwerk vor dem Cluster erstellt werden muss.

NAT-Gateway für Egress. Private Knoten benötigen immer noch ausgehenden Internetzugriff für Bildabrufe, Paket- und Sicherheitsupdates, NTP und Backup Service-Datenverkehr. Dieser Pfad ist der Managed NAT Gateway, der nur SNAT-basiert ist: Er bietet keinen eingehenden Zugriff (keine 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 Cluster. Ein wichtiger Punkt: Die Standardroute zum Gateway wird nicht automatisch injiziert. Für private virtuelle Maschinen muss die Routing-Tabelle so modifiziert werden, dass die Standardroute (oder eine dedizierte Route pro Ziel) auf das NAT-Gateway verweist; die private Node-Pool-Integration handhabt den Node-Egress durch das Gateway, aber Sie sind für die reservierte IP und die Routing-Intent verantwortlich. Ein einzelnes NAT-Gateway kann bis zu sechs private LANs bedienen.

Privates Cross Connect für cross-VDC-Node-Datenverkehr. Wenn Knoten auf Ressourcen in einem anderen virtuellen Rechenzentrum (für FinCorp, die private Datenebene aus Modul 5 in einem separaten VDC) zugreifen müssen, ist dieser Ost-West-Pfad ein privates Cross Connect. Seine Einschränkungen sind Eignungsregeln, keine Optionen: Es ist regionen- und vertragsidentisch (keine Regionen- oder Vertragsüberschreitung), jede Netzwerkkarte auf jedem verbundenen VDC muss den gleichen IP-Bereich teilen, und jede LAN kann nur einer Cross Connect-Verbindung angehören. Seine Bandbreite ist mit der einer normalen privaten Netzwerkkarte vergleichbar, und sie ist nicht kostenlos. Stellen Sie sie vor dem Node Pools her, das von der cross-VDC-Erreichbarkeit abhängt, oder diese Knoten werden in ein Netzwerk eingerichtet, das ihre Abhängigkeiten nicht sehen kann.

DCD Implementierung Schritt-für-Schritt

Ziel: Bau des privaten Variants unter Wiederverwendung der öffentlichen-Cluster-Muster, Netzwerk zuerst.

Sie werden ein privates Cluster und einen privaten Node-Pool im Data Center Designer für die FinCorp-Container-Plattform erstellen. Dies wiederverwendet den öffentlichen-Cluster-Fluss aus Einheit 6.2; die Unterschiede sind die Netzwerk-Voraussetzungen und drei Felder, die permanent werden. Der Node-Pool-Schritt-für-Schritt (Pool-Einstellungen, Node-Vorlage, Server-Typ, Speicher, angehängte 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 NAT-Gateway, das an das private LAN angehängt ist, wobei die Standardroute des LAN auf es zeigt; und, wenn Knoten ein weiteres VDC benötigen, ein privates Cross Connect vor Ort. Das VDC und seine Region werden aus früheren Modulen wiederverwendet.

Schritte (im Data Center Designer):

  1. Reservieren Sie eine IPv4-Adresse unter Menü > Netzwerkdienste > IP-Verwaltung. Dies wird zum Gateway-IP, also reservieren Sie es, bevor Sie das Cluster-Dialogfeld öffnen.
  2. Bauen Sie das NAT-Gateway: Wählen Sie das Rechenzentrum, stellen Sie sicher, dass ein privates Netzwerk mit dem Worker-LAN existiert, fügen Sie das NAT-Gateway hinzu, verbinden Sie seine Quell-Schnittstelle mit diesem privaten LAN und weisen Sie die reservierte öffentliche IP im Inspector > Einstellungen-Tab zu. Setzen Sie die Standardroute des privaten LAN 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 ein, der der Kubernetes-Benennungskonvention folgt (max. 63 Zeichen, alphanumerischer Anfang und Ende).
  4. Wählen Sie die Kubernetes-Version aus dem Dropdown-Menü.
  5. Im Node-Pool-Typ-Feld wählen Sie Privat.
  6. Wählen Sie eine Region aus dem Dropdown-Menü. Sie können das private Cluster nur in der gleichen Region wie das Cluster erstellen, also wird die Souveränitätsplatzierung jetzt festgelegt.
  7. Im Gateway-IP-Feld wählen Sie die reservierte IP, die Ihrem NAT-Gateway zugewiesen ist.
  8. (Optional) Definieren Sie ein Subnetz für das private LAN: ein /16-CIDR, das die Cluster-Pod- und Service-Netzwerke (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) nicht schneidet.
  9. Wählen Sie + Cluster erstellen. Sobald das Cluster aktiv ist, fügen Sie den privaten Node-Pool genau wie in Einheit 6.2 hinzu: Ein Node-Pool erfordert ein Rechenzentrum am gleichen Standort wie das Cluster, plus ein angehängtes privates LAN und reservierte IPs.
  10. Setzen Sie die API-IP-Allowlist (Zugriff beschränken durch IP) auf die Quellbereiche, die den Kubernetes-API erreichen dürfen, und rufen Sie dann die kubeconfig ab, um mit kubectl zu verbinden.

Häufige Fehler:

  • Die Behandlung von "privat" als Schutz für die API. Es schützt die Knoten; die API bleibt verwaltet und internet-reachable. Setzen Sie die IP-Allowlist separat, oder die Steuerungsebene ist der Welt offen.
  • Die Erstellung des Cluster vor dem NAT-Gateway. Das Gateway-IP-Feld benötigt eine reservierte IP, die bereits auf einem bereitgestellten Gateway existiert.
  • Die Annahme, dass der Egress einfach funktioniert. Die NAT-Standardroute wird nicht automatisch injiziert; setzen Sie die Standardroute des privaten LAN auf das Gateway oder Bildziehen und Updates schlagen stillschweigend fehl.
  • Die Wahl einer US-Region für die Steuerungsebene auf einer souveränitätsgebundenen Workload. Für ein privates Cluster wird die Steuerungsebene im gewählten Rechenzentrum erstellt, also ist die Regionenauswahl die Souveränitätsentscheidung.
  • Die Abhängigkeit von einem LoadBalancer-Dienst. Er ist auf privaten Node Pools nicht verfügbar; verwenden Sie einen separat bereitgestellten Load Balancer plus einen In-Cluster-Ingress-Controller.
  • Das Vergessen, dass die Felder permanent 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 umgeschaltet werden.

3. Control-Plane-Platzierung und Unveränderlichkeit

Für ein privates Cluster wird die Control-Plane im von Ihnen gewählten Rechenzentrum erstellt, sodass die Control-Plane-Metadaten in der gewählten Region verbleiben. Die Wahl des Standorts Deutschland (Frankfurt) bewahrt FinCorps Control-Plane-Daten in Deutschland und erhält die EU/deutsche Souveränität; Node-Pool-Workloads und Daten verbleiben immer in der gewählten Region, unabhängig davon. Dies ist der praktische Hebel hinter dem Souveränitäts-als-Platzierungsprinzip der Einheit 1.4 und unterscheidet sich von einem öffentlichen Cluster, dessen gemanagte Control-Plane in Frankfurt oder einem von drei US-Rechenzentren läuft.

Mehrere bei der Erstellung getroffene Entscheidungen sind dauerhafte Designentscheidungen und keine Konsoledurchgabewerte. Der Node-Pool-Typ (privat vs öffentlich) ist nach der Erstellung unveränderlich, und die Region, Gateway IP und Subnetz des privaten Cluster können nach der Bereitstellung nicht geändert werden. Sie können immer noch den Servertyp eines Node-Pools zwischen Dedicated Core und vCPU wechseln, aber der Typ und die Netzwerkverankerung sind festgelegt. Stellen Sie sicher, dass Sie die Region und die Netzwerk-Voraussetzungen richtig haben, bevor Sie auf "Erstellen" klicken; das einzige Mittel danach ist, das Cluster neu aufzubauen.

Zusammenfassung

Ein privates Cluster isoliert die Node-Daten-Ebene hinter einem SNAT-only-NAT-Gateway, während der IONOS-verwaltete API-Endpunkt internet-erreichbar bleibt, sodass ein konformes Build private Node Pools mit einer expliziten API-IP-Allowlist paart. Das Build ist netzwerk-erstes: Eine reservierte IP und ein NAT-Gateway (mit der Standard-Route) und ein gleiches Rechenzentrum, gleicher Vertrag Private Cross Connect für den Cross-VDC-Node-Datenverkehr müssen existieren, bevor das Cluster erstellt wird. Die Platzierung der Steuer-Ebene im gewählten deutschen Rechenzentrum bewahrt die Datensouveränität, und da die Node-Pool-Art, das Rechenzentrum, das Gateway-IP und das Subnetz alle bei der Erstellung festgelegt sind, sind die Entscheidungen hier permanent.

Wichtige Punkte:

  • Private isoliert die Knoten, nicht die API; schützen Sie die API-Endpunkt mit der IP-Allowlist als separaten, obligatorischen Schritt.
  • Das NAT-Gateway (Egress, SNAT-only, reservierte IP, manuelle Standard-Route) und das Private Cross Connect (Cross-VDC, gleiches Rechenzentrum und gleicher Vertrag nur) sind Voraussetzungen, nicht spätere Ergänzungen.
  • Für ein privates Cluster sitzt die Steuer-Ebene im gewählten Rechenzentrum, sodass die Rechenzentrum-Auswahl die Entscheidung über die Datensouveränität ist.
  • Rechenzentrum, Gateway-IP, Subnetz und Node-Pool-Art sind nach der Erstellung nicht änderbar; der Node-Pool-Durchlauf selbst ist derselbe wie in Einheit 6.2.