Netzwerkanforderungen

In diesem Dokument werden die Netzwerkanforderungen für die Installation und den Betrieb von Google Distributed Cloud beschrieben.

Diese Seite richtet sich an Administratoren und Architekten, Betreiber und Netzwerkspezialisten, die den Lebenszyklus der zugrunde liegenden Technologieinfrastruktur verwalten und das Netzwerk für ihre Organisation entwerfen und erstellen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Anforderungen an externe Netzwerke

Für Google Distributed Cloud ist eine Internetverbindung erforderlich. Google Distributed Cloud ruft Clusterkomponenten aus Container Registry ab und der Cluster ist bei Connect registriert.

Sie können die Verbindung zu Google über das öffentliche Internet über HTTPS, ein virtuelles privates Netzwerk (VPN) oder eine Dedicated Interconnect-Verbindung herstellen.

Wenn die Maschinen, die Sie für Ihre Administrator-Workstation und Clusterknoten verwenden, einen Proxyserver für den Zugriff auf das Internet verwenden, muss Ihr Proxyserver einige bestimmte Verbindungen zulassen. Weitere Informationen finden Sie im Abschnitt „Voraussetzungen“ unter Hinter einem Proxy installieren.

Interne Netzwerkanforderungen

Google Distributed Cloud kann mit Ebene 2- oder Ebene 3-Verbindungen zwischen Clusterknoten arbeiten. Bei den Knoten des Load-Balancers kann es sich um die Knoten der Steuerungsebene oder eine dedizierte Gruppe von Knoten handeln. Weitere Informationen finden Sie unter Load-Balancer auswählen und konfigurieren.

Wenn Sie gebündeltes Layer-2-Load-Balancing mit MetalLB (spec.loadBalancer.mode: bundled und spec.loadBalancer.type: layer2) verwenden, benötigen Load-Balancer-Knoten eine Layer-2-Adjazenz. Die Anforderung der Layer-2-Adjazenz gilt unabhängig davon, ob Sie den Load Balancer auf Knoten der Steuerungsebene oder in einer dedizierten Gruppe von Load-Balancing-Knoten ausführen. Das gebündelte Load Balancing mit BGP unterstützt das Layer-3-Protokoll. Eine strenge Layer-2-Adjazenz ist also nicht erforderlich.

Für Load-Balancer-Maschinen gelten die folgenden Anforderungen:

  • Beim gebündelten Layer-2-Load-Balancing befinden sich alle Load Balancer für einen bestimmten Cluster in derselben Layer-2-Domain. Steuerungsebenenknoten müssen sich außerdem in derselben Layer-2-Domain befinden.
  • Beim gebündelten Layer 2-Load-Balancing müssen sich alle virtuellen IP-Adressen (VIPs) im Maschinensubnetz des Load Balancers befinden und mit dem Gateway des Subnetzes verbunden werden können.
  • Nutzer müssen eingehenden Traffic für den Load Balancer zulassen.

Pod-Netzwerke

In Google Distributed Cloud können Sie bis zu 250 Pods pro Knoten konfigurieren. Kubernetes weist jedem Knoten einen CIDR-Block (Classless Inter-Domain Routing) zu, sodass jeder Pod eine eindeutige IP-Adresse haben kann. Die Größe des CIDR-Blocks entspricht der maximalen Anzahl von Pods pro Knoten. In der folgenden Tabelle ist die Größe des CIDR-Blocks aufgeführt, der in Kubernetes jedem Knoten basierend auf den konfigurierten maximalen Pods pro Knoten zugewiesen wird:

Maximale Anzahl von Pods pro Knoten CIDR-Block pro Knoten Anzahl der IP-Adressen
32 /26 64
33–64 /25 128
65 – 128 /24 256
129 - 250 /23 512

Für das Ausführen von 250 Pods pro Knoten muss Kubernetes für jeden Knoten einen CIDR-Block von /23 reservieren. Wenn der Cluster den Standardwert /16 für das Feld clusterNetwork.pods.cidrBlocks verwendet, hat der Cluster ein Limit von (2(23–16))=128 Knoten. Wenn Sie den Cluster über dieses Limit hinaus erweitern möchten, können Sie entweder den Wert von clusterNetwork.pods.cidrBlocks erhöhen oder den Wert von nodeConfig.podDensity.maxPodsPerNode verringern. Diese Methode hatte einige Nachteile.

Clusterbereitstellung für einen Nutzer mit hoher Verfügbarkeit

Das folgende Diagramm zeigt eine Reihe von wichtigen Netzwerkkonzepten für Google Distributed Cloud in einer möglichen Netzwerkkonfiguration.

Typische Netzwerkkonfiguration für Google Distributed Cloud

Berücksichtigen Sie die folgenden Informationen, um die Netzwerkanforderungen zu erfüllen:

  • Die Knoten der Steuerungsebene führen die Load-Balancer aus und haben alle Layer-2-Verbindungen. Andere Verbindungen, einschließlich Worker-Knoten, erfordern jedoch nur Layer-3-Verbindungen.
  • Konfigurationsdateien definieren IP-Adressen für Worker-Knotenpools. Konfigurationsdateien definieren auch VIPs für die folgenden Zwecke:
    • Dienste
    • Eingehender Traffic
    • Zugriff der Steuerungsebene über die Kubernetes API
  • Sie benötigen eine Verbindung zu Google Cloud.

Portnutzung

In diesem Abschnitt werden die Portanforderungen für Google Distributed Cloud-Cluster beschrieben. In den folgenden Tabellen wird erläutert, wie UDP- und TCP-Ports von Kubernetes-Komponenten auf Cluster- und Load Balancer-Knoten verwendet werden.

Knoten der Steuerungsebene

Version 1.29

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Bereitstellung und Aktualisierung von Administratorclusterknoten Administratorworkstation
TCP Eingehend 2379 - 2381 etcd-Server-Client-API, Messwerte und Status kube-apiserver und etcd
TCP Eingehend 2382 - 2384 etcd-events-Server-Client-API, Messwerte und Status kube-apiserver und etcd-events
TCP Beides 4240 CNI-Systemdiagnose Alle
UDP Eingehend 6081 GENEVE-Kapselung Self
TCP Eingehend 6444 Kubernetes API-Server Alle
TCP Eingehend 9100 Auth-Proxy node-exporter
TCP Eingehend 9101 Knotenmesswerte nur auf localhost bereitstellen

(gilt für Version 1.28 und höher)

node-exporter
TCP Eingehend 9977 Audit-Ereignis vom API-Server empfangen audit-proxy
TCP Eingehend 10250 kubelet API Self und Steuerungsebene
TCP Eingehend 10256 Knoten-Systemdiagnose Alle
TCP Eingehend 10257 kube-controller-manager

(Portnummernänderung für Version 1.28 und höher)

Self
TCP Eingehend 10259 kube-scheduler

(Portnummernänderung für Version 1.28 und höher)

Self
TCP Eingehend 11002 Der GKE Identity Service-Kerncontainer wird über hostPort an den Port gebunden.

(gilt für Version 1.29 und höher)

Self
TCP Eingehend 14443 ANG-Webhook-Dienst kube-apiserver und ang-controller-manager

Version 1.28

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Bereitstellung und Aktualisierung von Administratorclusterknoten Administratorworkstation
TCP Eingehend 2379 - 2381 etcd-Server-Client-API, Messwerte und Status kube-apiserver und etcd
TCP Eingehend 2382 - 2384 etcd-events-Server-Client-API, Messwerte und Status kube-apiserver und etcd-events
TCP Beides 4240 CNI-Systemdiagnose Alle
UDP Eingehend 6081 GENEVE-Kapselung Self
TCP Eingehend 6444 Kubernetes API-Server Alle
TCP Eingehend 8444 Der GKE Identity Service-Kerncontainer wird über hostPort mit dem Port verbunden.

(gilt nur für Version 1.28)

Alle
TCP Eingehend 9100 Auth-Proxy node-exporter
TCP Eingehend 9101 Knotenmesswerte nur auf localhost bereitstellen

(gilt für Version 1.28 und höher)

node-exporter
TCP Eingehend 9977 Audit-Ereignis vom API-Server empfangen audit-proxy
TCP Eingehend 10250 kubelet API Self und Steuerungsebene
TCP Eingehend 10256 Knoten-Systemdiagnose Alle
TCP Eingehend 10257 kube-controller-manager

(Portnummernänderung für Version 1.28 und höher)

Self
TCP Eingehend 10259 kube-scheduler

(Portnummernänderung für Version 1.28 und höher)

Self
TCP Eingehend 14443 ANG-Webhook-Dienst kube-apiserver und ang-controller-manager

Version 1.16

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Bereitstellung und Aktualisierung von Administratorclusterknoten Administratorworkstation
TCP Eingehend 2379 - 2381 etcd-Server-Client-API, Messwerte und Status kube-apiserver und etcd
TCP Eingehend 2382 - 2384 etcd-events-Server-Client-API, Messwerte und Status

(gilt für Version 1.16 und höher)

kube-apiserver und etcd-events
TCP Beides 4240 CNI-Systemdiagnose Alle
UDP Eingehend 6081 GENEVE-Kapselung Self
TCP Eingehend 6444 Kubernetes API-Server Alle
TCP Eingehend 9100 Messwerte bereitstellen node-exporter
TCP Eingehend 9443 Messwerte für Steuerungsebenenkomponenten bereitstellen (Proxy) (Diese Portanforderung gilt für Clusterversion 1.16 und niedriger.) kube-control-plane-metrics-proxy
TCP Eingehend 9977 Audit-Ereignis vom API-Server empfangen audit-proxy
TCP Eingehend 10250 kubelet API Self und Steuerungsebene
TCP Eingehend 10251 kube-scheduler Self
TCP Eingehend 10252 kube-controller-manager Self
TCP Eingehend 10256 Knoten-Systemdiagnose Alle
TCP Eingehend 14443 ANG-Webhook-Dienst kube-apiserver und ang-controller-manager

Version 1.15 und niedriger

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Bereitstellung und Aktualisierung von Administratorclusterknoten Administratorworkstation
TCP Eingehend 2379 - 2381 etcd-Server-Client-API, Messwerte und Status kube-apiserver und etcd
TCP Beides 4240 CNI-Systemdiagnose Alle
UDP Eingehend 6081 GENEVE-Kapselung Self
TCP Eingehend 6444 Kubernetes API-Server Alle
TCP Eingehend 9100 Messwerte bereitstellen node-exporter
TCP Eingehend 9443 Messwerte für Steuerungsebenenkomponenten bereitstellen (Proxy) (Diese Portanforderung gilt für Clusterversion 1.16 und niedriger.) kube-control-plane-metrics-proxy
TCP Eingehend 9977 Audit-Ereignis vom API-Server empfangen audit-proxy
TCP Eingehend 10250 kubelet API Self und Steuerungsebene
TCP Eingehend 10251 kube-scheduler Self
TCP Eingehend 10252 kube-controller-manager Self
TCP Eingehend 10256 Knoten-Systemdiagnose Alle
TCP Eingehend 14443 ANG-Webhook-Dienst kube-apiserver und ang-controller-manager

Worker-Knoten

Version 1.29

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Bereitstellung und Aktualisierung von Nutzerclusterknoten Administratorcluster-Knoten
TCP Beides 4240 CNI-Systemdiagnose Alle
UDP Eingehend 6081 GENEVE-Kapselung Self
TCP Eingehend 9100 Auth-Proxy node-exporter
TCP Eingehend 9101 Knotenmesswerte nur auf localhost bereitstellen

(gilt für Version 1.28 und höher)

node-exporter
TCP Eingehend 10250 kubelet API Self und Steuerungsebene
TCP Eingehend 10256 Knoten-Systemdiagnose Alle
TCP Eingehend 30000 bis 32767 NodePort Dienste Self

Version 1.28

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Bereitstellung und Aktualisierung von Nutzerclusterknoten Administratorcluster-Knoten
TCP Beides 4240 CNI-Systemdiagnose Alle
UDP Eingehend 6081 GENEVE-Kapselung Self
TCP Eingehend 9100 Auth-Proxy node-exporter
TCP Eingehend 9101 Knotenmesswerte nur auf localhost bereitstellen

(gilt für Version 1.28 und höher)

node-exporter
TCP Eingehend 10250 kubelet API Self und Steuerungsebene
TCP Eingehend 10256 Knoten-Systemdiagnose Alle
TCP Eingehend 30000 bis 32767 NodePort Dienste Self

Version 1.16

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Bereitstellung und Aktualisierung von Nutzerclusterknoten Administratorcluster-Knoten
TCP Beides 4240 CNI-Systemdiagnose Alle
UDP Eingehend 6081 GENEVE-Kapselung Self
TCP Eingehend 9100 Messwerte bereitstellen node-exporter
TCP Eingehend 10250 kubelet API Self und Steuerungsebene
TCP Eingehend 10256 Knoten-Systemdiagnose Alle
TCP Eingehend 30000 bis 32767 NodePort Dienste Self

Version 1.15 und niedriger

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Bereitstellung und Aktualisierung von Nutzerclusterknoten Administratorcluster-Knoten
TCP Beides 4240 CNI-Systemdiagnose Alle
UDP Eingehend 6081 GENEVE-Kapselung Self
TCP Eingehend 9100 Messwerte bereitstellen node-exporter
TCP Eingehend 10250 kubelet API Self und Steuerungsebene
TCP Eingehend 10256 Knoten-Systemdiagnose Alle
TCP Eingehend 30000 bis 32767 NodePort Dienste Self

Load-Balancer-Knoten

Version 1.29

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Bereitstellung und Aktualisierung von Nutzerclusterknoten Administratorcluster-Knoten
TCP Eingehend 443 Clusterverwaltung

Dieser Port kann in der Clusterkonfigurationsdatei mit dem Feld controlPlaneLBPort konfiguriert werden.

Alle
TCP Beides 4240 CNI-Systemdiagnose Alle
UDP Eingehend 6081 GENEVE-Kapselung Self
TCP und UDP Eingehend 7946 MetalLB-Systemdiagnose Load-Balancer-Knoten
TCP Eingehend 10256 Knoten-Systemdiagnose Alle
TCP Eingehend 11000 Überwachungsport für HAProxy-Messwerte (nicht veränderbar)

(gilt für Version 1.29 und höher)

Alle
TCP Eingehend 11001 Überwachungsport für GKE Identity Service (unveränderlich)

(gilt für Version 1.29 und höher)

Alle

Version 1.28

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Bereitstellung und Aktualisierung von Nutzerclusterknoten Administratorcluster-Knoten
TCP Eingehend 443 Clusterverwaltung

Dieser Port kann in der Clusterkonfigurationsdatei mit dem Feld controlPlaneLBPort konfiguriert werden.

Alle
TCP Beides 4240 CNI-Systemdiagnose Alle
UDP Eingehend 6081 GENEVE-Kapselung Self
TCP und UDP Eingehend 7946 MetalLB-Systemdiagnose Load-Balancer-Knoten
TCP Eingehend 8443 Überwachungsport für GKE Identity Service (unveränderlich)

(gilt nur für Version 1.28)

Alle
TCP Eingehend 10256 Knoten-Systemdiagnose Alle

Version 1.16

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Bereitstellung und Aktualisierung von Nutzerclusterknoten Administratorcluster-Knoten
TCP Eingehend 443 Clusterverwaltung

Dieser Port kann in der Clusterkonfigurationsdatei mit dem Feld controlPlaneLBPort konfiguriert werden.

Alle
TCP Beides 4240 CNI-Systemdiagnose Alle
UDP Eingehend 6081 GENEVE-Kapselung Self
TCP Eingehend 7946 MetalLB-Systemdiagnose Load-Balancer-Knoten
TCP Eingehend 10256 Knoten-Systemdiagnose Alle

Version 1.15 und niedriger

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Bereitstellung und Aktualisierung von Nutzerclusterknoten Administratorcluster-Knoten
TCP Eingehend 443 Clusterverwaltung

Dieser Port kann in der Clusterkonfigurationsdatei mit dem Feld controlPlaneLBPort konfiguriert werden.

Alle
TCP Beides 4240 CNI-Systemdiagnose Alle
UDP Eingehend 6081 GENEVE-Kapselung Self
TCP Eingehend 7946 MetalLB-Systemdiagnose Load-Balancer-Knoten
TCP Eingehend 10256 Knoten-Systemdiagnose Alle

Multi-Cluster-Portanforderungen

In einer Multi-Cluster-Konfiguration müssen hinzugefügte Cluster die folgenden Ports enthalten, um mit dem Administratorcluster zu kommunizieren.

Protokoll Richtung Portbereich Zweck Verwendet von
TCP Eingehend 22 Clusterknoten bereitstellen und aktualisieren Alle Knoten
TCP Eingehend 443 Kubernetes API-Server für hinzugefügten Cluster

Dieser Port kann in der Clusterkonfiguration mit dem Feld controlPlaneLBPort konfiguriert werden.

Knoten der Steuerungsebene und der Load-Balancer

firewalld-Ports konfigurieren

Sie müssen Firewalls nicht deaktivieren, um Google Distributed Cloud unter Red Hat Enterprise Linux (RHEL) auszuführen. Um firewalld verwenden zu können, müssen Sie die UDP- und TCP-Ports öffnen, die von Steuerungsebenen-, Worker- und Load-Balancer-Knoten verwendet werden, wie auf dieser Seite unter Portnutzung beschrieben. Die folgenden Beispielkonfigurationen zeigen, wie Sie Ports mit firewall-cmd, dem firewalld-Befehlszeilen-Dienstprogramm, öffnen können. Sie sollten die Befehle als Root-Nutzer ausführen.

Beispielkonfiguration für den Knoten der Steuerungsebene

Der folgende Befehlsblock zeigt ein Beispiel dafür, wie Sie die erforderlichen Ports auf Servern öffnen können, auf denen Knoten der Steuerungsebene ausgeführt werden:

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=10257/tcp
firewall-cmd --permanent --zone=public --add-port=10259/tcp
firewall-cmd --permanent --zone=public --add-port=2379-2380/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Die spezifischen Portanforderungen für die von Ihnen verwendete Clusterversion finden Sie im Abschnitt Portnutzung. Aktualisieren Sie die Beispielbefehle entsprechend.

Ersetzen Sie PODS_CIDR durch die im Feld clusterNetwork.pods.cidrBlocks konfigurierten CIDR-Blöcke, die für Ihre Pods reserviert sind. Der Standard-CIDR-Block für Pods ist 192.168.0.0/16.

Beispielkonfiguration für Worker-Knoten

Der folgende Befehlsblock zeigt ein Beispiel dafür, wie Sie die erforderlichen Ports auf Servern öffnen können, auf denen Worker-Knoten ausgeführt werden:

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Die spezifischen Portanforderungen für die von Ihnen verwendete Clusterversion finden Sie im Abschnitt Portnutzung. Aktualisieren Sie die Beispielbefehle entsprechend.

Ersetzen Sie PODS_CIDR durch die im Feld clusterNetwork.pods.cidrBlocks konfigurierten CIDR-Blöcke, die für Ihre Pods reserviert sind. Der Standard-CIDR-Block für Pods ist 192.168.0.0/16.

Beispielkonfiguration für Load-Balancer-Knoten

Der folgende Befehlsblock zeigt ein Beispiel dafür, wie Sie die erforderlichen Ports auf Servern öffnen können, auf denen Knoten der Steuerungsebene ausgeführt werden:

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=7946/tcp
firewall-cmd --permanent --zone=public --add-port=7946/udp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Die spezifischen Portanforderungen für die von Ihnen verwendete Clusterversion finden Sie im Abschnitt Portnutzung. Aktualisieren Sie die Beispielbefehle entsprechend.

Ersetzen Sie PODS_CIDR durch die im Feld clusterNetwork.pods.cidrBlocks konfigurierten CIDR-Blöcke, die für Ihre Pods reserviert sind. Der Standard-CIDR-Block für Pods ist 192.168.0.0/16.

Zusätzliche Konfiguration für RHEL 9.2 und 9.4

Red Hat Enterprise Linux (RHEL) Version 9.2 und 9.4 werden als GA in Version 1.29.400 und höher unterstützt. Bei den RHEL-Versionen 9.2 und 9.4 müssen Sie auf den Knoten eine zusätzliche Firewalld-Konfiguration vornehmen, damit Ihre Dienste und Pods ordnungsgemäß funktionieren:

  1. Listen Sie die aktiven Schnittstellen für den Knoten auf, um die Hauptknotenschnittstelle zu finden:

    firewall-cmd --list-interfaces
    

    Gemäß den Benennungskonventionen für Linux-Maschinenschnittstellen kann der Name der Hauptschnittstelle so aussehen: eth0, eno1, ens1 oder enp2s0.

  2. Listen Sie die Zonen für den Knoten auf, um herauszufinden, welche Zone von der Hauptoberfläche verwendet wird:

    firewall-cmd --list-all-zones
    

    Wenn Ihre Hauptoberfläche beispielsweise eno1 ist, gibt der folgende Abschnitt der Antwort an, dass sich die Hauptoberfläche in der Zone public befindet:

    ...
    public (active)
      target: default
      icmp-block-inversion: no
      interfaces: eno1
      sources:
      ...
    
  3. Führen Sie die folgenden firewalld-Befehle aus, um benutzerdefinierte Zonen- und Richtliniendetails für RHEL 9.2 oder 9.4 einzurichten:

    firewall-cmd --permanent --new-zone=cilium
    firewall-cmd --permanent --zone=cilium --add-interface=cilium_host
    firewall-cmd --permanent --zone=cilium --set-target ACCEPT
    firewall-cmd --permanent --zone=cilium --add-masquerade
    firewall-cmd --permanent --zone=cilium --add-forward
    firewall-cmd --permanent --new-policy cilium-host-port-forwarding
    firewall-cmd --permanent --policy cilium-host-port-forwarding --add-ingress-zone IN_ZONE
    firewall-cmd --permanent --policy cilium-host-port-forwarding --add-egress-zone cilium
    firewall-cmd --permanent --policy cilium-host-port-forwarding --set-target ACCEPT
    firewall-cmd --reload
    

    Ersetzen Sie IN_ZONE durch einen der folgenden Werte, basierend auf den Ergebnissen der vorherigen Schritte:

    • public: Vordefinierte Zone für die Verwendung in öffentlichen Bereichen, in denen nur ausgewählte eingehende Verbindungen zulässig sind.
    • trusted: Vordefinierte Zone in einer kontrollierten Umgebung, in der alle Netzwerkverbindungen akzeptiert werden.
    • Der Name einer benutzerdefinierten Zone, die Sie definiert haben.
  4. Folgen Sie der Anbieterdokumentation, um Ihre Speicherlösung zu konfigurieren.

    Wenn Sie beispielsweise Portworx zum Verwalten zustandsbasierter Arbeitslasten verwenden, sind in den Portworx-Netzwerkanforderungen die Ports aufgeführt, die geöffnet bleiben müssen.

    Führen Sie für jeden in der Anbieterdokumentation aufgeführten Anschluss den folgenden Befehl aus:

    firewall-cmd --permanent --zone=public --add-port=PORT_INFO
    

    Ersetzen Sie PORT_INFO durch die Portnummer oder den Portnummernbereich, gefolgt vom Protokoll. Beispiel: 10250-10252/tcp.

Portkonfiguration bestätigen

Führen Sie die folgenden Schritte auf den Knoten der Steuerungsebene, den Worker-Knoten und den Load Balancer-Knoten aus, um die Portkonfiguration zu prüfen:

  1. Führen Sie den folgenden Network Mapper-Befehl aus, um zu sehen, welche Ports geöffnet sind:

    nmap localhost
    
  2. Führen Sie die folgenden Befehle aus, um die Firewalld-Konfigurationseinstellungen abzurufen:

    firewall-cmd --info-zone=public
    firewall-cmd --info-zone=k8s-pods
    firewall-cmd --list-all-policies
    
  3. Führen Sie bei Bedarf die Befehle aus den vorherigen Abschnitten noch einmal aus, um Ihre Knoten richtig zu konfigurieren. Möglicherweise müssen Sie die Befehle als Root-Nutzer ausführen.

Bekanntes Problem mit firewalld

Wenn Sie Google Distributed Cloud mit aktivierter firewalld unter Red Hat Enterprise Linux (RHEL) ausführen, können Änderungen an firewalld die Cilium-iptables-Ketten im Hostnetzwerk entfernen. Die iptables-Ketten werden vom anetd-Pod beim Start hinzugefügt. Der Verlust der Cilium-iptables-Ketten führt dazu, dass die Netzwerkverbindung des Pods auf dem Knoten außerhalb des Knotens unterbrochen wird.

Änderungen an firewalld, die die iptables-Ketten entfernen, sind unter anderem:

  • firewalld mit systemctl neu starten

  • firewalld mit dem Befehlszeilenclient neu laden (firewall-cmd --reload)

Wenn Sie firewalld-Änderungen anwenden möchten, ohne iptables-Ketten zu entfernen, starten Sie anetd auf dem Knoten neu:

  1. Suchen Sie den anetd-Pod und löschen Sie ihn mit den folgenden Befehlen, um anetd neu zu starten:

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
    

    Ersetzen Sie ANETD_XYZ durch den Namen des anetd-Pods.