Damit Sie die Distributed Cloud-Software nur für Bare Metal installieren und betreiben können, muss Ihr Netzwerk die Anforderungen in diesem Dokument erfüllen. Diese Anforderungen umfassen die externe Verbindung zu Google, die Layer-2- und Layer-3-Verbindung zwischen Clusterknoten und Load Balancern, IP-Adressbereiche für Pods und Dienste sowie die Ports, die von Clusterkomponenten verwendet werden. Wenn auf Ihren Knoten Red Hat Enterprise Linux (RHEL) mit firewalld ausgeführt wird, wird in diesem Dokument auch beschrieben, wie Sie die erforderlichen Ports öffnen.
Anforderungen an externe Netzwerke
Für Google Distributed Cloud ist eine Internetverbindung erforderlich. Google Distributed Cloud ruft Clusterkomponenten aus Artifact Registry ab und der Cluster wird bei Connect Agent 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. 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.
Gebündeltes Load Balancing mit BGP unterstützt das Layer-3-Protokoll, sodass keine strikte Layer-2-Adjazenz 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 ebenfalls 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 sind dafür verantwortlich, eingehenden Load-Balancer-Traffic zuzulassen.
Pod- und Dienstnetzwerke
Die für Dienste und Pods verfügbaren IP-Adressbereiche werden in der Clusterkonfigurationsdatei angegeben. In den folgenden Abschnitten werden die Mindest- und Höchstwerte für die Adressbereiche sowie einige der zugehörigen Faktoren erläutert, die Sie bei der Planung Ihrer Clusterinstallation berücksichtigen müssen.
Die Anzahl der Pods und Dienste, die Sie in Ihren Clustern haben können, wird durch die folgenden Einstellungen gesteuert:
clusterNetwork.pods.cidrBlocksgibt die Anzahl der Pods an, die in Ihrem Cluster zulässig sind.clusterNetwork.services.cidrBlocksgibt die Anzahl der Dienste an, die in Ihrem Cluster zulässig sind.nodeConfig.podDensity.maxPodsPerNodeGibt die maximale Anzahl von Pods an, die auf einem einzelnen Knoten ausgeführt werden können.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: admin-basic
namespace: cluster-admin-basic
spec:
type: admin
profile: default
...
clusterNetwork:
pods:
cidrBlocks:
- 192.168.0.0/16
services:
cidrBlocks:
- 10.96.0.0/20
...
nodeConfig:
podDensity:
maxPodsPerNode: 250
IP-Adressbereiche für Pods und Dienste
Sie geben einen IP-Adressbereich als CIDR-Block (Classless Inter-Domain Routing) an, der für Pods verwendet werden soll, und einen weiteren CIDR-Block, der für die ClusterIP-Adressen von Kubernetes-Diensten verwendet wird. Verwenden Sie IP-Adressen im privaten Adressbereich, wie in RFC 1918 beschrieben. Die Clusterkonfigurationsdatei ist mit Werten vorausgefüllt, die innerhalb der in der folgenden Tabelle beschriebenen Limits liegen:
| Limit | Pods | Dienste |
|---|---|---|
| Mindestreichweite | Maskenwert von /18 (16.384 Adressen) |
Maskenwert von /24 (256 Adressen) |
| Vorausgefüllter Bereich | Maskenwert von /16 (65.536 Adressen) |
Maskenwert von /20 (4.096 Adressen) |
| Maximale Reichweite | Maskenwert von /8 (16.777.216 Adressen) |
Maskenwert von /12 (1.048.576 Adressen) |
Verwenden Sie möglicherweise andere CIDR-Bereiche als die vorausgefüllten Werte, um eine Überschneidung mit IP-Adressen zu vermeiden, die in Ihrem Netzwerk erreichbar sind. Insbesondere dürfen sich die Bereiche für Dienste und Pods nicht überschneiden mit:
IP-Adressen von Knoten in einem beliebigen Cluster
Von Knoten der Steuerungsebene und Load-Balancern verwendete VIPs
IP-Adressen von DNS-Servern oder NTP-Servern
Preflight-Prüfungen blockieren die Erstellung und Upgrades von Clustern, wenn sich überschneidende IP-Adressen erkannt werden.
Sie können den Dienstnetzwerkbereich (clusterNetwork.services.cidrBlocks) nach dem Erstellen eines Clusters erhöhen, aber Sie können die Anzahl der zugewiesenen IP-Adressen nicht reduzieren oder ändern. Sie können nur das Suffix des CIDR-Blocks ändern und den Maskenwert verringern, um die Anzahl der IP-Adressen zu erhöhen.
Sowohl clusterNetwork.pods.cidrBlocks als auch nodeConfig.podDensity.maxPodsPerNode (im folgenden Abschnitt beschrieben) sind unveränderlich. Planen Sie daher das zukünftige Wachstum Ihres Clusters sorgfältig, um zu vermeiden, dass Ihnen die Knotenkapazitäten ausgehen. Die empfohlenen Höchstwerte für Pods pro Cluster, Pods pro Knoten und Knoten pro Cluster basierend auf Tests finden Sie unter Limits.
Maximale Anzahl von Pods pro Knoten
Auf Bare Metal können Sie in Google Distributed Cloud maximal 250 Pods pro Knoten konfigurieren. Jedem Knoten wird in Kubernetes ein CIDR-Block zugewiesen, sodass jeder Pod eine eindeutige IP-Adresse haben kann. Die Größe des Pod-CIDR-Blocks entspricht der maximalen Anzahl von Pods pro Knoten.
In der folgenden Tabelle ist die Größe des CIDR-Blocks aufgeführt, den Kubernetes jedem Knoten basierend auf der konfigurierten maximalen Anzahl von Pods pro Knoten zuweist:
| 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 |
Wenn 250 Pods pro Knoten ausgeführt werden, muss Kubernetes für jeden Knoten einen /23-CIDR-Block reservieren. Wenn Ihr Cluster den Standardwert /16 für das Feld clusterNetwork.pods.cidrBlocks verwendet, hat Ihr Cluster ein Limit von (2(23-16))=128 Knoten.
Wenn Sie den Cluster über dieses Limit hinaus erweitern möchten, empfehlen wir dringend, für clusterNetwork.pods.cidrBlocks einen deutlich größeren Pod-CIDR-Block als den vorausgefüllten Wert festzulegen.
Weitere Informationen dazu, wie sich die Anzahl der Pods und Dienste sowie andere Faktoren auf die Skalierbarkeit von Clustern auswirken, finden Sie unter Google Distributed Cloud-Cluster hochskalieren.
Clusterbereitstellung für einen Nutzer mit Hochverfügbarkeit
Das folgende Diagramm zeigt eine Reihe von wichtigen Netzwerkkonzepten 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. In den folgenden Tabellen wird gezeigt, wie UDP- und TCP-Ports von Kubernetes-Komponenten auf Cluster- und Load-Balancer-Knoten verwendet werden.
Knoten der Steuerungsebene
Version 1.33 und höher
| 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 | 9192 (Standard, kann aber konfiguriert werden) | Node Agent-Port (gilt nur für Cluster, die Node Agent verwenden)
(gilt für Version 1.33 und höher) |
node-agent-port |
| 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.29–1.32
| 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 an den Port gebunden.
(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.33 und höher
| 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 | 9192 (Standard, kann aber konfiguriert werden) | Node Agent-Port (gilt nur für Cluster, die Node Agent verwenden)
(gilt für Version 1.33 und höher) |
node-agent-port |
| TCP | Eingehend | 10250 | kubelet API |
Self und Steuerungsebene |
| TCP | Eingehend | 10256 | Knoten-Systemdiagnose | Alle |
| TCP | Eingehend | 30000 bis 32767 | NodePort Dienste |
Self |
Version 1.29–1.32
| 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.33 und höher
| 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 |
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 | 9192 (Standard, kann aber konfiguriert werden) | Node Agent-Port (gilt nur für Cluster, die Node Agent verwenden)
(gilt für Version 1.33 und höher) |
node-agent-port |
| TCP | Eingehend | 10256 | Knoten-Systemdiagnose | Alle |
| TCP | Eingehend | 11000 | Überwachungsport für HAProxy-Messwerte (unveränderlich)
(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.29–1.32
| 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 |
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 (unveränderlich)
(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 |
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 |
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 |
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 | Bereitstellung und Aktualisierung von Clusterknoten | Alle Knoten |
| TCP | Eingehend | 443 | Kubernetes API-Server für hinzugefügten Cluster Dieser Port kann in der Clusterkonfiguration mit dem Feld |
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 Clusterversion, die Sie verwenden möchten, finden Sie im vorherigen 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 Clusterversion, die Sie verwenden möchten, finden Sie im vorherigen 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 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=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 Clusterversion, die Sie verwenden möchten, finden Sie im vorherigen 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 Knoten eine zusätzliche firewalld-Konfiguration vornehmen, damit Ihre Dienste und Pods ordnungsgemäß funktionieren:
Listen Sie die aktiven Schnittstellen für den Knoten auf, um die Hauptschnittstelle des Knotens zu finden:
firewall-cmd --list-interfacesGemäß den Benennungskonventionen für Linux-Maschinenschnittstellen kann der Name der Hauptschnittstelle so aussehen:
eth0,eno1,ens1oderenp2s0.Listen Sie die Zonen für den Knoten auf, um herauszufinden, welche Zone die Hauptschnittstelle verwendet:
firewall-cmd --list-all-zonesWenn Ihre Hauptschnittstelle beispielsweise
eno1ist, gibt der folgende Abschnitt der Antwort an, dass sich die Hauptschnittstelle in der Zonepublicbefindet:... public (active) target: default icmp-block-inversion: no interfaces: eno1 sources: ...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 --reloadErsetzen Sie
IN_ZONEdurch einen der folgenden Werte, je nachdem, was Sie in den vorherigen Schritten gefunden haben:public: vordefinierte Zone für die Verwendung in öffentlichen Bereichen, in denen nur ausgewählte eingehende Verbindungen akzeptiert werden.trusted: vordefinierte Zone in einer kontrollierten Umgebung, in der alle Netzwerkverbindungen akzeptiert werden.- Der Name einer benutzerdefinierten Zone, die Sie definiert haben.
Folgen Sie der Anbieterdokumentation, um Ihre Speicherlösung zu konfigurieren.
Wenn Sie beispielsweise Portworx zum Verwalten zustandsorientierter Arbeitslasten verwenden, sind in den Portworx-Netzwerkanforderungen Ports aufgeführt, die geöffnet bleiben müssen.
Führen Sie für jeden der in der Dokumentation des Anbieters aufgeführten Ports den folgenden Befehl aus:
firewall-cmd --permanent --zone=public --add-port=PORT_INFOErsetzen Sie
PORT_INFOdurch die Portnummer oder den Portnummernbereich, gefolgt vom Protokoll. Beispiel:10250-10252/tcp.
Portkonfiguration bestätigen
Führen Sie die folgenden Schritte auf Knoten der Steuerungsebene, Worker-Knoten und Load-Balancer-Knoten aus, um die Portkonfiguration zu prüfen:
Führen Sie den folgenden Network Mapper-Befehl aus, um zu sehen, welche Ports geöffnet sind:
nmap localhostFü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-policiesFü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 mit firewalld
Wenn Sie Google Distributed Cloud mit aktiviertem 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 hinzugefügt, wenn er gestartet wird. 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:
firewalldmitsystemctlneu startenfirewalldmit dem Befehlszeilenclient (firewall-cmd --reload) neu laden
Wenn Sie firewalld-Änderungen anwenden möchten, ohne iptables-Ketten zu entfernen, starten Sie anetd auf dem Knoten neu:
Suchen Sie den
anetd-Pod und löschen Sie ihn 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.