Netzwerkanforderungen
Anforderungen an externe Netzwerke
Für Anthos-Cluster auf Bare-Metal ist eine Internetverbindung erforderlich. Anthos-Cluster auf Bare-Metal ruft Clusterkomponenten aus Container Registry ab und der Cluster ist bei Connect registriert.
Sie können eine Verbindung zu Google über das öffentliche Internet (mit HTTPS), über ein Virtual Private Network (VPN) oder über eine Dedicated Interconnect-Verbindung herstellen.
Interne Netzwerkanforderungen
Anthos-Cluster auf Bare-Metal-Servern können mit Layer-2- oder Layer-3-Verbindungen zwischen Clusterknoten arbeiten und Load-Balancer-Knoten müssen sich in derselben Layer-2-Domain befinden. Bei den Knoten des Load-Balancers kann es sich um die Knoten der Steuerungsebene oder eine dedizierte Gruppe von Knoten handeln. Informationen zur Konfiguration finden Sie unter Load-Balancer auswählen und konfigurieren.
Die Layer-2-Netzwerkanforderung gilt unabhängig davon, ob Sie den Load-Balancer auf dem Knotenpool der Steuerungsebene oder in einer dedizierten Gruppe von Knoten ausführen.
Die Anforderungen an Load-Balancer-Maschinen sind:
- Alle Load-Balancer für einen bestimmten Cluster befinden sich in derselben Layer-2-Domain.
- Alle VIPs müssen sich im Load-Balancer-Maschinensubnetz befinden und müssen 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 zu, damit 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 clusterNetwork.pods.cidrBlocks für den Cluster auf den Standardwert /16 konfiguriert ist, kann der Cluster ein Limit von 2(23-16)=128 Knoten haben. 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.
- Knoten der Steuerungsebene führen Load-Balancer aus und befinden sich alle im selben Layer-2-Netzwerk. 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
- Eine Verbindung zu Google Cloud ist ebenfalls erforderlich.
Portnutzung
In diesem Abschnitt wird erläutert, wie UDP- und TCP-Ports auf Clusterknoten und Load-Balancer-Knoten verwendet werden.
Masterknoten
| Protokoll | Richtung | Portbereich | Zweck | Verwendet von |
|---|---|---|---|---|
| UDP | Eingehend | 6081 | GENEVE-Kapselung | Self |
| TCP | Eingehend | 22 | Bereitstellung und Aktualisierung von Administratorclusterknoten | Administratorworkstation |
| TCP | Eingehend | 6444 | Kubernetes API-Server | Alle |
| TCP | Eingehend | 2379–2380 | etcd server client-API | kube-apiserver, etcd |
| TCP | Eingehend | 10250 | kubelet API | Self, Steuerungsebene |
| TCP | Eingehend | 10251 | kube-scheduler | Self |
| TCP | Eingehend | 10252 | kube-controller-manager | Self |
| TCP | Beides | 4240 | CNI-Systemdiagnose | Alle |
Worker-Knoten
| Protokoll | Richtung | Portbereich | Zweck | Verwendet von |
|---|---|---|---|---|
| TCP | Eingehend | 22 | Bereitstellung und Aktualisierung von Nutzerclusterknoten | Administratorcluster-Knoten |
| UDP | Eingehend | 6081 | GENEVE-Kapselung | Self |
| TCP | Eingehend | 10250 | kubelet API | Self, Steuerungsebene |
| TCP | Eingehend | 30000 bis 32767 | NodePort-Dienste | Self |
| TCP | Beides | 4240 | CNI-Systemdiagnose | Alle |
Load-Balancer-Knoten
| Protokoll | Richtung | Portbereich | Zweck | Verwendet von |
|---|---|---|---|---|
| TCP | Eingehend | 22 | Bereitstellung und Aktualisierung von Nutzerclusterknoten | Administratorcluster-Knoten |
| UDP | Eingehend | 6081 | GENEVE-Kapselung | Self |
| TCP | Eingehend | 443* | Clusterverwaltung | Alle |
| TCP | Beides | 4240 | CNI-Systemdiagnose | Alle |
| TCP | Eingehend | 7946 | LB-Systemdiagnose | LB-Knoten |
| UDP | Eingehend | 7946 | LB-Systemdiagnose | LB-Knoten |
* 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.
| 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 | Steuerungsebene, LB-Knoten |
* Dieser Port kann in der Clusterkonfiguration mit dem Feld controlPlaneLBPort konfiguriert werden.
firewalld-Ports konfigurieren
Ab den Anthos-Clustern auf Bare-Metal-Version 1.7.0 ist es nicht erforderlich, firewalld zu deaktivieren, um Anthos-Cluster auf Bare-Metal auf 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 Master-, 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-Befehlszeilenclient, öffnen können.
Beispielkonfiguration für Masterknoten
Der folgende Beispielblock von Befehlen zeigt, wie Sie die erforderlichen Ports auf Servern öffnen können, auf denen Masterknoten 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=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 CIDR-Blöcke, die für Ihre Pods reserviert sind, clusterNetwork.pods.cidrBlocks. Der Standard-CIDR-Block für Pods ist 192.168.0.0/16.
Beispielkonfiguration für Worker-Knoten
Der folgende Beispielblock von Befehlen zeigt, 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=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 CIDR-Blöcke, die für Ihre Pods reserviert sind, clusterNetwork.pods.cidrBlocks. Der Standard-CIDR-Block für Pods ist 192.168.0.0/16.
Beispielkonfiguration für Load-Balancer-Knoten
Der folgende Beispielblock von Befehlen zeigt, wie Sie die erforderlichen Ports auf Servern öffnen können, auf denen Load-Balancer-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=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=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 --reloadfirewall-cmd --reload
Ersetzen Sie PODS_CIDR durch die CIDR-Blöcke, die für Ihre Pods reserviert sind, clusterNetwork.pods.cidrBlocks. Der Standard-CIDR-Block für Pods ist 192.168.0.0/16.