Internen Load Balancer erstellen

Auf dieser Seite erfahren Sie, wie Sie einen internen LoadBalancer-Dienst bereitstellen, der einen internen Passthrough-Network-Load-Balancer erstellt. Bevor Sie diese Seite lesen, sollten Sie mit Folgendem vertraut sein:

Weitere Informationen zu internen Passthrough-Network-Load-Balancern im Allgemeinen 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 diese Aufgabe 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. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
  • 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-Back-Ends 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 die GKE-Version 1.33.3-gke.1392000 oder höher erforderlich.

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

    • Die GKE-Teilmengeneinstellung ist in Clustern mit Version 1.36 und höher standardmäßig aktiviert. Für diese Versionen ist die Teilmengenerstellung unabhängig vom Wert des Flags für die Teilmengenerstellung 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-Teilmengeneinstellung 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-Teilmengen überprüfen und aktivieren.

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

  • Wenn Sie Cloud Logging für einen internen LoadBalancer-Dienst aktivieren möchten, muss Ihr GKE-Cluster die Version 1.36.0-gke.2459000 oder höher verwenden.

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-Teilmengeneinstellungen manuell in neuen und vorhandenen Standard- und Autopilot-Clustern aktivieren, auf denen die GKE-Version 1.18.19-gke.1400 oder höher, aber vor der 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 die GKE-Teilmengenerstellung 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. Interpretieren Sie die Ausgabe so:

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

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

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 aktivieren, indem Sie die gcloud CLI oder dieGoogle Cloud Console verwenden oder Ihren Cluster auf Version 1.36 oder höher aktualisieren, werden vorhandene interne LoadBalancer-Dienste nicht geändert. Wenn Sie einen vorhandenen internen LoadBalancer-Dienst migrieren möchten, um GCE_VM_IP-NEG-Backends 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) Deaktivieren Sie die automatische Erstellung von VPC-Firewallregeln:

    GKE erstellt automatisch VPC-Firewallregeln, um Traffic zu Ihrem internen Load Balancer zuzulassen. Sie können die automatische Erstellung von VPC-Firewallregeln jedoch deaktivieren und Firewallregeln selbst 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 die automatische Erstellung von VPC-Firewallregeln deaktivieren, müssen Sie Zulassungsregeln definieren, die Traffic zu Ihrem Load Balancer und Ihren Anwendungs-Pods zulassen.

    Weitere Informationen zum Verwalten von VPC-Firewallregeln finden Sie unter Automatische Erstellung von Firewallregeln verwalten. Informationen zum Deaktivieren der automatischen Erstellung von Firewallregeln finden Sie unter Nutzerverwaltete 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: PreferSameZone
  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:

      • Ein 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 den Konzepten des LoadBalancer-Dienstes unter Destination Network Address Translation auf Knoten.

      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. Wenn Sie einen Single-Stack-IPv6-Dienst in einem Dual-Stack-Cluster erstellen möchten, setzen Sie den Wert des Felds spec.ipFamilyPolicy auf SingleStack und den Wert des Felds spec.ipFamilies auf IPv6. In einem Single-Stack-IPv6-Cluster sind dies die Standardwerte und Sie können sie weglassen. Weitere Informationen finden Sie unter IPv4/IPv6-Dual-Stack-Dienste.

      • spec.trafficDistribution, 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 innerhalb 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.

        Wichtige Überlegungen und eine Problemumgehung für die Skalierung von Arbeitslasten mit zonaler Affinität finden Sie unter Arbeitslasten mit zonaler Affinität skalieren.

      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 GKE-Teilmengeneinstellung verwenden.

Internen LoadBalancer-Dienst in einem Single-Stack-IPv6-Cluster erstellen

Wenn Sie einen internen Single-Stack-IPv6-LoadBalancer-Dienst in einem Single-Stack-IPv6-Cluster oder einem Dual-Stack-Cluster bereitstellen, hängt das vom Load Balancer verwendete Subnetz davon ab, ob das Knotensubnetz Ihres Clusters einen IPv6-Zugriffstyp INTERNAL oder EXTERNAL verwendet. In einem Dual-Stack-Cluster müssen Sie den Wert des Felds spec.ipFamilyPolicy auf SingleStack und den Wert des Felds spec.ipFamilies auf IPv6 festlegen. In einem Single-Stack-IPv6-Cluster sind dies die Standardwerte und Sie können sie weglassen. Wenn Sie stattdessen einen Dual-Stack-Dienst erstellen möchten, setzen Sie den Wert des Felds spec.ipFamilyPolicy auf RequireDualStack und listen Sie beide Adressfamilien im Feld spec.ipFamilies auf:

  • Cluster mit internen Knoten (INTERNAL-ULA-Zugriffstyp): Wenn Ihre Clusterknoten in einem internen Subnetzwerk mit eindeutigen lokalen Unicast-Adressen (ULA) ausgeführt werden, verwendet der interne Load Balancer automatisch das vorhandene Knoten-Subnetzwerk. Erstellen Sie Ihren Dienst ohne benutzerdefinierte Subnetzannotationen:

    apiVersion: v1
kind: Service
metadata:
  name: ilb-ipv6-svc
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-internal
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: my-app
  ports:
    - name: tcp-port
      protocol: TCP
      port: 80
      targetPort: 8080

  • Cluster mit externen Knoten (Zugriffstyp EXTERNAL GUA): Wenn Ihre Clusterknoten in einem externen Subnetzwerk mit Global Unicast Addresses (GUA) ausgeführt werden, kann ein interner Load Balancer dieses Subnetzwerk nicht direkt verwenden. Sie müssen ein dediziertes internes (INTERNAL) IPv6-Subnetz bereitstellen und das Subnetz mit der Annotation networking.gke.io/load-balancer-subnet in Ihrem Dienst referenzieren:

    1. Erstellen Sie ein dediziertes internes IPv6-Subnetzwerk:

      gcloud compute networks subnets create SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=INTERNAL \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

      Ersetzen Sie Folgendes:

      • SUBNET_NAME: Der Name des zu erstellenden Subnetzes.
      • NETWORK_NAME: der Name des VPC-Netzwerks, in dem Sie dieses Subnetz erstellen.
      • COMPUTE_REGION: die Compute Engine-Region für das Subnetz.

    2. Erstellen Sie den Service und verweisen Sie in der Annotation networking.gke.io/load-balancer-subnet auf den Namen des Subnetzwerks aus dem vorherigen Schritt:

      apiVersion: v1
kind: Service
metadata:
  name: ilb-ipv6-svc
  annotations:
    networking.gke.io/load-balancer-subnet: SUBNET_NAME
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-internal
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: my-app
  ports:
    - name: tcp-port
      protocol: TCP
      port: 80
      targetPort: 8080

  1. Prüfen Sie die zugewiesene Dienst-IP-Adresse:

    kubectl get svc ilb-ipv6-svc

    Die Ausgabe bestätigt, dass die Spalten CLUSTER-IP und EXTERNAL-IP (eine interne ULA-Adresse) ausgefüllt sind:

    NAME           TYPE           CLUSTER-IP                          EXTERNAL-IP               PORT(S)        AGE
ilb-ipv6-svc   LoadBalancer   2600:2d00:0:4:1a1e:d3b3:de4d:c549   fd20:f5d:a91f:3:0:9:0:0   80:30234/TCP   3m

Weitere Informationen finden Sie unter IPv6-LoadBalancer-Dienste.

Eigene IPv6-Adressen verwenden (BYOIPv6)

Wenn Sie einen internen IPv6-LoadBalancer-Dienst mit Bring Your Own IPv6-Adressen (BYOIPv6) konfigurieren möchten, erstellen Sie ein Subnetz mit einem internen BYOIPv6-Adressbereich und verweisen Sie in Ihrem Dienst auf das Subnetz. Der IPv6-Adressbereich des Subnetzes muss aus einem regionalen IPv6-Unterpräfix eines öffentlich delegierten Präfixes (PDP) im INTERNAL_IPV6_SUBNETWORK_CREATION-Modus stammen.

Prüfen Sie vor dem Erstellen des Service, ob Sie ein regionales IPv6-Subpräfix im INTERNAL_IPV6_SUBNETWORK_CREATION-Modus in derselben Region wie Ihr Cluster haben. Weitere Informationen finden Sie unter IPv6-Unterpräfixe erstellen und Subnetze mit IPv6-BYOIP-Bereichen erstellen.

  1. Erstellen Sie in derselben Region und demselben VPC-Netzwerk wie Ihr Cluster ein Subnetz mit einem internen BYOIPv6-Bereich aus Ihrem Unterpräfix:

    gcloud compute networks subnets create BYOIP_SUBNET_NAME \
    --network=NETWORK_NAME \
    --region=REGION \
    --stack-type=IPV6_ONLY \
    --ipv6-access-type=INTERNAL \
    --ip-collection=projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME

    Ersetzen Sie Folgendes:

    • BYOIP_SUBNET_NAME: der Name des neuen Subnetzes.
    • NETWORK_NAME: der Name des VPC-Netzwerk Ihres Clusters.
    • REGION: Die Region Ihres Clusters.
    • PROJECT_ID: die ID des Projekts, das das Unterpräfix enthält.
    • SUB_PREFIX_NAME: der Name des regionalen Unterpräfixes im INTERNAL_IPV6_SUBNETWORK_CREATION-Modus.

  2. Optional: Reservieren Sie einen statischen internen /96-IPv6-Adressbereich aus dem BYOIPv6-Subnetz. Wenn Sie diesen Schritt überspringen, weist GKE automatisch einen sitzungsspezifischen internen BYOIPv6-Adressbereich aus dem Subnetz zu, das Sie in der Annotation networking.gke.io/load-balancer-subnet angeben:

    gcloud compute addresses create STATIC_IPV6_NAME \
    --region=REGION \
    --subnet=BYOIP_SUBNET_NAME \
    --ip-version=IPV6

    Ersetzen Sie STATIC_IPV6_NAME durch einen Namen für die statische IPv6-Adressressource.

  3. Speichern Sie das folgende Manifest als ilb-byoipv6-svc.yaml:

    apiVersion: v1
kind: Service
metadata:
  name: ilb-byoipv6-svc
  annotations:
    networking.gke.io/load-balancer-subnet: BYOIP_SUBNET_NAME
    # Optional: To use a static address, uncomment the following line
    # networking.gke.io/load-balancer-ip-addresses: STATIC_IPV6_NAME
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-internal
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: ilb-deployment
  ports:
  - name: tcp-port
    protocol: TCP
    port: 80
    targetPort: 8080

    Ersetzen Sie BYOIP_SUBNET_NAME durch den Namen des von Ihnen erstellten BYOIPv6-Subnetzes. Standardmäßig weist GKE einen sitzungsspezifischen internen BYOIPv6-Adressbereich aus diesem Subnetz zu.

    Optional: Wenn Sie im vorherigen Schritt eine statische interne BYOIPv6-Adresse reserviert haben, entfernen Sie die Auskommentierung der Annotation networking.gke.io/load-balancer-ip-addresses und ersetzen Sie STATIC_IPV6_NAME durch den Namen der statischen IPv6-Adressressource.

  4. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f ilb-byoipv6-svc.yaml

Weitere Informationen finden Sie unter Eigene IPv6-Adressen verwenden (BYOIPv6).

Logging für Backend-Dienste aktivieren

Sie können Logs für einen internen Passthrough-Network-Load-Balancer aktivieren, deaktivieren und aufrufen. Wenn Sie das Logging für Ihre Backend-Dienste aktivieren möchten, muss die GKE-Teilmengeneinstellung aktiviert sein.

Sie konfigurieren Cloud Logging, indem Sie eine benutzerdefinierte L4LBConfig-Ressource erstellen, in der Ihre Logging-Einstellungen angegeben sind. Die L4LBConfig-Ressource ist im Dienstmanifest mit einem Kubernetes-Dienst verknüpft. Nachdem Sie das Manifest angewendet haben, konfiguriert der GKE-Controller das Logging für den Backend-Dienst. Wenn Sie keine L4LBConfig-Ressource mit dem Dienst verknüpfen, verwaltet der Controller die Logging-Konfiguration nicht mehr und belässt den Backend-Dienst im letzten bekannten Zustand. Weitere Informationen finden Sie unter Informationen zum Coast-Verhalten.

Sie können folgende Felder konfigurieren:

  • enabled: Wenn dieser Wert auf true gesetzt ist, wird das Logging für diesen Dienst aktiviert und Logs sind in Cloud Logging verfügbar. Andernfalls ist das Logging für diesen Dienst deaktiviert.
  • sampleRate: Gibt einen Wert zwischen 0 und 1,000,000 (Standard) an, wobei 0 bedeutet, dass keine Pakete protokolliert werden, und 1,000,000 bedeutet, dass 100 % der Pakete protokolliert werden. Das Feld sampleRate ist optional und nur relevant, wenn der Wert des Felds enable auf true gesetzt ist.
  • optionalMode: Steuert, welche optionalen Metadatenfelder in den generierten Logs für den Load Balancer enthalten sind. Das Feld akzeptiert einen der folgenden Stringwerte:
    • EXCLUDE_ALL_OPTIONAL: Standardeinstellung, wenn optionalMode nicht angegeben ist. Wenn diese Option festgelegt ist, sind keine optionalen Felder in den Logs enthalten. Dies ist das prägnanteste Logformat.
    • INCLUDE_ALL_OPTIONAL: Aktiviert das Logging für alle verfügbaren optionalen Felder und liefert die detailliertesten Logeinträge.
    • CUSTOM: Gibt eine benutzerdefinierte Liste optionaler Felder an, die in den Logs enthalten sind. Im Modus CUSTOM müssen Sie außerdem den Parameter optionalFields verwenden, um eine durch Kommas getrennte Liste der gewünschten Felder anzugeben.
  • optionalFields: kommagetrennter String mit Feldnamen. Definiert die genauen optionalen Metadatenfelder, die in den generierten Logs enthalten sein sollen. Dieses Feld wird nur verwendet, wenn optionalMode auf CUSTOM gesetzt ist. Andernfalls werden alle Werte ignoriert.

Erstellen Sie zum Konfigurieren von Cloud Logging die L4LBConfig-Ressource im selben Namespace wie Ihre Service-Ressource. Im folgenden L4LBConfig-Beispielmanifest wird Cloud Logging aktiviert und die Abtastrate auf 50 % der Anfragen für einen bestimmten Load-Balancer-Dienst festgelegt.

  1. Speichern Sie das folgende Manifest als svc-l4lb-config.yaml:

    apiVersion: networking.gke.io/v1
kind: L4LBConfig
metadata:
  name: svc-l4lb-config
  namespace: default
spec:
  logging:
    enabled: true # must be included
    sampleRate: 500000
    optionalMode: "INCLUDE_ALL_OPTIONAL"

  2. Wenden Sie das L4LBConfig-Manifest auf Ihren Cluster an:

    kubectl apply -f svc-l4lb-config.yaml

  3. Fügen Sie dem ilb-svc.yaml-Dienstmanifest die Annotation networking.gke.io/l4lb-config hinzu:

    apiVersion: v1
kind: Service
metadata:
  name: ilb-svc
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
    networking.gke.io/l4lb-config: "svc-l4lb-config"
spec:
  type: LoadBalancer
  selector:
    app: store
  ports:
    - name: tcp-port
      protocol: TCP
      port: 8080
      targetPort: 8080

  4. Wenden Sie das Dienstmanifest auf Ihren Cluster an:

    kubectl apply -f ilb-svc.yaml

Arbeitslasten mit zonaler Affinität skalieren

Da der HorizontalPodAutoscaler (HPA) Pods basierend auf aggregierten Clustermesswerten und nicht auf der zonalen Last skaliert, sollten Sie Ihre Arbeitslasten nach Zone entkoppeln, um eine zonale Überlastung zu vermeiden. Erstellen Sie anstelle eines einzelnen clusterweiten Deployments und HPA ein separates Deployment und HPA für jede Zone, in der Ihr Cluster ausgeführt wird. Ein einzelner interner LoadBalancer-Dienst kann Traffic gleichzeitig an alle diese unabhängigen zonalen Arbeitslasten weiterleiten.

Architektur

  • Eine Arbeitslast pro Zone: Erstellen Sie separate Deployments für jede Zone (z. B. zone-a, zone-b).
  • Knotenauswahl: Jedes Deployment wird mit der Knotenauswahl topology.kubernetes.io/zone an die jeweilige Zone gebunden.
  • Ein HPA pro Zone: Hängen Sie einen HPA an jedes Deployment an, damit die Pods unabhängig voneinander basierend auf lokalisierten Messwerten skaliert werden.
  • Ein freigegebener Dienst: Alle diese Deployments werden hinter einem einzelnen internen LoadBalancer-Dienst verfügbar gemacht, der mit zonaler Affinität konfiguriert ist (mit demselben Selektor).

Unabhängige zonale Arbeitslasten konfigurieren

Im folgenden Beispiel wird gezeigt, wie diese Architektur in zwei Zonen implementiert wird.

  1. Erstellen Sie für jede Zone ein separates Deployment. Die Deployments haben dasselbe app-Label, aber eine strikte nodeSelector, die sie an eine bestimmte Zone bindet.

    Speichern Sie das folgende Manifest als zonal-deployments.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-zone-a
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
      zone: zone-a
  template:
    metadata:
      labels:
        app: my-app
        zone: zone-a
    spec:
      nodeSelector:
        topology.kubernetes.io/zone: "COMPUTE_ZONE_A"
      containers:
      - name: echoserver
        image: gcr.io/google_containers/echoserver:1.10
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "100m"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-zone-b
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
      zone: zone-b
  template:
    metadata:
      labels:
        app: my-app
        zone: zone-b
    spec:
      nodeSelector:
        topology.kubernetes.io/zone: "COMPUTE_ZONE_B"
      containers:
      - name: echoserver
        image: gcr.io/google_containers/echoserver:1.10
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "100m"

    Ersetzen Sie COMPUTE_ZONE_A und COMPUTE_ZONE_B durch Ihre tatsächlichen Zonen (z. B. us-central1-a und us-central1-b).

  2. Wenden Sie das Manifest an:

    kubectl apply -f zonal-deployments.yaml

  3. Erstellen Sie für jedes zonale Deployment einen unabhängigen HPA.

    Speichern Sie das folgende Manifest als zonal-hpas.yaml:

    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-zone-a
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-zone-a
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-zone-b
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-zone-b
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

  4. Wenden Sie das Manifest an:

    kubectl apply -f zonal-hpas.yaml

  5. Achten Sie darauf, dass Ihr Dienst auf das freigegebene Label (app: my-app) ausgerichtet ist und die zonale Affinität aktiviert ist.

    Speichern Sie das folgende Manifest als zonal-service.yaml:

    apiVersion: v1
kind: Service
metadata:
  name: my-app-service-internal
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-internal
  trafficDistribution: PreferSameZone
  selector:
    app: my-app
  ports:
  - name: tcp-port
    protocol: TCP
    port: 8080
    targetPort: 8080

  6. Wenden Sie das Manifest an:

    kubectl apply -f zonal-service.yaml

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 ist 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 in dem Beispiel aus dem 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 mithilfe der Google Cloud CLI:

    gcloud compute backend-services describe k8s2-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 gesetzt oder nicht enthalten sein. Die zonale Affinität wird automatisch deaktiviert, wenn Ihr Cluster eine Version vor 1.33.3-gke.1392000 hat.

  • Liste der Knoten in einer Teilmenge für einen Dienst 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.

  • Prüfen Sie, ob Cloud Logging für den Dienst aktiviert wurde:

    kubectl get svc SERVICE_NAME --output yaml

    Ersetzen Sie Folgendes:

    • SERVICE_NAME: Der Name des Diensts.

    Prüfen Sie in der Ausgabe, ob das Feld Status.Conditions die Werte Type: LoggingConfigManaged und Reason: Reconciled enthält.

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

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 globalen Zugriff in das Dienstmanifest auf.

Führen Sie den folgenden Befehl in derselben Region wie den 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

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. Wenn Sie aufgefordert werden, den Vorgang zu bestätigen, setzen Sie ein Häkchen bei 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 ein interner LoadBalancer-Dienst mehr als fünf Ports definiert, 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.
  • Jede Weiterleitungsregel, die dieselbe IP-Adresse verwendet, muss eine eindeutige Kombination aus Protokollen und Ports verwenden. Daher muss jeder interne LoadBalancer-Dienst einen eindeutigen Satz von 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.
  • Gemeinsam genutzte IP-Adressen werden nur für interne IPv4-Adressen unterstützt. Sie können einen statischen internen IPv6-Adressbereich nicht für mehrere interne LoadBalancer-Dienste freigeben.

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 verwendet. Das gilt auch dann, wenn der Wert der IP-Adresse aus dem Bereich der verfügbaren IP-Adressen in einem ausgewählten gemeinsam genutzten Subnetz des freigegebene VPC-Netzwerks stammt. Weitere Informationen finden Sie auf der Seite Gemeinsam genutzte VPC bereitstellen 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 freigegebene VPC-Netzwerk 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. Wenn Sie eine automatisch ausgewählte Adresse ermitteln möchten, müssen Sie gcloud compute addresses describe ausführen.
    • 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 die 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.

Fehler bei der Verwendung der Annotation networking.gke.io/ip-collection-v6 für einen internen LoadBalancer-Dienst

Wenn Sie die Annotation networking.gke.io/ip-collection-v6 zu einem internen LoadBalancer-Dienst hinzufügen, gibt GKE ein IPCollectionV6Error-Warnereignis mit der folgenden Meldung aus:

networking.gke.io/ip-collection-v6 is not supported for Internal LoadBalancers. To use BYOIPv6 with ILB, specify a BYOIP subnet using the "networking.gke.io/load-balancer-subnet" annotation

Die Annotation networking.gke.io/ip-collection-v6 gilt nur für externe Single-Stack-IPv6-LoadBalancer-Dienste. Wenn Sie BYOIPv6-Adressen mit einem internen LoadBalancer-Dienst verwenden möchten, erstellen Sie ein Subnetz mit einem internen IPv6-Adressbereich aus einem öffentlichen delegierten Präfix im Modus INTERNAL_IPV6_SUBNETWORK_CREATION. Geben Sie dieses Subnetz mit der Annotation networking.gke.io/load-balancer-subnet an. Weitere Informationen finden Sie unter Eigene IPv6-Adressen verwenden (BYOIPv6).

Nächste Schritte