In diesem Dokument werden die Netzwerkanforderungen für die Installation und den Betrieb von Google Distributed Cloud beschrieben.
Anforderungen an externe Netzwerke
Google Distributed Cloud erfordert für betriebliche Zwecke eine Internetverbindung. Google Distributed Cloud ruft Clusterkomponenten aus Container Registry ab und der Cluster wird 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 Layer-2- oder Layer-3-Verbindungen zwischen Clusterknoten arbeiten. Die Load-Balancer-Knoten können die Knoten der Steuerungsebene oder eine dedizierte Gruppe von Knoten sein. 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 Ebene-2-Anbindung. Die Anforderung an die Näherung der Ebene 2 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, sodass keine strikte Abhängigkeit von Layer-2 erforderlich ist.
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. Knoten der Steuerungsebene müssen sich außerdem in derselben Ebene-2-Domain befinden.
- Beim gebündelten Layer-2-Load-Balancing müssen sich alle virtuellen IP-Adressen (VIPs) im Subnetz der Load-Balancer-Maschine befinden und an das Gateway des Subnetzes weitergeleitet werden.
- Die Nutzer sind selbst dafür verantwortlich, eingehenden Load-Balancer-Traffic zuzulassen.
Pod-Netzwerke
Mit 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 veranschaulicht eine Reihe wichtiger Netzwerkkonzepte für Google Distributed Cloud in einer möglichen 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 werden die Portanforderungen für Google Distributed Cloud-Cluster beschrieben. Die folgenden Tabellen zeigen, wie UDP- und TCP-Ports von Kubernetes-Komponenten auf Cluster- und Load-Balancer-Knoten verwendet werden.
Knoten der Steuerungsebene
Version 1.28
| Protokoll | Richtung | Portbereich | Zweck | Verwendet von |
|---|---|---|---|---|
| TCP | Eingehend | 22 | Administratorclusterknoten bereitstellen und aktualisieren | 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 -Zustand | 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 | 8443 und 8444 | GKE Identity Service v2 | ais-Deployment wird im Namespace anthos-identity-service ausgeführt |
| TCP | Eingehend | 9100 | Auth-Proxy | node-exporter |
| TCP | Eingehend | 9101 | Knotenmesswerte nur auf localhost bereitstellen (Voraussetzung für Port wurde ab Version 1.28 hinzugefügt.) |
node-exporter |
| TCP | Eingehend | 9977 | Audit-Ereignis vom API-Server erhalten | audit-proxy |
| TCP | Eingehend | 10250 | kubelet API |
Self und Steuerungsebene |
| TCP | Eingehend | 10256 | Knoten-Systemdiagnose | Alle |
| TCP | Eingehend | 10257 | kube-controller-manager Die Portnummer wurde für Version 1.28 und höher geändert. |
Self |
| TCP | Eingehend | 10259 | kube-scheduler (Die Portnummer wurde für Version 1.28 und höher geändert.) |
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 | Administratorclusterknoten bereitstellen und aktualisieren | 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 -Zustand Dies ist für Ports ab Version 1.16 erforderlich. |
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 | Auslieferungsmesswerte | node-exporter |
| TCP | Eingehend | 9443 | Bereitstellungs-/Proxymesswerte für Komponenten der Steuerungsebene (Diese Portanforderung gilt für Clusterversion 1.16 und niedriger.) | kube-control-plane-metrics-proxy |
| TCP | Eingehend | 9977 | Audit-Ereignis vom API-Server erhalten | 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 | Administratorclusterknoten bereitstellen und aktualisieren | 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 | Auslieferungsmesswerte | node-exporter |
| TCP | Eingehend | 9443 | Bereitstellungs-/Proxymesswerte für Komponenten der Steuerungsebene (Diese Portanforderung gilt für Clusterversion 1.16 und niedriger.) | kube-control-plane-metrics-proxy |
| TCP | Eingehend | 9977 | Audit-Ereignis vom API-Server erhalten | 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.28
| Protokoll | Richtung | Portbereich | Zweck | Verwendet von |
|---|---|---|---|---|
| TCP | Eingehend | 22 | Nutzerclusterknoten bereitstellen und aktualisieren | 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 (Voraussetzung für Port wurde ab Version 1.28 hinzugefügt.) |
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 | Nutzerclusterknoten bereitstellen und aktualisieren | Administratorcluster-Knoten |
| TCP | Beides | 4240 | CNI-Systemdiagnose | Alle |
| UDP | Eingehend | 6081 | GENEVE-Kapselung | Self |
| TCP | Eingehend | 9100 | Auslieferungsmesswerte | 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 | Nutzerclusterknoten bereitstellen und aktualisieren | Administratorcluster-Knoten |
| TCP | Beides | 4240 | CNI-Systemdiagnose | Alle |
| UDP | Eingehend | 6081 | GENEVE-Kapselung | Self |
| 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.28
| Protokoll | Richtung | Portbereich | Zweck | Verwendet von |
|---|---|---|---|---|
| TCP | Eingehend | 22 | Nutzerclusterknoten bereitstellen und aktualisieren | Administratorcluster-Knoten |
| TCP | Eingehend | 443 | Clusterverwaltung Dieser Port kann in der Clusterkonfiguration über das Feld |
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 |
Version 1.16
| Protokoll | Richtung | Portbereich | Zweck | Verwendet von |
|---|---|---|---|---|
| TCP | Eingehend | 22 | Nutzerclusterknoten bereitstellen und aktualisieren | Administratorcluster-Knoten |
| TCP | Eingehend | 443 | Clusterverwaltung Dieser Port kann in der Clusterkonfiguration über das Feld |
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 | Nutzerclusterknoten bereitstellen und aktualisieren | Administratorcluster-Knoten |
| TCP | Eingehend | 443 | Clusterverwaltung Dieser Port kann in der Clusterkonfiguration über das Feld |
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 über das Feld |
Knoten der Steuerungsebene und der Load-Balancer |
firewalld-Ports konfigurieren
Sie müssen die Firewall nicht deaktivieren, um Google Distributed Cloud unter Red Hat Enterprise Linux (RHEL) auszuführen. Wenn Sie „firewalld“ verwenden möchten, müssen Sie die von Steuerungsebenen-, Worker- und Load-Balancer-Knoten verwendeten UDP- und TCP-Ports öffnen, wie unter Portnutzung auf dieser Seite beschrieben. Die folgenden Beispielkonfigurationen zeigen, wie Sie Ports mit firewall-cmd, dem Befehlszeilendienstprogramm mit Firewall, ö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=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.
Portkonfiguration bestätigen
Führen Sie zum Prüfen der Portkonfiguration die folgenden Schritte auf Knoten der Steuerungsebene, Worker und Load-Balancer aus:
Führen Sie den folgenden Network Mapper-Befehl aus, um zu sehen, welche Ports offen sind:
nmap localhostFühren Sie die folgenden Befehle aus, um Ihre Firewall-Konfigurationseinstellungen abzurufen:
firewall-cmd --zone=public --list-all-policies firewall-cmd --zone=public --list-ports firewall-cmd --zone=public --list-services firewall-cmd --zone=k8s-pods --list-all-policies firewall-cmd --zone=k8s-pods --list-ports firewall-cmd --zone=k8s-pods --list-servicesFühren Sie bei Bedarf die Befehle aus den vorherigen Abschnitten noch einmal aus, um die Knoten richtig zu konfigurieren. Möglicherweise müssen Sie die Befehle als Root-Nutzer ausführen.
Bekanntes Problem bei Firewalld
Wenn Sie Google Distributed Cloud mit aktiviertem firewalld unter Red Hat Enterprise Linux (RHEL) ausführen, können durch Änderungen an firewalld die Cilium-iptables-Ketten im Hostnetzwerk entfernt werden. Die iptables-Ketten werden vom Pod anetd beim Start hinzugefügt. Der Verlust der Cilium-iptables-Ketten führt dazu, dass der Pod auf dem Knoten die Netzwerkverbindung außerhalb des Knotens verliert.
Zu den Änderungen an firewalld, durch die die iptables-Ketten entfernt werden, gehören unter anderem:
firewalldmitsystemctlneu startenfirewalldmit dem Befehlszeilenclient (firewall-cmd --reload) aktualisieren
Wenn Sie firewalld-Änderungen anwenden möchten, ohne iptables-Ketten zu entfernen, starten Sie anetd auf dem Knoten neu:
Suchen und löschen Sie den
anetd-Pod mit den folgenden Befehlen, umanetdneu zu starten:kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZErsetzen Sie ANETD_XYZ durch den Namen des
anetd-Pods.