Beispielkonfiguration einer Netzwerkressource für Cluster mit virtuellen Knoten

Erfahren Sie, wie Sie Netzwerkressourcen für ein Cluster mit virtuellen Knoten konfigurieren können, wenn Sie Kubernetes Engine (OKE) verwenden.

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/28
  • Routentabelle: routetable-KubernetesAPIendpoint
  • Subnetzzugriff: Öffentlich
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-KubernetesAPIendpoint
Privates Subnetz für virtuelle Knoten und Pods

Name: nodespods mit den folgenden Eigenschaften:

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

Name: loadbalancers, mit den folgenden Eigenschaften:

  • Typ: Regional
  • CIDR-Block: 10.0.20.0/24
  • Routentabelle: routetable-serviceloadbalancers
  • Subnetzzugriff: Öffentlich
  • DNS-Auflösung: Ausgewählt
  • DHCP-Optionen: Standardwert
  • Sicherheitsliste: seclist-loadbalancers

Routentabellen

Ressource Beispiel
Routentabelle für öffentliches 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: Internetgateway
    • Ziel: internet-gateway-0
Routentabelle für privates virtuelles Knoten- und Podsubnetz

Name: routetable-nodespods, 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
  • Zielinternetgateway: 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 0.0.0.0/0 TCP/6443 Externer Zugriff auf den Kubernetes-API-Endpunkt.
Zustandsbehaftet 10.0.10.0/19 (Knoten-/Pod-CIDR) TCP/6443 Kommunikation zwischen virtuellem Knoten und Kubernetes-API-Endpunkt.
Zustandsbehaftet 10.0.10.0/19 (Knoten-/Pod-CIDR) TCP/12250 Virtueller Knoten zur Steuerung der Kommunikation auf der Ebene.
Zustandsbehaftet 10.0.10.0/19 (Knoten-/Pod-CIDR) ICMP 3,4 Pfad-Discovery

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network TCP/443 Kommunikation des Kubernetes-API-Endpunkts mit regionalen OCI-Serviceendpunkten zulassen.
Zustandsbehaftet 10.0.10.0/19 (Knoten-/Pod-CIDR) TCP/ALLE Kommunikation zwischen Kubernetes-API-Endpunkt und virtuellen Knoten zulassen.
Zustandsbehaftet 10.0.10.0/19 (Knoten-/Pod-CIDR) ICMP 3,4 Pfad-Discovery

Sicherheitslistenregeln für private Knoten/Podsubnetze

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

Ingress-Regeln:

Status Quelle Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.10.0/19 ALLE/ALLE Pod-to-Pod-Kommunikation.
Zustandsbehaftet 10.0.10.0/19 ALLE / 30000-32767 Traffic von Load Balancer zu Pod und Health-Check-Knotenporttraffic für externes Traffic-Policy=lokal
Zustandsbehaftet 10.0.10.0/19 TCP/UDP/10256 Traffic vom Load Balancer zum Health-Check-Port für external-traffic-policy=cluster
Zustandsbehaftet 10.0.0.0/28 ICMP 3,4 Pfad-Discovery vom API-Server.
Zustandsbehaftet 10.0.0.0/28 TCP/ALLE Kommunikation zwischen API-Server und virtuellen Knoten.

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.10.0/19 (Knoten-/Pod-CIDR) ALLE/ALLE Pod-to-Pod-Kommunikation.
Zustandsbehaftet 10.0.0.0/28 TCP/6443 Kommunikation zwischen virtuellem Knoten/Pod und API-Server.
Zustandsbehaftet 10.0.0.0/28 TCP/12250 Kommunikation zwischen virtuellem Knoten/Pod und API-Server.
Zustandsbehaftet 10.0.0.0/28 ICMP 3,4 Pfad-Discovery zum API-Server.
Zustandsbehaftet Alle <Region>-Services in Oracle Services Network TCP/443 Kommunikation zwischen virtuellem Knoten/Pod und regionalen OCI-Serviceendpunkten.
Zustandsbehaftet 0.0.0.0/0 ICMP 3,4 Zugriff vom virtuellen Knoten/Pod zur Kubernetes-Control Plane.
Zustandsbehaftet 0.0.0.0/0 ALLE/ALLE Podzugriff auf das Internet

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

0.0.0.0/0

TCP / 443/80

Eingehender Traffic zum Load Balancer unter der Annahme, dass der Listener-Port 80/443 ist

Egress-Regeln:

Status Ziel Protokoll/Ziel- Port Beschreibung
Zustandsbehaftet 10.0.10.0/19 (Knoten-/Pod-CIDR) ALLE / 30000-32767 Traffic zu Pod und Health-Check-Knotenporttraffic für externe Traffic-Policy=lokal
Zustandsbehaftet 10.0.10.0/19 (Knoten-/Pod-CIDR) TCP/UDP/10256 Traffic zu Health-Check-Port für external-traffic-policy=cluster