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 funktioniert mit L2- oder L3-Verbindungen zwischen Clusterknoten und erfordert, dass sich die Knoten des Load-Balancers in derselben L2-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 L2-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 L2-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.
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.
- Auf den Knoten der Steuerungsebene werden Load-Balancer ausgeführt. Sie befinden sich alle im selben L2-Netzwerk, während für andere Verbindungen (einschließlich Worker-Knoten) nur eine L3-Verbindung erforderlich ist.
- Konfigurationsdateien definieren IP-Adressen für Worker-Knotenpools sowie virtuelle IP-Adressen für Dienste, für eingehenden Traffic und für Steuerungsebenenzugriff (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 | 443 | Clusterverwaltung | Administratorcluster-Knoten |
| TCP | Eingehend | 6443 | Kubernetes API-Server | Alle |
| TCP | Eingehend | 6444 | Steuerungsebene HA | 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 |
|---|---|---|---|---|
| UDP | Eingehend | 6081 | GENEVE-Kapselung | Self |
| TCP | Eingehend | 6444 | Kubernetes API-Server | Alle |
| TCP | Beides | 4240 | CNI-Systemdiagnose | Alle |
| TCP | Eingehend | 7946 | LB-Systemdiagnose | LB-Knoten |
| UDP | Eingehend | 7946 | LB-Systemdiagnose | LB-Knoten |