Interne Load-Balancer konfigurieren

Interne Load Balancer (ILB) stellen Dienste innerhalb der Organisation über einen internen IP-Pool bereit, der der Organisation zugewiesen ist. Ein ILB-Dienst ist von keinem Endpunkt außerhalb der Organisation aus zugänglich.

Standardmäßig können Sie von jedem Cluster in der Organisation auf ILB-Dienste im selben Projekt zugreifen. Mit der standardmäßigen projektbezogenen Netzwerkrichtlinie können Sie nicht von außerhalb des Projekts auf Projektressourcen zugreifen. Diese Einschränkung gilt auch für ILB-Dienste. Wenn der Plattformadministrator (PA) projektbezogene Netzwerkrichtlinien konfiguriert, die den Zugriff auf Ihr Projekt von anderen Projekten aus ermöglichen, ist der ILB-Dienst auch von diesen anderen Projekten in derselben Organisation aus zugänglich.

Hinweis

So konfigurieren Sie ILBs:

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

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

    • Bitten Sie Ihren IAM-Admin der Organisation, Ihnen die Rolle „Load Balancer-Administrator“ (load-balancer-admin) zuzuweisen.
    • Bitten Sie für globale ILBs Ihren IAM-Admin der Organisation, Ihnen die Rolle „Global Load Balancer Admin“ (global-load-balancer-admin) zuzuweisen. Weitere Informationen finden Sie unter Vordefinierte Rollenbeschreibungen.

  • Sie müssen wissen, welcher Clustertyp Ihre Arbeitslasten hostet. Es gibt separate Anleitungen zum Einrichten von ILBs für freigegebene und Standardcluster.

Internen Load Balancer für freigegebene Cluster erstellen

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

Erstellen Sie ILBs mit drei verschiedenen Methoden in GDC:

  • Verwenden Sie die gdcloud CLI, um globale oder zonale ILBs zu erstellen.
  • Verwenden Sie die Networking Kubernetes Resource Model (KRM) API, um globale oder zonale interne Load Balancer 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 gdcloud CLI als Ziel festlegen. Wenn Sie den Kubernetes-Dienst direkt aus dem Kubernetes-Cluster verwenden, können Sie nur Arbeitslasten im Cluster als Ziel festlegen, in dem das Service-Objekt erstellt wird.

Zonalen ILB erstellen

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

gdcloud

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

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

So erstellen Sie einen ILB mit der gdcloud 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-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 ILB für Pod-Arbeitslasten bestimmt ist. Wenn Sie einen internen Load Balancer für VM-Arbeitslasten konfigurieren, definieren Sie den Typ der Systemdiagnose für den internen Load Balancer. 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 gilt. 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 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 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 internen Load Balancer 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. 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 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.

  6. Prüfen Sie die Ready-Bedingung für jedes der erstellten Objekte, um den konfigurierten ILB 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_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 einen ILB, der Pod- oder VM-Arbeitslasten mit der KRM API als Ziel hat. Dieser ILB 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 Load Balancer 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.

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

  2. Überspringen Sie diesen Schritt, wenn dieser ILB für Pod-Arbeitslasten bestimmt 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 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 internen Load Balancer 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 ILB für Pod-Arbeitslasten konfigurieren.

  4. Erstellen Sie eine interne 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: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  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_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 Backends 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

  5. Prüfen Sie die Ready-Bedingung für jedes der erstellten Objekte, um den konfigurierten ILB 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 forwardingruleinternal -n PROJECT_NAME

      Die Ausgabe sieht etwa 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-Service

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 auf Arbeitslasten im Cluster ausgerichtet, 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 internen Dienst entwerfen.

    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, 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 Definition Service 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 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-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, der die Backend-Arbeitslasten enthält.
    • ILB_SERVICE_NAME: der Name des ILB-Dienstes.

    Die Ausgabe sollte in etwa wie im folgenden Beispiel 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

    In den Feldern CLUSTER-IP und EXTERNAL-IP muss derselbe Wert angezeigt werden, d. h. die IP-Adresse des ILB-Dienstes. Diese IP-Adresse ist jetzt gemäß den projektbezogenen Netzwerkrichtlinien des Projekts von anderen Clustern in der Organisation aus zugänglich.

    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.

Globalen ILB erstellen

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

gdcloud

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

Dieser ILB 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 gdcloud 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-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 ILB für Pod-Arbeitslasten bestimmt 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 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 internen Load Balancer 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-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 gewä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 Beispiele für benutzerdefinierte Ressourcen. Wenn Sie nichts angeben, 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 freigegebene Port muss mit dem Port übereinstimmen, den die eigentliche Anwendung im Container freigibt.

  6. Prüfen Sie die Ready-Bedingung für jedes der erstellten Objekte, um den konfigurierten ILB 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_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 des Felds PROTOCOL_PORT in der Weiterleitungsregel.

API

Erstellen Sie einen ILB, der Pod- oder VM-Arbeitslasten mit der KRM API als Ziel hat. Dieser ILB 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 Load Balancer 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.global.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 für jede Zone dieselbe Backend-Ressource verwenden oder Backend-Ressourcen mit unterschiedlichen Label-Sets für jede Zone erstellen.

  2. Überspringen Sie diesen Schritt, wenn dieser ILB für Pod-Arbeitslasten bestimmt 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 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 ILB handelt, erstellen Sie die Systemdiagnose in der globalen API.

  3. Erstellen Sie ein BackendService-Objekt mit der zuvor erstellten Backend-Ressource. Wenn Sie einen internen Load Balancer 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 ILB 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. Erstellen Sie eine interne 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: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  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_NAME: 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 Beispiele für benutzerdefinierte Ressourcen. Wenn Sie nichts angeben, wird automatisch ein IPv4/32-CIDR aus dem globalen IP-Pool reserviert. Dieses Feld ist optional.
    • 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

  5. Prüfen Sie die Ready-Bedingung für jedes der erstellten Objekte, um den konfigurierten ILB 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 forwardingruleinternal -n PROJECT_NAME

      Die Ausgabe sieht etwa 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 an dem 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.

Internen Load Balancer für Standardcluster erstellen

Sie können zonale ILBs für Standardcluster erstellen. Globale ILBs werden nicht unterstützt. Der Umfang zonaler ILBs ist auf die Zone beschränkt, die bei der Erstellung angegeben wurde. Weitere Informationen finden Sie unter Globale und zonale Load Balancer.

Erstellen Sie zonale ILBs für Standardcluster, indem Sie den Kubernetes-Dienst direkt im Kubernetes-Cluster verwenden. Wenn Sie den Kubernetes-Dienst direkt aus dem Kubernetes-Cluster verwenden, können Sie nur Arbeitslasten im Cluster als Ziel festlegen, in dem das Service-Objekt erstellt wird.

Zonalen ILB für Standardcluster erstellen

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 auf Arbeitslasten im Cluster ausgerichtet, 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 internen Dienst entwerfen.

    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: ILB_SERVICE_NAMESPACE
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.
    • ILB_SERVICE_NAMESPACE: der Namespace, 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 Definition von Service die Pods an, die als Backend-Arbeitslasten dienen sollen.

    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 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 ILB_FILE. 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:

    export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ILB_FILE

    Ersetzen Sie Folgendes:

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

    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 ILB_SERVICE_NAMESPACE get svc ILB_SERVICE_NAME

    Ersetzen Sie Folgendes:

    • ILB_SERVICE_NAMESPACE: der Namespace, der die Backend-Arbeitslasten enthält.
    • ILB_SERVICE_NAME: der Name des ILB-Dienstes.
    • KUBECONFIG_PATH: der Pfad zur kubeconfig-Datei für den Standardcluster.

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

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

    Diese IP-Adresse ist jetzt gemäß den projektbezogenen Netzwerkrichtlinien des Projekts von anderen Clustern in der Organisation aus zugänglich.

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.