Interne Load-Balancer konfigurieren

Interne Load-Balancer (ILB) machen Dienste innerhalb der Organisation über einen internen IP-Pool verfügbar, der der Organisation zugewiesen ist. Auf einen ILB-Dienst kann nie über einen Endpunkt außerhalb der Organisation zugegriffen werden.

Standardmäßig können Sie innerhalb desselben Projekts von jedem Cluster in der Organisation aus auf ILB-Dienste zugreifen. Mit der standardmäßigen Projektnetzwerkrichtlinie können Sie nicht von außerhalb des Projekts auf Projektressourcen zugreifen. Diese Einschränkung gilt auch für ILB-Dienste. Wenn der Plattformadministrator (Platform Administrator, PA) Projektnetzwerkrichtlinien konfiguriert, die den Zugriff auf Ihr Projekt von anderen Projekten aus zulassen, ist der ILB-Dienst auch von diesen anderen Projekten in derselben Organisation aus zugänglich.

Hinweise

Zum Konfigurieren von ILBs benötigen Sie Folgendes:

  • Sie sind Inhaber des Projekts, für das Sie den Load-Balancer konfigurieren. Weitere Informationen finden Sie unter Projekt erstellen.

  • Die erforderlichen Identitäts- und Zugriffsrollen:

    • Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Administrator für Load Balancer“ (load-balancer-admin) zuzuweisen.
    • Bitten Sie bei globalen internen Load Balancern Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Global Load Balancer Admin“ (global-load-balancer-admin) zuzuweisen. Weitere Informationen finden Sie unter Beschreibungen vordefinierter Rollen.

Internen Load-Balancer erstellen

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

Sie können ILBs in GDC auf drei verschiedene Arten erstellen:

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

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

Zonales internes Load Balancer-Gerät erstellen

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

gdcloud

Erstellen Sie mit der gcloud CLI einen ILB, der auf Pod- oder 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 ILB mit der gcloud CLI:

  1. Erstellen Sie eine Backend-Ressource, um den Endpunkt für den ILB 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 interne Lastenausgleich für Pod-Arbeitslasten vorgesehen ist. Wenn Sie einen internen Load Balancer für VM-Arbeitslasten konfigurieren, definieren Sie eine Systemdiagnose für den internen Load Balancer:

    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 ILB 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_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 ILB für VM-Arbeitslasten konfigurieren.

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

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

  5. Erstellen Sie eine interne ForwardingRule-Ressource, die die 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 \
  --zone=ZONE \
  --project=PROJECT_NAME

    Ersetzen Sie Folgendes:

    • BACKEND_SERVICE_NAME: der Name Ihres Backend-Dienstes.
    • FORWARDING_RULE_INTERNAL_NAME durch den von Ihnen ausgewählten Namen 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.

  6. Prüfen Sie die konfigurierte interne Load-Balancing-Instanz, 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_INTERNAL_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 internen Lastenausgleich, der auf Pod- oder 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 zonalen 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 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 Zum 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.

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

  2. Überspringen Sie diesen Schritt, wenn dieser interne Lastenausgleich für Pod-Arbeitslasten vorgesehen ist. Wenn Sie einen internen Load Balancer für VM-Arbeitslasten konfigurieren, definieren Sie eine Systemdiagnose für den internen Load Balancer:

    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 ILB 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 ILB für Pod-Arbeitslasten konfigurieren.

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  Name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Ersetzen Sie Folgendes:

    • FORWARDING_RULE_INTERNAL_NAME: Der ausgewählte Name für Ihre ForwardingRuleInternal-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 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 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 forwardingruleinternal -n PROJECT_NAME

      Die Ausgabe sieht so aus:

      NAME           BACKENDSERVICE                               CIDR              READY
ilb-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 ILBs in GDC erstellen, indem Sie ein Kubernetes-Service-Objekt vom Typ LoadBalancer in einem Kubernetes-Cluster erstellen. Dieser ILB ist nur für Arbeitslasten im Cluster vorgesehen, in dem das Service-Objekt erstellt wird.

So erstellen Sie einen ILB mit dem Service-Objekt:

  1. Erstellen Sie eine YAML-Datei für die Service-Definition vom Typ LoadBalancer. Sie müssen den ILB-Dienst mit der Annotation networking.gke.io/load-balancer-type: internal als intern festlegen.

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

    apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

    Ersetzen Sie Folgendes:

    • ILB_SERVICE_NAME: der Name des ILB-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. Der ILB-Dienst kann nur Arbeitslasten auswählen, die sich im selben Cluster wie die Service-Definition befinden.

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

    kubectl apply -f ILB_FILE

    Ersetzen Sie ILB_FILE durch den Namen der Service-Definitionsdatei für den ILB-Dienst.

    Wenn Sie einen ILB-Dienst erstellen, erhält der Dienst eine IP-Adresse. Sie können die IP-Adresse des ILB-Dienstes abrufen, indem Sie den Dienststatus aufrufen:

    kubectl -n PROJECT_NAME get svc ILB_SERVICE_NAME

    Ersetzen Sie Folgendes:

    • PROJECT_NAME: der Namespace Ihres Projekts, das die Backend-Arbeitslasten enthält.
    • ILB_SERVICE_NAME: der Name des ILB-Dienstes.

    Die Ausgabe sollte in etwa so aussehen:

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h

    Die Felder CLUSTER-IP und EXTERNAL-IP müssen denselben Wert enthalten, nämlich die IP-Adresse des ILB-Dienstes. Auf diese IP-Adresse kann jetzt von anderen Clustern in der Organisation aus zugegriffen werden, gemäß den Netzwerkrichtlinien des Projekts.

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

    GDC unterstützt DNS-Namen (Domain Name System) für Dienste. Diese Namen funktionieren jedoch nur im selben Cluster für ILB-Dienste. Von anderen Clustern aus müssen Sie die IP-Adresse verwenden, um auf den ILB-Dienst zuzugreifen.

Globale ILB erstellen

Erstellen Sie einen globalen ILB mit der gcloud CLI oder der KRM API.

gdcloud

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

Dieser interne Load Balancer 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 ILB mit der gcloud CLI:

  1. Erstellen Sie eine Backend-Ressource, um den Endpunkt für den ILB 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 interne Lastenausgleich für Pod-Arbeitslasten vorgesehen ist. Wenn Sie einen internen Load Balancer für VM-Arbeitslasten konfigurieren, definieren Sie eine Systemdiagnose für den internen Load Balancer:

    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 ILB für VM-Arbeitslasten konfigurieren.

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

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

  5. Erstellen Sie eine interne ForwardingRule-Ressource, die die 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_NAME \
  --global

    Ersetzen Sie Folgendes:

    • FORWARDING_RULE_INTERNAL_NAME: der von Ihnen ausgewählte Name für die Weiterleitungsregel.
    • CIDR: der Name einer Subnet-Ressource im selben Namespace wie diese Weiterleitungsregel. 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. Wenn nichts angegeben ist, wird automatisch ein IPv4/32-CIDR aus dem globalen IP-Pool reserviert. Dieses Feld ist optional.
    • 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.

  6. Prüfen Sie die konfigurierte interne Load-Balancing-Instanz, 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_INTERNAL_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 internen Lastenausgleich, der auf Pod- oder 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. So erstellen Sie einen zonalen 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 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.

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

  2. Überspringen Sie diesen Schritt, wenn dieser interne Lastenausgleich für Pod-Arbeitslasten vorgesehen ist. Wenn Sie einen internen Load Balancer für VM-Arbeitslasten konfigurieren, definieren Sie eine Systemdiagnose für den internen Load Balancer:

    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

    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 einen globalen internen Load Balancer handelt, erstellen Sie die Systemdiagnose in der globalen API.

  3. Erstellen Sie ein BackendService-Objekt mit der zuvor erstellten Backend-Ressource. Wenn Sie einen ILB 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 internen Lastenausgleich 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. Erstellen Sie eine interne ForwardingRule-Ressource, die die VIP-Adresse definiert, unter der der Dienst verfügbar ist.

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

    Ersetzen Sie Folgendes:

    • FORWARDING_RULE_INTERNAL_NAME: Der ausgewählte Name für Ihre ForwardingRuleInternal-Ressource.
    • CIDR: der Name einer Subnet-Ressource im selben Namespace wie diese Weiterleitungsregel. 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. Wenn nichts angegeben ist, wird automatisch ein IPv4/32-CIDR aus dem globalen IP-Pool reserviert. Dieses Feld ist optional.
    • 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

  5. Prüfen Sie die konfigurierte interne Load-Balancing-Instanz, 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 forwardingruleinternal -n PROJECT_NAME

      Die Ausgabe sieht so aus:

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

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