Hochverfügbare VM-Anwendung bereitstellen

Console

1. Wählen Sie im Navigationsmenü Virtuelle Maschinen > Instanzen aus.
2. Klicken Sie auf Instanz erstellen.
3. Geben Sie im Feld Name einen Namen für die VM ein.
4. Wählen Sie die Zone aus, in der die VM erstellt werden soll.
5. Klicken Sie auf Labels hinzufügen, um der VM Labels zuzuweisen und Ihre VM-Instanzen besser zu organisieren.
6. Wählen Sie die Maschinenkonfiguration aus, die für die VM verwendet werden soll. Prüfen Sie, ob der Maschinentyp je nach Ihren Anforderungen zu Ihrer Arbeitslast passt.
7. Klicken Sie auf Weiter.
8. Aktivieren Sie den externen Zugriff für Ihre VM-Instanz.
9. Klicken Sie auf Weiter.
10. Wählen Sie Neues Laufwerk hinzufügen aus.
11. Weisen Sie Ihrer VM-Festplatte einen Namen zu.
12. Konfigurieren Sie die Laufwerkgröße und die Einstellungen für das Anhängen.
13. Klicken Sie auf Speichern.
14. Klicken Sie auf Erstellen, um die VM-Instanz zu erstellen.
15. Wiederholen Sie die vorherigen 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, eine VM-Instanz befindet.

gdcloud

1. Melden Sie sich in der Zone an, in der Sie Ihre VM-Instanz hosten möchten:

   gdcloud config set core/zone ZONE
   

2. Erstellen Sie die VM-Instanz in der Zone mit einem von GDC bereitgestellten Image:

   gdcloud compute instances create VM_NAME \
       --machine-type=MACHINE_TYPE \
       --image=BOOT_DISK_IMAGE_NAME
       --image-project=vm-system \
       --boot-disk-size=BOOT_DISK_SIZE \
       --no-boot-disk-auto-delete=NO_BOOT_DISK_AUTO_DELETE
   

   Ersetzen Sie Folgendes:

   • VM_NAME ist der Name der neuen VM. Der Name darf nur alphanumerische Zeichen und Bindestriche enthalten und darf nicht länger als 53 Zeichen sein.
   • MACHINE_TYPE ist der vordefinierte Maschinentyp für die neue VM. Führen Sie gdcloud compute machine-types list aus, um einen verfügbaren Maschinentyp auszuwählen.
   • BOOT_DISK_IMAGE_NAME: Der Name des Images, das für das neue VM-Bootlaufwerk verwendet werden soll.
   • BOOT_DISK_SIZE: die Größe des Bootlaufwerks, z. B. 20GB. Dieser Wert muss immer größer oder gleich dem minimumDiskSize des Bootlaufwerk-Images sein.
   • NO_BOOT_DISK_AUTO_DELETE: Gibt an, ob das Bootlaufwerk automatisch gelöscht wird, wenn die VM-Instanz gelöscht wird.

3. Wiederholen Sie die vorherigen 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, eine VM-Instanz befindet.

API

1. Erstellen Sie die VM-Instanz in der Zone mit einem von GDC bereitgestellten Image:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: virtualmachine.gdc.goog/v1
   kind: VirtualMachineDisk
   metadata:
     name: VM_BOOT_DISK_NAME
     namespace: PROJECT
   spec:
     source:
       image:
         name: BOOT_DISK_IMAGE_NAME
         namespace: vm-system
     size: BOOT_DISK_SIZE
   ---
   apiVersion: virtualmachine.gdc.goog/v1
   kind: VirtualMachine
   metadata:
     name: VM_NAME
     namespace: PROJECT
   spec:
     compute:
       virtualMachineType: MACHINE_TYPE
     disks:
       - virtualMachineDiskRef:
           name: VM_BOOT_DISK_NAME
         boot: true
         autoDelete: BOOT_DISK_AUTO_DELETE
   ---
   apiVersion: virtualmachine.gdc.goog/v1
   kind: VirtualMachineExternalAccess
   metadata:
     name: VM_NAME
     namespace: PROJECT
   spec:
     enabled: true
     ports:
     - name: port-80
       port: 80
       protocol: TCP
   EOF
   

   Ersetzen Sie Folgendes:

   • MANAGEMENT_API_SERVER: Die kubeconfig-Datei des Management API-Servers für die Zone, in der die VM-Instanz erstellt werden soll. Wenn Sie noch keine kubeconfig-Datei für den Management API-Server generiert haben, lesen Sie den Abschnitt kubeconfig-Datei manuell generieren.
   • VM_BOOT_DISK_NAME: der Name des neuen VM-Bootlaufwerks.
   • PROJECT: Das GDC-Projekt, in dem die VM erstellt werden soll.
   • BOOT_DISK_IMAGE_NAME: Der Name des Images, das für das neue VM-Bootlaufwerk verwendet werden soll.
   • BOOT_DISK_SIZE: die Größe des Bootlaufwerks, z. B. 20Gi. Dieser Wert muss immer größer oder gleich dem minimumDiskSize des Bootlaufwerk-Images sein.
   • VM_NAME ist der Name der neuen VM. Der Name darf nur alphanumerische Zeichen und Bindestriche enthalten und darf nicht länger als 53 Zeichen sein.
   • MACHINE_TYPE ist der vordefinierte Maschinentyp für die neue VM. Führen Sie gdcloud compute machine-types list aus, um einen verfügbaren Maschinentyp auszuwählen.
   • BOOT_DISK_AUTO_DELETE: Gibt an, ob das Bootlaufwerk automatisch gelöscht wird, wenn die VM-Instanz gelöscht wird.

2. Prüfen Sie, ob die VM verfügbar ist, und warten Sie, bis die VM den Status Running hat. Der Status Running bedeutet nicht, dass das Betriebssystem vollständig bereit und zugänglich ist.

   kubectl --kubeconfig MANAGEMENT_API_SERVER \
       get virtualmachine.virtualmachine.gdc.goog VM_NAME -n PROJECT
   

   Ersetzen Sie VM_NAME und PROJECT durch den Namen und das Projekt der VM.

3. Wiederholen Sie die vorherigen 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, eine VM-Instanz befindet.

gdcloud

Erstellen Sie mit der gcloud CLI einen internen Lastenausgleich, der auf VM-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 VMs 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 \
       --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 VMs für diese Backend-Ressource verwendet werden sollen, z. B. app=web.
   • PROJECT: Name Ihres Projekts
   • 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. Globale Systemdiagnose für den internen Lastenausgleich definieren:

   gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
       --check-interval=CHECK_INTERVAL \
       --healthy-threshold=HEALTHY_THRESHOLD \
       --timeout=TIMEOUT \
       --unhealthy-threshold=UNHEALTHY_THRESHOLD \
       --port=PORT \
       --global
   

   Ersetzen Sie Folgendes:

   • HEALTH_CHECK_NAME: Der Name der Systemdiagnoseressource, z. B. my-health-check.
   • CHECK_INTERVAL: die Zeitspanne in Sekunden vom Start einer Prüfung bis zum Start der nächsten. Der Standardwert ist 5. Dieses Feld ist optional.
   • HEALTHY_THRESHOLD: die Zeit, die gewartet werden soll, bevor ein Fehler gemeldet wird. Der Standardwert ist 5. Dieses Feld ist optional.
   • TIMEOUT: Die Zeit in Sekunden, die gewartet werden soll, bevor ein Fehler gemeldet wird. Der Standardwert ist 5. Dieses Feld ist optional.
   • UNHEALTHY_THRESHOLD: Die Anzahl der sequenziellen Testdurchläufe, die fehlschlagen müssen, damit der Endpunkt als fehlerhaft eingestuft wird. Der Standardwert ist 2. Dieses Feld ist optional.
   • PORT: Der Port, auf dem die Systemdiagnose ausgeführt wird. Der Standardwert ist 80. Dieses Feld ist optional.

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 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.
   • HEALTH_CHECK_NAME: der Name der Systemdiagnoseressource. Dieses Feld ist optional.

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

5. 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 freigegebene Port muss mit dem Port übereinstimmen, den die eigentliche Anwendung in der VM freigibt.

6. 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 ILB, der auf VM-Arbeitslasten 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 VM-Arbeitslasten befinden:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: Backend
   metadata:
     namespace: PROJECT
     name: BACKEND_NAME
   spec:
     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.
   • APP_NAME: der Name Ihrer VM-Anwendung.

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

2. Globale Systemdiagnose für den internen Lastenausgleich definieren:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: HealthCheck
   metadata:
     namespace: PROJECT
     name: HEALTH_CHECK_NAME
   spec:
     tcpHealthCheck:
       port: PORT
     timeoutSec: TIMEOUT
     checkIntervalSec: CHECK_INTERVAL
     healthyThreshold: HEALTHY_THRESHOLD
     unhealthyThreshold: UNHEALTHY_THRESHOLD
   EOF
   

   Ersetzen Sie Folgendes:

   • GLOBAL_API_SERVER: Der kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Zum globalen Kontext wechseln.
   • PROJECT: Name Ihres Projekts
   • HEALTH_CHECK_NAME: Der Name der Systemdiagnoseressource, z. B. my-health-check.
   • PORT: der Port, auf dem die Systemdiagnose ausgeführt werden soll. Der Standardwert ist 80.
   • TIMEOUT: Die Wartezeit in Sekunden, bevor ein Fehler gemeldet wird. Der Standardwert ist 5.
   • CHECK_INTERVAL: die Zeitspanne in Sekunden vom Start einer Prüfung bis zum Start der nächsten. Der Standardwert ist 5.
   • HEALTHY_THRESHOLD: Die Anzahl der sequenziellen Testdurchläufe, die bestanden werden müssen, damit der Endpunkt als fehlerfrei gilt. Der Standardwert ist 2.
   • UNHEALTHY_THRESHOLD: Die Anzahl der sequenziellen Prüfungen, die fehlschlagen müssen, damit der Endpunkt als fehlerhaft gilt. Der Standardwert ist 2.

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

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

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. 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 auf den VMs 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
   

   Ersetzen Sie Folgendes:

   • BACKEND_NAME: Der Name der Backend-Ressource, z. B. my-backend.
   • LABELS: Ein Selektor, der definiert, welche Endpunkte zwischen VMs für diese Backend-Ressource verwendet werden sollen, z. B. app=web.
   • PROJECT: Name Ihres Projekts

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

3. Globale Systemdiagnose für den ELB definieren:

   gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
     --check-interval=CHECK_INTERVAL \
     --healthy-threshold=HEALTHY_THRESHOLD \
     --timeout=TIMEOUT \
     --unhealthy-threshold=UNHEALTHY_THRESHOLD \
     --port=PORT \
     --global
   

   Ersetzen Sie Folgendes:

   • HEALTH_CHECK_NAME: der Name der Systemdiagnoseressource, z. B. my-health-check.
   • CHECK_INTERVAL: die Zeitspanne in Sekunden vom Start einer Prüfung bis zum Start der nächsten. Der Standardwert ist 5. Dieses Feld ist optional.
   • HEALTHY_THRESHOLD: Die Zeit, die gewartet werden soll, bevor ein Fehler gemeldet wird. Der Standardwert ist 5. Dieses Feld ist optional.
   • TIMEOUT: Die Wartezeit in Sekunden, bevor ein Fehler gemeldet wird. Der Standardwert ist 5. Dieses Feld ist optional.
   • UNHEALTHY_THRESHOLD: Die Anzahl der sequenziellen Prüfungen, die fehlschlagen müssen, damit der Endpunkt als fehlerhaft gilt. Der Standardwert ist 2. Dieses Feld ist optional.
   • PORT: der Port, auf dem die Systemdiagnose ausgeführt werden soll. Der Standardwert ist 80. Dieses Feld ist optional.

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

5. 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 BACKEND_ZONE \
     --project=PROJECT \
     --global
   

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

6. 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 freigegebene Port muss mit dem Port übereinstimmen, den die eigentliche Anwendung in der VM freigibt.
   • PROJECT: Name Ihres Projekts

7. 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 VM-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 auf den VMs 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:
     endpointsLabels:
       matchLabels:
         app: server
   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.

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

3. Globale Systemdiagnose für den ELB definieren:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: HealthCheck
   metadata:
     namespace: PROJECT
     name: HEALTH_CHECK_NAME
   spec:
     tcpHealthCheck:
       port: PORT
     timeoutSec: TIMEOUT
     checkIntervalSec: CHECK_INTERVAL
     healthyThreshold: HEALTHY_THRESHOLD
     unhealthyThreshold: UNHEALTHY_THRESHOLD
   EOF
   

   Ersetzen Sie Folgendes:

   • HEALTH_CHECK_NAME: der Name der Systemdiagnoseressource, z. B. my-health-check.
   • PORT: der Port, auf dem die Systemdiagnose ausgeführt werden soll. Der Standardwert ist 80.
   • TIMEOUT: Die Wartezeit in Sekunden, bevor ein Fehler gemeldet wird. Der Standardwert ist 5.
   • CHECK_INTERVAL: die Zeitspanne in Sekunden vom Start einer Prüfung bis zum Start der nächsten. Der Standardwert ist 5.
   • HEALTHY_THRESHOLD: Die Anzahl der sequenziellen Tests, die bestanden werden müssen, damit der Endpunkt als fehlerfrei gilt. Der Standardwert ist 2.
   • UNHEALTHY_THRESHOLD: Die Anzahl der sequenziellen Prüfungen, die fehlschlagen müssen, damit der Endpunkt als fehlerhaft gilt. Der Standardwert ist 2.

   Da es sich um eine globale ELB handelt, erstellen Sie die Systemdiagnose in der globalen API.

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

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

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

gdcloud

1. Legen Sie die asynchrone Replikationsbeziehung zwischen der primären Zone und den sekundären Zonen fest:

   gdcloud compute disks start-async-replication PRIMARY_DISK_NAME \
       --project PROJECT \
       --zone PRIMARY_ZONE \
       --secondary-disk SECONDARY_DISK_NAME \
       --secondary-zone SECONDARY_ZONE
   

   Ersetzen Sie Folgendes:

   • PRIMARY_DISK_NAME: der Name des Quelllaufwerks, das repliziert wird.
   • PROJECT: das GDC-Projekt des primären Laufwerks.
   • PRIMARY_ZONE: die Zone, in der sich das primäre Laufwerk befindet.
   • SECONDARY_DISK_NAME: der Name des Ziellaufwerks, auf das repliziert werden soll.
   • SECONDARY_ZONE: die Zone, in der sich das sekundäre Laufwerk befinden muss.

2. Erstellen Sie in der Zielzone eine benutzerdefinierte VolumeFailover-Ressource, die die Replikation in die Zielzone beendet, wenn die Quellzone aus irgendeinem Grund nicht verfügbar ist:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: storage.gdc.goog/v1
   kind: VolumeFailover
   metadata:
     name: FAILOVER_NAME
     namespace: PROJECT
   spec:
     volumeReplicationRelationshipRef: REPL_NAME
   EOF
   

   Ersetzen Sie Folgendes:

   • MANAGEMENT_API_SERVER: die kubeconfig-Datei für den Management API-Server.
   • FAILOVER_NAME: der Name des Failovers.
   • PROJECT: Das Projekt, in dem sich die Speicherinfrastruktur befindet.
   • REPL_NAME: der Name der Volume-Replikationsbeziehung.

   Weitere Informationen zum Verwalten der asynchronen Replikation für VM-Arbeitslasten finden Sie unter Volumes asynchron replizieren.

API

1. Erstellen Sie eine benutzerdefinierte VolumeReplicationRelationship-Ressourcendatei in YAML und stellen Sie sie auf dem globalen API-Server bereit:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: storage.global.gdc.goog/v1
   kind: VolumeReplicationRelationship
   metadata:
     name: VRR_NAME
     namespace: PROJECT
   spec:
     source:
       virtualMachineDisk:
         virtualMachineDiskRef: PRIMARY_DISK_NAME
       zoneRef: PRIMARY_ZONE
     destination:
       volumeOverrideName: SECONDARY_DISK_NAME
       zoneRef: SECONDARY_ZONE
   EOF
   

   Ersetzen Sie Folgendes:

   • GLOBAL_API_SERVER: die kubeconfig-Datei für den globalen Management-API-Server.
   • VRR_NAME: der Name der Volume-Replikationsbeziehung. Beim Beenden der asynchronen Replikation muss derselbe Name verwendet werden.
   • PROJECT: das GDC-Projekt des primären Laufwerks.
   • PRIMARY_DISK_NAME: der Name des Quelllaufwerks, das repliziert wird.
   • PRIMARY_ZONE: die Zone, in der sich das primäre Laufwerk befindet.
   • SECONDARY_DISK_NAME: der Name des Ziellaufwerks, auf das repliziert werden soll.
   • SECONDARY_ZONE: die Zone, in der sich das sekundäre Laufwerk befinden muss.

2. Erstellen Sie in der Zielzone eine benutzerdefinierte VolumeFailover-Ressource, die die Replikation in die Zielzone beendet, wenn die Quellzone aus irgendeinem Grund nicht verfügbar ist:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: storage.gdc.goog/v1
   kind: VolumeFailover
   metadata:
     name: FAILOVER_NAME
     namespace: PROJECT
   spec:
     volumeReplicationRelationshipRef: REPL_NAME
   EOF
   

   Ersetzen Sie Folgendes:

   • MANAGEMENT_API_SERVER: Die kubeconfig-Datei für den Management API-Server.
   • FAILOVER_NAME: der Name des Failovers.
   • PROJECT: Das Projekt, in dem sich die Speicherinfrastruktur befindet.
   • REPL_NAME: der Name der Volume-Replikationsbeziehung.

Weitere Informationen zum Verwalten der asynchronen Replikation für VM-Arbeitslasten finden Sie unter Volumes asynchron replizieren.