Netzwerkanforderungen

Anforderungen an externe Netzwerke

Für Anthos-Cluster auf Bare-Metal ist eine Internetverbindung erforderlich. Anthos-Cluster on Bare Metal 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

Anthos-Cluster auf Bare-Metal können mit Ebene-2- oder Ebene-3-Verbindungen zwischen Clusterknoten arbeiten, jedoch müssen Load-Balancer-Knoten über Ebene 2 verfügen. 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.

Die Anforderung der Layer-2-Verbindung gilt unabhängig davon, ob Sie den Load-Balancer im Knotenpool der Steuerungsebene oder in einem dedizierten Satz von Knoten ausführen.

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

  • Alle Load-Balancer für einen bestimmten Cluster befinden sich in derselben Layer-2-Domain.
  • Alle virtuellen IP-Adressen (VIPs) müssen sich im Maschinen-Subnetz 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

Mit Anthos-Cluster auf Bare-Metal 1.7.0 und höher 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.

Clusterbereitstellung für einen Nutzer mit hoher Verfügbarkeit

Das folgende Diagramm zeigt eine Reihe von wichtigen Netzwerkkonzepten für Anthos-Cluster auf Bare-Metal in einer möglichen Netzwerkkonfiguration.

Anthos-Cluster in Bare-Metal – typische Netzwerkkonfiguration

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 wird erläutert, wie UDP- und TCP-Ports auf Clusterknoten und Load-Balancer-Knoten verwendet werden.

Knoten der Steuerungsebene

ProtokollRichtungPortbereichZweckVerwendet von
UDPEingehend6081GENEVE-KapselungSelf
TCPEingehend22Bereitstellung und Aktualisierung von AdministratorclusterknotenAdministratorworkstation
TCPEingehend6444Kubernetes API-ServerAlle
TCPEingehend2379–2380etcd server client-APIkube-apiserver und etcd
TCPEingehend10250kubelet APISelf und Steuerungsebene
TCPEingehend10251kube-schedulerSelf
TCPEingehend10252kube-controller-managerSelf
TCPEingehend10256Knoten-SystemdiagnoseAlle
TCPBeides4240CNI-SystemdiagnoseAlle

Worker-Knoten

ProtokollRichtungPortbereichZweckVerwendet von
TCPEingehend22Bereitstellung und Aktualisierung von NutzerclusterknotenAdministratorcluster-Knoten
UDPEingehend6081GENEVE-KapselungSelf
TCPEingehend10250kubelet APISelf und Steuerungsebene
TCPEingehend10256Knoten-SystemdiagnoseAlle
TCPEingehend30000 bis 32767NodePort DiensteSelf
TCPBeides4240CNI-SystemdiagnoseAlle

Load-Balancer-Knoten

ProtokollRichtungPortbereichZweckVerwendet von
TCPEingehend22Bereitstellung und Aktualisierung von NutzerclusterknotenAdministratorcluster-Knoten
UDPEingehend6081GENEVE-KapselungSelf
TCPEingehend443*ClusterverwaltungAlle
TCPBeides4240CNI-SystemdiagnoseAlle
TCPEingehend7946LB-SystemdiagnoseLoad-Balancer-Knoten
UDPEingehend7946LB-SystemdiagnoseLoad-Balancer-Knoten
TCPEingehend10256Knoten-SystemdiagnoseAlle

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

Multi-Cluster-Portanforderungen

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

ProtokollRichtungPortbereichZweckVerwendet von
TCPEingehend22Clusterknoten bereitstellen und aktualisierenAlle Knoten
TCPEingehend443*Kubernetes API-Server für hinzugefügten ClusterKnoten der Steuerungsebene und der Load-Balancer

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

firewalld-Ports konfigurieren

Sie müssen Firewalls nicht deaktivieren, um Anthos-Cluster auf Bare-Metal unter Red Hat Enterprise Linux (RHEL) oder CentOS 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.

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=10250-10252/tcp
firewall-cmd --permanent --zone=public --add-port=10256/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

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

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

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.