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