Backend-Dienst-basierten externen Load-Balancer bereitstellen


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

Backend-Dienst-basierter externer Passthrough-Network-Load-Balancer

Als Clusteradministrator können Sie einen externen LoadBalancer-Dienst erstellen, damit Clients außerhalb des Clusters Pakete an die Pods des Dienstes senden können. Das folgende Diagramm zeigt zwei Backend-Dienst-basierte externe Passthrough-Network-Load-Balancer, die für zwei externe LoadBalancer-Dienste erstellt wurden (store-v1-lb-svc und store-v2-lb-svc). Beide Load Balancer verteilen Pakete auf die Knoten im Cluster und die Knoten leiten Pakete an Bereitstellungs-Pods weiter.

Externe LoadBalancer-Dienste, die von regionalen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancern unterstützt werden

In dieser Anleitung erfahren Sie, wie Sie mit den folgenden Schritten einen externen LoadBalancer-Dienst mit dem Namen store-v1-lb-svc einrichten:

  1. Erstellen Sie einen Cluster mit aktiviertem Add-on HttpLoadBalancing.
  2. Erstellen Sie einen Service, der die Annotation cloud.google.com/l4-rbs enthält. Diese Annotation weist GKE an, einen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer zu erstellen, der den regionalen Backend-Dienst verwendet.
  3. Prüfen Sie, ob der Load-Balancer Pakete erfolgreich an die Pods des store-v1-lb-svc-Dienstes sendet. Prüfen Sie auch, ob GKE die Komponenten des Backend-Dienst-basierten externen Passthrough-Network-Load-Balancers erstellt hat:

    • Weiterleitungsregel
    • Regionaler Backend-Dienst
    • Instanzgruppe
    • Systemdiagnose
    • VPC-Firewallregeln
  4. Löschen Sie den externen LoadBalancer-Dienst store-v1-lb-svc.

Vorbereitung

Führen Sie die folgenden Schritte durch, 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 gcloud components update ab.

Cluster einrichten

Cluster erstellen

Verwenden Sie die gcloud CLI, um einen neuen Cluster zu erstellen, der die Erstellung von Backend-Dienst-basierten externen Passthrough-Network-Load-Balancern unterstützt:

gcloud container clusters create-auto CLUSTER_NAME \
    --release-channel=RELEASE_CHANNEL \
    --cluster-version=VERSION \
    --location=COMPUTE_LOCATION

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des neuen Clusters.
  • RELEASE_CHANNEL: der Name der GKE-Release-Version für den Cluster.
  • VERSION: die GKE-Version für den Cluster, die 1.24.9 oder höher sein muss.
  • COMPUTE_LOCATION: die Compute Engine-Region des Clusters.

In Ihrem neuen Cluster ist das Add-on HttpLoadBalancing standardmäßig aktiviert. Dieses Add-on ist erforderlich, damit die Steuerungsebene externe Passthrough-Network-Load-Balancer erstellen und verwalten kann.

Vorhandenen Cluster aktualisieren

Verwenden Sie die gcloud CLI, um einen vorhandenen Cluster zu aktualisieren, damit er das Erstellen von Backend-Dienst-basierten externen Passthrough-Network-Load-Balancern unterstützen kann.

  1. Aktualisieren Sie die Steuerungsebene auf die GKE-Version 1.24.9 oder höher:

    gcloud container clusters upgrade CLUSTER_NAME \
        --cluster-version=VERSION \
        --master \
        --location=COMPUTE_LOCATION
    

    Dabei gilt:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • VERSION: die GKE-Version; die 1.24.9 oder höher sein muss. Die Version muss eine gültige Nebenversion in der Release-Version Ihres Clusters sein. Weitere Informationen finden Sie unter Manuelles Upgrade der Steuerungsebene.
    • COMPUTE_LOCATION: der Compute Engine-Standort für den neuen Cluster.

Externen LoadBalancer-Dienst erstellen

  1. Speichern Sie das folgende Beispiel-Deployment als store-deployment.yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: store
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: store
      template:
        metadata:
          labels:
            app: store
        spec:
          containers:
          - image: gcr.io/google_containers/echoserver:1.10
            imagePullPolicy: Always
            name: echoserver
            ports:
              - name: http
                containerPort: 8080
            readinessProbe:
              httpGet:
                path: /healthz
                port: 8080
                scheme: HTTP
    
  2. Wenden Sie das Manifest auf den Cluster an:

    kubectl apply -f store-deployment.yaml
    
  3. Prüfen Sie, ob für das Deployment zwei Bereitstellungs-Pods vorhanden sind:

    kubectl get pods
    

    Die Ausgabe sieht etwa so aus:

    NAME                     READY   STATUS    RESTARTS   AGE
    store-cdb9bb4d6-s25vw      1/1     Running   0          10s
    store-cdb9bb4d6-vck6s      1/1     Running   0          10s
    
  4. Speichern Sie das folgende Dienstmanifest als store-v1-lb-svc.yaml:

    apiVersion: v1
    kind: Service
    metadata:
      name: store-v1-lb-svc
      annotations:
        cloud.google.com/l4-rbs: "enabled"
    spec:
      type: LoadBalancer
      externalTrafficPolicy: Cluster
      selector:
        app: store
      ports:
      - name: tcp-port
        protocol: TCP
        port: 8080
        targetPort: 8080
    

    Dieser externe LoadBalancer-Dienst verwendet den Standard-externalTrafficPolicy von Cluster. Ausführliche Informationen dazu, wie mit externalTrafficPolicy die Knotengruppierung definiert wird, welche Knoten ihre Load-Balancer-Systemdiagnosen und die Paketverarbeitung bestehen, finden Sie unter Konzepte des LoadBalancer-Dienstes.

    Wenn Sie einen IPv4/IPv6-Dual-Stack-Cluster verwenden, fügen Sie spec.ipFamilyPolicy und ipFamilies hinzu, um zu definieren, wie GKE dem Dienst IP-Adressen zuweist. Beachten Sie die folgenden Bedingungen, wenn Sie die Spezifikationen ipFamilyPolicy und ipFamilies verwenden:

    • Wenn Sie einen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer erstellen, fügt GKE automatisch die Annotation cloud.google.com/l4-rbs zu neuen Diensten hinzu, die auf IPv4/IPv6-Dual-Stack-Clustern erstellt wurden. Wenn Sie jedoch die Annotation cloud.google.com/l4-rbs: "enabled" zu vorhandenen Dienstmanifesten hinzufügen, verwenden bereits im Cluster vorhandene LoadBalancer-Dienste weiterhin zielpoolbasierte externe Passthrough-Network-Load-Balancer, die nur für IPv4 geeignet sind. Weitere Informationen finden Sie unter Knotengruppierung.
    • GKE kann entweder Single-Stack-Dienste (nur IPv4 oder nur IPv6) oder Dual-Stack-LoadBalancer-Dienste zuweisen. Der Dual-Stack-LoadBalancer-Dienst wird mit zwei separaten Weiterleitungsregeln für externe Passthrough-Network-Load-Balancer implementiert: einer zum Verarbeiten von TCP-Traffic über IPv4 und einer zum Verarbeiten von TCP-Traffic über IPv6. Weitere Informationen finden Sie unter Dienste.
  5. Wenden Sie das Manifest auf den Cluster an:

    kubectl apply -f store-v1-lb-svc.yaml
    
  6. Prüfen Sie, ob Ihr Dienst ausgeführt wird:

    kubectl get svc store-v1-lb-svc
    

    Die Ausgabe sieht in etwa so aus:

    NAME               TYPE           CLUSTER-IP        EXTERNAL-IP     PORT(S)          AGE
    store-v1-lb-svc   LoadBalancer   10.44.196.160     35.193.28.231   8080:32466/TCP   11m
    

    GKE hat EXTERNAL_IP für den externen Passthrough-Network-Load-Balancer zugewiesen.

  7. Testen Sie die Verbindung zum Load-Balancer:

    curl EXTERNAL_IP:PORT
    

    Ersetzen Sie Folgendes:

    • EXTERNAL_IP: die zugewiesene IP-Adresse für den externen Passthrough-Network-Load-Balancer.
    • PORT: die zugewiesene Portnummer für den externen Passthrough-Network-Load-Balancer.

    Die Ausgabe sieht in etwa so aus:

    Hostname: store-v1-lb-svc-cdb9bb4d6-hflxd
    
    Pod Information:
      -no pod information available-
    
    Server values:
      server_version=nginx: 1.13.3 - lua: 10008
    
    Request Information:
      client_address=10.128.0.50
      method=GET
      real path=/
      query=
      request_version=1.1
      request_scheme=http
      request_uri=EXTERNAL_IP
    
    Request Headers:
      accept=*/*
      host=EXTERNAL_IP
      user-agent=curl/7.81.0
    
    Request Body:
      -no body in request-
    
    

Externen LoadBalancer-Dienst und seine Komponenten überprüfen

  1. Prüfen Sie Ihren LoadBalancer-Dienst und die zugehörigen Annotationen, um seine Google Cloud-Ressourcen zu beschreiben:

    kubectl describe svc store-v1-lb-svc
    

    Die Ausgabe sieht in etwa so aus:

    Name:                     store-v1-lb-svc
    Namespace:                default
    Labels:                   <none>
    Annotations:              cloud.google.com/l4-rbs: enabled
                              service.kubernetes.io/backend-service: k8s2-c086604n-default-store-v1-lb-svc-aip4ty1x
                              service.kubernetes.io/firewall-rule: k8s2-c086604n-default-store-v1-lb-svc-aip4ty1x
                              service.kubernetes.io/firewall-rule-for-hc: k8s2-c086604n-l4-shared-hc-fw
                              service.kubernetes.io/healthcheck: k8s2-c086604n-l4-shared-hc
                              service.kubernetes.io/tcp-forwarding-rule: a683373f85bfe433ba929a50ca8d72e2
    Selector:                 app=store
    Type:                     LoadBalancer
    IP Family Policy:         SingleStack
    IP Families:              IPv4
    IP:                       10.44.196.160
    IPs:                      10.44.196.160
    LoadBalancer Ingress:     35.193.28.231
    Port:                     tcp-port  8080/TCP
    TargetPort:               8080/TCP
    NodePort:                 tcp-port  32466/TCP
    Endpoints:                10.48.0.5:8080,10.48.2.8:8080
    Session Affinity:         None
    External Traffic Policy:  Cluster
    Events:
      Type    Reason                Age                   From                     Message
      ----    ------                ----                  ----                     -------
      Normal  ADD                   2m42s                 loadbalancer-controller  default/store-v1-lb-svc
      Normal  EnsuringLoadBalancer  102s (x2 over 2m42s)  service-controller       Ensuring load balancer
      Normal  Annotations           102s                  loadbalancer-controller  map[cloud.google.com/l4-rbs:enabled kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"v1","kind":"Service","metadata":{"annotations":
    {"cloud.google.com/l4-rbs":"enabled"},"name":"store-v1-lb-svc","namespace":"default"}
    ,"spec":{"externalTrafficPolicy":"Cluster","ports":
    [{"name":"tcp-port","port":8080,"protocol":"TCP","targetPort":8080}],
    "selector":{"app":"store"},"type":"LoadBalancer"}}
    ] -> map[cloud.google.com/l4-rbs:enabled
    kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"v1","kind":
    "Service","metadata":{"annotations":{"cloud.google.com/l4-rbs":"enabled"},
    "name":"store-v1-lb-svc","namespace":"default"},"spec":{"externalTrafficPolicy"
    :"Cluster","ports":[{"name":"tcp-port","port":8080,"protocol":"TCP","targetPort"
    :8080}],"selector":{"app":"store"},"type":"LoadBalancer"}}
    service.kubernetes.io/backend-service:k8s2-c086604n-default-store-v1-lb-svc-aip4ty1x
    service.kubernetes.io/firewall-rule:k8s2-c086604n-default-store-v1-lb-svc-aip4ty1x
    service.kubernetes.io/firewall-rule-for-hc:k8s2-c086604n-l4-shared-hc-fw
    service.kubernetes.io/healthcheck:k8s2-c086604n-l4-shared-hc
    service.kubernetes.io/tcp-forwarding-rule:a683373f85bfe433ba929a50ca8d72e2]
    Normal  SyncLoadBalancerSuccessful  16s (x3 over 102s)  loadbalancer-controller  Successfully ensured L4 External LoadBalancer resources
    

    Es gibt mehrere Felder, die angeben, dass ein Backend-Dienst-basierter externer Passthrough-Network-Load-Balancer und seine Google Cloud-Ressourcen erfolgreich erstellt wurden:

    • Events-Feld. Dieses Feld ist leer, wenn der LoadBalancer-Dienst und seine Ressourcen erfolgreich erstellt wurden. Ein Fehler ist hier aufgeführt.
    • Liste aktivierter Annotations: GKE fügt dem Dienstmanifest die folgende Liste schreibgeschützter Annotationen hinzu. Jede Annotation, deren Name mit service.kubernetes.io/ beginnt, wird verwendet, um den Namen einer Google Cloud-Ressource anzugeben, die als Teil oder zur Unterstützung des Load-Balancers erstellt wurde.

    • Die Annotation service.kubernetes.io/backend-service gibt den Namen des Backend-Dienstes des Load-Balancers an.

    • Die Annotation service.kubernetes.io/healthcheck gibt den Namen der Load-Balancer-Systemdiagnose an, die vom Backend-Dienst verwendet wird.

    • Die Annotation service.kubernetes.io/tcp-forwarding-rule oder service.kubernetes.io/udp-forwarding-rule gibt den Namen der Weiterleitungsregel des Load-Balancers an.

    • Die Anmerkung service.kubernetes.io/firewall-rule gibt den Namen der Firewallregel an, die Traffic zu den Clusterknoten zulässt. Die Quellbereiche für diese Firewallregel können mit spec.loadBalancerSourceRanges[] angepasst werden. Weitere Informationen zu Firewallregeln für LoadBalancer-Dienste finden Sie unter Firewallregeln und Zulassungslisten für Quell-IP-Adressen.

    • Die Annotation service.kubernetes.io/firewall-rule-for-hc gibt den Namen der Firewallregel an, die für Systemdiagnosen des Load-Balancers erforderlich ist.

  2. Prüfen Sie, ob Load-Balancer-Ressourcen und Firewallregeln für den externen LoadBalancer-Dienst erstellt wurden:

  • Führen Sie den folgenden Befehl aus, um die Weiterleitungsregel aufzurufen:

      gcloud compute forwarding-rules describe FWD_RULE_NAME \
        --region=REGION_NAME
    

    Dabei gilt:

    • FWD_RULE_NAME: der Name der Weiterleitungsregel, der durch die schreibgeschützten Annotationen service.kubernetes.io/tcp-forwarding-rule oder service.kubernetes.io/udp-forwarding-rule bereitgestellt wird. Führen Sie kubectl describe svc SERVICE_NAME aus, um diese Annotationen zu prüfen.
    • REGION_NAME: die Google Cloud-Region, die den Cluster enthält. Bei zonalen Clustern enthält die Region die vom Cluster verwendete Zone.
  • Führen Sie den folgenden Befehl aus, um den Backend-Dienst anzuzeigen:

    gcloud compute backend-services describe BACKEND_SERVICE_NAME \
      --region=REGION_NAME
    

    Dabei gilt:

    • BACKEND_SERVICE_NAME: der Name des Backend-Dienstes, der von der schreibgeschützten Annotation service.kubernetes.io/backend-service bereitgestellt wird. Um diese schreibgeschützte Annotation zu prüfen, führen Sie kubectl describe svc SERVICE_NAME aus.
    • REGION_NAME: die Google Cloud-Region, die den Cluster enthält. Bei zonalen Clustern enthält die Region die vom Cluster verwendete Zone.
  • Führen Sie den folgenden Befehl aus, um die Systemdiagnose des Load-Balancers anzeigen zu lassen:

    gcloud compute health-checks describe HEALTH_CHECK_NAME \
      --region=REGION_NAME
    

    Dabei gilt:

    • HEALTH_CHECK_NAME: der Name der Systemdiagnose des Load-Balancers. Der Name der Systemdiagnose wird durch die schreibgeschützte Annotation service.kubernetes.io/healthcheck bereitgestellt. Um diese schreibgeschützte Annotation zu prüfen, führen Sie kubectl describe svc SERVICE_NAME aus.
    • REGION_NAME: die Google Cloud-Region, die den Cluster enthält. Bei zonalen Clustern enthält die Region die vom Cluster verwendete Zone.
  • Führen Sie die folgenden Befehle aus, um die Firewall-Regeln anzeigen zu lassen:

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME \
    gcloud compute firewall-rules describe HEALTH_CHECK_FIREWALL_RULE_NAME
    

    Dabei gilt:

    • FIREWALL_RULE_NAME: der Name der Firewallregel, die Traffic zum Load-Balancer zulässt. Der Name dieser Firewallregel wird von der schreibgeschützten Annotation service.kubernetes.io/firewall-rule bereitgestellt. Um diese schreibgeschützte Annotation zu prüfen, führen Sie kubectl describe svc SERVICE_NAME aus.
    • HEALTH_CHECK_FIREWALL_RULE_NAME: der Name der Firewallregel, die Systemdiagnosen der Back-Ends des Load-Balancers (die Knoten des Clusters) zulässt. Der Name dieser Firewallregel wird von der schreibgeschützten Annotation service.kubernetes.io/firewall-rule-for-hc bereitgestellt. Um diese schreibgeschützte Annotation zu prüfen, führen Sie kubectl describe svc SERVICE_NAME aus.

Externen LoadBalancer-Dienst und seine Komponenten löschen

Löschen Sie den externen LoadBalancer-Dienst store-v1-lb-svc.

kubectl delete service store-v1-lb-svc

GKE löscht die folgenden Ressourcen:

  • Weiterleitungsregel des Load-Balancers.
  • Backend-Dienst des Load-Balancers.
  • Systemdiagnose des Load-Balancers.
  • Die VPC-Firewallregeln, die für den Load-Balancer und dessen Systemdiagnosen-Traffic erforderlich sind
  • Die Back-Ends der zonalen nicht verwalteten Instanzgruppen, nur wenn GKE sie nicht als Back-Ends für andere vom Cluster erstellte Load-Balancer verwenden muss.

Nächste Schritte