Internen Load Balancer über VPC-Netzwerke erstellen

Autopilot Standard

---

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:

• LoadBalancer-Dienst:
• LoadBalancer-Dienstparameter
• Private Service Connect

Hinweis

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 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.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

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.
• 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.

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 Cloud-Projekts.
   • 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.2.19
           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
   

   Hinweis: Verwenden Sie für GKE-Versionen vor 1.23.3-gke.900 networking.gke.io/v1beta1 statt networking.gke.io/v1.

   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.
   Hinweis: Bei der Ressource ServiceAttachment treten Fehlerereignisse auf, bis der GKE-Controller den vom Service definierten internen Passthrough-Network-Load-Balancer erstellt. Nachdem der interne Passthrough-Network-Load-Balancer bereitgestellt wurde, werden die Fehler nicht mehr veröffentlicht.

   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:

 kubectl describe serviceattachment foo-sa
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:

Hinweis: Sie können das Feld resourceRef nicht aktualisieren und nur Subnetze in das Feld natSubnets einfügen. Sie können Subnetze nicht entfernen. Wenn Sie das Feld resourceRef aktualisieren oder Subnetze aus dem Feld natSubnets entfernen müssen, müssen Sie das ServiceAttachment löschen und dann neu erstellen.

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
   

   Hinweis: Verwenden Sie für GKE-Versionen vor 1.23.3-gke.900 networking.gke.io/v1beta1 statt networking.gke.io/v1.

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.
  Hinweis: Nachdem ein Dienstanhang mit einem internen Passthrough-Network-Load-Balancer verbunden ist, können Sie den internen Passthrough-Network-Load-Balancer nicht löschen oder aktualisieren eine Wenn Sie versuchen, den internen Passthrough-Network-Load-Balancer zu löschen oder zu aktualisieren, wird eine Fehlermeldung angezeigt. Weitere Informationen finden Sie unter Fehlerbehebung.

Problembehebung

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.

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.

Nächste Schritte

• Netzwerkübersicht
• Mehr über Compute Engine-Load-Balancer erfahren
• VPC-nativen Cluster erstellen
• Autorisierte Netzwerke für Masterzugriff erstellen