Internen Load Balancer über VPC-Netzwerke erstellen

Auf dieser Seite wird erläutert, wie Sie einen internen TCP/UDP-Load-Balancer in Google Kubernetes Engine (GKE) über VPC-Netzwerke erstellen.

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Konzepten vertraut:

Hinweise

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 diesen Task 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. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

Internen Load-Balancer mit Private Service Connect erstellen

Als Dienstersteller können Sie Dienstanhänge verwenden, um Ihre Dienste für Dienstnutzer in anderen VPC-Netzwerken mit Private Service Connect verfügbar zu machen. Sie können Dienstanhänge mit einer benutzerdefinierten ServiceAttachment-Ressource erstellen, verwalten und löschen.

Anforderungen und Einschränkungen

  • Es gelten Einschränkungen für Private Service Connect.
  • Sie können einen Dienstanhang in GKE-Versionen 1.21.4-gke.300 und höher erstellen.
  • In Ihrem Cluster muss das HttpLoadBalancing-Add-on aktiviert sein. In neuen GKE-Clustern ist das Add-on HttpLoadBalancing standardmäßig aktiviert.
  • Sie können dasselbe Subnetz nicht in mehreren Konfigurationen für Dienstanhänge verwenden.
  • Sie müssen einen GKE-Dienst erstellen, der einen internen Passthrough-Network-Load-Balancer verwendet.
  • Sie können kein Subnetz in einem anderen Projekt (freigegebene VPC) für GKE-Versionen vor 1.22.4-gke.100 angeben. Achten Sie bei freigegebenen VPCs darauf, dass alle Anforderungen für freigegebene VPCs erfüllt sind.
  • Nachdem Sie einen Dienstanhang erstellt haben, können Sie den internen Load Balancer nicht mehr aktualisieren. Wenn Sie die Konfigurationen des Load-Balancers ändern möchten, müssen Sie die Dienstanhänge löschen und neu erstellen.

ServiceAttachment erstellen

  1. Erstellen Sie ein Subnetz.

    Sie müssen für jedes ServiceAttachment ein neues Subnetz erstellen.

    gcloud beta compute networks subnets create SUBNET_NAME \
    --project PROJECT_ID \
    --network NETWORK_NAME \
    --region REGION \
    --range SUBNET_RANGE \
    --purpose PRIVATE_SERVICE_CONNECT

    Dabei gilt:

    • SUBNET_NAME: der Name des neuen Subnetzes. In den GKE-Versionen 1.22.4-gke.100 und höher können Sie ein Subnetz in einem anderen Projekt angeben. Verwenden Sie dazu die vollständig qualifizierte Ressourcen-URL für dieses Feld. Sie können die vollständig qualifizierte Ressourcen-URL mit dem Befehl gcloud compute networks subnets describe abrufen.
    • PROJECT_ID: die ID Ihres Google CloudProjekts.
    • NETWORK_NAME: Name des VPC-Netzwerks für das Subnetz.
    • REGION: die Region für das neue Subnetz. Sie müssen dieselbe Region wie für den von Ihnen erstellten Dienst verwenden.
    • SUBNET_RANGE: der IP-Adressbereich, der für das Subnetz verwendet werden soll.

  2. Stellen Sie eine Arbeitslast bereit.

    Das folgende Manifest beschreibt eine Bereitstellung, die ein Container-Image einer Beispielwebanwendung ausführt: Speichern Sie das Manifest als my-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: psc-ilb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: psc-ilb
  template:
    metadata:
      labels:
        app: psc-ilb
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
        ports:
          - name: http
            containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 5
          timeoutSeconds: 1

  3. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f my-deployment.yaml

  4. Einen Dienst erstellen Das folgende Manifest beschreibt einen Dienst, der einen internen Passthrough-Network-Load-Balancer an TCP-Port 8080 erstellt. Speichern Sie das Manifest als my-service.yaml:

     apiVersion: v1
 kind: Service
 metadata:
   name: SERVICE_NAME
   annotations:
     networking.gke.io/load-balancer-type: "Internal"
 spec:
   type: LoadBalancer
   selector:
     app: psc-ilb
   ports:
   - port: 80
     targetPort: 8080
     protocol: TCP

    Dabei gilt:

    • SERVICE_NAME: der Name des neuen Dienstes.

  5. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f my-service.yaml

  6. Erstellen Sie ServiceAttachment.

    Das folgende Manifest beschreibt ein ServiceAttachment, das den von Ihnen erstellten Dienst für Dienstnutzer verfügbar macht. Speichern Sie das Manifest als my-psc.yaml:

    apiVersion: networking.gke.io/v1
kind: ServiceAttachment
metadata:
 name: SERVICE_ATTACHMENT_NAME
 namespace: default
spec:
 connectionPreference: ACCEPT_AUTOMATIC
 natSubnets:
 - SUBNET_NAME
 proxyProtocol: false
 resourceRef:
   kind: Service
   name: SERVICE_NAME

    Dabei gilt:

    • SERVICE_ATTACHMENT_NAME: der Name des neuen Dienstanhangs.
    • SUBNET_NAME: der Name des neuen Subnetzes. In den GKE-Versionen 1.22.4-gke.100 und höher können Sie ein Subnetz in einem anderen Projekt angeben. Verwenden Sie dazu die vollständig qualifizierte Ressourcen-URL für dieses Feld. Sie können die vollständig qualifizierte Ressourcen-URL mit dem Befehl gcloud compute networks subnets describe abrufen. Verwenden Sie für eine freigegebene VPC-Konfiguration das folgende Format: projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME.

    Weitere Informationen zu den Manifestfeldern finden Sie in den Feldern des Dienstanhangs.

  7. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f my-psc.yaml

  8. Prüfen Sie, ob der Private Service Connect-Controller den Dienstanhang erstellt hat:

    gcloud beta compute service-attachments list

    Die Ausgabe zeigt einen Dienstanhang mit einem automatisch generierten Namen:

    NAME        REGION       PRODUCER_FORWARDING_RULE          CONNECTION_PREFERENCE
k8s1-sa-... REGION_NAME  a3fea439c870148bdba5e59c9ea9451a  ACCEPT_AUTOMATIC

Ein ServiceAttachment aufrufen

Mit dem folgenden Befehl können Sie die Details eines ServiceAttachment aufrufen:

kubectl describe serviceattachment SERVICE_ATTACHMENT_NAME

Die Ausgabe sieht etwa so aus:

Name:        <sa-name>
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         ServiceAttachment
Metadata:
  ...
Status:
  Forwarding Rule URL:      https://www.googleapis.com/compute/beta/projects/<project>/regions/<region>/forwardingRules/<fr-name>
  Last Modified Timestamp:  2021-07-08T01:32:39Z
  Service Attachment URL:   https://www.googleapis.com/compute/beta/projects/<projects>/regions/<region>/serviceAttachments/<gce-service-attachment-name>
Events:                     <none>

Ein ServiceAttachment nutzen

Führen Sie die folgenden Schritte aus, um Ihren Dienst aus einem anderen Projekt zu nutzen:

  1. Rufen Sie die URL von ServiceAttachment ab:

    kubectl get serviceattachment SERVICE_ATTACHMENT_NAME -o=jsonpath="{.status.serviceAttachmentURL}"

    Die Ausgabe sieht etwa so aus:

      serviceAttachmentURL: https://www.googleapis.com/compute/alpha/projects/<project>/region/<region>/serviceAttachments/k8s1-...my-sa

  2. Mit der URL von ServiceAttachment einen Private Service Connect-Endpunkt erstellen

  3. Bestätigen Sie, dass Sie eine Verbindung zu dem Dienst herstellen können, den Sie im Erstellerprojekt bereitgestellt haben, indem Sie einen curl-Befehl von einer VM im Nutzerprojekt verwenden:

    curl PSC_IP_ADDRESS

    Ersetzen Sie PSC_IP_ADDRESS durch die IP-Adresse der Weiterleitungsregel im Nutzerprojekt.

    Die Ausgabe sieht etwa so aus:

    {
  "cluster_name":"cluster",
  "host_header":"10.128.15.200",
  "node_name":"gke-psc-default-pool-be9b6e0e-dvxg.c.gke_project.internal",
  "pod_name":"foo-7bf648dcfd-l5jf8",
  "pod_name_emoji":"👚",
  "project_id":"gke_project",
  "timestamp":"2021-06-29T21:32:03",
  "zone":"ZONE_NAME"
}

ServiceAttachment aktualisieren

Ein ServiceAttachment lässt sich mit den folgenden Schritten aktualisieren:

  1. Bearbeiten Sie das Manifest ServiceAttachment in my-psc.yaml:

    apiVersion: networking.gke.io/v1
kind: ServiceAttachment
metadata:
  name: my-sa
  namespace: default
spec:
  connectionPreference: ACCEPT_AUTOMATIC
  natSubnets:
  - my-nat-subnet
  proxyProtocol: false
  resourceRef:
    kind: Service
    name: ilb-service

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f my-psc.yaml

ServiceAttachment löschen

Mit einem Dienstanhang verbundene interne Network-Load-Balancer können nicht gelöscht werden. Sie müssen den Dienstanhang und den GKE-Dienst separat löschen.

  1. So löschen Sie den Dienstanhang:

    kubectl delete serviceattachment SERVICE_ATTACHMENT_NAME --wait=false

    Mit diesem Befehl wird der Dienstanhang zum Löschen markiert, die Ressource ist jedoch weiterhin vorhanden. Sie können auch warten, bis der Löschvorgang abgeschlossen ist. Lassen Sie dazu das Flag --wait weg.

  2. Dienst löschen:

    kubectl delete svc SERVICE_NAME

  3. Löschen Sie das Subnetz:

    gcloud compute networks subnets delete SUBNET_NAME

ServiceAttachment Felder

Das ServiceAttachment hat die folgenden Felder:

  • connectionPreference: die Verbindungsoption, die bestimmt, wie Kunden eine Verbindung zum Dienst herstellen. Sie können entweder die automatische Projektgenehmigung mit ACCEPT_AUTOMATIC oder eine explizite Projektgenehmigung mit ACCEPT_MANUAL verwenden. Weitere Informationen finden Sie unter Dienste mit Private Service Connect veröffentlichen.
  • natSubnets: eine Liste der Namen der Subnetzwerkressourcen, die für den Dienstanhang verwendet werden sollen.
  • proxyProtocol: wenn diese Option auf "true" gesetzt ist, sind die IP-Adresse der Nutzerquelle und die Verbindungs-ID von Private Service Connect in den Anfragen verfügbar. Dieses Feld ist optional und wird standardmäßig auf "false" gesetzt, wenn es nicht angegeben ist.
  • consumerAllowList: die Liste der Nutzerprojekte, die eine Verbindung zum ServiceAttachment herstellen dürfen. Dieses Feld kann nur verwendet werden, wenn connectionPreference ACCEPT_MANUAL ist. Weitere Informationen zu diesem Feld finden Sie unter Dienste mit Private Service Connect veröffentlichen.
    • project: die Projekt-ID oder Nummer des Nutzerprojekts.
    • connectionLimit: das Verbindungslimit für das Nutzerprojekt. Dieses Feld ist optional.
    • forceSendFields: die Feldnamen, die an API-Anfragen gesendet werden sollen. Dieses Feld ist optional.
    • nullFields: Die Feldnamen, die in API-Anfragen mit einem Nullwert enthalten sein sollen. Dieses Feld ist optional.
  • consumerRejectList: die Liste der Nutzerprojekt-IDs oder -Nummern, die keine Verbindung zum ServiceAttachment herstellen dürfen. Dieses Feld kann nur verwendet werden, wenn connectionPreference ACCEPT_MANUAL ist. Weitere Informationen zu diesem Feld finden Sie unter Dienste mit Private Service Connect veröffentlichen.

  • resourceRef: ein Verweis auf die Kubernetes-Ressource.

    • kind: der Typ der Kubernetes-Ressource. Sie müssen Service verwenden.
    • name: der Name der Kubernetes-Ressource, die sich im selben Namespace wie der interne Passthrough-Network-Load-Balancer befinden muss.

Fehlerbehebung

Fehlermeldungen können Sie mit dem folgenden Befehl aufrufen:

kubectl get events -n NAMESPACE

Ersetzen Sie NAMESPACE durch den Namespace des internen Passthrough-Network-Load-Balancers.

Fehler beim Löschen eines internen Passthrough-Network Load Balancers

Eine Fehlermeldung wie die folgende tritt auf, wenn Sie versuchen, einen internen Passthrough-Network-Load-Balancer zu löschen, der von einem Dienstanhang verwendet wird. Sie müssen ServiceAttachment löschen, bevor Sie den internen Passthrough-Network-Load-Balancer löschen können.

Error syncing load balancer: failed to ensure load balancer: googleapi:
Error 400: The forwarding_rule resource '<fwd-rule-URL>' is already being used
by '<svc-attachment-URL>', resourceInUseByAnotherResource.

Fehler beim Aktivieren des globalen Zugriffs

Möglicherweise tritt ein Fehler auf, wenn Sie globalen Zugriff für einen internen Passthrough-Network Load Balancer aktivieren, der ein Private Service Connect-Dienst-Attachment verwendet.

Symptom:

Wenn Sie den globalen Zugriff aktivieren, indem Sie Ihr GKE-Dienstmanifest aktualisieren und die Annotation networking.gke.io/internal-load-balancer-allow-global-access: "true" festlegen, schlägt die Aktualisierung fehl, wenn Sie das Manifest anwenden. Beim Ausführen des Befehls kubectl get events wird die folgende Fehlermeldung angezeigt:

Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: The forwarding_rule resource '...' is already being used by '...', resourceInUseByAnotherResource

Grund:

Dieser Fehler tritt auf, weil die GKE-Steuerungsebene versucht, die Weiterleitungsregel des Load Balancers neu zu erstellen, um den globalen Zugriff zu ermöglichen. Da die Weiterleitungsregel jedoch von einem ServiceAttachment verwendet wird, kann sie nicht gelöscht und neu erstellt werden. Dies führt zu dem Fehler.

Workaround:

Wenn Sie den globalen Zugriff auf den Load-Balancer aktivieren und gleichzeitig die Ausfallzeit minimieren möchten, müssen Sie die GKE-Dienstkonfiguration aktualisieren und die Weiterleitungsregel manuell aktualisieren:

  1. GKE-Dienstmanifest aktualisieren: Aktualisieren Sie Ihr GKE-Dienstmanifest, um die Annotation networking.gke.io/internal-load-balancer-allow-global-access: "true" einzufügen.

  2. Globalen Zugriff für die Weiterleitungsregel manuell aktivieren: Folgen Sie der Anleitung unter Globalen Zugriff aktivieren, um die Weiterleitungsregel des Load Balancers mit derGoogle Cloud -Konsole, der Google Cloud CLI oder der Compute Engine API zu aktualisieren.

Nächste Schritte