Internen Load Balancer über VPC-Netzwerke erstellen

Autopilot Standard

Auf dieser Seite wird erläutert, wie Sie einen internen Passthrough-Network-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 dem Befehl gcloud components update ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

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. Der GKE Private Service Connect-Controller überwacht Ihre ServiceAttachment-Ressource und erstellt, aktualisiert oder löscht automatisch eine entsprechende ServiceAttachment-Ressource in Compute Engine.

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.
• Für den Cluster muss das Add-on HttpLoadBalancing aktiviert sein. Für neue GKE-Cluster 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.
• Der GKE-Dienst darf nur ein einziges Protokoll verwenden. GKE-Dienste mit gemischten Protokollen werden nicht unterstützt.
• 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 gemeinsam genutzten VPCs darauf, dass alle Anforderungen für gemeinsam genutzte VPCs erfüllt sind.
• Nachdem Sie einen Dienstanhang erstellt haben, können Sie den internen Load Balancer nicht mehr aktualisieren. Wenn Sie die Load-Balancer-Konfigurationen ändern möchten, müssen Sie den Dienstanhang löschen und neu erstellen.

Kompatibilität der IP-Version für Dienste und NAT-Subnetze

Wenn Sie eine ServiceAttachment-Ressource erstellen, erstellt der GKE Private Service Connect-Controller einen einzelnen Compute Engine-Dienstanhang, der mit einer Weiterleitungsregel des Erstellers verknüpft ist. Die Weiterleitungsregel des Erstellers verwendet entweder eine IPv4- oder eine IPv6-Adresse. In der folgenden Tabelle sehen Sie, wie der Controller die Weiterleitungsregel basierend auf der IP-Familienkonfiguration (Feld spec.ipFamilies) des referenzierten Kubernetes-Dienstes und den Stack-Typen aller im Feld spec.natSubnets angegebenen Subnetze auswählt:

Kubernetes-Dienst (Weiterleitungsregeln)	Stacktypen von Subnetzen im Feld natSubnets	Weiterleitungsregel für Compute Engine-Dienstanhang	Hinweise
Single-Stack-IPv4	IPV4_ONLY, IPV4_IPV6 oder beides	IPv4-Adresse	Unterstützt.
	Enthält ein beliebiges IPV6_ONLY-Subnetz	Keine (Fehler)	Konfigurationsfehler. Alle NAT-Subnetze müssen IPv4-Adressen unterstützen.
Dual-Stack (IPv4- und IPv6-Adressen)	IPV4_ONLY, IPV4_IPV6 oder beides (kein IPV6_ONLY-Subnetz)	IPv4-Adresse	Unterstützt. Verwendet die IPv4-Weiterleitungsregel. Ein IPv4-Dienstanhang kann Verbindungen von IPv4- und IPv6-Nutzerendpunkten akzeptieren.
	IPV6_ONLY oder eine Kombination aus IPV6_ONLY und IPV4_IPV6 (kein IPV4_ONLY-Subnetz)	IPv6-Adresse	Unterstützt. Verwendet die IPv6-Weiterleitungsregel, da ein IPV6_ONLY-Subnetz vorhanden ist. Ein IPv6-Dienstanhang akzeptiert nur Verbindungen von IPv6-Nutzerendpunkten.
	Enthält die Subnetze IPV4_ONLY und IPV6_ONLY	Keine (Fehler)	Konfigurationsfehler. Alle NAT-Subnetze müssen dieselbe IP-Version verwenden.
Single-Stack-IPv6	IPV6_ONLY, IPV4_IPV6 oder beides	IPv6-Adresse	Unterstützt.
	Enthält ein beliebiges IPV4_ONLY-Subnetz	Keine (Fehler)	Konfigurationsfehler. Alle NAT-Subnetze müssen IPv6-Adressen unterstützen.

Weitere Informationen dazu, wie Nutzerendpunkte mit IPv4- und IPv6-Dienstanhängen verbunden werden, finden Sie unter Übersetzung von IP-Versionen.

Hinweis: Sie können dem Feld spec.natSubnets nur Subnetze hinzufügen und keine vorhandenen Subnetze entfernen. Betrachten Sie beispielsweise ein ServiceAttachment für einen Dual-Stack-Dienst, der ursprünglich mit IPV4_ONLY-Subnetzen oder IPV4_IPV6-Subnetzen erstellt wurde, die die IPv4-Weiterleitungsregel verwenden. Wenn Sie zur IPv6-Weiterleitungsregel wechseln möchten, müssen Sie die ServiceAttachment-Ressource mit IPV6_ONLY-Subnetzen löschen und neu erstellen.

ServiceAttachment erstellen

1. Erstellen Sie ein Subnetz.

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

   gcloud 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 Projekts in Google Cloud.
   • 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 IPv4-Adressbereich, der für das Subnetz verwendet werden soll.

   Wenn Sie ein Dual-Stack- oder reines IPv6-Private Service Connect-Subnetz erstellen möchten, fügen Sie die Flags --stack-type=IPV4_IPV6 und --ipv6-access-type=INTERNAL oder die Flags --stack-type=IPV6_ONLY und --ipv6-access-type=INTERNAL hinzu. Lassen Sie das Flag --range weg, wenn Sie den Stack-Typ IPV6_ONLY verwenden. Achten Sie darauf, dass der Stack-Typ des Subnetzes mit der IP-Familie Ihres Dienstes kompatibel ist, wie unter IP-Versionskompatibilität für Dienste und NAT-Subnetze beschrieben.

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
    reconcileConnections: false  # set to true to enable connection reconciliation
    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 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:

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.
• reconcileConnections (Vorabversion): Wenn dieser Wert auf „true“ gesetzt ist, werden bei Änderungen an den Listen der akzeptierten oder abgelehnten Dienstnutzer automatisch bestehende, nicht autorisierte Verbindungen beendet. Wenn der Wert auf „false“ gesetzt ist, wirken sich Änderungen nur auf neue Verbindungen aus. Dieses Feld ist optional und wird standardmäßig auf „false“ gesetzt. Dieses Feld wird ab GKE-Version 1.36.0-gke.2459000 unterstützt.
• 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 zu 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.

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

Fehler beim Aktivieren des globalen Zugriffs

Wenn Sie den globalen Zugriff für einen internen Passthrough-Network-Load-Balancer aktivieren, der einen Private Service Connect-Dienstanhang verwendet, kann ein Fehler auftreten.

Symptom:

Wenn Sie den globalen Zugriff aktivieren, indem Sie das 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. Wenn Sie den Befehl kubectl get events ausführen, 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 aktivieren. Da die Weiterleitungsregel jedoch von einem ServiceAttachment verwendet wird, kann sie nicht gelöscht und neu erstellt werden, was zu dem Fehler führt.

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 entweder über dieGoogle Cloud Console, die Google Cloud CLI oder die Compute Engine API zu aktualisieren.

Nicht synchronisiertes Feld „ReconcileConnections“

Wenn Sie das Feld ReconcileConnections in der Compute Engine-Ressource ServiceAttachment manuell aktiviert, aber im Kubernetes-Manifest weggelassen haben, wird das Feld standardmäßig auf false gesetzt. Der GKE-Controller überschreibt dann den Wert des Felds nicht.

Symptom:

Die Kubernetes-Ressource ServiceAttachment hat die Annotation networking.gke.io/unsynced-field: ReconcileConnections. Wenn Sie den Befehl kubectl get events ausführen, wird ein Warnereignis ähnlich dem folgenden angezeigt:

Field "ReconcileConnections" is not specified in the ServiceAttachment CR but has a value in GCE. The controller will not overwrite this field until it is explicitly set in the CR.

Workaround:

Führen Sie eine der folgenden Aktionen aus, um diese Warnung zu beheben und die Werte zu synchronisieren:

• GKE-ServiceAttachment-Ressource aktualisieren: Aktualisieren Sie Ihr GKE-ServiceAttachment-Manifest, um reconcileConnections: true (oder false, wenn Sie es deaktivieren möchten) einzuschließen.
• Compute Engine-ServiceAttachment-Ressource aktualisieren: Setzen Sie das Feld reconcileConnections manuell auf false.

Nächste Schritte

• GKE-Netzwerkübersicht
• Mehr über Compute Engine-Load-Balancer erfahren
• VPC-nativen Cluster erstellen
• Autorisierte Netzwerke für Masterzugriff erstellen
• Fehlerbehebung beim Load-Balancing in GKE.