Oracle Cloud Infrastructure - Dokumentation

Beispielkonfigurationen für Netzwerkressourcen

Hier finden Sie Beispiele, wie Sie Netzwerkressourcen zum Erstellen und Bereitstellen von hochverfügbaren Clustern in einer Region mit drei Availability-Domains konfigurieren können, wenn Sie die Kubernetes Engine (OKE) verwenden.

Beim Erstellen eines neuen Clusters können Sie mit dem Workflow "Schnellerstellung" automatisch neue Netzwerkressourcen erstellen. Alternativ können Sie mit dem Workflow "Benutzerdefinierte Erstellung" explizit vorhandene Netzwerkressourcen angeben. Weitere Informationen zu den erforderlichen Netzwerkressourcen finden Sie unter Netzwerkressourcenkonfiguration für Clustererstellung und -Deployment.

Dieses Thema enthält Beispiele, wie Sie Netzwerkressourcen konfigurieren können, wenn Sie mit dem Workflow "Benutzerdefinierte Erstellung" hochverfügbare Cluster in einer Region mit drei Availability-Domains erstellen:

Einige zugehörige Entwicklungstutorials sind verfügbar.

Hinweis

In den Beispielen in diesem Abschnitt wird die Verwendung von Sicherheitsregeln in Sicherheitslisten zur Kontrolle des Zugriffs auf Cluster gezeigt. Wenn Sie Netzwerksicherheitsgruppen (die empfohlen werden) gegenüber Sicherheitslisten verwenden möchten, können Sie identische Sicherheitsregeln für Netzwerksicherheitsgruppen angeben.

Beispiel 1: Cluster mit Flannel-CNI-Plug-in, öffentlichem Kubernetes-API-Endpunkt, privaten Worker-Knoten und öffentlichen Load Balancern

In diesem Beispiel wird davon ausgegangen, dass der Zugriff auf den Kubernetes-API-Endpunkt und die Load Balancer direkt über das Internet erfolgen soll. Auf die Worker-Knoten wird innerhalb des VCN zugegriffen.

Beachten Sie, dass dem Kubernetes-API-Endpunkt standardmäßig eine private IP-Adresse zugewiesen wird. Um den Kubernetes-API-Endpunkt für das Internet verfügbar zu machen, führen Sie die beiden folgenden Schritte aus:

  • Wählen Sie ein öffentliches Subnetz aus, in dem der Kubernetes-API-Endpunkt gehostet werden soll.
  • Geben Sie an, dass eine öffentliche IP-Adresse dem Kubernetes-API-Endpunkt zugewiesen werden soll (sowie die private IP-Adresse).

Diese Abbildung zeigt ein Beispiel für eine Cluster-Konfiguration mit einem öffentlichen Kubernetes-API-Endpunktsubnetz, einem privaten Worker-Knotensubnetz, öffentlichen Load-Balancer-Subnetzen und einem privaten Bastion-Subnetz. Der Zugriff auf die Subnetze wird jeweils über die Sicherheitslisten seclist-KubernetesAPIendpoint, seclist-workernodes, seclist-loadbalancers und seclist-Bastion kontrolliert. Dieses Cluster verwendet das flannel CNI-Plug-in für das Pod-Networking. Das Kubernetes-API-Endpunktsubnetz ist über eine VNIC mit der Cluster-Control-Plane verbunden. Weitere Features dieser Beispielkonfiguration werden im umliegenden Text beschrieben.

VCN

Ressource Beispiel
VCN
  • Name: acme-dev-vcn
  • CIDR-Block: 10.0.0.0/16
  • DNS-Auflösung: Ausgewählt
Internetgateway
  • Name: internet-gateway-0
NAT-Gateway
  • Name: nat-gateway-0
Servicegateway
  • Name: service-gateway-0
  • Services: All <region> Services in Oracle Services Network
DHCP-Optionen
  • DNS-Typ auf "Internet- und VCN-Resolver" gesetzt

Subnetze

Ressource Beispiel
Öffentliches Subnetz für Kubernetes-API-Endpunkt

Name: KubernetesAPIendpoint, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.0.0/30
  • Routentabelle: routetable-KubernetesAPIendpoint
  • Subnetzzugriff: Öffentlich
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-KubernetesAPIendpoint
Privates Subnetz für Worker-Knoten

Name: workernodes, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.1.0/24
  • Routentabelle: routetable-workernodes
  • Subnetzzugriff: Privat
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-workernodes
Öffentliches Subnetz für Service-Load-Balancer

Name: loadbalancers, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.2.0/24
  • Routentabelle: routetable-serviceloadbalancers
  • Subnetzzugriff: Öffentlich
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-loadbalancers
Privates Subnetz für Bastion

Name: Bastion mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.3.0/24
  • Subnetzzugriff: Privat
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-Bastion

Routentabellen

Ressource Beispiel
Routentabelle für öffentliches Kubernetes-API-Endpunktsubnetz

Name: routetable-KubernetesAPIendpoint, mit einer Routingregel, die wie folgt definiert ist:

  • Ziel-CIDR-Block: 0.0.0.0/0
  • Zieltyp: Internetgateway
  • Ziel: internet-gateway-0
Routentabelle für privates Worker-Knotensubnetz

Name: routetable-workernodes, mit zwei Routingregeln, die wie folgt definiert sind:

  • Regel für Internettraffic:
    • Ziel-CIDR-Block: 0.0.0.0/0
    • Zieltyp: NAT-Gateway
    • Ziel: nat-gateway-0
  • Regel für OCI-Servicetraffic:
    • Ziel: All <region> Services in Oracle Services Network
    • Zieltyp: Servicegateway
    • Ziel: service-gateway-0
Routentabelle für öffentliches Load-Balancer-Subnetz

Name: routetable-serviceloadbalancers, mit einer Routingregel, die wie folgt definiert ist:

  • Ziel-CIDR-Block: 0.0.0.0/0
  • Zieltyp: Internetgateway
  • Ziel: internet-gateway-0

Sicherheitslistenregeln für öffentliche Kubernetes-API-Endpunktsubnetze

Die seclist-KubernetesAPIendpoint-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/6443 Kommunikation zwischen Kubernetes-Worker-Knoten und Kubernetes-API-Endpunkt
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/12250 Kommunikation zwischen Kubernetes-Worker-Knoten und Control-Plane
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ICMP 3,4 Pfad-Discovery
Zustandsbehaftet 0.0.0.0/0, Bastionsubnetz-CIDR oder bestimmtes CIDR TCP/6443

(Optional) Externer Zugriff auf den Kubernetes-API-Endpunkt

  • 0.0.0.0/0, wenn die Quelle Internet ist, das Subnetz öffentlich ist und dem API-Endpunkt eine öffentliche IP zugewiesen ist
  • Bastionsubnetz-CIDR, wenn der Zugriff über OCI Bastion erfolgt
  • Spezifisches CIDR, wenn der Zugriff von einem anderen spezifischen CIDR erfolgt

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network TCP/ALLE Kommunikation zwischen Kubernetes-Control-Plane und OKE zulassen
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network ICMP 3,4 Pfad-Discovery
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/ALLE Kommunikation zwischen Kubernetes-Control-Plane und Worker-Knoten zulassen
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ICMP 3,4 Pfad-Discovery

Sicherheitslistenregeln für private Worker-Knotensubnetze

Die Seclist-workernodes-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/ALLE Kommunikation zwischen Pods auf einem Worker-Knoten und Pods auf anderen Worker-Knoten zulassen
Zustandsbehaftet 10.0.0.0/30 (Kubernetes-API-Endpunkt-CIDR) TCP/ALLE Kommunikation zwischen Kubernetes-Control-Plane und Worker-Knoten zulassen
Zustandsbehaftet 0.0.0.0/0 ICMP 3,4 Pfad-Discovery
Zustandsbehaftet Bastionsubnetz-CIDR oder spezifisches CIDR TCP/22 (Optional) Eingehenden SSH-Traffic für verwaltete Knoten zulassen
Zustandsbehaftet CIDR des Load-Balancer-Subnetzes ALLE/30000-32767 Knotenports von Load Balancer zu Worker-Knoten.
Zustandsbehaftet CIDR des Load-Balancer-Subnetzes ALLE/10256 Ermöglichen Sie dem Load Balancer die Kommunikation mit kube-proxy auf Worker-Knoten.

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/ALLE Kommunikation zwischen Pods auf einem Worker-Knoten und Pods auf anderen Worker-Knoten zulassen
Zustandsbehaftet 0.0.0.0/0 ICMP 3,4 Pfad-Discovery
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network TCP/ALLE Kommunikation zwischen Worker-Knoten und OKE zulassen
Zustandsbehaftet 10.0.0.0/30 (Kubernetes-API-Endpunkt-CIDR) TCP/6443 Kommunikation zwischen Kubernetes-Worker-Knoten und Kubernetes-API-Endpunkt
Zustandsbehaftet 10.0.0.0/30 (Kubernetes-API-Endpunkt-CIDR) TCP/12250 Kommunikation zwischen Kubernetes-Worker-Knoten und Control-Plane
Zustandsbehaftet 0.0.0.0/0 TCP/ALLE (Optional) Kommunikation der Worker-Knoten mit dem Internet zulassen

Sicherheitslistenregeln für öffentliche Load-Balancer-Subnetze

Die Sicherheitsliste "seclist-loadbalancers" enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet

Anwendungsspezifisch (Internet oder spezifisches CIDR)

Anwendungsspezifisch (z. B. TCP, UDP - 443, 8080)

 (Optional) Load Balancer Listener-Protokoll und -Port. Nach Bedarf anpassen.

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/30000-32767 Knotenports von Load Balancer zu Worker-Knoten.
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/10256 Ermöglichen Sie dem Load Balancer die Kommunikation mit kube-proxy auf Worker-Knoten.

Sicherheitslistenregeln für privates Bastionsubnetz

Die Seclist-Bastion-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln: Kein Wert

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.0.0/30 (Kubernetes-API-Endpunkt-CIDR) TCP/6443

(Optional) Zugriff auf den Kubernetes-API-Endpunkt durch Bastion zulassen
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/22 (Optional) SSH-Traffic für Worker-Knoten zulassen

Beispiel 2: Cluster mit Flannel-CNI-Plug-in, privatem Kubernetes-API-Endpunkt, privaten Worker-Knoten und öffentlichen Load Balancern

In diesem Beispiel wird davon ausgegangen, dass der Zugriff auf die Load Balancer direkt über das Internet erfolgen soll. Auf den Kubernetes-API-Endpunkt und die Worker-Knoten wird innerhalb des VCN zugegriffen.

Diese Abbildung zeigt ein Beispiel für eine Cluster-Konfiguration mit einem privaten Kubernetes-API-Endpunktsubnetz, einem privaten Worker-Knotensubnetz, öffentlichen Load-Balancer-Subnetzen und einem privaten Bastion-Subnetz. Der Zugriff auf die Subnetze wird jeweils über die Sicherheitslisten seclist-KubernetesAPIendpoint, seclist-workernodes, seclist-loadbalancers und seclist-Bastion kontrolliert. Dieses Cluster verwendet das flannel CNI-Plug-in für das Pod-Networking. Das Kubernetes-API-Endpunktsubnetz ist über eine VNIC mit der Cluster-Control-Plane verbunden. Weitere Features dieser Beispielkonfiguration werden im umliegenden Text beschrieben.

VCN

Ressource Beispiel
VCN
  • Name: acme-dev-vcn
  • CIDR-Block: 10.0.0.0/16
  • DNS-Auflösung: Ausgewählt
Internetgateway
  • Name: internet-gateway-0
NAT-Gateway
  • Name: nat-gateway-0
Servicegateway
  • Name: service-gateway-0
  • Services: All <region> Services in Oracle Services Network
DHCP-Optionen
  • DNS-Typ auf "Internet- und VCN-Resolver" gesetzt

Subnetze

Ressource Beispiel
Privates Subnetz für Kubernetes-API-Endpunkt

Name: KubernetesAPIendpoint, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.0.0/30
  • Routentabelle: routetable-KubernetesAPIendpoint
  • Subnetzzugriff: Privat
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-KubernetesAPIendpoint
Privates Subnetz für Worker-Knoten

Name: workernodes, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.1.0/24
  • Routentabelle: routetable-workernodes
  • Subnetzzugriff: Privat
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-workernodes
Öffentliches Subnetz für Service-Load-Balancer

Name: loadbalancers, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.2.0/24
  • Routentabelle: routetable-serviceloadbalancers
  • Subnetzzugriff: Öffentlich
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-loadbalancers
Privates Subnetz für Bastion

Name: Bastion mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.3.0/24
  • Subnetzzugriff: Privat
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-Bastion

Routentabellen

Ressource Beispiel
Routentabelle für privates Kubernetes-API-Endpunktsubnetz

Name: routetable-KubernetesAPIendpoint, mit einer Routingregel, die wie folgt definiert ist:

  • Regel für Internettraffic:
    • Ziel-CIDR-Block: 0.0.0.0/0
    • Zieltyp: NAT-Gateway
    • Ziel: nat-gateway-0
  • Regel für OCI-Servicetraffic:
    • Ziel: All <region> Services in Oracle Services Network
    • Zieltyp: Servicegateway
    • Ziel: service-gateway-0
Routentabelle für privates Worker-Knotensubnetz

Name: routetable-workernodes, mit zwei Routingregeln, die wie folgt definiert sind:

  • Regel für Internettraffic:
    • Ziel-CIDR-Block: 0.0.0.0/0
    • Zieltyp: NAT-Gateway
    • Ziel: nat-gateway-0
  • Regel für OCI-Servicetraffic:
    • Ziel: All <region> Services in Oracle Services Network
    • Zieltyp: Servicegateway
    • Ziel: service-gateway-0
Routentabelle für öffentliches Load-Balancer-Subnetz

Name: routetable-serviceloadbalancers, mit einer Routingregel, die wie folgt definiert ist:

  • Ziel-CIDR-Block: 0.0.0.0/0
  • Zieltyp: Internetgateway
  • Ziel: internet-gateway-0

Sicherheitslistenregeln für private Kubernetes-API-Endpunktsubnetze

Die seclist-KubernetesAPIendpoint-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/6443 Kommunikation zwischen Kubernetes-Worker-Knoten und Kubernetes-API-Endpunkt
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/12250 Kommunikation zwischen Kubernetes-Worker-Knoten und Control-Plane
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ICMP 3,4 Pfad-Discovery
Zustandsbehaftet 0.0.0.0/0, Bastionsubnetz-CIDR oder bestimmtes CIDR TCP/6443

(Optional) Externer Zugriff auf den Kubernetes-API-Endpunkt

  • 0.0.0.0/0, wenn die Quelle Internet ist, das Subnetz öffentlich ist und dem API-Endpunkt eine öffentliche IP zugewiesen ist
  • Bastionsubnetz-CIDR, wenn der Zugriff über OCI Bastion erfolgt
  • Spezifisches CIDR, wenn der Zugriff von einem anderen spezifischen CIDR erfolgt

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet

Alle <Region>-Services in Oracle Services Network

 TCP/ALLE Kommunikation zwischen Kubernetes-Control-Plane und OKE zulassen
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network ICMP 3,4 Pfad-Discovery
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/ALLE Kommunikation zwischen Kubernetes-Control-Plane und Worker-Knoten zulassen
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ICMP 3,4 Pfad-Discovery

Sicherheitslistenregeln für private Worker-Knotensubnetze

Die Seclist-workernodes-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/ALLE Kommunikation zwischen Pods auf einem Worker-Knoten und Pods auf anderen Worker-Knoten zulassen
Zustandsbehaftet 10.0.0.0/30 (Kubernetes-API-Endpunkt-CIDR) TCP/ALLE Kommunikation zwischen Kubernetes-Control-Plane und Worker-Knoten zulassen
Zustandsbehaftet 0.0.0.0/0 ICMP 3,4 Pfad-Discovery
Zustandsbehaftet Bastionsubnetz-CIDR oder spezifisches CIDR TCP/22 (Optional) Eingehenden SSH-Traffic für verwaltete Knoten zulassen
Zustandsbehaftet CIDR des Load-Balancer-Subnetzes ALLE/30000-32767 Knotenports von Load Balancer zu Worker-Knoten.
Zustandsbehaftet CIDR des Load-Balancer-Subnetzes ALLE/10256 Ermöglichen Sie dem Load Balancer die Kommunikation mit kube-proxy auf Worker-Knoten.

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/ALLE Kommunikation zwischen Pods auf einem Worker-Knoten und Pods auf anderen Worker-Knoten zulassen
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network TCP/ALLE Kommunikation zwischen Worker-Knoten und OKE zulassen
Zustandsbehaftet 10.0.0.0/30 (Kubernetes-API-Endpunkt-CIDR) TCP/6443 Kommunikation zwischen Kubernetes-Worker-Knoten und Kubernetes-API-Endpunkt
Zustandsbehaftet 10.0.0.0/30 (Kubernetes-API-Endpunkt-CIDR) TCP/12250 Kommunikation zwischen Kubernetes-Worker-Knoten und Control-Plane
Zustandsbehaftet 0.0.0.0/0 TCP/ALLE (Optional) Kommunikation der Worker-Knoten mit dem Internet zulassen

Sicherheitslistenregeln für öffentliche Load-Balancer-Subnetze

Die Sicherheitsliste "seclist-loadbalancers" enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet

Anwendungsspezifisch (Internet oder spezifisches CIDR)

Anwendungsspezifisch (z. B. TCP, UDP - 443, 8080)

 (Optional) Load Balancer Listener-Protokoll und -Port. Nach Bedarf anpassen.

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/30000-32767 Knotenports von Load Balancer zu Worker-Knoten.
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/10256 Ermöglichen Sie dem Load Balancer die Kommunikation mit kube-proxy auf Worker-Knoten.

Sicherheitslistenregeln für privates Bastionsubnetz

Die Seclist-Bastion-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln: Kein Wert

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.0.0/30 (Kubernetes-API-Endpunkt-CIDR) TCP/6443

(Optional) Zugriff auf den Kubernetes-API-Endpunkt durch Bastion zulassen
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/22 (Optional) SSH-Traffic für Worker-Knoten zulassen

Beispiel 3: Cluster mit OCI-CNI-Plug-in, öffentlichem Kubernetes-API-Endpunkt, privaten Worker-Knoten und öffentlichen Load Balancern

In diesem Beispiel wird davon ausgegangen, dass der Zugriff auf den Kubernetes-API-Endpunkt und die Load Balancer direkt über das Internet erfolgen soll. Auf die Worker-Knoten wird innerhalb des VCN zugegriffen.

Beachten Sie, dass dem Kubernetes-API-Endpunkt standardmäßig eine private IP-Adresse zugewiesen wird. Um den Kubernetes-API-Endpunkt für das Internet verfügbar zu machen, führen Sie die beiden folgenden Schritte aus:

  • Wählen Sie ein öffentliches Subnetz aus, in dem der Kubernetes-API-Endpunkt gehostet werden soll.
  • Geben Sie an, dass eine öffentliche IP-Adresse dem Kubernetes-API-Endpunkt zugewiesen werden soll (sowie die private IP-Adresse).

Diese Abbildung zeigt ein Beispiel für eine Clusterkonfiguration mit einem öffentlichen Kubernetes-API-Endpunktsubnetz, einem privaten Worker-Knotensubnetz, öffentlichen Load-Balancer-Subnetzen, einem privaten Podsubnetz und einem privaten Bastionsubnetz. Der Zugriff auf die Subnetze wird jeweils über die Sicherheitslisten seclist-KubernetesAPIendpoint, seclist-workernodes, seclist-loadbalancers, seclist-pods und seclist-Bastion kontrolliert. Dieses Cluster verwendet das OCI CNI-Plug-in für Podnetworking. Das Kubernetes-API-Endpunktsubnetz ist über eine VNIC mit der Cluster-Control-Plane verbunden. Weitere Features dieser Beispielkonfiguration werden im umliegenden Text beschrieben.

VCN

Ressource Beispiel
VCN
  • Name: acme-dev-vcn
  • CIDR-Block: 10.0.0.0/16
  • DNS-Auflösung: Ausgewählt
Internetgateway
  • Name: internet-gateway-0
NAT-Gateway
  • Name: nat-gateway-0
Servicegateway
  • Name: service-gateway-0
  • Services: All <region> Services in Oracle Services Network
DHCP-Optionen
  • DNS-Typ auf "Internet- und VCN-Resolver" gesetzt

Subnetze

Ressource Beispiel
Öffentliches Subnetz für Kubernetes-API-Endpunkt

Name: KubernetesAPIendpoint, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.0.0/29
  • Routentabelle: routetable-KubernetesAPIendpoint
  • Subnetzzugriff: Öffentlich
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-KubernetesAPIendpoint
Privates Subnetz für Worker-Knoten

Name: workernodes, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.1.0/24
  • Routentabelle: routetable-workernodes
  • Subnetzzugriff: Privat
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-workernodes
Privates Subnetz für Pods

Name: Pods mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.32.0/19
  • Routentabelle: routetable-pods
  • Subnetzzugriff: Privat
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-pods
Öffentliches Subnetz für Service-Load-Balancer

Name: loadbalancers, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.2.0/24
  • Routentabelle: routetable-serviceloadbalancers
  • Subnetzzugriff: Öffentlich
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-loadbalancers
Privates Subnetz für Bastion

Name:bastion mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.3.0/24
  • Subnetzzugriff: Privat
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-Bastion

Routentabellen

Ressource Beispiel
Routentabelle für öffentliches Kubernetes-API-Endpunktsubnetz

Name: routetable-KubernetesAPIendpoint, mit einer Routingregel, die wie folgt definiert ist:

  • Ziel-CIDR-Block: 0.0.0.0/0
  • Zieltyp: Internetgateway
  • Ziel: internet-gateway-0
Routentabelle für privates Worker-Knotensubnetz

Name: routetable-workernodes, mit einer Routingregel, die wie folgt definiert ist:

  • Ziel: All <region> Services in Oracle Services Network
  • Zieltyp: Servicegateway
  • Ziel: service-gateway-0
Routentabelle für privates Podsubnetz

Name: routetable-pods, mit zwei Routingregeln, die wie folgt definiert sind:

  • Regel für Internettraffic:
    • Ziel-CIDR-Block: 0.0.0.0/0
    • Zieltyp: NAT-Gateway
    • Ziel: nat-gateway-0
  • Regel für OCI-Servicetraffic:
    • Ziel: All <region> Services in Oracle Services Network
    • Zieltyp: Servicegateway
    • Ziel: service-gateway-0
Routentabelle für öffentliches Load-Balancer-Subnetz

Name: routetable-serviceloadbalancers, mit einer Routingregel, die wie folgt definiert ist:

  • Ziel-CIDR-Block: 0.0.0.0/0
  • Zieltyp: Internetgateway
  • Ziel: internet-gateway-0

Sicherheitslistenregeln für öffentliche Kubernetes-API-Endpunktsubnetze

Die seclist-KubernetesAPIendpoint-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/6443 Kommunikation zwischen Kubernetes-Worker-Knoten und Kubernetes-API-Endpunkt
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/12250 Kommunikation zwischen Kubernetes-Worker-Knoten und Kubernetes-API-Endpunkt
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ICMP 3,4 Pfad-Discovery
Zustandsbehaftet 10.0.32.0/19 (Pod-CIDR) TCP/6443 Kommunikation zwischen Pod und Kubernetes-API-Endpunkt (bei Verwendung eines VCN-nativen Podnetzwerks).
Zustandsbehaftet 10.0.32.0/19 (Pod-CIDR) TCP/12250 Kommunikation zwischen Pod und Kubernetes-API-Endpunkt (bei Verwendung eines VCN-nativen Podnetzwerks).
Zustandsbehaftet 0.0.0.0/0, Bastionsubnetz-CIDR oder bestimmtes CIDR TCP/6443

(Optional) Externer Zugriff auf den Kubernetes-API-Endpunkt

  • 0.0.0.0/0, wenn die Quelle Internet ist, das Subnetz öffentlich ist und dem API-Endpunkt eine öffentliche IP zugewiesen ist
  • Bastionsubnetz-CIDR, wenn der Zugriff über OCI Bastion erfolgt
  • Spezifisches CIDR, wenn der Zugriff von einem anderen spezifischen CIDR erfolgt

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network TCP/ALLE Kommunikation zwischen Kubernetes-API-Endpunkt und OKE zulassen.
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network ICMP 3,4 Pfad-Discovery
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/10250 Kommunikation zwischen Kubernetes-API-Endpunkt und Worker-Knoten zulassen.
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ICMP 3,4 Pfad-Discovery
Zustandsbehaftet 10.0.32.0/19 (Pod-CIDR) ALLE/ALLE Lassen Sie zu, dass der Kubernetes-API-Endpunkt mit Pods kommuniziert (bei Verwendung eines VCN-nativen Podnetzwerks).

Sicherheitslistenregeln für private Worker-Knotensubnetze

Die Seclist-workernodes-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) TCP/10250 Kommunikation zwischen Kubernetes-API-Endpunkt und Worker-Knoten zulassen.
Zustandsbehaftet 0.0.0.0/0 ICMP 3,4 Pfad-Discovery
Zustandsbehaftet Bastionsubnetz-CIDR oder spezifisches CIDR TCP/22 (Optional) Eingehenden SSH-Traffic für verwaltete Knoten zulassen
Zustandsbehaftet CIDR des Load-Balancer-Subnetzes ALLE/30000-32767 Knotenports von Load Balancer zu Worker-Knoten.
Zustandsbehaftet CIDR des Load-Balancer-Subnetzes ALLE/10256 Ermöglichen Sie dem Load Balancer die Kommunikation mit kube-proxy auf Worker-Knoten.

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.32.0/19 (Pod-CIDR) ALLE/ALLE Zugriff auf Pods durch Worker-Knoten zulassen.
Zustandsbehaftet 0.0.0.0/0 ICMP 3,4 Pfad-Discovery
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network TCP/ALLE Kommunikation zwischen Worker-Knoten und OKE zulassen
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) TCP/6443 Kommunikation zwischen Kubernetes-Worker-Knoten und Kubernetes-API-Endpunkt
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) TCP/12250 Kommunikation zwischen Kubernetes-Worker-Knoten und Kubernetes-API-Endpunkt

Sicherheitslistenregeln für private Pods

Die seclist-pods-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/ALLE Zugriff auf Pods durch Worker-Knoten zulassen.
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) ALLE/ALLE Kommunikation zwischen Kubernetes-API-Endpunkt und Pods zulassen.
Zustandsbehaftet 10.0.32.0/19 (Pod-CIDR) ALLE/ALLE Pods dürfen mit anderen Pods kommunizieren.

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.32.0/19 (Pod-CIDR) ALLE/ALLE Pods dürfen mit anderen Pods kommunizieren.
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network

ICMP 3,4

 Pfad-Discovery
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network

TCP/ALLE

 Ermöglichen Sie Pods die Kommunikation mit OCI-Services.
Zustandsbehaftet 0.0.0.0/0

TCP/443

 (Optional) Ermöglichen Sie Pods die Kommunikation mit dem Internet.
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) TCP/6443 Kommunikation zwischen Pod und Kubernetes-API-Endpunkt (bei Verwendung eines VCN-nativen Podnetzwerks).
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) TCP/12250 Kommunikation zwischen Pod und Kubernetes-API-Endpunkt (bei Verwendung eines VCN-nativen Podnetzwerks).

Sicherheitslistenregeln für öffentliche Load-Balancer-Subnetze

Die Sicherheitsliste "seclist-loadbalancers" enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet

Anwendungsspezifisch (Internet oder spezifisches CIDR)

Anwendungsspezifisch (z. B. TCP, UDP - 443, 8080)

 (Optional) Load Balancer Listener-Protokoll und -Port. Nach Bedarf anpassen.

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/30000-32767 Knotenports von Load Balancer zu Worker-Knoten.
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/10256 Ermöglichen Sie dem Load Balancer die Kommunikation mit kube-proxy auf Worker-Knoten.

Sicherheitslistenregeln für privates Bastionsubnetz

Die Seclist-Bastion-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln: Kein Wert

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) TCP/6443

(Optional) Zugriff auf den Kubernetes-API-Endpunkt durch Bastion zulassen
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/22 (Optional) SSH-Traffic für Worker-Knoten zulassen

Beispiel 4: Cluster mit OCI-CNI-Plug-in, privatem Kubernetes-API-Endpunkt, privaten Worker-Knoten und öffentlichen Load Balancern

In diesem Beispiel wird davon ausgegangen, dass der Zugriff auf die Load Balancer direkt über das Internet erfolgen soll. Auf den Kubernetes-API-Endpunkt und die Worker-Knoten wird innerhalb des VCN zugegriffen.

Diese Abbildung zeigt eine Beispielclusterkonfiguration mit einem privaten Kubernetes-API-Endpunktsubnetz, einem privaten Worker-Knotensubnetz, öffentlichen Load-Balancer-Subnetzen, einem privaten Podsubnetz und einem privaten Bastion-Subnetz. Der Zugriff auf die Subnetze wird jeweils über die Sicherheitslisten seclist-KubernetesAPIendpoint, seclist-workernodes, seclist-loadbalancers, seclist-pods und seclist-Bastion kontrolliert. Dieses Cluster verwendet das OCI CNI-Plug-in für Podnetworking. Das Kubernetes-API-Endpunktsubnetz ist über eine VNIC mit der Cluster-Control-Plane verbunden. Weitere Features dieser Beispielkonfiguration werden im umliegenden Text beschrieben.

VCN

Ressource Beispiel
VCN
  • Name: acme-dev-vcn
  • CIDR-Block: 10.0.0.0/16
  • DNS-Auflösung: Ausgewählt
Internetgateway
  • Name: internet-gateway-0
NAT-Gateway
  • Name: nat-gateway-0
Servicegateway
  • Name: service-gateway-0
  • Services: All <region> Services in Oracle Services Network
DHCP-Optionen
  • DNS-Typ auf "Internet- und VCN-Resolver" gesetzt

Subnetze

Ressource Beispiel
Privates Subnetz für Kubernetes-API-Endpunkt

Name: KubernetesAPIendpoint, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.0.0/29
  • Routentabelle: routetable-KubernetesAPIendpoint
  • Subnetzzugriff: Privat
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-KubernetesAPIendpoint
Privates Subnetz für Worker-Knoten

Name: workernodes, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.1.0/24
  • Routentabelle: routetable-workernodes
  • Subnetzzugriff: Privat
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-workernodes
Privates Subnetz für Pods

Name: Pods mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.32.0/19
  • Routentabelle: routetable-pods
  • Subnetzzugriff: Privat
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-pods
Öffentliches Subnetz für Service-Load-Balancer

Name: loadbalancers, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.2.0/24
  • Routentabelle: routetable-serviceloadbalancers
  • Subnetzzugriff: Öffentlich
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-loadbalancers
Privates Subnetz für Bastion

Name: Bastion mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.3.0/24
  • Subnetzzugriff: Privat
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-Bastion

Routentabellen

Ressource Beispiel
Routentabelle für privates Kubernetes-API-Endpunktsubnetz

Name: routetable-KubernetesAPIendpoint, mit einer Routingregel, die wie folgt definiert ist:

  • Regel für Internettraffic:
    • Ziel-CIDR-Block: 0.0.0.0/0
    • Zieltyp: NAT-Gateway
    • Ziel: nat-gateway-0
  • Regel für OCI-Servicetraffic:
    • Ziel: All <region> Services in Oracle Services Network
    • Zieltyp: Servicegateway
    • Ziel: service-gateway-0
Routentabelle für privates Worker-Knotensubnetz

Name: routetable-workernodes, mit einer Routingregel, die wie folgt definiert ist:

  • Ziel: All <region> Services in Oracle Services Network
  • Zieltyp: Servicegateway
  • Ziel: Service-gateway0
Routentabelle für privates Podsubnetz

Name: routetable-pods, mit zwei Routingregeln, die wie folgt definiert sind:

  • Regel für Internettraffic:
    • Ziel-CIDR-Block: 0.0.0.0/0
    • Zieltyp: NAT-Gateway
    • Ziel: nat-gateway-0
  • Regel für OCI-Servicetraffic:
    • Ziel: All <region> Services in Oracle Services Network
    • Zieltyp: Servicegateway
    • Ziel: Service-gateway0
Routentabelle für öffentliches Load-Balancer-Subnetz

Name: routetable-serviceloadbalancers, mit einer Routingregel, die wie folgt definiert ist:

  • Ziel-CIDR-Block: 0.0.0.0/0
  • Zieltyp: Internetgateway
  • Zielinternetgateway: internet-gateway-0

Sicherheitslistenregeln für private Kubernetes-API-Endpunktsubnetze

Die seclist-KubernetesAPIendpoint-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/6443 Kommunikation zwischen Kubernetes-Worker-Knoten und Kubernetes-API-Endpunkt
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/12250 Kommunikation zwischen Kubernetes-Worker-Knoten und Kubernetes-API-Endpunkt
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ICMP 3,4 Pfad-Discovery
Zustandsbehaftet 10.0.32.0/19 (Pod-CIDR) TCP/6443 Kommunikation zwischen Pod und Kubernetes-API-Endpunkt (bei Verwendung eines VCN-nativen Podnetzwerks).
Zustandsbehaftet 10.0.32.0/19 (Pod-CIDR) TCP/12250 Kommunikation zwischen Pod und Kubernetes-API-Endpunkt (bei Verwendung eines VCN-nativen Podnetzwerks).
Zustandsbehaftet Bastionsubnetz-CIDR oder spezifisches CIDR TCP/6443

(Optional) Externer Zugriff auf den Kubernetes-API-Endpunkt

  • Bastionsubnetz-CIDR, wenn der Zugriff über OCI Bastion erfolgt
  • Spezifisches CIDR, wenn der Zugriff von einem anderen spezifischen CIDR erfolgt

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet

Alle <Region>-Services in Oracle Services Network

 TCP/ALLE Kommunikation zwischen Kubernetes-API-Endpunkt und OKE zulassen.
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network ICMP 3,4 Pfad-Discovery
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/10250 Kommunikation zwischen Kubernetes-API-Endpunkt und Worker-Knoten zulassen.
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ICMP 3,4 Pfad-Discovery
Zustandsbehaftet 10.0.32.0/19 (Pod-CIDR) ALLE/ALLE Kommunikation zwischen Kubernetes-API-Endpunkt und Pods zulassen.

Sicherheitslistenregeln für private Worker-Knotensubnetze

Die Seclist-workernodes-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) TCP/10250 Kommunikation zwischen Kubernetes-API-Endpunkt und Worker-Knoten zulassen.
Zustandsbehaftet 0.0.0.0/0 ICMP 3,4 Pfad-Discovery
Zustandsbehaftet Bastionsubnetz-CIDR oder spezifisches CIDR TCP/22 (Optional) Eingehenden SSH-Traffic für verwaltete Knoten zulassen
Zustandsbehaftet CIDR des Load-Balancer-Subnetzes ALLE/30000-32767 Knotenports von Load Balancer zu Worker-Knoten.
Zustandsbehaftet CIDR des Load-Balancer-Subnetzes ALLE/10256 Ermöglichen Sie dem Load Balancer die Kommunikation mit kube-proxy auf Worker-Knoten.

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.32.0/19 (Pod-CIDR) ALLE/ALLE Zugriff auf Pods durch Worker-Knoten zulassen.
Zustandsbehaftet 0.0.0.0/0 ICMP 3,4 Pfad-Discovery
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network TCP/ALLE Kommunikation zwischen Worker-Knoten und OKE zulassen
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) TCP/6443 Kommunikation zwischen Kubernetes-Worker-Knoten und Kubernetes-API-Endpunkt
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) TCP/12250 Kommunikation zwischen Kubernetes-Worker-Knoten und Kubernetes-API-Endpunkt

Sicherheitslistenregeln für private Pods

Die seclist-pods-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/ALLE Zugriff auf Pods durch Worker-Knoten zulassen.
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) ALLE/ALLE Kommunikation zwischen Kubernetes-API-Endpunkt und Pods zulassen.
Zustandsbehaftet 10.0.32.0/19 (Pod-CIDR) ALLE/ALLE Pods dürfen mit anderen Pods kommunizieren.

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.32.0/19 (Pod-CIDR) ALLE/ALLE Pods dürfen mit anderen Pods kommunizieren.
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network

ICMP 3,4

 Pfad-Discovery
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network

TCP/ALLE

 Ermöglichen Sie Pods die Kommunikation mit OCI-Services.
Zustandsbehaftet 0.0.0.0/0

TCP/443

 (Optional) Ermöglichen Sie Pods die Kommunikation mit dem Internet.
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) TCP/6443 Kommunikation zwischen Pod und Kubernetes-API-Endpunkt (bei Verwendung eines VCN-nativen Podnetzwerks).
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) TCP/12250 Kommunikation zwischen Pod und Kubernetes-API-Endpunkt (bei Verwendung eines VCN-nativen Podnetzwerks).

Sicherheitslistenregeln für öffentliche Load-Balancer-Subnetze

Die Sicherheitsliste "seclist-loadbalancers" enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet

Anwendungsspezifisch (Internet oder spezifisches CIDR)

Anwendungsspezifisch (z. B. TCP, UDP - 443, 8080)

 (Optional) Load Balancer Listener-Protokoll und -Port. Nach Bedarf anpassen.

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/30000-32767 Knotenports von Load Balancer zu Worker-Knoten.
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) ALLE/10256 Ermöglichen Sie dem Load Balancer die Kommunikation mit kube-proxy auf Worker-Knoten.

Sicherheitslistenregeln für privates Bastionsubnetz

Die Seclist-Bastion-Sicherheitsliste enthält die hier aufgeführten Ingress- und Egress-Regeln.

Ingress-Regeln: Kein Wert

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.0.0/29 (Kubernetes-API-Endpunkt-CIDR) TCP/6443

(Optional) Zugriff auf den Kubernetes-API-Endpunkt durch Bastion zulassen
Zustandsbehaftet 10.0.1.0/24 (Worker-Knoten-CIDR) TCP/22 (Optional) SSH-Traffic für Worker-Knoten zulassen