Externe Load-Balancer konfigurieren

Externe Load-Balancer (ELB) machen Dienste für den Zugriff von außerhalb der Organisation über die IP-Adressen eines Pools verfügbar, die der Organisation aus dem größeren IP-Pool für externe Instanzen zugewiesen sind.

ELB-VIP-Adressen (Virtual IP) stehen nicht in Konflikt mit anderen Organisationen und sind organisationsübergreifend eindeutig. Aus diesem Grund dürfen Sie ELB-Dienste nur für Dienste verwenden, auf die Clients außerhalb der Organisation unbedingt zugreifen müssen.

Auf ELB-Dienste kann von Arbeitslasten zugegriffen werden, die innerhalb der Organisation ausgeführt werden, sofern Sie den Zugriff auf die Organisation für die Arbeitslasten aktivieren. Für dieses Traffic-Muster ist effektiv ausgehender Traffic von der Organisation erforderlich, bevor zum internen Dienst zurückgekehrt wird.

Hinweise

Zum Konfigurieren von ELB-Diensten benötigen Sie Folgendes:

  • Sie sind Inhaber des Projekts, für das Sie den Load-Balancer konfigurieren. Weitere Informationen finden Sie unter Projekt erstellen.
  • Eine benutzerdefinierte ProjectNetworkPolicy-Einlassrichtlinie (PNP), um Traffic zu diesem ELB-Dienst zuzulassen. Weitere Informationen finden Sie unter PNP konfigurieren, um Traffic zu ELB zuzulassen.

  • Die erforderlichen Identitäts- und Zugriffsrollen:

    • Project NetworkPolicy Admin: Hat Zugriff zum Verwalten von Projekt-NetworkPolicies im Projekt-Namespace. Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Project NetworkPolicy Admin“ (project-networkpolicy-admin) zu gewähren.
    • Administrator für Load-Balancer: Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Administrator für Load-Balancer“ (load-balancer-admin) zu gewähren.
    • Administrator für globale Load Balancer: Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Administrator für globale Load Balancer“ (global-load-balancer-admin) zuzuweisen. Weitere Informationen finden Sie unter Beschreibungen vordefinierter Rollen.

PNP konfigurieren, um Traffic zu ELB zuzulassen

Damit ELB-Dienste funktionieren, müssen Sie eine eigene benutzerdefinierte ProjectNetworkPolicy-Richtlinie für eingehenden Traffic konfigurieren und anwenden, um Traffic zu den Workloads 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 für den Arbeitslastport zuzulassen, z. B. 8080.

Geben Sie die externe CIDR-Adresse an, um Traffic zu den Arbeitslasten dieser 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 Management API-Servers. Wenn Sie noch keine kubeconfig-Datei für den API-Server in Ihrer Zielzone generiert haben, lesen Sie die 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 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[].targetPort des Manifests für die Ressource Service. Dieses Feld ist optional.

Externen Load-Balancer erstellen

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

Erstellen Sie ELBs mit drei verschiedenen Methoden in GDC:

  • Verwenden Sie die gcloud 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 gcloud CLI ausrichten. Sie können nur Arbeitslasten in dem Cluster anvisieren, in dem das Service-Objekt erstellt wird, wenn Sie den Kubernetes-Dienst direkt im Kubernetes-Cluster verwenden.

Zonale ELB erstellen

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

gdcloud

Erstellen Sie mit der gcloud CLI einen ELB, der auf Pod- oder VM-Arbeitslasten ausgerichtet ist.

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

So erstellen Sie eine ELB mit der gcloud CLI:

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

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster=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. 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.
    • 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 vorgesehen 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 \
  --zone=ZONE

    Ersetzen Sie Folgendes:

    • HEALTH_CHECK_NAME: der von Ihnen ausgewä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. Der Standardwert ist 5. Dieses Feld ist optional.
    • HEALTHY_THRESHOLD: die Zeit, die gewartet wird, 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 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 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. 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, um sicherzustellen, dass Anfragen von demselben Client immer an dasselbe Backend weitergeleitet werden. Um die Sitzungsaffinität für Load Balancer zu aktivieren, erstellen Sie eine Backend-Dienstrichtlinie mit dem gdcloud compute load-balancer-policy create-Befehl:

     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 vom selben 4‑Tupel (Quell‑IP‑Adresse, Ziel‑IP‑Adresse, Zielport und Protokoll) werden an dasselbe Backend weitergeleitet.

    • RESOURCE_LABEL: Der Label-Selektor, der auswählt, 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 ausgewählte Name für die Weiterleitungsregel.
    • CIDR: Dieses Feld ist optional. Wenn nichts angegeben ist, 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 Beispiel 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 bereitgestellte Port muss mit dem Port übereinstimmen, den die eigentliche Anwendung im Container bereitstellt.

  7. Prüfen Sie die konfigurierte ELB, indem Sie die Bedingung Ready für jedes der erstellten Objekte bestätigen. So rufen Sie die zugewiesene IP-Adresse des Load Balancers ab:

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. Prüfen Sie die konfigurierte ELB, indem Sie die Bedingung Ready 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_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- oder VM-Arbeitslasten ausgerichtet ist. Dieser 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. 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
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
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: 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 vorgesehen 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 ausgewä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 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 Prüfungen, 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. Wenn Sie einen ELB für VM-Arbeitslasten konfigurieren, fügen Sie die HealthCheck-Ressource ein.

    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, um sicherzustellen, dass Anfragen von demselben Client immer 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 BackendServicePolicy-Ressource auf die BackendService-Ressource an. Erstellen und wenden Sie die BackendServicePolicy-Ressource 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 vom selben 4‑Tupel (Quell‑IP‑Adresse, Ziel‑IP‑Adresse, Zielport und Protokoll) werden an dasselbe Backend weitergeleitet.

    • RESOURCE_LABEL: Der Label-Selektor, der auswählt, 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, in der die VIP definiert ist, 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: CIDR
  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 die ForwardingRuleExternal-Ressource.
    • CIDR: Dieses Feld ist optional. Wenn nichts angegeben ist, 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 Beispiel für benutzerdefinierte Ressourcen.
    • PORT: Mit dem Feld ports können Sie ein Array von L4-Ports angeben, für die Pakete an die Back-Ends weitergeleitet werden, die mit dieser Weiterleitungsregel konfiguriert sind. Es muss mindestens ein Port angegeben werden. Geben Sie im Feld port eine Portnummer an. 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 konfigurierte ELB, indem Sie die Bedingung Ready für jedes der erstellten Objekte bestätigen. 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 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-Dienst

Sie können ELBs in GDC erstellen, indem Sie in einem Kubernetes-Cluster ein 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: 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, das die Backend-Arbeitslasten enthält.

    Mit dem Feld port wird der Frontend-Port konfiguriert, den Sie für die VIP-Adresse bereitstellen. Mit dem Feld targetPort wird der Backend-Port konfiguriert, an den Sie den Traffic für die Backend-Arbeitslasten weiterleiten möchten. Der Load-Balancer unterstützt Network Address Translation (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 Back-End-Arbeitslasten für diesen Dienst verwendet werden sollen. Dazu werden die von Ihnen angegebenen Labels mit den Labels der Arbeitslasten abgeglichen. Die Service kann nur Back-End-Arbeitslasten im selben Projekt und im selben Cluster auswählen, 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, das die Backend-Arbeitslasten enthält.
    • ELB_SERVICE_NAME: der Name des ELB-Dienstes.

    Die Ausgabe sollte in etwa so 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 die von außerhalb der Organisation zugegriffen werden kann.

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

Globale ELB erstellen

Erstellen Sie eine globale ELB mit der gcloud CLI oder der KRM API.

gdcloud

Erstellen Sie mit der gcloud CLI einen ELB, der auf Pod- oder VM-Arbeitslasten ausgerichtet ist.

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

So erstellen Sie eine ELB mit der gcloud CLI:

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

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster=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. Wenn Sie das Zonenflag 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.

  2. Überspringen Sie diesen Schritt, wenn dieser ELB für Pod-Arbeitslasten vorgesehen 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 ausgewä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. Der Standardwert ist 5. Dieses Feld ist optional.
    • HEALTHY_THRESHOLD: die Zeit, die gewartet wird, 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 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 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. 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, um sicherzustellen, dass Anfragen von demselben Client immer an dasselbe Backend weitergeleitet werden. Um die Sitzungsaffinität für Load Balancer zu aktivieren, erstellen Sie eine Backend-Dienstrichtlinie mit dem gdcloud compute load-balancer-policy create-Befehl:

     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 vom selben 4‑Tupel (Quell‑IP‑Adresse, Ziel‑IP‑Adresse, Zielport und Protokoll) werden an dasselbe Backend weitergeleitet.

    • RESOURCE_LABEL: Der Label-Selektor, der auswählt, 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 ausgewählte Name für die Weiterleitungsregel.
    • CIDR: Dieses Feld ist optional. Wenn Sie nichts angeben, 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 Beispiel 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 bereitgestellte Port muss mit dem Port übereinstimmen, den die eigentliche Anwendung im Container bereitstellt.

  7. Prüfen Sie die konfigurierte ELB, indem Sie die Bedingung Ready für jedes der erstellten Objekte bestätigen. So rufen Sie die zugewiesene IP-Adresse des Load Balancers ab:

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. Prüfen Sie die konfigurierte ELB, indem Sie die Bedingung Ready 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_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 ausgerichtet ist. Diese ELB ist auf alle Arbeitslasten im Projekt ausgerichtet, die dem im Backend-Objekt definierten Label entsprechen. So erstellen Sie einen zonenbasierten ELB mit der KRM API:

  1. 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
  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 vorgesehen 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 ausgewä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 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 Prüfungen, 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.

  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 HealthCheck-Ressource ein.

    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 mehrere Back-Ends im Feld backendRefs angeben. Beispiel:

      - name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-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, in den der PORT-Wert ü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, um sicherzustellen, dass Anfragen von demselben Client immer 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 BackendServicePolicy-Ressource auf die BackendService-Ressource an. Erstellen und wenden Sie die BackendServicePolicy-Ressource 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 vom selben 4‑Tupel (Quell‑IP‑Adresse, Ziel‑IP‑Adresse, Zielport und Protokoll) werden an dasselbe Backend weitergeleitet.

    • RESOURCE_LABEL: Der Label-Selektor, der auswählt, 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, in der die VIP definiert ist, 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: 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: Dieses Feld ist optional. Wenn Sie nichts angeben, 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 Beispiel für benutzerdefinierte Ressourcen.
    • PORT: Mit dem Feld ports können Sie ein Array von L4-Ports angeben, für die Pakete an die Back-Ends weitergeleitet werden, die mit dieser Weiterleitungsregel konfiguriert sind. Es muss mindestens ein Port angegeben werden. Geben Sie im Feld port eine Portnummer an. 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 konfigurierte ELB, indem Sie die Bedingung Ready für jedes der erstellten Objekte bestätigen. 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 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.