Auf dieser Seite werden Parameter für Dienstmanifeste beschrieben, die das Verhalten und die Konfiguration des LoadBalancer-Dienstes steuern. Bevor Sie diese Seite lesen, sollten Sie mit den Konzepten der LoadBalancer-Dienste für Google Kubernetes Engine (GKE) vertraut sein.
Dienstparameter
GKE unterstützt die folgenden Parameter für LoadBalancer-Dienste.
| Parameter | Dienstfeld und -beschreibung | Intern | Extern | Versionsunterstützung |
|---|---|---|---|---|
| Interner Passthrough-Network-Load-Balancer | networking.gke.io/load-balancer-type: "Internal"
Weist GKE an, einen internen Passthrough-Network-Load-Balancer zu erstellen. Weitere Informationen finden Sie unter Konzepte des LoadBalancer-Dienstes. |
Alle unterstützten Versionen. | ||
| Backend-Dienst-basierter externer Passthrough-Network-Load-Balancer | cloud.google.com/l4-rbs: "enabled"
Weist GKE an, einen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer zu erstellen. Weitere Informationen finden Sie unter Konzepte des LoadBalancer-Dienstes. |
GKE 1.25.5+ | ||
| Richtlinie für internen Traffic | spec.internalTrafficPolicy
Wenn Dieser Parameter wird nicht für Cluster unterstützt, auf denen GKE Dataplane V2 ausgeführt wird. |
GKE ab Version 1.22 | ||
| Richtlinie für externen Traffic | spec.externalTrafficPolicy
Steuert, welche Knoten-VMs Systemdiagnosen des Load-Balancers bestehen und wie Pakete an Bereitschafts- und Bereitstellungs-Pods im Cluster weitergeleitet werden. Steuert auch, wie Knoten in Weitere Informationen finden Sie unter Konzepte des LoadBalancer-Dienstes. |
GKE 1.14 und höher (1.23.4-gke.400 und höher für Windows-Knotenpool) | ||
| Systemdiagnose-Port | spec.healthCheckNodePort
Stellt eine Load-Balancer-Systemdiagnose für LoadBalancer-Dienste bereit. Dieser Parameter ist nur gültig, wenn |
Alle unterstützten Versionen. | ||
| Firewallregeln und Zulassungsliste für Quell-IP-Adressen | spec.loadBalancerSourceRanges
Konfiguriert optionale Firewallregeln in GKE und im der VPC-netzwerk, um nur bestimmte Quellbereiche zuzulassen |
Alle unterstützten Versionen. | ||
| Statische IP-Adressen |
Gibt eine statische IPv4-Adresse, einen statischen IPv6-Adressbereich oder beides an, die den Weiterleitungsregeln des Load-Balancers zugewiesen sind. Wichtige Konfigurationsanforderungen und Implementierungsdetails finden Sie unter Überlegungen zur Freigabe einer gemeinsamen IP-Adresse. |
|
||
| Netzwerkdienststufen | cloud.google.com/network-tier
Gibt an, welche Netzwerkdienststufen GKE für die externe Weiterleitungsregel und IP-Adresse verwendet. Gültige Annotationswerte sind |
GKE 1.19 und höher. | ||
| Benutzerdefiniertes Subnetz |
|
(nur für IPv6) |
|
|
| Globaler Zugriff | networking.gke.io/internal-load-balancer-allow-global-access: "true"
Ermöglicht, dass die IP-Adresse der Weiterleitungsregel für Clients in jeder Region des VPC-Netzwerks oder eines angeschlossenen Netzwerks zugänglich ist. |
Vorschau in GKE 1.16 und höher. Allgemein verfügbar in GKE 1.17.9-gke.600 und höher. | ||
| Alle Ports | Es ist keine Annotation erforderlich, aber die GKE-Teileinstellung muss aktiviert sein. GKE konfiguriert die Weiterleitungsregel automatisch für die Verwendung aller Ports, wenn in |
GKE-Version 1.18.19-gke.1400 oder höher | ||
| ipFamilyPolicy |
Definiert, wie GKE einem Service IP-Adressen zuweist.
Sie können Weitere Informationen finden Sie unter IPv4/IPv6-Dual-Stack-Dienste. |
GKE-Cluster in Version 1.29 oder höher unterstützen Dual-Stack-Netzwerke für LoadBalancer-Dienste. | ||
| ipFamilies (optional) |
Definiert die IP-Adressfamilie, um entweder Single-Stack- oder Dual-Stack-Dienste zuzuweisen. Verwende einen der folgenden Werte:
|
GKE-Cluster in Version 1.29 oder höher unterstützen Dual-Stack-Netzwerke für LoadBalancer-Dienste. |
Systemdiagnose-Port
Wie unter Load-Balancer-Systemdiagnosen und externalTrafficPolicy beschrieben, stellt GKE immer eine Load-Balancer-Systemdiagnose bereit, wenn ein externer Passthrough-Network-Load-Balancer oder ein interner Passthrough-Network-Load-Balancer erstellt wird.
Ob Sie den Parameter healthCheckNodePort einrichten können, hängt von der folgenden externalTrafficPolicy-Konfiguration ab:
externalTrafficPolicy |
Systemdiagnose-Port |
|---|---|
Cluster |
Sie können |
Local |
Sie können einen benutzerdefinierten Port mit |
Firewallregeln und Zulassungsliste für Quell-IP-Adressen
Wenn Sie einen LoadBalancer-Dienst erstellen, erstellt GKE eine VPC-Firewallregel, die dem Dienst entspricht. Jede Firewallregel hat die folgenden Eigenschaften:
- Die Richtung der Firewallregel ist „ingress” und ihre Aktion ist „allow”. Die implizierte Firewallregel zum Ablehnen von eingehendem Traffic in Google Cloud bedeutet, dass GKE ein Modell auf der Zulassungsliste verwendet, wenn Sie Firewallregeln für eingehenden Traffic erstellen.
- GKE legt das Protokoll und den Zielport der Firewallregel auf diejenigen fest, die in der
spec.ports[]-Liste des Dienstes angegeben sind. - GKE legt das Ziel für die Firewallregel fest. Dazu legt es den Zielparameter auf die virtuelle IP-Adresse des Load Balancers fest.
- Wenn der Dienst
spec.loadBalancerSourceRanges[]enthält, legt GKE den Quellparameter der Firewallregel auf die IP-Adressen in dieser Liste fest. Wenn der ServiceloadBalancerSourceRanges[]nicht enthält, legt GKE den Quellparameter der Firewallregel auf alle IP-Adressen(0.0.0.0/0)fest.
Die für einen Load Balancer-Dienst erstellte Firewallregel erlaubt Pakete, die dem Protokoll und den Zielports dieses Dienstes entsprechen, an die virtuelle IP-Adresse des Dienstes.
Dienste mit gemeinsamen Ports
Wenn ein Cluster zwei oder mehr Dienste enthält, die mindestens ein gemeinsames Protokoll und einen Zielport haben, ist der effektive Satz von Quellbereichen die Vereinigung von loadBalancerSourceRanges für alle Dienste, die dieses Protokoll und diese Zielportkombination angeben. Dies liegt daran, dass der Zielparameter einer Firewallregel für eingehenden Traffic die Ziel-IP-Adressen als alle IP-Adressen definiert, die einer VM zugeordnet sind.
Betrachten Sie einen Cluster mit zwei LoadBalancer-Diensten:
- Der
spec.ports[0].portdes ersten Service ist der TCP-Port80und seinspec.loadBalancerSourceRanges=[100.10.0.0/16]. Der resultierende Load-Balancer, der diesem Dienst entspricht, hat die IP-Adresse192.0.2.2. - Der
spec.ports[0].portdes zweiten Diensts ist der TCP-Port80,spec.ports[1].portist der TCP-Port90und seinespec.loadBalancerSourceRanges=[172.16.0.0/24]. Der resultierende Load-Balancer, der diesem Dienst entspricht, hat die IP-Adresse198.51.100.3.
GKE erstellt zwei Firewallregeln für zulässigen eingehenden Traffic im Virtual Private Cloud-Netzwerk des Clusters. Beide Firewallregeln geben alle Knoten des Clusters als Ziele an:
- Die erste Firewallregel lässt Pakete an den TCP-Zielport
80aus der Quelle100.10.0.0/16zu. - Die zweite Firewallregel lässt Pakete an die TCP-Zielports
80und90aus der Quelle172.16.0.0/24zu.
Die erste Weiterleitungsregel leitet den Traffic weiter, der mit dem Ziel 192.0.2.2:80 übereinstimmt. Die zweite Weiterleitungsregel leitet den Traffic weiter, der mit den Zielen 198.51.100.3:80 und 198.51.100.3:90 übereinstimmt. Alle drei der folgenden Ziele sind gültige Ziele auf jedem Knoten: 192.0.2.2:80, 198.51.100.3:80 und 198.51.100.3:90. Das bedeutet:
- Beide Dienste akzeptieren Pakete zum TCP-Port
80aus der Vereinigung der IP-Adressbereichsquellbereiche entweder aus100.10.0.0/16oder172.16.0.0/24. - Der zweite Dienst akzeptiert Pakete an den TCP-Port
90von172.16.0.0/24.
Der effektive Satz von Quellbereichen für alle Dienste mit derselben Protokoll- und Zielportkombination wird zu allen IP-Adressen, wenn spec.loadBalancerSourceRanges für mindestens einen Dienst mit dieser Protokoll- und Zielportkombination ausgelassen wird. Wenn beispielsweise der zweite Dienst spec.loadBalancerSourceRanges weggelassen hat, lautet die Quelle der zweiten Firewall 0.0.0.0/0.
- Beide Dienste akzeptieren Pakete an den TCP-Port 80 aus der Vereinigung der IP-Adressbereiche von
100.10.0.0/16oder0.0.0.0/0. Da der Bereich0.0.0.0/0den Bereich100.10.0.0/16enthält, ist die effektive Quelle für Pakete an TCP-Port 80 eine beliebige IP-Adresse. - Der zweite Dienst akzeptiert Pakete an den TCP-Port
90von0.0.0.0/0(beliebige IP-Adresse).
Statische IP-Adressen
Sie können eine statische IP-Adresse erstellen und GKE so konfigurieren, dass diese der Weiterleitungsregel des Load-Balancers zugewiesen wird. Durch die Verwendung einer statischen IP-Adresse wird sichergestellt, dass die IP-Adresse des Load-Balancers gleich bleibt, auch wenn Sie Änderungen am LoadBalancer-Dienst vornehmen.
Ohne eine statische IP-Adresse weist GKE der Weiterleitungsregel des Load-Balancers möglicherweise eine andere IP-Adresse zu, wenn Sie einen LoadBalancer-Dienst aktualisieren. Die IP-Adresse der Weiterleitungsregel ist nicht mit der Adresse spec.clusterIP des Dienstes identisch. Die ClusterIP-Adresse für einen Dienst ändert sich nie, wenn Sie einen LoadBalancer-Dienst aktualisieren.
Parameter für statische IP-Adressen
Um einen LoadBalancer-Dienst anzuweisen, eine statische IP-Adresse zu verwenden, verwenden Sie entweder den Parameter spec.loadBalancerIP oder die Annotation networking.gke.io/load-balancer-ip-addresses. Ab GKE-Version 1.29 hat die Annotation Vorrang vor spec.loadBalancerIP, wenn das Dienstmanifest sowohl den Parameter als auch die Annotation enthält.
| Parameter oder Annotation und Wert | Anforderungen und Funktionen |
|---|---|
spec.loadBalancerIP:IPv4_ADDRESS
|
Sie können eine statische interne IPv4-Adresse für einen reinen IPv4-LoadBalancer-Dienst angeben. Sie können eine statische externe IPv4-Adresse für einen reinen IPv4-LoadBalancer-Dienst angeben. Der Parameter funktioniert mit allen unterstützten GKE-Versionen. |
networking.gke.io/load-balancer-ip-addresses:IP_ADDRESS_RESOURCE_NAME
|
Sie können eine statische IPv4-Adresse, einen statischen IPv6-Adressbereich oder beides für reine IPv4-, nur IPv6- und Dual-Stack-interne und externe LoadBalancer-Dienste angeben. Für die Annotation sind GKE 1.29 oder höher und die folgenden zusätzlichen Anforderungen erforderlich:
|
Hinweise zur Freigabe einer gemeinsamen IP-Adresse
Zwei oder mehr LoadBalancer-Dienste können auf dieselbe statische IP-Adresse verweisen, wenn die Weiterleitungsregel für jeden Load-Balancer eine eindeutige Kombination aus IP-Adresse, Protokoll, Portspezifikation und Netzwerkdienststufen-Spezifikation verwendet, wie in der Tabelle in diesem Abschnitt angegeben. Außerdem:
Statische IPv6-Adressen sind tatsächlich
/96-IPv6-Adressbereiche. GKE konfiguriert jedoch nur Knoten so, dass sie Pakete an der ersten IPv6-Adresse (/128) im Bereich/96akzeptieren.Damit zwei oder mehr interne LoadBalancer-Dienste dieselbe interne IPv4-Adresse oder denselben internen IPv6-Adressbereich verwenden können, muss die statische IP-Adresse mit dem Zweck
SHARED_LOADBALANCER_VIPerstellt werden.
| Interner LoadBalancer-Dienst | Externer LoadBalancer-Dienst | |
|---|---|---|
| Portspezifikation | Weiterleitungsregeln für interne Passthrough-Network Load Balancer unterstützen bis zu fünf separate Portnummern oder können so konfiguriert werden, dass sie alle Ports verwenden. Wenn für einen internen LoadBalancer-Dienst sechs oder mehr Wenn eine Weiterleitungsregel alle Ports verwendet, kann keine andere Weiterleitungsregel (d. h. kein anderer interner LoadBalancer-Dienst) dieselbe IP-Adresse verwenden. |
GKE erstellt einen zielpoolbasierten externen Passthrough-Network Load Balancer, wenn das LoadBalancer-Dienstmanifest die Annotation Weiterleitungsregeln für zielpoolbasierte externe Passthrough-Network Load Balancer müssen zusammenhängende Portbereiche verwenden. Der zusammenhängende Portbereich umfasst alle Ports, die der Dienst benötigt, aber der Bereich kann auch zusätzliche Ports enthalten, die vom Dienst nicht verwendet werden. Beispiel: Ein externer LoadBalancer-Dienst, der von einem zielpoolbasierten externen Passthrough-Network Load Balancer bereitgestellt wird und in seinem Dienstmanifest die Ports 80 und 443 angibt, verwendet eine Weiterleitungsregel für den Load-Balancer mit einem Portbereich von 80–443. Dieser Portbereich verhindert, dass andere externe LoadBalancer-Dienste einen der Ports 80, 443 und eine der Zahlen zwischen 80 und 443 verwenden. GKE erstellt einen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer, wenn das LoadBalancer-Dienstmanifest die Annotation |
| Netzwerkdienststufen | Nicht konfigurierbar – interne Adressen sind immer Premium-Stufe. | Konfigurierbar für statische regionale, externe IPv4-Adressen. Statische regionale externe IPv6-Adressbereiche können nur in der Premium-Stufe erstellt werden. Die Netzwerkdienststufen-Spezifikation der statischen externen IP-Adresse muss mit einem der Folgenden übereinstimmen:
Die Standardstufe des Projekts ist Premium, sofern Sie sie nicht anders konfiguriert haben. |
LoadBalancer-Subnetz
Sie können einen internen LoadBalancer-Dienst so konfigurieren, dass eine sitzungsspezifische oder statische IPv4-Adresse, ein IPv6-Adressbereich oder beides in einem benutzerdefinierten Subnetz verwendet wird, das sich in derselben Region und demselben VPC-Netzwerk wie der Cluster befindet. Verwenden Sie ein benutzerdefiniertes Subnetz für einen internen LoadBalancer-Dienst, um:
- Gruppieren Sie interne Passthrough-Network Load Balancer, die von internen LoadBalancer-Diensten aus zwei oder mehr GKE-Clustern im selben VPC-Netzwerk und in derselben Region erstellt wurden.
- Erstellen Sie interne LoadBalancer-Dienste, deren interne Passthrough-Network Load Balancer IPv4-Adressen haben, die von den IPv4-Adressen des Knotens getrennt sind.
- Erstellen Sie in einem Dual-Stack-Cluster interne LoadBalancer-Dienste, deren interne Passthrough-Network-Load-Balancer IPv6-Adressbereiche haben, die vom Knoten und den Pod-IPv6-Adressen des Clusters getrennt sind. Ein benutzerdefiniertes LoadBalancer-Subnetz ist obligatorisch, um interne LoadBalancer-Dienste zu unterstützen, wenn das Subnetz des Clusters einen externen IPv6-Adressbereich hat.
Sie können einen externen LoadBalancer-Dienst so konfigurieren, dass er einen sitzungsspezifischen oder statischen IPv6-Adressbereich in einem benutzerdefinierten Subnetz verwendet, das sich in derselben Region und demselben VPC-Netzwerk wie der Cluster befindet. Verwenden Sie ein benutzerdefiniertes Subnetz, um externe LoadBalancer-Dienste zu erstellen, deren externe Passthrough-Network-Load-Balancer IPv6-Adressbereiche haben, die von den Knoten- und Pod-IPv6-Adressen des Clusters getrennt sind. Ein benutzerdefiniertes LoadBalancer-Subnetz ist obligatorisch, um externe LoadBalancer-Dienste in einem privaten Dual-Stack-Cluster zu unterstützen, da das Subnetz des Clusters einen internen IPv6-Adressbereich hat.
Benutzerdefinierte Subnetzannotationen
Verwenden Sie eine der folgenden Annotationen, um einen LoadBalancer-Dienst anzuweisen, eine sitzungsspezifische oder statische IP-Adresse in einem benutzerdefinierten Subnetz zu verwenden. Wenn ein LoadBalancer-Dienstmanifest beide Annotationen enthält, hat die Annotation networking.gke.io/load-balancer-subnet Vorrang, sofern ihre Annotationsanforderungen erfüllt sind.
| Anmerkung und Wert | Anforderungen und Funktionen |
|---|---|
networking.gke.io/internal-load-balancer-subnet:SUBNET_RESOURCE_NAME
|
Sie können die Annotation nur verwenden, um ein benutzerdefiniertes Subnetz für einen reinen IPv4-LoadBalancer-Dienst anzugeben. Die Annotation funktioniert mit allen unterstützten GKE-Versionen. |
networking.gke.io/load-balancer-subnet:SUBNET_RESOURCE_NAME
|
Sie können ein benutzerdefiniertes Subnetz für einen reinen IPv4-, reinen IPv6- oder Dual-Stack-Dienst für den internen LoadBalancer angeben. Sie können ein benutzerdefiniertes Subnetz für einen externen IPv6- oder Dual-Stack-LoadBalancer-Dienst angeben. Für die Annotation sind GKE 1.29 oder höher und die folgenden zusätzlichen Anforderungen erforderlich:
|
Subnetz und IPv4-Adresse für einen internen LoadBalancer-Dienst
In der folgenden Tabelle werden gültige Subnetzspezifikationen und IPv4-Adresskombinationen für einen internen IPv4- oder Dual-Stack-LoadBalancer-Dienst beschrieben.
Statische IPv4-Adresse
|
Sitzungsspezifische IPv4-Adresse | |
|---|---|---|
Benutzerdefiniertes Subnetz
|
Benutzerdefiniertes Subnetz und statische IPv4-Adresse: Die statische interne IPv4-Adresse muss im primären IPv4-Adressbereich des benutzerdefinierten Subnetzes erstellt worden sein. | Benutzerdefiniertes Subnetz und sitzungsspezifische IPv4-Adresse: GKE verwendet eine nicht zugewiesene interne IPv4-Adresse im primären IPv4-Adressbereich des benutzerdefinierten Subnetzes. |
| Clustersubnetz | Clustersubnetz und statische IPv4-Adresse: Die statische interne IPv4-Adresse muss im primären IPv4-Adressbereich des Clustersubnetzes erstellt worden sein. | Clustersubnetz und sitzungsspezifische IPv4-Adresse: GKE verwendet eine nicht zugewiesene interne IPv4-Adresse im primären IPv4-Adressbereich des Clustersubnetzes. |
Subnetz und IPv6-Adressbereich für einen internen LoadBalancer-Dienst
In der folgenden Tabelle werden gültige Kombinationen von Subnetzspezifikationen und IPv6-Adressbereichen für einen internen IPv6- oder Dual-Stack-LoadBalancer-Dienst beschrieben. Obwohl die IPv6-Weiterleitungsregel des internen Passthrough-Netzwerk-Load-Balancers den internen IPv6-Adressbereich /96 verwendet, konfiguriert GKE nur Knoten so, dass Pakete akzeptiert werden, deren Ziele mit der ersten IPv6-Adresse (/128) des /96-Bereichs der Weiterleitungsregel übereinstimmen.
Statischer IPv6-Adressbereich
|
Sitzungsspezifischer IPv6-Adressbereich | |
|---|---|---|
Benutzerdefiniertes Dual-Stack-Subnetz
|
Benutzerdefiniertes Subnetz und statischer IPv6-Adressbereich: Der statische interne IPv6-Adressbereich /96 muss im internen IPv6-Adressbereich /64 des benutzerdefinierten Subnetzes erstellt worden sein.
|
Benutzerdefiniertes Subnetz und sitzungsspezifischer IPv6-Adressbereich: GKE verwendet einen nicht zugewiesenen internen /96-IPv6-Adressbereich aus dem internen /64-IPv6-Adressbereich des benutzerdefinierten Subnetzes.
|
Dual-Stack-Cluster-Subnetz
|
Clustersubnetz und statischer IPv6-Adressbereich: Der statische interne IPv6-Adressbereich /96 muss im internen IPv6-Adressbereich /64 des Clustersubnetzes erstellt worden sein.
|
Clustersubnetz und sitzungsspezifischer IPv6-Adressbereich: GKE verwendet einen nicht zugewiesenen internen /96-IPv6-Adressbereich aus dem internen /64-IPv6-Adressbereich des Clustersubnetzes.
|
Subnetz und IPv4-Adresse für einen externen LoadBalancer-Dienst
Bei externen reinen IPv4- und Dual-Stack-LoadBalancer-Diensten kommt die externe IPv4-Adresse – ob eine statische externe IPv4-Adresse oder eine sitzungsspezifische externe IPv4-Adresse – nicht aus einem Subnetz.
Subnetz- und IPv6-Adressbereich für einen externen LoadBalancer-Dienst
In der folgenden Tabelle werden gültige Kombinationen von Subnetzspezifikationen und IPv6-Adressbereichen für einen externen IPv6- oder Dual-Stack-LoadBalancer-Dienst beschrieben. Obwohl die IPv6-Weiterleitungsregel des externen Passthrough-Netzwerk-Load-Balancers den externen IPv6-Adressbereich /96 verwendet, konfiguriert GKE nur Knoten so, dass Pakete akzeptiert werden, deren Ziele mit der ersten IPv6-Adresse (/128) des /96-Bereichs der Weiterleitungsregel übereinstimmen.
Statischer IPv6-Adressbereich
|
Sitzungsspezifischer IPv6-Adressbereich | |
|---|---|---|
Benutzerdefiniertes Dual-Stack-Subnetz
|
Benutzerdefiniertes Subnetz und statischer IPv6-Adressbereich: Der statische externe IPv6-Adressbereich /96 muss im externen IPv6-Adressbereich /64 des benutzerdefinierten Subnetzes erstellt worden sein. Statische externe IPv6-Adressbereiche können nur in der Premium-Stufe erstellt werden.
|
Benutzerdefiniertes Subnetz und sitzungsspezifischer IPv6-Adressbereich: GKE verwendet einen nicht zugewiesenen externen /96-IPv6-Adressbereich aus dem externen /64-IPv6-Adressbereich des benutzerdefinierten Subnetzes.
|
Dual-Stack-Cluster-Subnetz
|
Clustersubnetz und statischer IPv6-Adressbereich: Der statische externe IPv6-Adressbereich /96 muss im externen IPv6-Adressbereich /64 des Clustersubnetzes erstellt worden sein. Statische externe IPv6-Adressbereiche können nur in der Premium-Stufe erstellt werden.
|
Clustersubnetz und sitzungsspezifischer IPv6-Adressbereich: GKE verwendet einen nicht zugewiesenen externen /96-IPv6-Adressbereich aus dem externen /64-IPv6-Adressbereich des Clustersubnetzes.
|
Globaler Zugriff
Wenn die Annotation networking.gke.io/internal-load-balancer-allow-global-access für einen internen LoadBalancer-Dienst false ist oder nicht angegeben ist, erstellt GKE einen internen Passthrough-Network-Load-Balancer, dessen Weiterleitungsregel den globalen Zugriff deaktiviert hat. Wenn der globale Zugriff deaktiviert ist, müssen sich Clients, die auf den Load-Balancer zugreifen müssen, in derselben Region und demselben VPC-Netzwerk oder in einem Netzwerk befinden, das mit dem VPC-Netzwerk des Clusters verbunden ist.
Wenn die Annotation networking.gke.io/internal-load-balancer-allow-global-access für einen internen LoadBalancer-Dienst true lautet, aktiviert GKE die globale Zugriffsoption für die Weiterleitungsregel des internen Passthrough-Network-Load-Balancers.
Clients, die sich in einer beliebigen Region des VPC-Netzwerks oder einem Netzwerk befinden, das mit dem VPC-Netzwerk des Clusters verbunden ist, können auf den Load-Balancer zugreifen.
Weitere Informationen zum globalen Zugriff gelten für Clients in einem verbundenen Netzwerk:
- Clientzugriff in der Dokumentation zum internen Passthrough-Network-Load-Balancer
- Interne Passthrough-Network-Load-Balancer und verbundene Netzwerke
Alle Portweiterleitungsregeln
Weiterleitungsregeln für interne Passthrough-Network-Load-Balancer unterstützen fünf eindeutige Portnummern oder alle Ports.
In GKE-Clustern mit deaktivierter GKE-Teileinstellung kann ein interner LoadBalancer-Dienst nur fünf eindeutige Ports in der Datei spec.ports[].port des Dienstes unterstützen.
In GKE-Clustern mit aktivierter GKE-Teileinstellung kann ein interner LoadBalancer-Dienst nur bis zu 100 Ports im spec.ports[].port des Dienstes unterstützen. Für interne LoadBalancer-Dienste mit sechs bis 100 eindeutigen spec.ports[].port-Einträgen konfiguriert GKE die Weiterleitungsregel des internen Passthrough-Network-Load-Balancers so, dass alle Ports seit der Erstellung verwendet werden. Der GKE-Controller aktiviert alle Ports in der Weiterleitungsregel, da der Dienst mehr als fünf Ports hat. Wenn Sie eine Weiterleitungsregel für die Verwendung aller Ports konfigurieren, erstellt GKE nur Firewallregeln für zulässigen eingehenden Traffic für die spezifischen Ports, die in spec.ports[].port für den Service konfiguriert sind.
Weitere Informationen zu Weiterleitungsregeln des internen Passthrough-Network-Load-Balancers und zu gültigen Portspezifikationen finden Sie unter Weiterleitungsregeln und Portspezifikationen.
IPv4/IPv6-Dual-Stack-LoadBalancer-Dienst
Sie können einen internen oder externen LoadBalancer-Dienst erstellen, der Single-Stack (nur IPv4 oder nur IPv6) oder Dual-Stack sein kann. Single-Stack-LoadBalancer-Dienste erstellen eine einzelne Weiterleitungsregel mit einer IPv4-Adresse oder einer IPv6-Adresse. Dual-Stack-LoadBalancer-Dienste erstellen zwei Weiterleitungsregeln: eine mit einer IPv4-Adresse und eine mit einer IPv6-Adresse. Erstellen Sie einen IPv4/IPv6-Dual-Stack-Dienst auf einem IPv4/IPv6-Dual-Stack-Cluster und führen Sie je nach verwendetem Load-Balancer einen der folgenden Schritte aus:
- Für interne LoadBalancer-Dienste muss die GKE-Teilmengeneinstellung aktiviert sein. Weitere Informationen finden Sie unter Teilmengeneinstellung der internen Load Balancer.
- Für externe LoadBalancer-Dienste müssen Sie einen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer verwenden, der regionale Backend-Dienste nutzt. Weitere Informationen finden Sie unter Backend-Dienst-basierter externer Netzwerk-Load Balancer.
Für jeden Service können Sie die Spezifikationen ipFamilyPolicy und ipFamilies definieren. Weitere Informationen finden Sie unter IPv4/IPv6-Dual-Stack.
Einschränkungen von Dual-Stack-LoadBalancer-Diensten
- LoadBalancer-Dienste mit IPv6-Adressen werden nur auf Clustern mit dem Stacktyp
ipv4-ipv6unterstützt. Weitere Informationen finden Sie unter Dual-Stack-IP-Adresse für einen VPC-nativen Cluster verwenden. LoadBalancer-Dienste, die mit einer Single-Stack-Adresse erstellt wurden, können nicht auf Dual-Stack-Dienste aktualisiert werden.
LoadBalancer-Dienste, die mit Dual-Stack-Adressen erstellt werden, können gemäß den folgenden Bedingungen in einzelne Stacks geändert werden:
- Ein Dienst mit ipFamilies
["IPv4","IPv6"]kann in einen Dienst mit ipFamiliesIPv4geändert werden, jedoch nichtIPv6. - Ein Dienst mit ipFamilies
["IPv6","IPv4"]kann in einen Dienst mit ipFamiliesIPv6, aber nicht inIPv4geändert werden.
- Ein Dienst mit ipFamilies