LoadBalancer-Dienste mit mehreren Netzwerken bereitstellen

In diesem Dokument wird beschrieben, wie Sie Pods mit mehreren Netzwerken für interne oder externe Clients verfügbar machen, indem Sie Google Cloud regionale externe Passthrough-Network-Load-Balancer- und interne Passthrough-Network-Load-Balancer-Ressourcen in GKE erstellen. Es werden die erforderliche Konfiguration, die Funktionen und die Einschränkungen von Multi-Netzwerk-LoadBalancer-Diensten beschrieben.

Wenn Sie Arbeitslasten mit mehreren VPC-Netzwerken verbinden, verwenden Sie einen Kubernetes-Dienst vom Typ LoadBalancer, um Traffic an Pods in einem bestimmten sekundären Netzwerk weiterzuleiten. Wenn Sie den Dienst erstellen, erstellt GKE einen Passthrough-Network-Load-Balancer, um diesen Traffic zu verwalten.

Weitere Informationen zur Unterstützung mehrerer Netzwerke in GKE finden Sie unter Unterstützung mehrerer Netzwerke für Pods.

Funktionsweise von LoadBalancer-Diensten für mehrere Netzwerke

Um eine Arbeitslast mit mehreren Netzwerken verfügbar zu machen, erstellen Sie ein Service vom Typ type: LoadBalancer. Der Dienst muss einen speziellen Selektor enthalten, der auf Pods auf Grundlage des Netzwerks ihrer sekundären Schnittstelle ausgerichtet ist. Fügen Sie eine Annotation hinzu, um anzugeben, ob ein interner oder externer Load Balancer erstellt werden soll.

Mit dem Label networking.gke.io/network in den Auswahlfiltern werden Endpunkte nach Netzwerk gefiltert. Dieses Label sorgt dafür, dass der Load Balancer Traffic nur an die Pod-Schnittstellen sendet, die mit dem angegebenen Netzwerk verbunden sind.

Beschränkungen

Für Load Balancer mit mehreren Netzwerken gelten die folgenden Einschränkungen:

  • Dienste, die externalTrafficPolicy: Cluster verwenden, werden nicht unterstützt.
  • Dienste, die auf hostNetwork-Pods ausgerichtet sind, werden nicht unterstützt.
  • IPv6 und Dual-Stack-Netzwerke werden nicht unterstützt.
  • Sie können das Netzwerk eines vorhandenen Dienstes nicht ändern.
  • Es werden nur Layer 3-Netzwerke unterstützt.
  • Load Balancer, die auf Zielpools oder Instanzgruppen-Back-Ends basieren, werden nicht unterstützt.
  • ClusterIP- und NodePort-Dienste werden in sekundären (nicht standardmäßigen) Netzwerken nicht unterstützt.

Hinweis

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

  1. Führen Sie die Schritte unter Unterstützung mehrerer Netzwerke für Pods einrichten aus, um Ihre VPC-Netzwerke vorzubereiten und einen GKE-Cluster mit einem zusätzlichen Netzwerk zu erstellen.
  2. Achten Sie darauf, dass in Ihrem Cluster die Teilmengeneinstellung für interne L4-Load-Balancer aktiviert ist. Wenn Sie dieses Feature aktivieren möchten, verwenden Sie beim Erstellen oder Aktualisieren des Clusters das Flag --enable-l4-ilb-subsetting.
  3. Achten Sie darauf, dass auf Ihrem Cluster die GKE-Version 1.36 oder höher ausgeführt wird.

Pods mit mehreren Netzwerken bereitstellen

Wenn Sie Pods an ein zusätzliches Netzwerk anhängen möchten, erstellen Sie ein Deployment mit der Annotation networking.gke.io/interfaces. Diese Annotation gibt die Netzwerke und Schnittstellen für die Pods an.

  1. Speichern Sie das folgende Manifest als web-app-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
      annotations:
        networking.gke.io/default-interface: 'eth1'
        networking.gke.io/interfaces: '[
          {"interfaceName":"eth0","network":"default"},
          {"interfaceName": "eth1","network": "dmz"}
        ]'
spec:
  containers:
  - name: whereami
    image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
    ports:
    - containerPort: 8080

    Dieses Manifest erstellt ein Deployment mit dem Namen web-app mit drei Pods. Die Pods haben zwei Schnittstellen: eth0, die mit dem Netzwerk default verbunden ist, und eth1, die mit dem Netzwerk dmz verbunden ist. Mit der Annotation networking.gke.io/default-interface wird eth1 als Standardschnittstelle für die Pods festgelegt.

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f web-app-deployment.yaml

Wenn Sie eine nicht standardmäßige Schnittstelle für Ihren Dienst verwenden, müssen Sie das Routing im Pod konfigurieren. Fügen Sie der Pod-Spezifikation einen initContainer mit der Funktion NET_ADMIN hinzu, um das Routing zu konfigurieren.

Im folgenden Beispiel wird ein initContainer gezeigt, das eine Standardroute für die Schnittstelle eth1 hinzufügt:

initContainers:
      - name: init-routes-busybox
        image: busybox
        command: ['sh', '-c', 'ip route add default dev eth1 table 200 && ip rule add from 172.16.1.0/24 table 200']
        securityContext:
          capabilities:
            add: ["NET_ADMIN"]

Ersetzen Sie im Befehl initContainer den Wert 172.16.1.0/24 durch den sekundären IP-Adressbereich Ihres Pod-Netzwerks.

Internen LoadBalancer-Dienst bereitstellen

Um das web-app-Deployment im dmz-Netzwerk verfügbar zu machen, erstellen Sie einen internen LoadBalancer-Dienst.

  1. Speichern Sie das folgende Manifest als internal-lb-service.yaml:

    apiVersion: v1
kind: Service
metadata:
  name: web-app-internal-lb
  namespace: default
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  externalTrafficPolicy: Local
  ports:
  -   port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    networking.gke.io/network: dmz
    app: web-app
  type: LoadBalancer

    Mit diesem Manifest wird ein Service mit den folgenden Attributen erstellt:

    • networking.gke.io/load-balancer-type: "Internal": Gibt einen internen Passthrough-Network Load Balancer an.
    • selector: Wählt Pods mit dem Label app: web-app aus, die mit dem Netzwerk dmz verbunden sind.

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f internal-lb-service.yaml

Externen LoadBalancer-Dienst bereitstellen

Um das web-app-Deployment für externe Clients verfügbar zu machen, erstellen Sie einen externen LoadBalancer-Dienst.

  1. Speichern Sie das folgende Manifest als external-lb-service.yaml:

    apiVersion: v1
kind: Service
metadata:
  name: web-app-external-lb
  namespace: default
  annotations:
    cloud.google.com/l4-rbs: "enabled"
spec:
  externalTrafficPolicy: Local
  ports:
  -   port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    networking.gke.io/network: dmz
    app: web-app
  type: LoadBalancer

    Mit diesem Manifest wird ein Service mit den folgenden Attributen erstellt:

    • cloud.google.com/l4-rbs: "enabled": gibt einen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer an. In GKE 1.37 und höher ist diese Konfiguration die Standardeinstellung und die Annotation ist nicht erforderlich.
    • selector: wählt Pods mit dem Label app: web-app aus, die mit dem Netzwerk dmz verbunden sind.

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f external-lb-service.yaml

Dienste überprüfen

Prüfen Sie nach der Bereitstellung der Dienste, ob die Load Balancer erstellt und richtig konfiguriert wurden.

  1. Status der Dienste prüfen:

    kubectl get services

    Die Ausgabe sieht etwa so aus:

    NAME                  TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)        AGE
web-app-external-lb   LoadBalancer   10.8.47.77    35.239.57.231   80:31550/TCP   5m
web-app-internal-lb   LoadBalancer   10.8.43.251   172.16.0.43     80:32628/TCP   6m
kubernetes            ClusterIP      10.8.32.1     <none>          443/TCP        43h

    Die EXTERNAL-IP-Adresse für den internen Load Balancer gehört zum dmz-Netzwerk.

  2. So listen Sie die Weiterleitungsregeln in Ihrem Projekt auf:

    gcloud compute forwarding-rules list

    Die Ausgabe sieht etwa so aus:

    NAME                                                   REGION        IP_ADDRESS     IP_PROTOCOL  TARGET
af901673cc0f24907a6aa8c3ce4afc21                       us-central1   35.239.57.231  TCP          us-central1/backendServices/k8s2-xhvzqabw-default-web-app-external-lb-u4xbs4ot
k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a us-central1   172.16.0.43    TCP          us-central1/backendServices/k8s2-xhvzqabw-default-web-app-internal-lb-vp1x1d6a

  3. Beschreiben Sie die Weiterleitungsregel für den internen Load Balancer, um zu prüfen, ob er mit dem richtigen Netzwerk verbunden ist:

    gcloud compute forwarding-rules describe k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a --region=$REGION

    Ersetzen Sie REGION durch die Region Ihres Clusters.

    Die entsprechende Ausgabe sieht etwa so aus: Prüfen Sie, ob die Felder network und subnetwork mit den Details des dmz-Netzwerks übereinstimmen.

    IPAddress: 172.16.0.43
IPProtocol: TCP
...
loadBalancingScheme: INTERNAL
name: k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a
network: https://www.googleapis.com/compute/v1/projects/projectId/global/networks/dmz-vpc
...
subnetwork: https://www.googleapis.com/compute/v1/projects/projectId/regions/us-central1/subnetworks/dmz-subnet

Load Balancer testen

  1. Senden Sie eine Anfrage an die externe IP-Adresse des externen Load Balancers, um ihn zu testen:

    curl EXTERNAL_LB_IP:80

    Ersetzen Sie EXTERNAL_LB_IP durch die externe IP-Adresse des web-app-external-lb-Dienstes.

  2. Um den internen Load Balancer zu testen, senden Sie eine Anfrage von einem Host in derselben VPC wie der Load Balancer:

    curl INTERNAL_LB_IP:80

    Ersetzen Sie INTERNAL_LB_IP durch die IP-Adresse des web-app-internal-lb-Dienstes.

Fehlerbehebung

In diesem Abschnitt wird beschrieben, wie Sie Probleme mit Multi-Netzwerk-Load-Balancern beheben.

Load-Balancer kann nicht erstellt werden

Wenn die Erstellung des Load Balancers fehlschlägt, prüfen Sie die Dienstereignisse auf Fehlermeldungen:

kubectl describe service SERVICE_NAME

Ersetzen Sie SERVICE_NAME durch den Namen Ihres Dienstes.

Eine Fehlermeldung wie network some-other-network does not exist weist darauf hin, dass das im Dienstselektor angegebene Netzwerk nicht im Cluster definiert ist. Prüfen Sie, ob das Netzwerk vorhanden ist:

kubectl get networks

Wenn das Netzwerk vorhanden ist, prüfen Sie, ob das Network-Objekt korrekt auf eine gültige GKENetworkParamSet-Ressource verweist. Prüfen Sie den Status der Network-Ressource, um nach Konfigurationsfehlern zu suchen:

kubectl get networks NETWORK_NAME -o yaml

Ersetzen Sie NETWORK_NAME durch den Namen Ihres Netzwerks.

In einer gültigen Konfiguration sind sowohl die Bedingung ParamsReady als auch die Bedingung Ready True. Wenn ParamsReady nicht True ist, prüfen Sie, ob der parametersRef in der Network-Spezifikation mit dem Namen, der Art und der Gruppe einer vorhandenen GKENetworkParamSet-Ressource übereinstimmt.

Wenn die Ressource Network korrekt ist, aber immer noch nicht bereit ist, prüfen Sie den Status der referenzierten GKENetworkParamSet auf Fehler, z. B. ein fehlendes Subnetz:

kubectl get gkenetworkparamsets GNP_NAME -o yaml

Ersetzen Sie GNP_NAME durch den Namen Ihres GKENetworkParamSet.

Load-Balancer hat keine Back-Ends

Wenn der Load Balancer bereitgestellt ist, aber keine fehlerfreien Backends hat, gehen Sie so vor:

  1. Prüfen Sie, ob ein Knotenpool mit Netzwerkschnittstellen im Netzwerk vorhanden ist, das vom Dienst verwendet wird.
  2. Prüfen Sie, ob die vom Dienst ausgewählten Pods ausgeführt werden.

  3. Prüfen Sie die Endpunkte für den Dienst:

    kubectl describe endpointslice -l kubernetes.io/service-name=SERVICE_NAME

    Der multinet-endpointslice-controller.gke.io-Controller erstellt die Multi-Netzwerk-Endpunkte. Die im EndpointSlice aufgeführten Pod-IP-Adressen gehören zum Netzwerk, das vom Service verwendet wird. Wenn das EndpointSlice keine Endpunkte hat, prüfen Sie, ob die Labels der Serviceauswahl mit den ausgeführten Pods übereinstimmen und ob die Netzwerkauswahl mit dem Netzwerk der Pods übereinstimmt.

Nächste Schritte