Externe Load Balancer konfigurieren

Externe Load Balancer (ELB) stellen Dienste für den Zugriff von außerhalb der Organisation über die IP-Adressen eines Pools bereit, die der Organisation aus dem größeren instanzexternen IP-Pool zugewiesen wurden.

ELB-VIP-Adressen (virtuelle IP-Adressen) stehen nicht im Konflikt zwischen Organisationen und sind für alle Organisationen eindeutig. Aus diesem Grund sollten Sie ELB-Dienste nur für Dienste verwenden, auf die Clients außerhalb der Organisation zugreifen müssen.

Arbeitslasten, die innerhalb der Organisation ausgeführt werden, können auf ELB-Dienste zugreifen, solange Sie den Arbeitslasten erlauben, die Organisation zu verlassen. Dieses Trafficmuster erfordert effektiv ausgehenden Traffic von der Organisation, bevor er zum internen Dienst zurückkehrt.

Es gibt separate Anleitungen zum Einrichten von ELBs für freigegebene und Standardcluster.

Externen Load Balancer für freigegebene Cluster erstellen

Sie können globale oder zonale ELBs erstellen. Der Bereich globaler ELBs erstreckt sich über ein GDC-Universum. Der Bereich zonaler ELBs ist auf die Zone beschränkt, die beim Erstellen angegeben wurde. Weitere Informationen finden Sie unter Globale und zonale Load Balancer.

Hinweis

So konfigurieren Sie ELB-Dienste:

  • Sie müssen Inhaber des Projekts sein, für das Sie den Load Balancer konfigurieren. Weitere Informationen finden Sie unter Projekt erstellen.
  • Sie haben eine benutzerdefinierte ProjectNetworkPolicy-Richtlinie für eingehenden Traffic (PNP), um Traffic zu diesem ELB-Dienst zuzulassen. Weitere Informationen finden Sie unter PNP so konfigurieren, dass Traffic zum ELB zugelassen wird.

  • Sie benötigen die erforderlichen Identitäts- und Zugriffsrollen:

    • Project NetworkPolicy Admin: Hat Zugriff zum Verwalten von projektbezogenen Netzwerkrichtlinien im Projekt-Namespace. Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Project NetworkPolicy Admin“ (project-networkpolicy-admin) zuzuweisen.
    • Load Balancer Admin: Bitten Sie Ihren IAM-Admin der Organisation, Ihnen die Rolle „Load Balancer Admin“ (load-balancer-admin) zuzuweisen.
    • Global Load Balancer Admin: Bitten Sie Ihren IAM-Organisationsadministrator, Ihnen für globale ELBs die Rolle „Global Load Balancer Admin“ (global-load-balancer-admin) zuzuweisen. Weitere Informationen finden Sie unter Vordefinierte Rollenbeschreibungen.

PNP so konfigurieren, dass Traffic zu ELB zugelassen wird

Damit ELB-Dienste funktionieren, müssen Sie eine eigene benutzerdefinierte ProjectNetworkPolicy-Richtlinie für eingehenden Traffic 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 stellen Arbeitslasten für Ihr Kundennetzwerk bereit. Dazu sind explizite Netzwerkrichtlinien erforderlich, um externen Traffic zum Arbeitslastport zuzulassen, z. B. 8080.

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

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.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:

  • MANAGEMENT_API_SERVER: der kubeconfig-Pfad des kubeconfig-Pfads des Management API-Servers. Wenn Sie noch keine kubeconfig-Datei für den API-Server in Ihrer Zielzone generiert haben, finden Sie weitere Informationen unter Anmelden.
  • PROJECT: der Name Ihres GDC-Projekts.
  • CIDR: der externe CIDR-Bereich, über den auf den ELB zugegriffen werden muss. Diese Richtlinie ist erforderlich, da der externe Load Balancer Direct Server Return (DSR) 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 Traffic für Traffic außerhalb der Organisation erstellen.
  • PORT: der Backend-Port auf den Pods hinter dem Load Balancer. Dieser Wert befindet sich im Feld .spec.ports[].targetPort des Manifests für die Ressource Service. Dieses Feld ist optional.

Erstellen Sie ELBs mit drei verschiedenen Methoden in GDC:

  • Verwenden Sie die gdcloud CLI, um globale oder zonale ELBs zu erstellen.
  • Verwenden Sie die Networking Kubernetes Resource Model (KRM) API, um globale oder zonale ELBs zu erstellen.
  • Verwenden Sie den Kubernetes-Dienst direkt im Kubernetes-Cluster. Diese Methode ist nur für zonale ELBs verfügbar.

Sie können Pod- oder VM-Arbeitslasten mit der KRM API und der gdcloud CLI als Ziel festlegen. Wenn Sie den Kubernetes-Dienst direkt im Kubernetes-Cluster verwenden, können Sie nur Arbeitslasten im Cluster als Ziel festlegen, in dem das Service-Objekt erstellt wird.

Zonalen ELB erstellen

Erstellen Sie einen zonalen ELB mit der gdcloud CLI, der KRM API oder dem Kubernetes-Dienst im Kubernetes-Cluster:

gdcloud

Erstellen Sie mit der gdcloud CLI einen ELB, der auf Pod- oder VM-Arbeitslasten abzielt.

Dieser ELB ist auf alle Arbeitslasten im Projekt ausgerichtet, die dem im Backend-Objekt definierten Label entsprechen.

So erstellen Sie einen ELB mit der gdcloud CLI:

  1. Erstellen Sie eine Backend-Ressource, um den Endpunkt für den ELB zu definieren:

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

    Ersetzen Sie Folgendes:

    • BACKEND_NAME: der von Ihnen gewählte Name für die Backend-Ressource, z. B. my-backend.
    • LABELS: Ein Selektor, der definiert, welche Endpunkte zwischen Pods und VMs für diese Backend-Ressource verwendet werden sollen. Beispiel: app=web.
    • PROJECT_NAME: Name Ihres Projekts
    • ZONE: die Zone, die für diesen Aufruf verwendet werden soll. Führen Sie gdcloud config set core/zone ZONE aus, um das Zonen-Flag für alle Befehle, die es erfordern, voreinzustellen. Das Zonen-Flag ist nur in Umgebungen mit mehreren Zonen verfügbar. Dieses Feld ist optional.
    • CLUSTER_NAME: der 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.

  2. Überspringen Sie diesen Schritt, wenn dieser ELB für Pod-Arbeitslasten bestimmt ist. Wenn Sie einen ELB für VM-Arbeitslasten konfigurieren, definieren Sie den Typ der Systemdiagnose für den ELB. So erstellen Sie beispielsweise eine TCP-Systemdiagnose:

    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 \
  --zone=ZONE

    Ersetzen Sie Folgendes:

    • HEALTH_CHECK_NAME: der von Ihnen gewählte Name für die Systemdiagnoseressource, z. B. my-health-check.
    • CHECK_INTERVAL: die Zeitspanne in Sekunden vom Start einer Prüfung bis zum Start der nächsten. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 5 verwendet. Es wird davon abgeraten, das Zeitlimit länger als „checkInterval“ festzulegen.
    • HEALTHY_THRESHOLD: Die Anzahl der sequenziellen Prüfungen, die bestanden werden müssen, damit der Endpunkt als fehlerfrei eingestuft wird. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 5 verwendet.
    • TIMEOUT: die Zeit in Sekunden, die gewartet werden soll, bevor ein Fehler gemeldet wird. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 5 verwendet. Es wird davon abgeraten, das Zeitlimit länger als „checkInterval“ festzulegen.
    • UNHEALTHY_THRESHOLD: Die Anzahl der sequenziellen Testdurchläufe, die fehlschlagen müssen, damit der Endpunkt als fehlerhaft eingestuft wird. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 2 verwendet.
    • PORT: der Port, auf dem die Systemdiagnose ausgeführt wird. Der Standardwert ist 80. Dieses Feld ist optional.
    • ZONE: die Zone, in der Sie diesen ELB erstellen.

  3. Erstellen Sie eine BackendService-Ressource und fügen Sie ihr die zuvor erstellte Backend-Ressource hinzu:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME

    Ersetzen Sie Folgendes:

    • BACKEND_SERVICE_NAME: der ausgewählte Name für diesen Backend-Dienst.
    • TARGET_PORT: eine durch Kommas getrennte Liste von Zielports, die dieser Backend-Dienst übersetzt, wobei jeder Zielport das Protokoll, den Port in der Weiterleitungsregel und den Port auf der Backend-Instanz angibt. 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. Geben Sie dieses Feld nur an, wenn Sie einen ELB für VM-Arbeitslasten konfigurieren.

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

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

  5. Optional: Verwenden Sie die Sitzungsaffinität für ELBs, damit Anfragen desselben Clients konsistent an dasselbe Backend weitergeleitet werden. Wenn Sie die Sitzungsaffinität für Load Balancer aktivieren möchten, erstellen Sie mit dem Befehl gdcloud compute load-balancer-policy create eine Backend-Dienstrichtlinie:

     gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL

    Ersetzen Sie Folgendes:

    • POLICY_NAME: der von Ihnen gewählte Name für die Backend-Dienstrichtlinie.

    • MODE: der Sitzungsaffinitätsmodus. Es werden zwei Modi unterstützt:

      • NONE: Die Sitzungsaffinität ist deaktiviert. Anfragen werden an ein beliebiges verfügbares Backend weitergeleitet. Das ist der Standardmodus.
      • CLIENT_IP_DST_PORT_PROTO: Anfragen mit demselben Vier-Tupel (Quell-IP-Adresse, Ziel-IP-Adresse, Zielport und Protokoll) werden an dasselbe Backend weitergeleitet.

    • RESOURCE_LABEL: die Labelauswahl, mit der ausgewählt wird, auf welchen Backend-Dienst die BackendServicePolicy-Ressource im Projekt-Namespace angewendet wird. Wenn mehrere BackendServicePolicy-Ressourcen mit demselben Backend-Dienst übereinstimmen und für mindestens eine dieser Richtlinien die Sitzungsaffinität aktiviert ist, wird die Sitzungsaffinität für diese BackendService-Ressource aktiviert.

  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 \
  --zone=ZONE \
  --project=PROJECT_NAME

    Ersetzen Sie Folgendes:

    • BACKEND_SERVICE_NAME: der Name Ihres Backend-Dienstes.
    • FORWARDING_RULE_EXTERNAL_NAME: der von Ihnen gewählte Name für die Weiterleitungsregel.
    • CIDR: Dieses Feld ist optional. Wenn keine Angabe erfolgt, wird automatisch ein IPv4/32-CIDR aus dem zonalen IP-Pool reserviert. Geben Sie den Namen einer Subnet-Ressource im selben Namespace wie diese Weiterleitungsregel an. Eine Subnet-Ressource stellt die Anfrage- und Zuweisungsinformationen eines zonalen Subnetzes dar. Weitere Informationen zu Subnet-Ressourcen finden Sie unter Beispiele für benutzerdefinierte Ressourcen.
    • 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 im Container freigibt.

  7. Prüfen Sie die Bedingung Ready für jedes der erstellten Objekte, um den konfigurierten ELB zu verifizieren. Rufen Sie die Weiterleitungsregel auf, um die zugewiesene IP-Adresse des Load Balancers zu ermitteln:

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. 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. Rufen Sie die Weiterleitungsregel auf, um die zugewiesene VIP abzurufen:

      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 des Felds PROTOCOL_PORT in der Weiterleitungsregel.

API

Erstellen Sie mit der KRM API einen ELB, der auf Pod- oder VM-Arbeitslasten abzielt. Dieser ELB ist auf alle Arbeitslasten im Projekt ausgerichtet, die dem im Backend-Objekt definierten Label entsprechen.

So erstellen Sie einen zonalen ELB mit der KRM API:

  1. Erstellen Sie eine Backend-Ressource, um die Endpunkte für den ELB zu definieren. Erstellen Sie Backend-Ressourcen für jede Zone, in der die Arbeitslasten platziert werden:

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

    Ersetzen Sie Folgendes:

    • MANAGEMENT_API_SERVER: der kubeconfig-Pfad des kubeconfig-Pfads des zonalen Management API-Servers. Weitere Informationen finden Sie unter Zu einem zonalen Kontext wechseln.
    • PROJECT_NAME: Name Ihres Projekts
    • BACKEND_NAME ist der Name der Backend-Ressource.
    • CLUSTER_NAME: Dies ist ein optionales Feld. In diesem Feld wird der Cluster angegeben, auf den der Bereich der definierten Selektoren beschränkt ist. Dieses Feld gilt nicht für VM-Arbeitslasten. Wenn eine Backend-Ressource das Feld clusterName nicht enthält, gelten die angegebenen Labels für alle Arbeitslasten im Projekt.

  2. Überspringen Sie diesen Schritt, wenn dieser ELB für Pod-Arbeitslasten bestimmt ist. Wenn Sie einen ELB für VM-Arbeitslasten konfigurieren, definieren Sie eine Systemdiagnose für den ELB:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  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 von Ihnen gewählte Name für die Systemdiagnoseressource, z. B. my-health-check.
    • PORT: der Port, auf dem die Systemdiagnose ausgeführt wird. Der Standardwert ist 80.
    • TIMEOUT: die Zeit in Sekunden, die gewartet werden soll, bevor ein Fehler gemeldet wird. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 5 verwendet. Es wird davon abgeraten, das Zeitlimit länger als „checkInterval“ festzulegen.
    • CHECK_INTERVAL: die Zeitspanne in Sekunden vom Start einer Prüfung bis zum Start der nächsten. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 5 verwendet. Es wird davon abgeraten, das Zeitlimit länger als „checkInterval“ festzulegen.
    • HEALTHY_THRESHOLD: Die Anzahl der sequenziellen Prüfungen, die bestanden werden müssen, damit der Endpunkt als fehlerfrei gilt. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 2 verwendet.
    • UNHEALTHY_THRESHOLD: Die Anzahl der sequenziellen Testdurchläufe, die fehlschlagen müssen, damit der Endpunkt als fehlerhaft eingestuft wird. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 2 verwendet.

  3. Erstellen Sie ein BackendService-Objekt mit der zuvor erstellten Backend-Ressource. Wenn Sie einen ELB für VM-Arbeitslasten konfigurieren, fügen Sie die Ressource HealthCheck hinzu.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
  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.

  4. Optional: Verwenden Sie die Sitzungsaffinität für ELBs, damit Anfragen desselben Clients konsistent an dasselbe Backend weitergeleitet werden. Wenn Sie die Sitzungsaffinität für Load Balancer aktivieren möchten, erstellen Sie eine BackendServicePolicy-Ressource. Diese Ressource definiert die Einstellungen für die Sitzungsaffinität und wendet die Ressource BackendServicePolicy auf die Ressource BackendService an. Erstellen Sie die Ressource BackendServicePolicy und wenden Sie sie an:

     kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL

    Ersetzen Sie Folgendes:

    • POLICY_NAME: der von Ihnen gewählte Name für die Backend-Dienstrichtlinie.

    • MODE: der Sitzungsaffinitätsmodus. Es werden zwei Modi unterstützt:

      • NONE: Die Sitzungsaffinität ist deaktiviert. Anfragen werden an ein beliebiges verfügbares Backend weitergeleitet. Das ist der Standardmodus.
      • CLIENT_IP_DST_PORT_PROTO: Anfragen mit demselben Vier-Tupel (Quell-IP-Adresse, Ziel-IP-Adresse, Zielport und Protokoll) werden an dasselbe Backend weitergeleitet.

    • RESOURCE_LABEL: die Labelauswahl, mit der ausgewählt wird, auf welchen Backend-Dienst die BackendServicePolicy-Ressource im Projekt-Namespace angewendet wird. Wenn mehrere BackendServicePolicy-Ressourcen mit demselben Backend-Dienst übereinstimmen und für mindestens eine dieser Richtlinien die Sitzungsaffinität aktiviert ist, wird die Sitzungsaffinität für diese BackendService-Ressource aktiviert.

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

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

    Ersetzen Sie Folgendes:

    • BACKEND_SERVICE_NAME: der Name Ihrer BackendService-Ressource.
    • FORWARDING_RULE_EXTERNAL_NAME: Der von Ihnen gewählte Name für Ihre ForwardingRuleExternal-Ressource.
    • CIDR_NAME: Das Feld cidrRef ist optional. Wenn keine Angabe erfolgt, wird automatisch ein IPv4/32-CIDR aus dem zonalen IP-Pool reserviert. Geben Sie den Namen einer Subnet-Ressource im selben Namespace wie diese Weiterleitungsregel an. Eine Subnet-Ressource stellt die Anfrage- und Zuweisungsinformationen eines zonalen Subnetzes dar. Weitere Informationen zu Subnet-Ressourcen finden Sie unter Beispiele für benutzerdefinierte Ressourcen.
    • PORT: Verwenden Sie das Feld ports, um ein Array von L4-Ports anzugeben, für die Pakete an die Back-Ends weitergeleitet werden, die mit dieser Weiterleitungsregel konfiguriert sind. Es muss mindestens ein Port angegeben werden. Verwenden Sie das Feld port, um eine Portnummer anzugeben. Der freigegebene Port muss mit dem Port übereinstimmen, den die eigentliche Anwendung im Container freigibt.

    • 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. Prüfen Sie den Traffic mit einer curl-Anfrage an die VIP:

    1. Verwenden Sie kubectl get, um die VIP abzurufen:

      kubectl get forwardingruleexternal -n PROJECT_NAME

      Die Ausgabe sieht etwa so aus:

      NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/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 durch die VIP der Weiterleitungsregel.

Kubernetes-Service

Sie können ELBs in GDC erstellen, indem Sie einen Kubernetes-Service vom Typ LoadBalancer in einem Kubernetes-Cluster erstellen.

So erstellen Sie einen ELB-Dienst:

  1. Erstellen Sie eine YAML-Datei für die Service-Definition vom Typ LoadBalancer.

    Das folgende Service-Objekt ist ein Beispiel für einen ELB-Dienst:

    apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1235
    protocol: TCP
    targetPort: 1235
  selector:
    k8s-app: my-app
  type: LoadBalancer

    Ersetzen Sie Folgendes:

    • ELB_SERVICE_NAME: der Name des ELB-Dienstes.
    • PROJECT_NAME: der Namespace Ihres Projekts, der die Backend-Arbeitslasten enthält.

    Im Feld port wird der Frontend-Port konfiguriert, den Sie über die VIP-Adresse freigeben. Im Feld targetPort wird der Backend-Port konfiguriert, an den der Traffic auf den Backend-Arbeitslasten weitergeleitet werden soll. Der Load Balancer unterstützt die Netzwerkadressübersetzung (NAT). Die Frontend- und Backend-Ports können unterschiedlich sein.

  2. Geben Sie im Feld selector der Service-Definition Pods oder virtuelle Maschinen als Backend-Arbeitslasten an.

    Der Selektor definiert, welche Arbeitslasten als Backend-Arbeitslasten für diesen Dienst verwendet werden sollen. Dazu werden die von Ihnen angegebenen Labels mit den Labels der Arbeitslasten abgeglichen. Mit der Service können nur Backend-Arbeitslasten im selben Projekt und im selben Cluster ausgewählt werden, in dem Sie die Service definieren.

    Weitere Informationen zur Dienstauswahl finden Sie unter https://kubernetes.io/docs/concepts/services-networking/service/.

  3. Speichern Sie die Service-Definitionsdatei im selben Projekt wie die Backend-Arbeitslasten.

  4. Wenden Sie die Definitionsdatei Service auf den Cluster an:

    kubectl apply -f ELB_FILE

    Ersetzen Sie ELB_FILE durch den Namen der Service-Definitionsdatei für den ELB-Dienst.

    Wenn Sie einen ELB erstellen, erhält der Dienst zwei IP-Adressen. Eine ist eine interne IP-Adresse, auf die nur innerhalb desselben Clusters zugegriffen werden kann. Die andere ist die externe IP-Adresse, auf die von innerhalb und außerhalb der Organisation zugegriffen werden kann. Sie können die IP-Adressen des ELB-Dienstes abrufen, indem Sie den Dienststatus aufrufen:

    kubectl -n PROJECT_NAME get svc ELB_SERVICE_NAME

    Ersetzen Sie Folgendes:

    • PROJECT_NAME: der Namespace Ihres Projekts, der die Backend-Arbeitslasten enthält.
    • ELB_SERVICE_NAME: der Name des ELB-Dienstes.

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      20.12.1.11      1235:31931/TCP   22h

    EXTERNAL-IP ist die IP-Adresse des Dienstes, auf den von außerhalb der Organisation zugegriffen werden kann.

    Wenn Sie keine Ausgabe erhalten, prüfen Sie, ob Sie den ELB-Dienst erfolgreich erstellt haben.

Globalen ELB erstellen

Erstellen Sie einen globalen ELB mit der gdcloud CLI oder der KRM API.

gdcloud

Erstellen Sie mit der gdcloud CLI einen ELB, der auf Pod- oder VM-Arbeitslasten abzielt.

Dieser ELB ist auf alle Arbeitslasten im Projekt ausgerichtet, die dem im Backend-Objekt definierten Label entsprechen. Die benutzerdefinierte Ressource Backend muss auf eine Zone beschränkt sein.

So erstellen Sie einen ELB mit der gdcloud CLI:

  1. Erstellen Sie eine Backend-Ressource, um den Endpunkt für den ELB zu definieren:

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

    Ersetzen Sie Folgendes:

    • BACKEND_NAME: der von Ihnen gewählte Name für die Backend-Ressource, z. B. my-backend.
    • LABELS: Ein Selektor, der definiert, welche Endpunkte zwischen Pods und VMs für diese Backend-Ressource verwendet werden sollen. Beispiel: app=web.
    • PROJECT_NAME: Name Ihres Projekts
    • CLUSTER_NAME: der 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. Führen Sie gdcloud config set core/zone ZONE aus, um das Zonen-Flag für alle Befehle voreinzustellen, für die es erforderlich ist. Das Zonen-Flag ist nur in Umgebungen mit mehreren Zonen verfügbar. Dieses Feld ist optional.

  2. Überspringen Sie diesen Schritt, wenn dieser ELB für Pod-Arbeitslasten bestimmt ist. Wenn Sie einen ELB für VM-Arbeitslasten konfigurieren, definieren Sie eine Systemdiagnose für den ELB:

    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 von Ihnen gewählte Name für die Systemdiagnoseressource, z. B. my-health-check.
    • CHECK_INTERVAL: die Zeitspanne in Sekunden vom Start einer Prüfung bis zum Start der nächsten. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 5 verwendet. Es wird davon abgeraten, das Zeitlimit länger als „checkInterval“ festzulegen.
    • HEALTHY_THRESHOLD: die Wartezeit, bevor ein Fehler gemeldet wird. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 5 verwendet.
    • TIMEOUT: die Zeit in Sekunden, die gewartet werden soll, bevor ein Fehler gemeldet wird. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 5 verwendet. Es wird davon abgeraten, das Zeitlimit länger als „checkInterval“ festzulegen.
    • UNHEALTHY_THRESHOLD: Die Anzahl der sequenziellen Testdurchläufe, die fehlschlagen müssen, damit der Endpunkt als fehlerhaft eingestuft wird. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 2 verwendet.
    • PORT: der Port, auf dem die Systemdiagnose ausgeführt wird. Der Standardwert ist 80. Dieses Feld ist optional.

  3. Erstellen Sie eine BackendService-Ressource und fügen Sie ihr die zuvor erstellte Backend-Ressource hinzu:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --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.
    • TARGET_PORTS: eine durch Kommas getrennte Liste von Zielports, die dieser Backend-Dienst übersetzt, wobei jeder Zielport das Protokoll, den Port in der Weiterleitungsregel und den Port auf der Backend-Instanz angibt. 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. Geben Sie dieses Feld nur an, wenn Sie einen ELB für VM-Arbeitslasten konfigurieren.

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

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --backend-zone BACKEND_ZONE \
  --project=PROJECT_NAME \
  --global

  5. Optional: Verwenden Sie die Sitzungsaffinität für ELBs, damit Anfragen desselben Clients konsistent an dasselbe Backend weitergeleitet werden. Wenn Sie die Sitzungsaffinität für Load Balancer aktivieren möchten, erstellen Sie mit dem Befehl gdcloud compute load-balancer-policy create eine Backend-Dienstrichtlinie:

     gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL

    Ersetzen Sie Folgendes:

    • POLICY_NAME: der von Ihnen gewählte Name für die Backend-Dienstrichtlinie.

    • MODE: der Sitzungsaffinitätsmodus. Es werden zwei Modi unterstützt:

      • NONE: Die Sitzungsaffinität ist deaktiviert. Anfragen werden an ein beliebiges verfügbares Backend weitergeleitet. Das ist der Standardmodus.
      • CLIENT_IP_DST_PORT_PROTO: Anfragen mit demselben Vier-Tupel (Quell-IP-Adresse, Ziel-IP-Adresse, Zielport und Protokoll) werden an dasselbe Backend weitergeleitet.

    • RESOURCE_LABEL: die Labelauswahl, mit der ausgewählt wird, auf welchen Backend-Dienst die BackendServicePolicy-Ressource im Projekt-Namespace angewendet wird. Wenn mehrere BackendServicePolicy-Ressourcen mit demselben Backend-Dienst übereinstimmen und für mindestens eine dieser Richtlinien die Sitzungsaffinität aktiviert ist, wird die Sitzungsaffinität für diese BackendService-Ressource aktiviert.

  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_NAME \
  --global

    Ersetzen Sie Folgendes:

    • BACKEND_SERVICE_NAME: der Name Ihres Backend-Dienstes.
    • FORWARDING_RULE_EXTERNAL_NAME: der von Ihnen gewählte Name für die Weiterleitungsregel.
    • CIDR: Dieses Feld ist optional. Wenn keine Angabe erfolgt, wird automatisch ein IPv4/32-CIDR aus dem globalen IP-Pool 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 Beispiele für benutzerdefinierte Ressourcen.
    • 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 im Container freigibt.

  7. Prüfen Sie die Bedingung Ready für jedes der erstellten Objekte, um den konfigurierten ELB zu verifizieren. Rufen Sie die Weiterleitungsregel auf, um die zugewiesene IP-Adresse des Load Balancers zu ermitteln:

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. 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. Rufen Sie die Weiterleitungsregel auf, um die zugewiesene VIP abzurufen:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME --global

    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- oder VM-Arbeitslasten abzielt. Dieser ELB ist auf alle Arbeitslasten im Projekt ausgerichtet, die dem im Backend-Objekt definierten Label entsprechen. So erstellen Sie einen zonalen ELB mit der KRM API:

  1. Erstellen Sie eine Backend-Ressource, um die Endpunkte für den ELB zu definieren. Erstellen Sie Backend-Ressourcen für jede Zone, in der die Arbeitslasten platziert werden:

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

    Ersetzen Sie Folgendes:

    • MANAGEMENT_API_SERVER: der kubeconfig-Pfad des globalen Management API-Servers. Weitere Informationen finden Sie unter Zum globalen Kontext wechseln.
    • PROJECT_NAME: Name Ihres Projekts
    • BACKEND_NAME ist der Name der Backend-Ressource.
    • CLUSTER_NAME: Dies ist ein optionales Feld. In diesem Feld wird der Cluster angegeben, auf den der Bereich der definierten Selektoren beschränkt ist. Dieses Feld gilt nicht für VM-Arbeitslasten. Wenn eine Backend-Ressource das Feld clusterName nicht enthält, gelten die angegebenen Labels für alle Arbeitslasten im Projekt.

  2. Überspringen Sie diesen Schritt, wenn dieser ELB für Pod-Arbeitslasten bestimmt ist. Wenn Sie einen ELB für VM-Arbeitslasten konfigurieren, definieren Sie eine Systemdiagnose für den ELB:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  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 von Ihnen gewählte Name für die Systemdiagnoseressource, z. B. my-health-check.
    • PORT: der Port, auf dem die Systemdiagnose ausgeführt wird. Der Standardwert ist 80.
    • TIMEOUT: die Zeit in Sekunden, die gewartet werden soll, bevor ein Fehler gemeldet wird. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 5 verwendet. Es wird davon abgeraten, das Zeitlimit länger als „checkInterval“ festzulegen.
    • CHECK_INTERVAL: die Zeitspanne in Sekunden vom Start einer Prüfung bis zum Start der nächsten. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 5 verwendet. Es wird davon abgeraten, das Zeitlimit länger als „checkInterval“ festzulegen.
    • HEALTHY_THRESHOLD: Die Anzahl der sequenziellen Prüfungen, die bestanden werden müssen, damit der Endpunkt als fehlerfrei gilt. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 2 verwendet.
    • UNHEALTHY_THRESHOLD: Die Anzahl der sequenziellen Testdurchläufe, die fehlschlagen müssen, damit der Endpunkt als fehlerhaft eingestuft wird. Wenn keine Angabe gemacht wird oder der Wert auf 0 gesetzt ist, wird der Standardwert 2 verwendet.

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

  3. Erstellen Sie ein BackendService-Objekt mit der zuvor erstellten Backend-Ressource. Wenn Sie einen ELB für VM-Arbeitslasten konfigurieren, fügen Sie die Ressource HealthCheck hinzu.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  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:

    • 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 die Backend-Ressource erstellt wird. Sie können im Feld backendRefs mehrere Back-Ends angeben. Beispiel:

      - name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B

    • Das Feld targetPorts ist optional. Diese Ressource listet Ports auf, 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. Es werden nur TCP und UDP unterstützt.

      • TARGET_PORT: der Port, in den der Wert PORT übersetzt wird, z. B. 8080. Der Wert von TARGET_PORT 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. Optional: Verwenden Sie die Sitzungsaffinität für ELBs, damit Anfragen desselben Clients konsistent an dasselbe Backend weitergeleitet werden. Wenn Sie die Sitzungsaffinität für Load Balancer aktivieren möchten, erstellen Sie eine BackendServicePolicy-Ressource. Diese Ressource definiert die Einstellungen für die Sitzungsaffinität und wendet die Ressource BackendServicePolicy auf die Ressource BackendService an. Erstellen Sie die Ressource BackendServicePolicy und wenden Sie sie an:

     kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL

    Ersetzen Sie Folgendes:

    • POLICY_NAME: der von Ihnen gewählte Name für die Backend-Dienstrichtlinie.

    • MODE: der Sitzungsaffinitätsmodus. Es werden zwei Modi unterstützt:

      • NONE: Die Sitzungsaffinität ist deaktiviert. Anfragen werden an ein beliebiges verfügbares Backend weitergeleitet. Das ist der Standardmodus.
      • CLIENT_IP_DST_PORT_PROTO: Anfragen mit demselben Vier-Tupel (Quell-IP-Adresse, Ziel-IP-Adresse, Zielport und Protokoll) werden an dasselbe Backend weitergeleitet.

    • RESOURCE_LABEL: die Labelauswahl, mit der ausgewählt wird, auf welchen Backend-Dienst die BackendServicePolicy-Ressource im Projekt-Namespace angewendet wird. Wenn mehrere BackendServicePolicy-Ressourcen mit demselben Backend-Dienst übereinstimmen und für mindestens eine dieser Richtlinien die Sitzungsaffinität aktiviert ist, wird die Sitzungsaffinität für diese BackendService-Ressource aktiviert.

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  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_NAME: Das Feld cidrRef ist optional. Wenn keine Angabe erfolgt, wird automatisch ein IPv4/32-CIDR aus dem globalen IP-Pool 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 Beispiele für benutzerdefinierte Ressourcen.
    • PORT: Verwenden Sie das Feld ports, um ein Array von L4-Ports anzugeben, für die Pakete an die Back-Ends weitergeleitet werden, die mit dieser Weiterleitungsregel konfiguriert sind. Es muss mindestens ein Port angegeben werden. Verwenden Sie das Feld port, um eine Portnummer anzugeben. Der freigegebene Port muss mit dem Port übereinstimmen, den die eigentliche Anwendung im Container freigibt.

    • 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. Prüfen Sie den Traffic mit einer curl-Anfrage an die VIP:

    1. Verwenden Sie kubectl get, um die VIP abzurufen:

      kubectl get forwardingruleexternal -n PROJECT_NAME

      Die Ausgabe sieht etwa so aus:

      NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/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 durch die VIP der Weiterleitungsregel.

Externen Load Balancer für Standardcluster erstellen

Ein Anwendungsinhaber (AO) kann einen Kubernetes-Dienst vom Typ „LoadBalancer“ erstellen, um Dienste extern bereitzustellen. Dieser Dienst kann nur die Backends im Standardcluster auswählen, in dem der Dienst erstellt wird. Dies entspricht einem zonalen ELB mit Clusterbereich. Globaler ELB wird für Standardcluster nicht unterstützt. Weitere Informationen finden Sie unter Globale und zonale Load Balancer.

Hinweis

So konfigurieren Sie ELB-Dienste:

  • Sie müssen Inhaber des Projekts sein, für das Sie den Load Balancer konfigurieren. Weitere Informationen finden Sie unter Projekt erstellen.
  • Sie haben eine benutzerdefinierte ProjectNetworkPolicy-Richtlinie für eingehenden Traffic (PNP), um Traffic zu diesem ELB-Dienst zuzulassen. Weitere Informationen finden Sie unter PNP so konfigurieren, dass Traffic zu ELB für Standardcluster zugelassen wird.

  • Sie benötigen die erforderlichen Identitäts- und Zugriffsrollen:

    • Project NetworkPolicy Admin: Hat Zugriff zum Verwalten von projektbezogenen Netzwerkrichtlinien im Projekt-Namespace. Bitten Sie Ihren IAM-Admin der Organisation, Ihnen die Rolle „Project NetworkPolicy Admin“ (project-networkpolicy-admin) zuzuweisen.
    • Load Balancer Admin: Bitten Sie Ihren IAM-Admin der Organisation, Ihnen die Rolle „Load Balancer Admin“ (load-balancer-admin) zuzuweisen.

PNP so konfigurieren, dass Traffic zu ELB für Standardcluster zugelassen wird

Damit ELB-Dienste funktionieren, müssen Sie eine eigene benutzerdefinierte ProjectNetworkPolicy-Richtlinie für eingehenden Traffic 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 stellen Arbeitslasten für Ihr Kundennetzwerk bereit. Dazu sind explizite Netzwerkrichtlinien erforderlich, um externen Traffic zum Arbeitslastport zuzulassen, z. B. 8080.

Die folgende YAML-Beispieldatei für eine projektbezogene Netzwerkrichtlinie ermöglicht es Traffic von einer Arbeitslast in einem anderen Projekt, über den ELB auf eine Arbeitslast im aktuellen Projekt zuzugreifen.

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-from-client-to-server
  namespace: ${VANILLA_CLUSTER_PROJECT}
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: my-sc-1
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: my-app-ns
        workloads:
          matchLabels:
            app: my-internal-app
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - "$PROJECT_2"
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: my-client
    ports:
    - protocol: TCP
      port: 8080

Zonalen ELB für Standardcluster erstellen

Sie können ELBs in GDC erstellen, indem Sie im Standard-Kubernetes-Cluster einen Kubernetes-Service vom Typ LoadBalancer erstellen.

So erstellen Sie einen ELB-Dienst:

  1. Erstellen Sie eine YAML-Datei für die Service-Definition vom Typ LoadBalancer.

    Das folgende Service-Objekt ist ein Beispiel für einen ELB-Dienst:

    apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: ELB_SERVICE_NAMESPACE
spec:
  ports:
  - port: PORT
    protocol: TCP
    targetPort: TARGET_PORT
  selector:
    k8s-app: my-app # Example selector, replace with your workload's labels
  type: LoadBalancer

    Ersetzen Sie Folgendes:

    • ELB_SERVICE_NAME: der Name des ELB-Dienstes.
    • ELB_SERVICE_NAMESPACE: Der Namespace in Ihrem Standardcluster, der die Backend-Arbeitslasten enthält.
    • PORT: der Port, der vom Kubernetes-Dienst selbst bereitgestellt wird. Andere Dienste oder externe Clients im Cluster stellen eine Verbindung zu diesem Port über die IP-Adresse des Dienstes her.
    • TARGET_PORT: der Port im Container Ihres Pods, auf dem Ihre Anwendung aktiv ausgeführt wird und auf eingehende Verbindungen wartet. Dies kann ein numerischer Port oder ein benannter Port sein, der in der Containerspezifikation des Pods definiert ist.

    Im Feld port wird der Frontend-Port konfiguriert, den Sie über die VIP-Adresse freigeben. Im Feld targetPort wird der Backend-Port konfiguriert, an den der Traffic auf den Backend-Arbeitslasten weitergeleitet werden soll. Der Load Balancer unterstützt die Netzwerkadressübersetzung (NAT). Die Frontend- und Backend-Ports können unterschiedlich sein.

  2. Geben Sie im Feld selector der Definition Service Schlüssel/Wert-Paare an, die den Backend-Arbeitslasten entsprechen. Für Standardcluster werden nur Pods als Arbeitslasten unterstützt.

    Der Selektor, den Sie definieren, basiert auf der Übereinstimmung der von Ihnen angegebenen Labels mit Labels für die Arbeitslasten. Mit dem Service können nur Backend-Arbeitslasten im selben Projekt und im selben Cluster ausgewählt werden, in dem Sie den Service definieren.

    Weitere Informationen zur Dienstauswahl finden Sie unter https://kubernetes.io/docs/concepts/services-networking/service/.

  3. Speichern Sie die Service-Spezifikation in einer YAML-Datei. Ersetzen Sie im folgenden Befehl den Dateinamen durch ELB_FILE.

  4. Wenden Sie die Definitionsdatei Service auf den Cluster an:

    export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ELB_FILE

    Ersetzen Sie Folgendes:

    • ELB_FILE:der Name der Service-Definitionsdatei für den ELB-Dienst.
    • KUBECONFIG_PATH: der Pfad zur kubeconfig-Datei für den Standardcluster.

    Sie können die IP-Adressen des ELB-Dienstes abrufen, indem Sie den Dienststatus aufrufen:

    kubectl -n ELB_SERVICE_NAMESPACE get svc ELB_SERVICE_NAME

    Ersetzen Sie Folgendes:

    • ELB_SERVICE_NAMESPACE: der Namespace, der die Backend-Arbeitslasten enthält.
    • ELB_SERVICE_NAME: der Name des ELB-Dienstes.

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      203.0.1.11      1235:31931/TCP   22h

    EXTERNAL-IP ist die IP-Adresse des Dienstes, auf den von außerhalb der Organisation zugegriffen werden kann.

VM als Backend für einen Load Balancer auswählen

So verknüpfen Sie eine VM mit dem Load Balancer:

  1. Achten Sie darauf, dass die VM ein Label hat, das mit dem Labelselektor in der Load-Balancer-Konfiguration übereinstimmt.

    Wenn Ihre VM beispielsweise kein geeignetes Label hat, können Sie das angegebene Label aus dem Backend-Objekt der entsprechenden Zone zur VM hinzufügen:

    kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL

    Ersetzen Sie Folgendes:

    • LABEL: ein Label, das mit dem LabelSelector in der Load-Balancer-Konfiguration übereinstimmt, z. B. app=server.
    • VM_NAME: der Name der VM, die verknüpft wird.
    • PROJECT_NAME: Name Ihres Projekts

  2. Achten Sie darauf, dass der Server auf demselben Port wie im HealthCheck-Objekt angegeben überwacht wird.