LoadBalancer-Dienste mit mehreren Netzwerken bereitstellen

In diesem Dokument wird beschrieben, wie Sie Pods mit mehreren Netzwerken für interne oder externe Clients freigeben, indem Sie externe Passthrough-Network-Load-Balancer und interne Passthrough-Network-Load-Balancer Ressourcen in GKE erstellen. Google Cloud Es werden die erforderliche Konfiguration, Funktionen und Einschränkungen von LoadBalancer-Diensten mit mehreren Netzwerken 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 zu mehreren Netzwerken in GKE finden Sie unter Unterstützung mehrerer Netzwerke für Pods.

Funktionsweise von LoadBalancer-Diensten mit mehreren Netzwerken

Zum Freigeben einer Arbeitslast mit mehreren Netzwerken erstellen Sie einen Service vom type: LoadBalancer. Der Dienst muss einen speziellen Selektor enthalten, der Pods basierend auf dem Netzwerk ihrer sekundären Schnittstelle auswählt. Fügen Sie eine Annotation hinzu, um anzugeben, ob ein interner oder externer Load-Balancer erstellt werden soll.

Das Label networking.gke.io/network im Selektor filtert Endpunkte nach Netzwerk. 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.
  • Das Netzwerk eines vorhandenen Dienstes kann nicht geändert werden.
  • 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 Netzwerken (nicht standardmäßig) nicht unterstützt.

Hinweis

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

  1. Folgen Sie der Anleitung unter Unterstützung mehrerer Netzwerke für Pods einrichten, um Ihre VPC-Netzwerke vorzubereiten und einen GKE Cluster mit einem zusätzlichen Netzwerk zu erstellen.
  2. Prüfen Sie, ob für Ihren Cluster die Teilmengeneinstellung für interne Layer 4-Load-Balancer aktiviert ist. Verwenden Sie zum Aktivieren dieser Funktion das Flag --enable-l4-ilb-subsetting, wenn Sie den Cluster erstellen oder aktualisieren.
  3. Achten Sie darauf, dass in Ihrem Cluster GKE-Version 1.37 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 default-Netzwerk verbunden ist, und eth1, die mit dem dmz-Netzwerk 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 dazu der Pod-Spezifikation einen initContainer mit der Funktion NET_ADMIN hinzu.

Das folgende Beispiel zeigt einen initContainer, der eine Standardroute für die eth1-Schnittstelle 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 initContainer-Befehl 172.16.1.0/24 durch den sekundären IP-Adressbereich Ihres Pod-Netzwerks.

Internen LoadBalancer-Dienst bereitstellen

Wenn Sie das web-app-Deployment im dmz-Netzwerk freigeben möchten, 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

    Dieses Manifest erstellt einen Dienst mit den folgenden Eigenschaften:

    • 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 dmz-Netzwerk verbunden sind.

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f internal-lb-service.yaml

Externen LoadBalancer-Dienst bereitstellen

Wenn Sie das web-app-Deployment für externe Clients freigeben möchten, 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

    Dieses Manifest erstellt einen Dienst mit den folgenden Eigenschaften:

    • cloud.google.com/l4-rbs: "enabled": Gibt einen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer an.
    • selector: Wählt Pods mit dem Label app: web-app aus, die mit dem dmz-Netzwerk verbunden sind.

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f external-lb-service.yaml

Dienste prüfen

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

  1. Prüfen Sie den Status der Dienste:

    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. 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 zum Testen des externen Load-Balancers eine Anfrage an seine externe IP-Adresse:

    curl EXTERNAL_LB_IP:80

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

  2. Senden Sie zum Testen des internen Load-Balancers 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 Load-Balancern mit mehreren Netzwerken beheben.

Erstellung des Load-Balancers schlägt fehl

Wenn die Erstellung des Load-Balancers fehlschlägt, suchen Sie in den Dienstereignissen nach 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 gibt an, 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 auf Konfigurationsfehler:

kubectl get networks NETWORK_NAME -o yaml

Ersetzen Sie NETWORK_NAME durch den Namen Ihres Netzwerks.

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

Wenn die Network-Ressource korrekt ist, aber immer noch nicht bereit ist, prüfen Sie den Status von dem 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 wurde, aber keine fehlerfreien Back-Ends 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 Controller multinet-endpointslice-controller.gke.io erstellt die Endpunkte mit mehreren Netzwerken. Die in der EndpointSlice aufgeführten Pod-IP-Adressen gehören zum Netzwerk, das vom Dienst verwendet wird. Wenn die EndpointSlice keine Endpunkte hat, prüfen Sie, ob die Selektorlabels des Dienstes mit den ausgeführten Pods übereinstimmen und ob der Netzwerkselektor mit dem Netzwerk der Pods übereinstimmt.

Nächste Schritte