Internen Load Balancer erstellen

Auf dieser Seite erfahren Sie, wie Sie einen internen LoadBalancer-Dienst bereitstellen, der einen internen Passthrough-Network-Load-Balancer erstellt. Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Themen vertraut:

Weitere Informationen zu internen Passthrough-Network-Load-Balancern finden Sie unter Übersicht über interne Passthrough-Network-Load-Balancer.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
  • Prüfen Sie, ob Sie einen vorhandenen Autopilot- oder Standardcluster haben. Informationen zum Erstellen eines neuen Clusters finden Sie unter Autopilot-Cluster erstellen.

Voraussetzungen

  • In dieser Anleitung wird spec.loadBalancerClass verwendet, um einen internen Passthrough-Network Load Balancer mit GCE_VM_IP-NEG-Backends zu erstellen. Für diese Anleitung ist die GKE-Version 1.33.1-gke.1779000 oder höher erforderlich, da spec.loadBalancerClass die GKE-Version 1.33.1-gke.1779000 oder höher erfordert.

  • Für die zonale Affinität ist GKE-Version 1.33.3-gke.1392000 und höher erforderlich.

  • Für Ihren Cluster muss die GKE-Teilmengeneinstellung aktiviert sein:

    • Die GKE-Teilmengeneinstellung ist in Clustern mit Version 1.36 und höher standardmäßig aktiviert. Bei diesen Versionen ist das Subsetting unabhängig vom Wert des Subsetting-Flags des Clusters aktiv.

    • In unterstützten GKE-Versionen vor Version 1.36 müssen Sie die GKE-Teilmengeneinstellung explizit aktivieren. Sie können die GKE-Teileinstellung aktivieren, wenn Sie einen neuen Cluster erstellen oder einen vorhandenen Cluster aktualisieren. Nach der Aktivierung kann die GKE-Teilmengeneinstellung nicht mehr deaktiviert werden. Weitere Informationen finden Sie unter GKE-Subsetting überprüfen und aktivieren.

  • Wenn Ihr Cluster eine Version vor 1.36 hat, muss das Add-on HttpLoadBalancing in Ihrem Cluster aktiviert sein. Dieses Add-on ist standardmäßig aktiviert.

GKE-Teileinstellung prüfen und aktivieren

Prüfen Sie, ob die GKE-Teileinstellung aktiviert ist:

  • Die GKE-Teilmengeneinstellung ist in GKE-Version 1.36 und höher immer aktiviert.

  • Sie können die GKE-Teilmengeneinstellung manuell in neuen und vorhandenen Standard- und Autopilot-Clustern aktivieren, auf denen GKE-Version 1.18.19-gke.1400 und höher, aber vor GKE-Version 1.36 ausgeführt wird. Sie können die GKE-Teilmengeneinstellung nicht deaktivieren, nachdem Sie sie aktiviert haben.

Informationen dazu, warum die GKE-Teilmengeneinstellung wichtig ist, finden Sie unter Besondere Überlegungen für interne LoadBalancer-Dienste.

Führen Sie den folgenden Befehl aus, um festzustellen, ob das GKE-Subsetting aktiviert ist:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="get(currentMasterVersion, networkConfig.enableL4ilbSubsetting)"

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des Clusters.
  • LOCATION : Die Zone oder Region des Clusters.

Die Ausgabe des Befehls zeigt die Version der Steuerungsebene des Clusters, gefolgt von True oder False für das Attribut networkConfig.enableL4ilbSubsetting. So interpretieren Sie die Ausgabe:

  • Wenn die Version der Steuerungsebene 1.36 oder höher ist, ist das GKE-Subsetting unabhängig davon aktiviert, ob das Attribut networkConfig.enableL4ilbSubsetting True oder False ist.
  • Wenn die Version der Steuerungsebene vor 1.36 liegt:
    • True bedeutet, dass die GKE-Teilmengeneinstellung aktiviert ist.
    • False bedeutet, dass die GKE-Teilmengeneinstellung deaktiviert ist.

Wenn Sie die GKE-Teilmengeneinstellung in einem Cluster aktivieren möchten, in dem GKE-Version 1.18.19-gke.1400 oder höher, aber vor GKE-Version 1.36 ausgeführt wird, verwenden Sie die gcloud CLI oder die Google Cloud Konsole.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

  3. Klicken Sie unter Netzwerk neben dem Feld Teilmengeneinstellung für interne L4-Load-Balancer auf Teilmengeneinstellung für interne L4-Load-Balancer aktivieren.

  4. Wählen Sie das Kästchen Teilmengeneinstellung für interne L4-Load-Balancer aktivieren aus.

  5. Klicken Sie auf Änderungen speichern.

gcloud

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION
    --enable-l4-ilb-subsetting

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des Clusters.
  • LOCATION : Die Zone oder Region des Clusters.

Wenn Sie die GKE-Teilmengeneinstellung mit der gcloud CLI, derGoogle Cloud -Konsole oder durch Aktualisieren Ihres Clusters auf Version 1.36 oder höher aktivieren, werden vorhandene interne LoadBalancer-Dienste nicht geändert. Wenn Sie einen vorhandenen internen LoadBalancer-Dienst migrieren möchten, um GCE_VM_IP-NEG-Back-Ends zu verwenden, müssen Sie ein Ersatzdienstmanifest bereitstellen.

Arbeitslast bereitstellen

Das folgende Manifest beschreibt eine Bereitstellung, die ein Container-Image einer Beispielwebanwendung ausführt:

  1. Speichern Sie das Manifest als ilb-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: ilb-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ilb-deployment
  template:
    metadata:
      labels:
        app: ilb-deployment
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f ilb-deployment.yaml

Internen LoadBalancer-Dienst erstellen

  1. Optional: Automatisches Erstellen von VPC-Firewallregeln deaktivieren:

    GKE erstellt automatisch VPC-Firewallregeln, um Traffic zu Ihrem internen Load-Balancer zuzulassen. Sie haben jedoch die Möglichkeit, das automatische Erstellen von VPC-Firewallregeln zu deaktivieren und Firewallregeln selbst zu verwalten. Sie können VPC-Firewallregeln nur deaktivieren, wenn Sie die GKE-Teileinstellung für Ihren internen LoadBalancer-Dienst aktiviert haben. Die Verwaltung von VPC-Firewallregeln ist jedoch optional und Sie können sich auf die automatischen Regeln verlassen.

    Bevor Sie das automatische Erstellen von VPC-Firewallregeln deaktivieren, müssen Sie Zulassungsregeln definieren, die es ermöglichen, dass Traffic Ihren Load Balancer und Ihre Anwendungs-Pods erreicht.

    Weitere Informationen zum Verwalten von VPC-Firewallregeln finden Sie unter Automatisches Erstellen von Firewallregeln verwalten. Informationen zum Deaktivieren des automatischen Erstellens von Firewallregeln finden Sie unter Von Nutzern verwaltete Firewallregeln für GKE LoadBalancer-Dienste.

  2. Im folgenden Beispiel wird ein interner LoadBalancer-Dienst mit dem TCP-Port 80 erstellt. GKE stellt einen internen Passthrough-Network-Load-Balancer bereit, dessen Weiterleitungsregel Port 80 verwendet, aber dann Traffic an Backend-Pods auf Port 8080 weiterleitet:

    1. Speichern Sie das Manifest als ilb-svc.yaml:

      apiVersion: v1
kind: Service
metadata:
  name: ilb-svc
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # Evenly route external traffic to all endpoints.
  externalTrafficPolicy: Cluster
  # Prioritize routing traffic to endpoints that are in the same zone.
  trafficDistribution: PreferClose
  selector:
    app: ilb-deployment
  # Forward traffic from TCP port 80 to port 8080 in backend Pods.
  ports:
  - name: tcp-port
    protocol: TCP
    port: 80
    targetPort: 8080

      Ihr Manifest muss Folgendes enthalten:

      • Einen Namen (name) für den internen LoadBalancer-Dienst, in diesem Fall ilb-svc.
      • Das Feld spec.loadBalancerClass ist auf den Wert networking.gke.io/l4-regional-internal festgelegt, um einen internen LoadBalancer-Dienst anzugeben, wie im Beispielmanifest gezeigt.
      • Das Feld type: LoadBalancer.
      • Das Feld spec: selector zur Angabe der Pods, auf die der Dienst ausgerichtet werden soll, z. B. app: hello.
      • Port-Informationen:
        • port steht für den Zielport, über den die Weiterleitungsregel des internen Passthrough-Netzwerk-Load-Balancers Pakete empfängt.
        • Der targetPort muss mit einem containerPort übereinstimmen, der auf jedem Bereitstellungs-Pod definiert ist.
        • Die Werte port und targetPort müssen nicht identisch sein. Knoten führen immer Ziel-NAT aus, wobei die IP-Adresse der Weiterleitungsregel des Ziel-Load-Balancers und port in eine Ziel-Pod-IP-Adresse und targetPort geändert werden. Weitere Informationen finden Sie in der Dokumentation zu LoadBalancer-Dienstkonzepten unter Destination Network Address Translation on nodes.

      Ihr Manifest kann Folgendes enthalten:

      • spec.ipFamilyPolicy und ipFamilies, um zu definieren, wie GKE dem Dienst IP-Adressen zuweist. GKE unterstützt entweder Single-Stack-IP-LoadBalancer- (nur IPv4 oder IPv6) oder Dual-Stack-IP-LoadBalancer-Dienste. Ein Dual-Stack-LoadBalancer-Dienst wird mit zwei separaten internen Passthrough-Netzwerk-Load-Balancer-Weiterleitungsregeln implementiert: eine für IPv4-Traffic und eine für IPv6-Traffic. Der GKE-Dual-Stack-LoadBalancer-Dienst ist in Version 1.29 oder höher verfügbar. Weitere Informationen finden Sie unter IPv4/IPv6-Dual-Stack-Dienste.

      • spec.trafficDistribution (Vorschau), um zu definieren, wie GKE eingehenden Traffic weiterleitet. Wenn Sie die zonale Affinität aktivieren möchten, legen Sie den Wert dieses Felds auf PreferSameZone fest. Zonale Affinität bedeutet, dass GKE das Routing von Traffic, der aus einer Zone stammt, zu Knoten und Pods in derselben Zone priorisiert. Wenn in dieser Zone keine fehlerfreien Pods verfügbar sind, wird der Traffic an eine andere Zone weitergeleitet. Verwenden Sie für Clusterversionen vor 1.35.0-gke.1811000 stattdessen PreferClose als Wert. Für die zonale Affinität muss die GKE-Teileinstellung aktiviert sein.

      Weitere Informationen finden Sie unter Parameter des LoadBalancer-Dienstes.

    2. Wenden Sie das Manifest auf Ihren Cluster an:

      kubectl apply -f ilb-svc.yaml

  3. Rufen Sie detaillierte Informationen zum Dienst ab:

    kubectl get service ilb-svc --output yaml

    Die Ausgabe sieht etwa so aus:

    apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"ingress":true}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}'
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}}
    networking.gke.io/load-balancer-type: Internal
    service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
    service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
    service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw
    service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc
    service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r
  creationTimestamp: "2022-07-22T17:26:04Z"
  finalizers:
  - gke.networking.io/l4-ilb-v2
  - service.kubernetes.io/load-balancer-cleanup
  name: ilb-svc
  namespace: default
  resourceVersion: "51666"
  uid: d7a1a865-7972-44e1-aa9e-db5be23d6567
spec:
  allocateLoadBalancerNodePorts: true
  clusterIP: 10.88.2.141
  clusterIPs:
  - 10.88.2.141
  externalTrafficPolicy: Cluster
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: tcp-port
    # Kubernetes automatically allocates a port on the node during the
    # process of implementing a Service of type LoadBalancer.
    nodePort: 30521
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: ilb-deployment
  sessionAffinity: None
  trafficDistribution: PreferSameZone
  type: LoadBalancer
status:
  # IP address of the load balancer forwarding rule.
  loadBalancer:
    ingress:
    - ip: 10.128.15.245

    Die Ausgabe hat die folgenden Attribute:

    • Die IP-Adresse der Weiterleitungsregel des internen Passthrough-Netzwerk-Load-Balancers ist in status.loadBalancer.ingress enthalten. Diese IP-Adresse unterscheidet sich vom clusterIP-Wert. In diesem Beispiel lautet die IP-Adresse der Weiterleitungsregel des Load-Balancers 10.128.15.245.
    • Jeder Pod mit dem Label app: ilb-deployment ist ein Bereitstellungs-Pod für diesen Dienst. Dies sind die Pods, die Pakete empfangen, die vom internen Passthrough-Netzwerk-Load-Balancer weitergeleitet werden.
    • Clients rufen den Dienst über die loadBalancer-IP-Adresse und den im Feld port des Dienstmanifests angegebenen TCP-Zielport auf. Ausführliche Informationen dazu, wie Pakete weitergeleitet werden, nachdem sie von einem Knoten empfangen wurden, finden Sie unter Paketverarbeitung.
    • GKE hat dem Dienst einen nodePort zugewiesen. In diesem Beispiel wird Port 30521 zugewiesen. Der nodePort ist für den internen Passthrough-Netzwerk-Load-Balancer nicht relevant.

  4. Prüfen Sie die Endpunktgruppe des Dienstnetzwerks:

    kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"

    Die Ausgabe sieht etwa so aus:

    {"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["ZONE_NAME"]}

    Die Antwort zeigt an, dass GKE eine Netzwerk-Endpunktgruppe mit dem Namen k8s2-knlc4c77-default-ilb-svc-ua5ugas0 erstellt hat. Diese Annotation ist in Diensten vom Typ LoadBalancer vorhanden, die die GKE-Teilmengeneinstellung verwenden und nicht in Diensten enthalten, die keine Teilmengeneinstellung verwenden.

Komponenten des internen Passthrough-Netzwerk-Load-Balancers prüfen

In diesem Abschnitt erfahren Sie, wie Sie die wichtigsten Komponenten Ihres internen Passthrough-Network Load Balancers prüfen.

  • Prüfen Sie, ob Ihr Dienst ausgeführt wird:

    kubectl get service SERVICE_NAME --output yaml

    Ersetzen Sie SERVICE_NAME durch den Namen des Dienstmanifests.

    Wenn Sie die zonale Affinität aktiviert haben, enthält die Ausgabe den Parameter spec.trafficDistribution. Der Wert dieses Felds wird auf PreferSameZone oder PreferClose festgelegt, wenn die Clusterversion älter als 1.35.0-gke.1811000 ist.

  • Prüfen Sie die IP-Adresse der Weiterleitungsregel des internen Passthrough-Network Load Balancers. Die IP-Adresse der Weiterleitungsregel des internen Passthrough-Network Load Balancers ist 10.128.15.245 im Beispiel im Abschnitt Internen LoadBalancer-Dienst erstellen. Prüfen Sie mit der Google Cloud CLI, ob diese Weiterleitungsregel in der Liste der Weiterleitungsregeln im Projekt des Clusters enthalten ist:

    gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"

    Die Ausgabe enthält die relevante Weiterleitungsregel für den internen Passthrough-Netzwerk-Load-Balancer, die IP-Adresse und den Backend-Dienst, auf den die Weiterleitungsregel verweist (in diesem Beispiel k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r).

    NAME                          ... IP_ADDRESS  ... TARGET
...
k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r   10.128.15.245   ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r

  • Beschreiben Sie den Backend-Dienst des Load-Balancers mit der Google Cloud CLI:

    gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION

    Ersetzen Sie COMPUTE_REGION durch die Compute-Region des Backend-Dienstes.

    Wenn Sie die zonale Affinität aktiviert haben:

    • Das Feld networkPassThroughLbTrafficPolicy.zonalAffinity.spillover sollte auf den Wert ZONAL_AFFINITY_SPILL_CROSS_ZONE gesetzt werden.
    • Das Feld networkPassThroughLbTrafficPolicy.zonalAffinity.spilloverRatio sollte auf 0 gesetzt oder nicht enthalten sein.

    Die Ausgabe enthält die Backend-GCE_VM_IP-NEG oder die NEGs für den Dienst (in diesem Beispiel k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r).

    backends:
- balancingMode: CONNECTION
  group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
networkPassThroughLbTrafficPolicy:
  zonalAffinity:
    spillover: ZONAL_AFFINITY_SPILL_CROSS_ZONE
protocol: TCP
...

    Wenn Sie die zonale Affinität deaktiviert haben, sollte das Feld networkPassThroughLbTrafficPolicy.zonalAffinity.spillover auf ZONAL_AFFINITY_DISABLED festgelegt oder nicht enthalten sein. Die zonale Affinität wird automatisch deaktiviert, wenn Ihr Cluster eine Version vor 1.33.3-gke.1392000 verwendet.

  • Liste der Knoten in einem Teil eines Dienstes ermitteln:

    gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
    --zone=COMPUTE_ZONE

    Ersetzen Sie Folgendes:

    • NEG_NAME: durch den Namen der vom GKE-Controller erstellten Netzwerk-Endpunktgruppe.
    • COMPUTE_ZONE: durch die Computing-Zone der Netzwerk-Endpunktgruppe, die verwendet werden soll.

  • Liste der fehlerfreien Knoten für einen internen Passthrough-Network Load Balancer ermitteln:

    gcloud compute backend-services get-health SERVICE_NAME \
    --region=COMPUTE_REGION

    Ersetzen Sie Folgendes:

    • SERVICE_NAME ist der Name des Backend-Dienstes. Dieser Wert entspricht dem Namen der vom GKE-Controller erstellten Netzwerk-Endpunktgruppe.
    • COMPUTE_REGION: die Computing-Region des Backend-Dienstes, in dem der Vorgang ausgeführt werden soll.

Konnektivität zum internen Passthrough-Netzwerk-Load-Balancer testen

Führen Sie den folgenden Befehl in derselben Region wie der Cluster aus:

curl LOAD_BALANCER_IP:80

Ersetzen Sie LOAD_BALANCER_IP durch die IP-Adresse der Weiterleitungsregel des Load-Balancers.

Die Antwort zeigt die Ausgabe von ilb-deployment:

Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n

Auf den internen Passthrough-Network-Load-Balancer kann nur innerhalb desselben VPC-Netzwerks (oder eines verbundenen Netzwerks) zugegriffen werden. Standardmäßig ist bei der Weiterleitungsregel des Load Balancers der globale Zugriff deaktiviert, sodass sich Client-VMs, Cloud VPN-Tunnel oder Cloud Interconnect-Anhänge (VLANs) in derselben Region befinden müssen wie der interne Passthrough-Network-Load-Balancer. Zur Unterstützung von Clients in allen Regionen können Sie den globalen Zugriff auf die Weiterleitungsregel des Load Balancers aktivieren. Dazu nehmen Sie die Annotation globaler Zugriff in das Dienstmanifest auf.

Internen LoadBalancer-Dienst und Load-Balancer-Ressourcen löschen

Sie können das Deployment und den Dienst mit kubectl delete oder derGoogle Cloud Console löschen.

kubectl

Deployment löschen

Führen Sie zum Löschen des Deployments den folgenden Befehl aus:

kubectl delete deployment ilb-deployment

Dienst löschen

Führen Sie zum Löschen des Dienstes den folgenden Befehl aus:

kubectl delete service ilb-svc

Console

Deployment löschen

Führen Sie zum Löschen des Deployments die folgenden Schritte aus:

  1. Rufen Sie in der Google Cloud -Console die Seite Arbeitslasten auf.

    Zu Arbeitslasten

  2. Wählen Sie das Deployment aus, das Sie löschen möchten, und klicken Sie auf Löschen.

  3. Klicken Sie zur Bestätigung auf das Kästchen neben Horizontales Pod-Autoscaling löschen, das mit der ausgewählten Bereitstellung verknüpft ist, und klicken Sie dann auf Löschen.

Dienst löschen

Führen Sie zum Löschen des Dienstes die folgenden Schritte aus:

  1. Rufen Sie in der Google Cloud Console die Seite Dienste und Ingress auf.

    Zu "Dienste & Ingress"

  2. Wählen Sie den zu löschenden Dienst aus und klicken Sie auf Löschen.

  3. Wenn Sie zur Bestätigung aufgefordert werden, klicken Sie auf Löschen.

Freigegebene IP-Adresse

Der interne Passthrough-Netzwerk-Load-Balancer ermöglicht die gemeinsame Nutzung einer virtuellen IP-Adresse durch mehrere Weiterleitungsregeln. Dies ist nützlich, um die Anzahl von gleichzeitigen Ports auf derselben IP-Adresse zu erhöhen oder UDP- und TCP-Traffic auf derselben IP-Adresse zu akzeptieren. Pro IP-Adresse sind bis zu 50 freigegebene Ports möglich. Freigegebene IP-Adressen werden nativ auf GKE-Clustern mit internen LoadBalancer-Diensten unterstützt. Bei der Bereitstellung wird im Feld loadBalancerIP des Dienstes angegeben, welche IP-Adresse von den Diensten gemeinsam genutzt werden soll.

Beschränkungen

Eine für mehrere Load-Balancer freigegebene IP-Adresse hat die folgenden Beschränkungen und Funktionen:

  • Jede Weiterleitungsregel kann bis zu fünf Ports (fortlaufend oder nicht fortlaufend) haben oder so konfiguriert werden, dass Traffic an allen Ports abgeglichen und weitergeleitet wird. Wenn für einen internen LoadBalancer-Dienst mehr als fünf Ports definiert sind, wird die Weiterleitungsregel automatisch so festgelegt, dass sie mit allen Ports übereinstimmt.
  • Maximal zehn Dienste (Weiterleitungsregeln) können eine IP-Adresse gemeinsam nutzen. Dies bedeutet maximal 50 Ports pro freigegebener IP.
  • Für jede Weiterleitungsregel, die dieselbe IP-Adresse verwendet, muss eine eindeutige Kombination aus Protokollen und Ports verwendet werden. Daher muss jeder interne LoadBalancer-Dienst eine eindeutige Kombination aus Protokollen und Ports verwenden.
  • Eine Kombination aus reinen TCP- und UDP-Diensten wird auf derselben freigegebenen IP-Adresse unterstützt. Sie können jedoch nicht sowohl TCP- als auch UDP-Ports im selben Dienst verfügbar machen.

Freigegebene IP-Adresse aktivieren

So aktivieren Sie interne LoadBalancer-Dienste für die Freigabe einer gemeinsamen IP-Adresse:

  1. Erstellen Sie mit --purpose SHARED_LOADBALANCER_VIP eine statische interne IP-Adresse. Eine IP-Adresse muss zu diesem Zweck erstellt werden, damit sie freigegeben werden kann. Wenn Sie die statische interne IP-Adresse in einer freigegebene VPC erstellen, müssen Sie die IP-Adresse im selben Dienstprojekt wie die Instanz erstellen, die die IP-Adresse verwenden wird. Das gilt auch dann, wenn der Wert der IP-Adresse aus dem Bereich der verfügbaren IP-Adressen in einem bestimmten freigegebenen Subnetz des freigegebene VPC-Netzwerks stammt. Weitere Informationen finden Sie auf der Seite Bereitstellen einer gemeinsam genutzten VPC unter Statische interne IP-Adresse reservieren.

  2. Stellen Sie bis zu zehn interne LoadBalancer-Dienste mit dieser statischen IP-Adresse im Feld loadBalancerIP bereit. Die internen Passthrough-Netzwerk-Load-Balancer werden vom GKE-Dienst-Controller abgeglichen und mit derselben Frontend-IP bereitgestellt.

Im folgenden Beispiel wird gezeigt, wie auf diese Weise mehrere TCP- und UDP-Ports für dieselbe IP-Adresse des internen Load-Balancers unterstützt werden.

  1. Erstellen Sie eine statische IP-Adresse in derselben Region wie Ihr GKE-Cluster. Das Subnetz muss mit dem Subnetz übereinstimmen, das der Load-Balancer verwendet. Dies ist standardmäßig dasselbe Subnetz, das von den IP-Adressen der GKE-Clusterknoten genutzt wird.

    Wenn sich der Cluster und das VPC-Netzwerk im selben Projekt befinden:

    gcloud compute addresses create IP_ADDR_NAME \
    --project=PROJECT_ID \
    --subnet=SUBNET \
    --addresses=IP_ADDRESS \
    --region=COMPUTE_REGION \
    --purpose=SHARED_LOADBALANCER_VIP

    Wenn sich Ihr Cluster in einem Dienstprojekt einer freigegebene VPC befindet, aber ein VPC-Netzwerk einer freigegebene VPC in einem Hostprojekt verwendet:

    gcloud compute addresses create IP_ADDR_NAME \
    --project=SERVICE_PROJECT_ID \
    --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET \
    --addresses=IP_ADDRESS \
    --region=COMPUTE_REGION \
    --purpose=SHARED_LOADBALANCER_VIP

    Ersetzen Sie Folgendes:

    • IP_ADDR_NAME ist der Name des IP-Adressobjekts.
    • SERVICE_PROJECT_ID ist die ID des Dienstprojekts.
    • PROJECT_ID ist die ID Ihres Projekts (einzelnes Projekt).
    • HOST_PROJECT_ID: die ID des freigegebene VPC-Hostprojekts.
    • COMPUTE_REGION: Die Computing-Region, die das freigegebene Subnetz enthält.
    • IP_ADDRESS ist eine nicht verwendete interne IP-Adresse aus dem primären IP-Adressbereich des ausgewählten Subnetzes. Wenn Sie keine IP-Adresse angeben,wählt Google Cloud eine nicht verwendete interne IP-Adresse aus dem primären IP-Adressbereich des ausgewählten Subnetzes aus. Führen Sie gcloud compute addresses describe aus, um eine automatisch ausgewählte Adresse zu ermitteln.
    • SUBNET ist der Name des freigegebenen Subnetzes.

  2. Speichern Sie die folgende TCP-Dienstkonfiguration in einer Datei mit dem Namen tcp-service.yaml und stellen Sie sie dann im Cluster bereit. Ersetzen Sie IP_ADDRESS durch die IP-Adresse, die Sie im vorherigen Schritt ausgewählt haben.

    apiVersion: v1
kind: Service
metadata:
  name: tcp-service
  namespace: default
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # Use an IP address that you create.
  loadBalancerIP: IP_ADDRESS
  selector:
    app: myapp
  ports:
  - name: 8001-to-8001
    protocol: TCP
    port: 8001
    targetPort: 8001
  - name: 8002-to-8002
    protocol: TCP
    port: 8002
    targetPort: 8002
  - name: 8003-to-8003
    protocol: TCP
    port: 8003
    targetPort: 8003
  - name: 8004-to-8004
    protocol: TCP
    port: 8004
    targetPort: 8004
  - name: 8005-to-8005
    protocol: TCP
    port: 8005
    targetPort: 8005

  3. Wenden Sie diese Dienstdefinition auf Ihren Cluster an:

    kubectl apply -f tcp-service.yaml

  4. Speichern Sie die folgende UDP-Dienstkonfiguration in einer Datei mit dem Namen udp-service.yaml und stellen Sie sie dann bereit. Außerdem wird die IP_ADDRESS verwendet, die Sie im vorherigen Schritt angegeben haben.

    apiVersion: v1
kind: Service
metadata:
  name: udp-service
  namespace: default
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # Use the same IP address that you used for the TCP Service.
  loadBalancerIP: IP_ADDRESS
  selector:
    app: my-udp-app
  ports:
  - name: 9001-to-9001
    protocol: UDP
    port: 9001
    targetPort: 9001
  - name: 9002-to-9002
    protocol: UDP
    port: 9002
    targetPort: 9002

  5. Wenden Sie diese Datei auf Ihren Cluster an:

    kubectl apply -f udp-service.yaml

  6. Prüfen Sie, ob die VIP von den Weiterleitungsregeln des Load-Balancers gemeinsam genutzt wird. Listen Sie sie dazu auf und filtern Sie nach der statischen IP-Adresse. Dies zeigt, dass es eine UDP- und eine TCP-Weiterleitungsregel gibt, die jeweils sieben verschiedene Ports auf der freigegebenen IP_ADDRESS beobachten, die in diesem Beispiel 10.128.2.98 ist.

    gcloud compute forwarding-rules list | grep 10.128.2.98
ab4d8205d655f4353a5cff5b224a0dde                         us-west1   10.128.2.98     UDP          us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde
acd6eeaa00a35419c9530caeb6540435                         us-west1   10.128.2.98     TCP          us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435

Bekannte Probleme

Fehler beim Erstellen des Load-Balancers in der Standardstufe

Wenn Sie einen internen Passthrough-Netzwerk-Load-Balancer in einem Projekt erstellen, in dem die Standardnetzwerkstufe des Projekts auf Standard gesetzt ist, wird die folgende Fehlermeldung angezeigt:

Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest

Konfigurieren Sie die Standardnetzwerkstufe des Projekts auf Premium, um dieses Problem in GKE-Versionen vor 1.23.3-gke.900 zu beheben.

Dieses Problem wird in GKE-Versionen ab 1.23.3-gke.900 behoben, wenn GKE-Teileinstellung aktiviert ist.

Der GKE-Controller erstellt interne Passthrough-Netzwerk-Load-Balancer in der Premium-Netzwerkstufe, auch wenn die Standard-Netzwerkstufe des Projekts auf Standard eingestellt ist.

Nächste Schritte