Netzwerkressourcenkonfiguration für Clustererstellung und -Deployment

Routentabelle für Worker-Knotensubnetze

Wenn Sie Worker-Knoten in einem öffentlichen Subnetz bereitstellen möchten, muss die Routentabelle des Subnetzes eine Routingregel enthalten, die das Internetgateway als Ziel für den Ziel-CIDR-Block 0.0.0.0/0 angibt.

Wenn Sie Worker-Knoten in einem privaten Subnetz bereitstellen möchten, muss die Subnetzroutentabelle Folgendes aufweisen:

• eine Routingregel, die das Servicegateway als Ziel für Alle <Region>-Services in Oracle Services Network angibt
• eine Routingregel, die das NAT-Gateway als Ziel für den Ziel-CIDR-Block 0.0.0.0/0 angibt

Routentabelle für Kubernetes-API-Endpunktsubnetze

Wenn Sie den Kubernetes-API-Endpunkt in einem öffentlichen Subnetz bereitstellen möchten, muss die Routentabelle des Subnetzes eine Routingregel enthalten, die das Internetgateway als Ziel für den Ziel-CIDR-Block 0.0.0.0/0 angibt.

Wenn Sie den Kubernetes-API-Endpunkt in einem privaten Subnetz bereitstellen möchten, muss die Routentabelle des Subnetzes Folgendes aufweisen:

• eine Routingregel, die das Servicegateway als Ziel für Alle <Region>-Services in Oracle Services Network angibt
• eine Routingregel, die das NAT-Gateway als Ziel für den Ziel-CIDR-Block 0.0.0.0/0 angibt

Routentabelle für Load-Balancer-Subnetze

Wenn Sie Load Balancer in öffentlichen Subnetzen bereitstellen möchten, muss die Routentabelle des Subnetzes eine Routingregel enthalten, die das Internetgateway als Ziel für den Ziel-CIDR-Block 0.0.0.0/0 angibt.

Wenn Sie Load Balancer in privaten Subnetzen bereitstellen möchten, können Sie die Routentabelle des Subnetzes leer lassen.

Routentabelle für Pods-Subnetz

Wenn Sie das OCI-VCN-native Podnetworking-CNI-Plug-in für das Podnetzwerk verwenden möchten, stellen Sie Pods in einem privaten Subnetz bereit. Die Routentabelle des Subnetzes muss Folgendes aufweisen:

• eine Routingregel, die das Servicegateway als Ziel für Alle <Region>-Services in Oracle Services Network angibt
• eine Routingregel, die das NAT-Gateway als Ziel für den Ziel-CIDR-Block 0.0.0.0/0 angibt

Wenn Sie das Flannel-CNI-Plug-in für Podnetzwerke verwenden möchten, ist kein Podsubnetz erforderlich.

Hinweise zur Routentabellenkonfiguration

• Um die Möglichkeit des asymmetrischen Routings zu vermeiden, kann eine Routentabelle für ein öffentliches Subnetz nicht sowohl eine Routingregel enthalten, die ein Internetgateway als Ziel angibt, als auch eine Routingregel, die ein Servicegateway als Ziel angibt (siehe Probleme mit dem Zugriff auf Ihre öffentlichen Instanzen von Oracle-Services über ein Servicegateway).

• Weitere Informationen zum Einrichten von Routentabellen finden Sie unter:

  • Internetgateway
  • NAT-Gateway
  • Zugriff auf Oracle-Services: Servicegateway
  • Beispielkonfigurationen für Netzwerkressourcen

Konfiguration des Kubernetes-API-Endpunktsubnetzes

Das Kubernetes-API-Endpunktsubnetz hostet einen Endpunkt, der Zugriff auf die Kubernetes-API auf der Cluster-Control-Plane ermöglicht.

Das Kubernetes-API-Endpunktsubnetz muss ein regionales Subnetz sein. Dabei kann es sich um ein privates oder ein öffentliches Subnetz handeln:

• Wenn Sie ein öffentliches Subnetz für den Kubernetes-API-Endpunkt angeben, können Sie den Endpunkt optional dem Internet bereitstellen, indem Sie dem Endpunkt eine öffentliche IP-Adresse zuweisen. Mit der öffentlichen IP-Adresse können Drittanbieter-Cloud-Services (wie SaaS-CI/CD-Services) auf den Kubernetes-API-Endpunkt zugreifen. Beachten Sie Folgendes:
  • Wenn der Kubernetes-API-Endpunkt eine öffentliche IP-Adresse aufweist, müssen Routingregeln und Sicherheitsregeln vorhanden sein, um den Zugriff auf den Endpunkt über ein Internetgateway zu ermöglichen (siehe Beispiel 1: Cluster mit Flannel-CNI) Plug-in, öffentlicher Kubernetes-API-Endpunkt, private Worker-Knoten und öffentliche Load Balancer und Beispiel 3: Cluster mit OCI-CNI-Plug-in, öffentlichem Kubernetes-API-Endpunkt, privaten Worker-Knoten und öffentlichen Load Balancern.
  • Wenn der Kubernetes-API-Endpunkt keine öffentliche IP-Adresse hat, müssen Routingregeln und Sicherheitsregeln vorhanden sein, um den Zugriff auf den Endpunkt mit einem Servicegateway und einem NAT-Gateway zu ermöglichen (siehe Beispiel 2: Cluster mit Flannel-CNI-Plug-in, privatem Kubernetes-API-Endpunkt, privaten Worker-Knoten und öffentlichen Load Balancern und Beispiel 4: Cluster mit OCI-CNI-Plug-in, privatem Kubernetes-API-Endpunkt, privaten Worker-Knoten und öffentlichen Load Balancern.
  • Nachdem Sie ein Cluster erstellt haben, können Sie anschließend ändern, ob dem Kubernetes-API-Endpunkt eine öffentliche IP-Adresse zugewiesen ist. Wenn Sie ändern, ob dem Endpunkt eine öffentliche IP-Adresse zugewiesen ist, müssen Sie auch Routingregeln und Sicherheitsregeln entsprechend aktualisieren.
• Wenn Sie ein privates Subnetz für den Kubernetes-API-Endpunkt angeben, kann der Traffic von einem anderen Subnetz in Ihrem VCN, von einem anderen VCN oder von Ihrem On-Premise-Netzwerk aus auf das Kubernetes-API-Endpunktsubnetz zugreifen (über Peering mit FastConnect). Sie können auch einen Bastionhost in einem öffentlichen Subnetz einrichten, um den Kubernetes-API-Endpunkt zu erreichen (siehe Bastion für Clusterzugriff einrichten).

Konfiguration des Worker-Knotensubnetzes

Ein Worker-Knotensystem hostet Worker-Knoten. Alle verwalteten Knoten in einem Knotenpool gehören zum selben Worker-Knotensubnetz.

Beim Subnetz des Worker-Knotens kann es sich entweder um ein einzelnes regionales Subnetz oder um mehrere AD-spezifische Subnetze handeln (jeweils ein Subnetz pro Availability-Domain).

Verwaltete/selbstverwaltete Knoten: Das Worker-Knotensubnetz kann entweder ein öffentliches oder ein privates Subnetz sein. Für maximale Sicherheit empfehlen wir jedoch die Verwendung eines privaten Subnetzes für Worker-Knoten.

Virtuelle Knoten: Das Worker-Knotensubnetz kann entweder ein öffentliches oder ein privates Subnetz sein. Für maximale Sicherheit empfehlen wir jedoch die Verwendung eines privaten Subnetzes für Worker-Knoten. Außerdem wird empfohlen, dass das Worker-Knotensubnetz und das Podsubnetz dasselbe Subnetz sind (in diesem Fall muss das Worker-Knotensubnetz ein privates Subnetz sein, da virtuelle Knoten erfordern, dass das Podsubnetz ein privates Subnetz ist).

Podsubnetzkonfiguration

Ein Podsubnetz hostet die Pods auf den Worker-Knoten in einem Knotenpool, wenn es ein VCN-natives Podnetzwerk verwendet (siehe CNI-Plug-in für OCI-VCN-natives Podnetzwerk für Podnetzwerke verwenden).

Das Podsubnetz muss ein einzelnes regionales Subnetz sein.

Verwaltete Knoten: Das Podsubnetz muss ein privates Subnetz sein.

Virtuelle Knoten: Das Podsubnetz muss ein privates Subnetz sein. Wir empfehlen, dass das Podsubnetz und das Worker-Knotensubnetz dasselbe Subnetz sind (in diesem Fall muss das Worker-Knotensubnetz auch ein privates Subnetz sein).

Konfiguration des Load-Balancer-Subnetzes

Load-Balancer-Subnetze verbinden Oracle Cloud Infrastructure-Load-Balancer, die von Kubernetes-Services vom Typ LoadBalancer erstellt wurden.

Die Load-Balancer-Subnetze können einzelne regionale Subnetze oder AD-spezifische Subnetze sein (jeweils ein Subnetz pro Availability-Domain). Oracle empfiehlt jedoch regionale Subnetze.

Bei den Load-Balancer-Subnetzen kann es sich um öffentliche oder private Subnetze handeln, je nachdem, wie der Zugriff auf die Anwendungen erfolgt, die im Cluster bereitgestellt werden. Wenn der Zugriff auf Anwendungen intern aus Ihrem VCN erfolgt, verwenden Sie private Subnetze für die Load Balancer. Wenn der Zugriff auf Anwendungen über das Internet erfolgt, verwenden Sie öffentliche Subnetze für die Load Balancer.

Konfiguration des Bastionsubnetzes (optional)

Eine optionale Bastion in einem Bastionsubnetz kann sicheren Zugriff auf den Kubernetes-API-Endpunkt und SSH-Zugriff auf Worker-Knoten ermöglichen. Siehe Bastion für Clusterzugriff einrichten.

Sicherheitsregeln für den Kubernetes-API-Endpunkt

Die folgenden Ingress-Regeln müssen für den Kubernetes-API-Endpunkt, in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste definiert werden:

Die folgenden optionalen Ingress-Regeln können für den Kubernetes-API-Endpunkt, in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste definiert werden:

Die folgenden Egress-Regeln müssen für den Kubernetes-API-Endpunkt, in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste definiert werden:

Sicherheitsregeln für Mitarbeiterknoten

Worker-Knoten werden mit öffentlichen oder privaten IP-Adressen erstellt, je nachdem, ob Sie bei der Definition der Knotenpools in einem Cluster öffentliche oder private Subnetze angeben. Die Kubernetes-Engine muss auf Worker-Knoten zugreifen können.

Die folgenden Ingress-Regeln müssen für Worker-Knoten, in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste definiert werden:

Die folgenden optionalen Ingress-Regeln können für Worker-Knoten (nur verwaltete Knoten), in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste definiert werden:

Die folgenden Egress-Regeln müssen für Worker-Knoten, in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste definiert werden:

Die folgenden optionalen Egress-Regeln können für Worker-Knoten, in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste definiert werden:

Sicherheitsregeln für Podsubnetze

Wenn Sie das OCI-VCN-native Podnetworking-CNI-Plug-in für das Podnetworking verwenden:

• Die für das Worker-Knotensubnetz, in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste definierten Sicherheitsregeln müssen Folgendes enthalten:

  • Zustandsbehaftete Ingress- und Egress-Regeln, die den gesamten Traffic zwischen Worker-Knoten zulassen
  • Zustandsbehaftete Ingress- und Egress-Regeln, die den gesamten Traffic zwischen Worker-Knoten und Load Balancer zulassen
  • Regeln für zu Stateful Egress, die Traffic zwischen Worker-Knoten und Kubernetes-Engine ermöglichen
• Die für das Podsubnetz definierten Sicherheitsregeln in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste müssen zustandsbehaftete Ingress- und Egress-Regeln enthalten, die den gesamten Traffic zwischen Pods zulassen

Die folgenden Ingress-Regeln müssen für Podsubnetze, in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste definiert werden:

Die folgenden Egress-Regeln müssen für Podsubnetze, in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste definiert werden:

Die folgenden optionalen Egress-Regeln können für ein Podsubnetz, in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste definiert werden:

Sicherheitsregeln für Load Balancer und Network Load Balancer

Wenn die Kubernetes-Engine einen OCI-Load Balancer oder Network Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, müssen entsprechende Sicherheitsregeln vorhanden sein, um eingehenden und ausgehenden Traffic zum und vom Subnetz des Load Balancers oder Network Load Balancers zuzulassen. Bei verwalteten Knoten (nicht virtuellen Knoten) werden diese Sicherheitsregeln standardmäßig automatisch für Load Balancer erstellt, jedoch nicht standardmäßig automatisch für Network Load Balancer erstellt. Weitere Informationen zum Provisioning eines OCI-Load Balancers oder Network Load Balancers für einen Kubernetes-Service des Typs LoadBalancer finden Sie unter Kubernetes-Services des Typs LoadBalancer definieren.

Sie können Ingress- und Egress-Sicherheitsregeln für das Subnetz in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste definieren. Weitere Informationen finden Sie unter:

• Angeben von Netzwerksicherheitsgruppen (empfohlen)
• Verwaltungsoptionen für Sicherheitslisten beim Provisioning eines OCI Load Balancers angeben
• Verwaltungsoptionen für Sicherheitslisten beim Provisioning eines OCI Network Load Balancers angeben

Definieren Sie die folgende Ingress-Sicherheitsregel in einem oder beiden:

• eine Netzwerksicherheitsgruppe (empfohlen), der der der Load Balancer oder die Network Load Balancer-Ressource hinzugefügt wurde
• eine Sicherheitsliste, die mit dem Subnetz des Load Balancers oder des Network Load Balancers verknüpft ist

Legen Sie das Protokoll und den Zielport der Ingress-Regel entsprechend für bestimmte Anwendungsanforderungen fest. Beispiel: Geben Sie UDP als Protokoll für eine Anwendung an, die UDP-Datenverkehr verarbeitet.

Definieren Sie die folgende Egress-Sicherheitsregel in einem oder beiden:

• eine Netzwerksicherheitsgruppe (empfohlen), der der der Load Balancer oder die Network Load Balancer-Ressource hinzugefügt wurde
• eine Sicherheitsliste, die mit dem Subnetz des Load Balancers oder des Network Load Balancers verknüpft ist

Standardmäßig werden OCI Load Balancer oder Network Load Balancer, die von Kubernetes Engine-Proxyanforderungen bereitgestellt werden, für alle Worker-Knoten im Cluster bereitgestellt. Wenn Anforderungen mit Worker-Knoten im Cluster über einen Proxy geleitet werden, müssen die folgenden Ingress- und Egress-Sicherheitsregeln (in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste) vorhanden sein, damit der Load Balancer oder Network Load Balancer mit den Worker-Knoten auf Port 10256 (dem Kube-Proxy-Zustandsport) kommunizieren kann:

• Ingress-Sicherheitsregel für die Sicherheitsliste (oder Netzwerksicherheitsgruppe) des Worker-Knotensubnetzes, mit der der Load Balancer oder Network Load Balancer auf Worker-Knoten mit dem Kube-Proxy kommunizieren kann:

  Status	Quelle	Protokoll/Ziel- Port	Beschreibung
  Zustandsbehaftet	CIDR des Load-Balancer- oder Network Load Balancer-Subnetzes	ALLE/10256	Ermöglichen Sie OCI Load Balancer oder Network Load Balancer die Kommunikation mit Kube-Proxy auf Worker-Knoten.

• Egress-Sicherheitsregel für die Sicherheitsliste (oder Netzwerksicherheitsgruppe) des Load-Balancer- oder Network Load-Balancer-Subnetzes, mit der der der Load Balancer oder Network Load Balancer auf Worker-Knoten mit kube-proxy kommunizieren kann:

  Status	Ziel	Protokoll/Ziel- Port	Beschreibung
  Zustandsbehaftet	Subnetz-CIDR des Worker-Knotens	ALLE/10256	Ermöglichen Sie OCI Load Balancer oder Network Load Balancer die Kommunikation mit Kube-Proxy auf Worker-Knoten.

Beim Provisioning eines Network Load Balancers für einen Kubernetes-Service vom Typ LoadBalancer:

• Sie können angeben, dass Anforderungen mit der Client-IP-Adresse enden, die in den Headern von IP-Paketen angegeben ist, anstatt mit einem Proxy auf andere Worker-Knoten im Cluster (durch Festlegen von externalTrafficPolicy: Local) geleitet zu werden. Siehe Anforderungen auf dem empfangenden Knoten beenden.
• Wenn Sie angeben, dass Anforderungen mit der Client-IP-Adresse beendet werden, können Sie auch angeben, ob die Client-IP-Adresse in den Headern von IP-Paketen beibehalten werden soll (mit der Annotation oci-network-load-balancer.oraclecloud.com/is-preserve-source). Siehe Preserving the Client IP Address.

Beachten Sie, dass Sie in beiden Fällen eine Sicherheitsregel (in einer Netzwerksicherheitsgruppe (empfohlen) und/oder in einer Sicherheitsliste) für die Worker-Knoten im Cluster eingerichtet haben müssen, um Ingress-Traffic vom CIDR-Block, in dem die Clientverbindungen hergestellt werden, zu allen Knotenports (30000 bis 32767) zuzulassen. Wenn die Anwendung im Internet verfügbar gemacht wird, setzen Sie den Quell-CIDR-Block der Sicherheitsregel auf 0.0.0.0/0. Alternativ können Sie den CIDR-Block der Quelle der Sicherheitsregel auf einen bestimmten CIDR-Block festlegen (z.B. wenn die Clientverbindungen aus einem bestimmten Subnetz stammen).

Sicherheitsregeln für Bastionsubnetze

Eine optionale Bastion in einem Bastionsubnetz kann sicheren Zugriff auf den Kubernetes-API-Endpunkt und SSH-Zugriff auf Worker-Knoten ermöglichen. Informationen zu den zu definierenden Ingress- und Egress-Sicherheitsregeln finden Sie unter Bastion für Clusterzugriff einrichten.