Öffentliche und private Cluster
Entscheiden Sie vor dem Erstellen eines Clusters in Compute Cloud@Customer, welche Art von Netzwerkzugriff das Cluster benötigt: ob Sie ein öffentliches Cluster oder ein privates Cluster benötigen. Sie können nicht sowohl öffentliche als auch private Cluster in einem VCN erstellen.
Der Hauptunterschied zwischen einem öffentlichen Cluster und einem privaten Cluster besteht darin, ob Sie öffentliche oder private Subnetze für den Kubernetes-API-Endpunkt und den Worker Load Balancer konfigurieren.
Die Subnetze für die Worker-Knoten und Control-Plane-Knoten sind immer privat.
Für die Worker-Knoten und Control-Plane-Knoten können Sie Routingregeln konfigurieren, die den Zugriff nur innerhalb des VCN oder außerhalb des VCN zulassen. In dieser Dokumentation werden die Routentabellen "vcn_private" und "nat_private" genannt. Sie können eine dieser privaten Subnetzkonfigurationen für Ihre Worker-Knoten und Control-Plane-Knoten auswählen, unabhängig davon, ob das Cluster privat oder öffentlich ist.
Öffentliche Cluster
Für ein öffentliches Cluster sind die folgenden Netzwerkressourcen erforderlich:
-
Ein öffentliches Subnetz für den Kubernetes-API-Endpunkt. Anweisungen zum Erstellen eines öffentlichen "Control-Plane-Endpoint"-Subnetzes finden Sie unter OKE-Control-Plane-Subnetz erstellen (Flannel-Overlay) und Control-Plane-Subnetz erstellen (VCN-nativer Pod).
-
Ein öffentliches Subnetz für den Worker Load Balancer. Anweisungen zum Erstellen eines öffentlichen "service-lb"-Subnetzes finden Sie unter Worker Load-Balancer-Subnetz (Flannel-Overlay) erstellen und Worker Load-Balancer-Subnetz (VCN-nativer Pod) erstellen.
-
Ein Internetgateway, mit dem Ressourcen in einem öffentlichen Subnetz über öffentliche IP-Adressen mit dem Internet verbunden werden.
-
Ein NAT-Gateway. Verwenden Sie ein NAT-Gateway für ausgehenden Internetzugriff. Ein NAT-Gateway verbindet Ressourcen in einem privaten Subnetz mit dem Internet, ohne private IP-Adressen verfügbar zu machen.
-
Mindestens drei freie öffentliche IP-Adressen. Für das NAT-Gateway, den Control-Plane-Load-Balancer und den Worker-Load-Balancer sind kostenlose öffentliche IP-Adressen erforderlich.
Für den Worker Load Balancer ist eine kostenlose öffentliche IP-Adresse erforderlich, um Anwendungen verfügbar zu machen. Je nach den auf den Pods ausgeführten Anwendungen benötigt der Worker Load Balancer möglicherweise mehr freie öffentliche IP-Adressen.
Private Cluster
Wenn Sie mehrere OKE-VCNs erstellen, muss jedes CIDR eindeutig sein. CIDRs verschiedener VCNs für private Cluster dürfen sich nicht mit anderen VCN-CIDRs oder einem On-Premise-CIDR überschneiden. Die verwendeten IP-Adressen müssen für jedes VCN exklusiv sein.
Ein privates Cluster verfügt über die folgenden Netzwerkressourcen:
-
Ein privates Subnetz für den Kubernetes-API-Endpunkt. Anweisungen zum Erstellen eines privaten "Control-Plane-Endpoint"-Subnetzes finden Sie unter OKE-Control-Plane-Subnetz (Flannel-Overlay) erstellen und Control-Plane-Subnetz (VCN-nativer Pod) erstellen.
-
Ein privates Subnetz für den Worker-Load Balancer. Anweisungen zum Erstellen eines privaten "service-lb"-Subnetzes finden Sie unter OKE-Control-Plane-Load-Balancer-Subnetz (Flannel Overlay) erstellen und Control-Plane-Load-Balancer-Subnetz (VCN-nativer Pod) erstellen.
-
Eine Routentabelle ohne Routingregeln. Diese Routentabelle ermöglicht nur den Zugriff innerhalb des VCN.
-
(Optional) Ein lokales Peering-Gateway (LPG). Verwenden Sie ein LPG, um Zugriff von anderen VCNs zuzulassen. Ein LPG ermöglicht den Zugriff auf das Cluster von einer Instanz aus, die auf einem anderen VCN ausgeführt wird. Erstellen Sie ein LPG im OKE-VCN, und erstellen Sie ein LPG in einem zweiten VCN in Compute Cloud@Customer. Verwenden Sie den LPG-Verbindungsbefehl, um die beiden LPGs zu Peer. Peered VCNs können sich in verschiedenen Mandanten befinden. CIDRs für die Peer-VCNs dürfen sich nicht überschneiden. Siehe VCNs über ein lokales Peering-Gateway verbinden.
Erstellen Sie eine Routingregel, um den VCN-Subnetztraffic zu und von den LPGs zu steuern, und Sicherheitsregeln, um bestimmte Traffictypen zuzulassen oder abzulehnen. Informationen zur Routentabelle, die dem OKE-VCN hinzugefügt werden soll, und ähnliche Routentabelle, die dem zweiten VCN hinzugefügt werden soll, finden Sie unter VCN erstellen (Flannel-Overlay) oder VCN erstellen (VCN-nativer Pod). Fügen Sie dieselbe Routingregel im zweiten VCN hinzu, und geben Sie das OKE-VCN-CIDR als Ziel an.
Installieren Sie das OCI-SDK und
kubectlauf der Instanz im zweiten VCN, und stellen Sie eine Verbindung zum privaten Cluster her. Siehe Kubernetes-Konfigurationsdatei erstellen. -
(Optional) Ein Dynamisches Routinggateway (DRG). Verwenden Sie ein DRG, um den Zugriff über das On-Premise-Netzwerk zu ermöglichen. Ein DRG ermöglicht Traffic zwischen dem OKE-VCN und dem IP-Adressraum des On-Premise-Netzwerks. Erstellen Sie das DRG im OKE-VCN-Compartment, und hängen Sie das OKE-VCN an dieses DRG an. Siehe Verbindung zum On-Premise-Netzwerk über ein dynamisches Routinggateway (DRG) herstellen.
Erstellen Sie eine Routingregel, um den Traffic zum IP-Adressraum des On-Premise-Data-Center-Netzwerks zu lenken. Informationen zur Routentabelle, die dem OKE-VCN hinzugefügt werden soll, finden Sie unter VCN erstellen (Flannel-Overlay) oder VCN erstellen (VCN-nativer Pod).