Hochverfügbare Containeranwendung bereitstellen

Console

1. Wählen Sie im Navigationsmenü Kubernetes Engine > Cluster aus.

2. Klicken Sie auf Cluster erstellen.

3. Geben Sie im Feld Name einen Namen für den Cluster an.

4. Wählen Sie die Kubernetes-Version für den Cluster aus.

5. Wählen Sie die Zone aus, in der der Cluster erstellt werden soll.

6. Klicken Sie auf Projekt anhängen und wählen Sie ein vorhandenes Projekt aus, das Sie an Ihren Cluster anhängen möchten. Klicken Sie dann auf Speichern. Sie können Projekte nach dem Erstellen des Clusters auf der Seite Projektdetails anhängen oder trennen. Sie müssen Ihrem Cluster ein Projekt zuweisen, bevor Sie Containerarbeitslasten darin bereitstellen können.

7. Klicken Sie auf Weiter.

8. Konfigurieren Sie die Netzwerkeinstellungen für Ihren Cluster. Diese Netzwerkeinstellungen können nach dem Erstellen des Clusters nicht mehr geändert werden. Das Standard- und einzige unterstützte Internetprotokoll für Kubernetes-Cluster ist Internet Protocol Version 4 (IPv4).

   1. Geben Sie die Poolgröße für die IP-Adresse des Load-Balancers an, z. B. 20.

   2. Wählen Sie den zu verwendenden Service-CIDR (Classless Inter-Domain Routing) aus. Ihren bereitgestellten Diensten, z. B. Load-Balancern, werden IP-Adressen aus diesem Bereich zugewiesen.

   3. Wählen Sie den zu verwendenden Pod-CIDR aus. Der Cluster weist Ihren Pods und VMs IP-Adressen aus diesem Bereich zu.

   4. Klicken Sie auf Weiter.

9. Prüfen Sie die Details des automatisch generierten Standardknotenpools für den Cluster. Klicken Sie auf edit Bearbeiten, um den Standardknotenpool zu ändern.

10. Wenn Sie zusätzliche Knotenpools erstellen möchten, wählen Sie Knotenpool hinzufügen aus. Wenn Sie den Standardknotenpool bearbeiten oder einen neuen Knotenpool hinzufügen, können Sie ihn mit den folgenden Optionen anpassen:

    1. Weisen Sie dem Knotenpool einen Namen zu. Sie können den Namen nicht mehr ändern, nachdem Sie den Knotenpool erstellt haben.
    2. Geben Sie die Anzahl der Worker-Knoten an, die im Knotenpool erstellt werden sollen.

    3. Wählen Sie die Maschinenklasse aus, die Ihren Arbeitslastanforderungen am besten entspricht. Hier finden Sie eine Liste der folgenden Einstellungen:

       • Maschinentyp
       • CPU
       • Arbeitsspeicher

    4. Klicken Sie auf Speichern.

    5. Klicken Sie auf Erstellen, um den Cluster zu erstellen.

11. Wiederholen Sie diese Schritte für jede Zone in Ihrem GDC-Universum. Achten Sie darauf, dass sich in jeder Zone, die Sie für Ihre HA-Strategie benötigen, ein Kubernetes-Cluster befindet.

API

Wenn Sie einen neuen Kubernetes-Cluster direkt über die API erstellen möchten, wenden Sie eine benutzerdefinierte Ressource auf jede GDC-Zone an.

1. Erstellen Sie eine benutzerdefinierte Cluster-Ressource und stellen Sie sie auf dem Management API-Server für Ihre Zone bereit:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF \
   apiVersion: cluster.gdc.goog/v1
   kind: Cluster
   metadata:
     name: CLUSTER_NAME
     namespace: platform
   spec:
     clusterNetwork:
       podCIDRSize: POD_CIDR
       serviceCIDRSize: SERVICE_CIDR
     initialVersion:
       kubernetesVersion: KUBERNETES_VERSION
     loadBalancer:
       ingressServiceIPSize: LOAD_BALANCER_POOL_SIZE
     nodePools:
     - machineTypeName: MACHINE_TYPE
       name: NODE_POOL_NAME
       nodeCount: NUMBER_OF_WORKER_NODES
       taints: TAINTS
       labels: LABELS
       acceleratorOptions:
         gpuPartitionScheme: GPU_PARTITION_SCHEME
     releaseChannel:
       channel: UNSPECIFIED
   EOF
   

   Ersetzen Sie Folgendes:

   • MANAGEMENT_API_SERVER: Der kubeconfig-Pfad des zonalen Management API-Servers. Weitere Informationen finden Sie unter Zum zonalen Kontext wechseln.
   • CLUSTER_NAME ist der Name des Clusters. Der Clustername darf nicht mit -system enden. Das Suffix -system ist für von GDC erstellte Cluster reserviert.
   • POD_CIDR: Die Größe der Netzwerkbereiche, aus denen virtuelle IP-Adressen (VIPs) für Pods zugewiesen werden. Wenn keine Angabe gemacht wird, wird der Standardwert 21 verwendet.
   • SERVICE_CIDR: Die Größe der Netzwerkbereiche, aus denen Dienst-VIPs zugewiesen werden. Wenn keine Angabe erfolgt, wird der Standardwert 23 verwendet.
   • KUBERNETES_VERSION: Die Kubernetes-Version des Clusters, z. B. 1.26.5-gke.2100. Eine Liste der verfügbaren Kubernetes-Versionen, die Sie konfigurieren können, finden Sie unter Verfügbare Kubernetes-Versionen für einen Cluster auflisten.
   • LOAD_BALANCER_POOL_SIZE: die Größe der nicht überlappenden IP-Adresspools, die von Load-Balancer-Diensten verwendet werden. Wenn nicht festgelegt, wird der Standardwert 20 verwendet.
   • MACHINE_TYPE: Der Maschinentyp für die Worker-Knoten des Knotenpools. Hier finden Sie die verfügbaren Maschinentypen.
   • NODE_POOL_NAME ist der Name des Knotenpools.
   • NUMBER_OF_WORKER_NODES: Die Anzahl der Worker-Knoten, die im Knotenpool bereitgestellt werden sollen.
   • TAINTS: die Markierungen, die auf die Knoten dieses Knotenpools angewendet werden sollen. Dieses Feld ist optional.
   • LABELS: Die Labels, die auf die Knoten dieses Knotenpools angewendet werden sollen. Sie enthält eine Liste von Schlüssel/Wert-Paaren. Dieses Feld ist optional.
   • GPU_PARTITION_SCHEME: Das GPU-Partitionierungsschema, wenn Sie GPU-Arbeitslasten ausführen, z. B. mixed-2. Die GPU wird nicht partitioniert, wenn dieses Feld nicht festgelegt ist. Informationen zu verfügbaren MIG-Profilen (Multi-Instance GPU) finden Sie unter Unterstützte MIG-Profile.

2. Wiederholen Sie den vorherigen Schritt für jede Zone, in der Sie Ihre Containeranwendung für Ihre HA-Strategie hosten möchten.

gdcloud

Erstellen Sie mit der gcloud CLI einen internen Lastenausgleich, der auf Pod-Arbeitslasten ausgerichtet ist.

Dieser interne Load Balancer ist auf alle Arbeitslasten im Projekt ausgerichtet, die mit dem Label übereinstimmen, das im Backend-Objekt definiert ist. Die benutzerdefinierte Ressource Backend muss auf eine Zone beschränkt sein.

So erstellen Sie einen ILB mit der gcloud CLI:

1. Erstellen Sie in jeder Zone, in der Ihre Pods ausgeführt werden, eine zonale Backend-Ressource, um den Endpunkt für den ILB zu definieren:

   gdcloud compute backends create BACKEND_NAME \
       --labels=LABELS \
       --project=PROJECT \
       --cluster=CLUSTER_NAME \
       --zone=ZONE
   

   Ersetzen Sie Folgendes:

   • BACKEND_NAME: der ausgewählte Name für die Backend-Ressource, z. B. my-backend.
   • LABELS: Der Selektor, der definiert, welche Endpunkte zwischen Pods für diese Backend-Ressource verwendet werden sollen, z. B. app=web.
   • PROJECT: Name Ihres Projekts
   • CLUSTER_NAME: Der Kubernetes-Cluster, auf den der Bereich der definierten Selektoren beschränkt ist. Wenn dieses Feld nicht angegeben ist, werden alle Endpunkte mit dem angegebenen Label ausgewählt. Dieses Feld ist optional.
   • ZONE: die Zone, die für diesen Aufruf verwendet werden soll. Wenn Sie das Zonen-Flag für alle Befehle, die es erfordern, voreinstellen möchten, führen Sie gdcloud config set core/zone ZONE aus. Das Zonenflag ist nur in Umgebungen mit mehreren Zonen verfügbar. Dieses Feld ist optional.

   Wiederholen Sie diesen Schritt für jede Zone in Ihrem GDC-Universum.

2. Erstellen Sie eine globale BackendService-Ressource:

   gdcloud compute backend-services create BACKEND_SERVICE_NAME \
       --project=PROJECT \
       --target-ports=TARGET_PORTS \
       --global
   

   Ersetzen Sie Folgendes:

   • BACKEND_SERVICE_NAME: Der Name des Backend-Dienstes.
   • PROJECT: Name Ihres Projekts
   • TARGET_PORTS: eine durch Kommas getrennte Liste von Zielports, die von diesem Backend-Dienst übersetzt werden. Jeder Zielport gibt das Protokoll, den Port in der Weiterleitungsregel und den Port in der Backend-Instanz an. Sie können mehrere Zielports angeben. Dieses Feld muss das Format protocol:port:targetport haben, z. B. TCP:80:8080. Dieses Feld ist optional.

3. Fügen Sie die BackendService-Ressource der zuvor erstellten Backend-Ressource in jeder Zone hinzu:

   gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --backend-zone=ZONE \
       --backend=BACKEND_NAME \
       --project=PROJECT \
       --global
   

   Ersetzen Sie Folgendes:

   • BACKEND_SERVICE_NAME: der Name des globalen Backend-Dienstes.
   • ZONE: die Zone des Backends.
   • BACKEND_NAME: Der Name des zonalen Backends.
   • PROJECT: Name Ihres Projekts

   Führen Sie diesen Schritt für jedes zonale Backend aus, das Sie zuvor erstellt haben.

4. Erstellen Sie eine interne ForwardingRule-Ressource, die die virtuelle IP-Adresse (VIP) definiert, unter der der Dienst verfügbar ist:

   gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
       --backend-service=BACKEND_SERVICE_NAME \
       --cidr=CIDR \
       --ip-protocol-port=PROTOCOL_PORT \
       --load-balancing-scheme=INTERNAL \
       --project=PROJECT \
       --global
   

   Ersetzen Sie Folgendes:

   • FORWARDING_RULE_INTERNAL_NAME: der Name der Weiterleitungsregel.
   • CIDR: der CIDR-Bereich, der für Ihre Weiterleitungsregel verwendet werden soll. Dieses Feld ist optional. Wenn nichts angegeben ist, wird automatisch ein IPv4/32-CIDR aus dem globalen IP-Adresspool reserviert. Geben Sie den Namen einer Subnet-Ressource im selben Namespace wie diese Weiterleitungsregel an. Eine Subnet-Ressource stellt die Anfrage- und Zuweisungsinformationen eines globalen Subnetzes dar. Weitere Informationen zu Subnet-Ressourcen finden Sie unter Subnetze verwalten.
   • PROTOCOL_PORT: das Protokoll und der Port, die in der Weiterleitungsregel verfügbar gemacht werden sollen. Dieses Feld muss das Format ip-protocol=TCP:80 haben. Der bereitgestellte Port muss mit dem Port übereinstimmen, den die eigentliche Anwendung im Container bereitstellt.

5. Prüfen Sie die konfigurierte interne Load-Balancing-Instanz, indem Sie die Ready-Bedingung für jedes der erstellten Objekte bestätigen. Prüfen Sie den Traffic mit einer curl-Anfrage an die VIP:

   1. Beschreiben Sie die Weiterleitungsregel, um die zugewiesene VIP zu erhalten:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global
      

   2. Prüfen Sie den Traffic mit einer curl-Anfrage an die VIP am Port, der im Feld in der Weiterleitungsregel angegeben ist:

      curl http://FORWARDING_RULE_VIP:PORT
      

   Ersetzen Sie Folgendes:

   • FORWARDING_RULE_VIP: die VIP der Weiterleitungsregel.
   • PORT: die Portnummer der Weiterleitungsregel.

API

Erstellen Sie mit der KRM API einen internen Lastenausgleich, der auf Container-Workloads ausgerichtet ist. Dieser interne Load Balancer ist auf alle Arbeitslasten im Projekt ausgerichtet, die dem im Backend-Objekt definierten Label entsprechen. So erstellen Sie einen globalen ILB mit der KRM API:

1. Erstellen Sie eine Backend-Ressource, um die Endpunkte für den internen Lastenausgleich zu definieren. Erstellen Sie Backend-Ressourcen für jede Zone, in der sich die Containerarbeitslasten befinden:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: Backend
   metadata:
     namespace: PROJECT
     name: BACKEND_NAME
   spec:
     clusterName: CLUSTER_NAME
     endpointsLabels:
       matchLabels:
         app: APP_NAME
   EOF
   

   Ersetzen Sie Folgendes:

   • MANAGEMENT_API_SERVER: Der Kubeconfig-Pfad des zonalen Management API-Servers. Weitere Informationen finden Sie unter Auf zonalen Kontext umstellen.
   • PROJECT: Name Ihres Projekts
   • BACKEND_NAME: der Name der Backend-Ressource.
   • CLUSTER_NAME: Der Kubernetes-Cluster, auf den der Bereich der definierten Selektoren beschränkt ist. Wenn dieses Feld nicht angegeben ist, werden alle Endpunkte mit dem angegebenen Label ausgewählt. Dieses Feld ist optional.
   • APP_NAME: Der Name Ihrer Containeranwendung.

   Sie können dieselbe Backend-Ressource für jede Zone verwenden oder Backend-Ressourcen mit unterschiedlichen Labelsätzen für jede Zone erstellen.

2. Erstellen Sie ein BackendService-Objekt mit der zuvor erstellten Backend-Ressource. Achten Sie darauf, die Ressource HealthCheck anzugeben:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: BackendService
   metadata:
     namespace: PROJECT
     name: BACKEND_SERVICE_NAME
   spec:
     backendRefs:
     - name: BACKEND_NAME
       zone: ZONE
     healthCheckName: HEALTH_CHECK_NAME
     targetPorts:
     - port: PORT
       protocol: PROTOCOL
       targetPort: TARGET_PORT
   EOF
   

   Ersetzen Sie Folgendes:

   • GLOBAL_API_SERVER: Der kubeconfig-Pfad des globalen API-Servers.
   • PROJECT: Name Ihres Projekts
   • BACKEND_SERVICE_NAME: der ausgewählte Name für Ihre BackendService-Ressource.
   • HEALTH_CHECK_NAME: Der Name der zuvor erstellten HealthCheck-Ressource.
   • BACKEND_NAME: Der Name der zonalen Backend-Ressource.

   • ZONE: die Zone, in der sich die Backend-Ressource befindet. Sie können mehrere Back-Ends im Feld backendRefs angeben. Beispiel:

     - name: my-backend-1
       zone: us-east1-a
     - name: my-backend-2
       zone: us-east1-b
     

     Das Feld targetPorts ist optional. In dieser Ressource werden die Ports aufgeführt, die von dieser BackendService-Ressource übersetzt werden. Wenn Sie dieses Objekt verwenden, geben Sie Werte für Folgendes an:

   • PORT: der vom Dienst bereitgestellte Port.

   • PROTOCOL: Das Layer-4-Protokoll, mit dem der Traffic übereinstimmen muss. Nur TCP und UDP werden unterstützt.

   • TARGET_PORT: Der Port, zu dem der Wert übersetzt wird, z. B. 8080. Der Wert darf in einem bestimmten Objekt nicht wiederholt werden.

     Ein Beispiel für targetPorts könnte so aussehen:

     targetPorts:
       - port: 80
         protocol: TCP
         targetPort: 8080
     

3. Erstellen Sie eine interne ForwardingRule-Ressource, die die virtuelle IP-Adresse (VIP) definiert, unter der der Dienst verfügbar ist.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ForwardingRuleInternal
   metadata:
     namespace: PROJECT
     name: FORWARDING_RULE_INTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   Ersetzen Sie Folgendes:

   • GLOBAL_API_SERVER: Der kubeconfig-Pfad des globalen API-Servers.
   • PROJECT: Name Ihres Projekts
   • FORWARDING_RULE_INTERNAL_NAME: der ausgewählte Name für Ihre ForwardingRuleInternal-Ressource.
   • CIDR: der CIDR-Bereich, der für Ihre Weiterleitungsregel verwendet werden soll. Dieses Feld ist optional. Wenn nichts angegeben ist, wird automatisch ein IPv4/32-CIDR aus dem globalen IP-Adresspool reserviert. Geben Sie den Namen einer Subnet-Ressource im selben Namespace wie diese Weiterleitungsregel an. Eine Subnet-Ressource stellt die Anfrage- und Zuweisungsinformationen eines globalen Subnetzes dar. Weitere Informationen zu Subnet-Ressourcen finden Sie unter Subnetze verwalten.
   • PORT: Der Port, der für die Weiterleitungsregel verfügbar gemacht werden soll. Mit dem Feld ports können Sie ein Array von L4-Ports angeben, für die Pakete an die mit dieser Weiterleitungsregel konfigurierten Back-Ends weitergeleitet werden. Es muss mindestens ein Port angegeben werden. Verwenden Sie das Feld port, um eine Portnummer anzugeben. Der bereitgestellte Port muss mit dem Port übereinstimmen, den die eigentliche Anwendung im Container bereitstellt.

   • PROTOCOL: Das Protokoll, das für die Weiterleitungsregel verwendet werden soll, z. B. TCP. Ein Eintrag im ports-Array muss so aussehen:

     ports:
     - port: 80
       protocol: TCP
     

4. Prüfen Sie die konfigurierte interne Load-Balancing-Instanz, indem Sie die Ready-Bedingung für jedes der erstellten Objekte bestätigen. Prüfen Sie den Traffic mit einer curl-Anfrage an die VIP:

   1. Rufen Sie die VIP ab:

      kubectl get forwardingruleinternal -n PROJECT
      

      Die Ausgabe sieht so aus:

      NAME           BACKENDSERVICE                  CIDR              READY
      ilb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True
      

   2. Testen Sie den Traffic mit einer curl-Anfrage an die VIP am Port, der im Feld in der Weiterleitungsregel angegeben ist:

      curl http://FORWARDING_RULE_VIP:PORT
      

      Ersetzen Sie Folgendes:

      • FORWARDING_RULE_VIP: die VIP der Weiterleitungsregel.
      • PORT: die Portnummer des Felds in der Weiterleitungsregel.

gdcloud

Verwenden Sie die gcloud CLI, um einen globalen ELB zu erstellen, der auf alle Arbeitslasten im Projekt ausgerichtet ist, die mit dem Label übereinstimmen, das im Backend-Objekt definiert ist. Die benutzerdefinierte Ressource Backend muss auf eine Zone beschränkt sein.

1. Damit ELB-Dienste funktionieren, müssen Sie eine eigene angepasste ProjectNetworkPolicy-Datenübertragungsrichtlinie konfigurieren und anwenden, um Traffic zu den Arbeitslasten dieses ELB-Dienstes zuzulassen. Netzwerkrichtlinien steuern den Zugriff auf Ihre Arbeitslasten, nicht auf den Load-Balancer selbst. ELBs machen Arbeitslasten für Ihr Kundennetzwerk verfügbar. Daher sind explizite Netzwerkrichtlinien erforderlich, um externen Traffic zum Arbeitslastport, z. B. 8080, zuzulassen.

   Geben Sie die externe CIDR-Adresse an, um Traffic zu den Arbeitslasten dieses ELB zuzulassen:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT
     name: allow-inbound-traffic-from-external
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
     ingress:
     - from:
       - ipBlock:
           cidr: CIDR
       ports:
       - protocol: TCP
         port: PORT
   EOF
   

   Ersetzen Sie Folgendes:

   • GLOBAL_API_SERVER: Der kubeconfig-Pfad des globalen API-Servers. Wenn Sie noch keine kubeconfig-Datei für den globalen API-Server generiert haben, finden Sie weitere Informationen unter kubeconfig-Datei manuell generieren.
   • PROJECT: Name Ihres Projekts
   • CIDR: Der externe CIDR-Bereich, über den auf den ELB zugegriffen werden muss. Diese Richtlinie ist erforderlich, da der externe Load-Balancer DSR (Direct Server Return) verwendet. Dadurch wird die externe Quell-IP-Adresse beibehalten und der Load-Balancer auf dem Rückgabepfad umgangen. Weitere Informationen finden Sie unter Globale Firewallregel für eingehenden organisationsübergreifenden Traffic erstellen.
   • PORT: der Backend-Port für die Pods hinter dem Load-Balancer. Dieser Wert befindet sich im Feld .spec.ports[].targetPortfield des Manifests für die Ressource Service. Dieses Feld ist optional.

   Diese Konfiguration ermöglicht allen Ressourcen in Projekten den Zugriff auf den angegebenen CIDR-Bereich.

2. Erstellen Sie in jeder Zone eine Backend-Ressource, um den Endpunkt für den ELB zu definieren:

   gdcloud compute backends create BACKEND_NAME \
     --labels=LABELS \
     --project=PROJECT \
     --cluster=CLUSTER_NAME \
     --zone=ZONE
   

   Ersetzen Sie Folgendes:

   • BACKEND_NAME: Der Name der Backend-Ressource, z. B. my-backend.
   • LABELS: Eine Auswahl, die definiert, welche Endpunkte zwischen Pods für diese Backend-Ressource verwendet werden sollen, z. B. app=web.
   • PROJECT: Name Ihres Projekts
   • CLUSTER_NAME: Der Kubernetes-Cluster, auf den der Bereich der definierten Selektoren beschränkt ist. Wenn dieses Feld nicht angegeben ist, werden alle Endpunkte mit dem angegebenen Label ausgewählt. Dieses Feld ist optional.
   • ZONE: die Zone, die für diesen Aufruf verwendet werden soll. Wenn Sie das Zonen-Flag für alle Befehle, die es erfordern, voreinstellen möchten, führen Sie gdcloud config set core/zone ZONE aus. Das Zonenflag ist nur in Umgebungen mit mehreren Zonen verfügbar. Dieses Feld ist optional.

   Sie können dieselbe Backend-Ressource für jede Zone verwenden oder Backend-Ressourcen mit unterschiedlichen Labelsätzen für jede Zone erstellen.

3. Erstellen Sie eine globale BackendService-Ressource:

   gdcloud compute backend-services create BACKEND_SERVICE_NAME \
     --project=PROJECT \
     --target-ports=TARGET_PORTS \
     --health-check=HEALTH_CHECK_NAME \
     --global
   

   Ersetzen Sie Folgendes:

   • BACKEND_SERVICE_NAME: der ausgewählte Name für diesen Backend-Dienst.
   • PROJECT: Name Ihres Projekts
   • TARGET_PORTS: eine durch Kommas getrennte Liste der Zielports, die von diesem Backend-Dienst übersetzt werden. Jeder Zielport gibt das Protokoll, den Port in der Weiterleitungsregel und den Port in der Backend-Instanz an. Sie können mehrere Zielports angeben. Dieses Feld muss das Format protocol:port:targetport haben, z. B. TCP:80:8080. Dieses Feld ist optional.
   • HEALTH_CHECK_NAME: der Name der Systemdiagnoseressource. Dieses Feld ist optional.

4. Fügen Sie der zuvor erstellten zonalen Backend-Ressource die globale BackendService-Ressource hinzu:

   gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --backend=BACKEND_NAME \
     --backend-zone=ZONE \
     --project=PROJECT \
     --global
   

   Führen Sie diesen Schritt für jedes zonale Backend aus, das Sie zuvor erstellt haben.

5. Erstellen Sie eine externe ForwardingRule-Ressource, die die VIP definiert, unter der der Dienst verfügbar ist:

   gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
     --backend-service=BACKEND_SERVICE_NAME \
     --cidr=CIDR \
     --ip-protocol-port=PROTOCOL_PORT \
     --load-balancing-scheme=EXTERNAL \
     --project=PROJECT \
     --global
   

   Ersetzen Sie Folgendes:

   • FORWARDING_RULE_EXTERNAL_NAME: der Name der Weiterleitungsregel.
   • CIDR: der CIDR-Bereich, der für Ihre Weiterleitungsregel verwendet werden soll. Dieses Feld ist optional. Wenn nichts angegeben ist, wird automatisch ein IPv4/32-CIDR aus dem globalen IP-Adresspool reserviert. Geben Sie den Namen einer Subnet-Ressource im selben Namespace wie diese Weiterleitungsregel an. Eine Subnet-Ressource stellt die Anfrage- und Zuweisungsinformationen eines globalen Subnetzes dar. Weitere Informationen zu Subnet-Ressourcen finden Sie unter Subnetze verwalten.
   • PROTOCOL_PORT: das Protokoll und der Port, die in der Weiterleitungsregel verfügbar gemacht werden sollen. Dieses Feld muss das Format ip-protocol=TCP:80 haben. Der bereitgestellte Port muss mit dem Port übereinstimmen, den die eigentliche Anwendung im Container bereitstellt.
   • PROJECT: Name Ihres Projekts

6. Prüfen Sie die Ready-Bedingung für jedes der erstellten Objekte, um den konfigurierten ELB zu validieren. Prüfen Sie den Traffic mit einer curl-Anfrage an die VIP:

   1. Beschreiben Sie die Weiterleitungsregel, um die zugewiesene VIP zu erhalten:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
      

   2. Prüfen Sie den Traffic mit einer curl-Anfrage an die VIP am Port, der im Feld PROTOCOL_PORT in der Weiterleitungsregel angegeben ist:

      curl http://FORWARDING_RULE_VIP:PORT
      

      Ersetzen Sie Folgendes:

      • FORWARDING_RULE_VIP: die VIP der Weiterleitungsregel.
      • PORT: die Portnummer aus dem Feld PROTOCOL_PORT in der Weiterleitungsregel.

API

Erstellen Sie mit der KRM API einen ELB, der auf Pod-Arbeitslasten ausgerichtet ist. Diese ELB ist auf alle Arbeitslasten im Projekt ausgerichtet, die mit dem im Backend-Objekt definierten Label übereinstimmen. So erstellen Sie einen zonenbasierten ELB mit der KRM API:

1. Damit ELB-Dienste funktionieren, müssen Sie eine eigene angepasste ProjectNetworkPolicy-Datenübertragungsrichtlinie konfigurieren und anwenden, um Traffic zu den Arbeitslasten dieses ELB-Dienstes zuzulassen. Netzwerkrichtlinien steuern den Zugriff auf Ihre Arbeitslasten, nicht auf den Load-Balancer selbst. ELBs machen Arbeitslasten für Ihr Kundennetzwerk verfügbar. Daher sind explizite Netzwerkrichtlinien erforderlich, um externen Traffic zum Arbeitslastport, z. B. 8080, zuzulassen.

   Geben Sie die externe CIDR-Adresse an, um Traffic zu den Arbeitslasten dieses ELB zuzulassen:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT
     name: allow-inbound-traffic-from-external
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
     ingress:
     - from:
       - ipBlock:
           cidr: CIDR
       ports:
       - protocol: TCP
         port: PORT
   EOF
   

   Ersetzen Sie Folgendes:

   • GLOBAL_API_SERVER: Der kubeconfig-Pfad des globalen API-Servers. Wenn Sie noch keine kubeconfig-Datei für den globalen API-Server generiert haben, finden Sie weitere Informationen unter kubeconfig-Datei manuell generieren.
   • PROJECT: Name Ihres Projekts
   • CIDR: Der externe CIDR-Bereich, über den auf den ELB zugegriffen werden muss. Diese Richtlinie ist erforderlich, da der externe Load-Balancer DSR (Direct Server Return) verwendet. Dadurch wird die externe Quell-IP-Adresse beibehalten und der Load-Balancer auf dem Rückgabepfad umgangen. Weitere Informationen finden Sie unter Globale Firewallregel für eingehenden organisationsübergreifenden Traffic erstellen.
   • PORT: der Backend-Port für die Pods hinter dem Load-Balancer. Dieser Wert befindet sich im Feld .spec.ports[].targetPortfield des Manifests für die Ressource Service. Dieses Feld ist optional.

2. Erstellen Sie eine Backend-Ressource, um die Endpunkte für die ELB zu definieren. Erstellen Sie Backend-Ressourcen für jede Zone, in der sich die Arbeitslasten befinden:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: Backend
   metadata:
     namespace: PROJECT
     name: BACKEND_NAME
   spec:
     clusterName: CLUSTER_NAME
     endpointsLabels:
       matchLabels:
         app: APP_NAME
   EOF
   

   Ersetzen Sie Folgendes:

   • MANAGEMENT_API_SERVER: Der Kubeconfig-Pfad des zonalen Management API-Servers. Wenn Sie noch keine kubeconfig-Datei für den API-Server in Ihrer Zielzone generiert haben, lesen Sie den Abschnitt kubeconfig-Datei manuell generieren.
   • PROJECT: Name Ihres Projekts
   • BACKEND_NAME ist der Name der Backend-Ressource.
   • CLUSTER_NAME: Der Kubernetes-Cluster, auf den der Bereich der definierten Selektoren beschränkt ist. Wenn dieses Feld nicht angegeben ist, werden alle Endpunkte mit dem angegebenen Label ausgewählt. Dieses Feld ist optional.
   • APP_NAME: Der Name Ihrer Containeranwendung.

   Sie können dieselbe Backend-Ressource für jede Zone verwenden oder Backend-Ressourcen mit unterschiedlichen Labelsätzen für jede Zone erstellen.

3. Erstellen Sie ein BackendService-Objekt mit der zuvor erstellten Backend-Ressource:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: BackendService
   metadata:
     namespace: PROJECT
     name: BACKEND_SERVICE_NAME
   spec:
     backendRefs:
     - name: BACKEND_NAME
       zone: ZONE
     healthCheckName: HEALTH_CHECK_NAME
   EOF
   

   Ersetzen Sie Folgendes:

   • BACKEND_SERVICE_NAME: der ausgewählte Name für Ihre BackendService-Ressource.
   • HEALTH_CHECK_NAME: Der Name der zuvor erstellten HealthCheck-Ressource. Geben Sie dieses Feld nicht an, wenn Sie einen ELB für Pod-Arbeitslasten konfigurieren.
   • ZONE: die Zone, in der sich die Backend-Ressource befindet. Sie können mehrere Back-Ends im Feld backendRefs angeben. Beispiel:

   - name: my-backend-1
     zone: us-east1-a
   - name: my-backend-2
     zone: us-east1-b
   

4. Erstellen Sie eine externe ForwardingRule-Ressource, in der die VIP definiert ist, unter der der Dienst verfügbar ist.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ForwardingRuleExternal
   metadata:
     namespace: PROJECT
     name: FORWARDING_RULE_EXTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   Ersetzen Sie Folgendes:

   • FORWARDING_RULE_EXTERNAL_NAME: Der ausgewählte Name für Ihre ForwardingRuleExternal-Ressource.
   • CIDR: der CIDR-Bereich, der für Ihre Weiterleitungsregel verwendet werden soll. Dieses Feld ist optional. Wenn nichts angegeben ist, wird automatisch ein IPv4/32-CIDR aus dem globalen IP-Adresspool reserviert. Geben Sie den Namen einer Subnet-Ressource im selben Namespace wie diese Weiterleitungsregel an. Eine Subnet-Ressource stellt die Anfrage- und Zuweisungsinformationen eines globalen Subnetzes dar. Weitere Informationen zu Subnet-Ressourcen finden Sie unter Subnetze verwalten.
   • PORT: der Port, der für die Weiterleitungsregel verfügbar gemacht werden soll. Verwenden Sie das Feld ports, um ein Array von L4-Ports anzugeben, für die Pakete an die mit dieser Weiterleitungsregel konfigurierten Back-Ends weitergeleitet werden. Es muss mindestens ein Port angegeben werden. Verwenden Sie das Feld port, um eine Portnummer anzugeben. Der bereitgestellte Port muss mit dem Port übereinstimmen, den die eigentliche Anwendung im Container bereitstellt.
   • PROTOCOL: das Protokoll, das für die Weiterleitungsregel verwendet werden soll, z. B. TCP. Ein Eintrag im ports-Array muss so aussehen:

   ports:
   - port: 80
     protocol: TCP
   

5. Prüfen Sie die Ready-Bedingung für jedes der erstellten Objekte, um den konfigurierten ELB zu validieren. Testen Sie den Traffic mit einer curl-Anfrage an die VIP.

   1. Rufen Sie die VIP für das Projekt ab:

      kubectl get forwardingruleexternal -n PROJECT
      

      Die Ausgabe sieht so aus:

      NAME           BACKENDSERVICE                  CIDR              READY
      elb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True
      

   2. Prüfen Sie den Traffic mit einer curl-Anfrage an die VIP am Port, der im Feld PORT in der Weiterleitungsregel angegeben ist:

      curl http://FORWARDING_RULE_VIP:PORT
      

      Ersetzen Sie FORWARDING_RULE_VIP:PORT durch die VIP und den Port der Weiterleitungsregel, z. B. 192.0.2.0:80.