Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Die Google Distributed Cloud (GDC) Air-gapped-Appliance bietet Load Balancer, mit denen Anwendungen Dienste füreinander verfügbar machen können. Load-Balancer weisen eine stabile virtuelle IP-Adresse (VIP) zu, die den Traffic auf eine Reihe von Backend-Arbeitslasten verteilt.
Load-Balancer in GDC führen Load-Balancing auf Ebene 4 (L4) durch. Das bedeutet, dass sie eine Reihe von konfigurierten TCP- oder UDP-Frontend-Ports den entsprechenden Backend-Ports zuordnen. Load Balancer werden auf Projektebene konfiguriert.
Load-Balancer werden für die folgenden Arbeitslasttypen konfiguriert:
Arbeitslasten, die auf VMs ausgeführt werden.
Containerisierte Arbeitslasten im Kubernetes-Cluster.
Es gibt drei Möglichkeiten, Load Balancer in GDC zu konfigurieren:
Verwenden Sie die gcloud CLI.
Mit dieser API können Sie Load Balancer erstellen.
Verwenden Sie den Kubernetes-Dienst direkt über den Kubernetes-Cluster. Mit dieser Methode werden nur zonale Load-Balancer erstellt.
Komponenten des Lastenausgleichsmoduls
Wenn Sie die KRM API oder die gcloud CLI verwenden, um den Load-Balancer zu konfigurieren, verwenden Sie einen L4-Passthrough-Load-Balancer:
L4 bedeutet, dass das Protokoll entweder TCP oder UDP ist.
„Passthrough“ bedeutet, dass es keinen Proxy zwischen Arbeitslast und Client gibt.
Der Load-Balancer besteht aus den folgenden konfigurierbaren Komponenten:
Weiterleitungsregeln: Geben an, welcher Traffic weitergeleitet wird und an welchen Backend-Dienst. Für Weiterleitungsregeln gelten die folgenden Spezifikationen:
Besteht aus drei Tupeln: CIDR, Port und Protokoll für den Clientzugriff.
Unterstützt TCP- und UDP-Protokolle.
Bietet interne und externe Weiterleitungsregeln. Clients können innerhalb der Virtual Private Cloud (VPC) auf interne Weiterleitungsregeln zugreifen. Clients können von außerhalb der GDC-Plattform oder von Arbeitslasten mit dem definierten Wert EgressNAT auf externe Weiterleitungsregeln zugreifen.
Weiterleitungsregeln stellen eine Verbindung zu einem Backend-Dienst her. Sie können mehrere Weiterleitungsregeln auf denselben Back-End-Dienst verweisen lassen.
Backend-Dienste: Sie sind der Load-Balancing-Hub, der Weiterleitungsregeln, Systemdiagnosen und Backends miteinander verknüpft. Ein Back-End-Dienst verweist auf ein Back-End-Objekt, das die Arbeitslasten identifiziert, an die der Load-Balancer den Traffic weiterleitet. Es gibt Einschränkungen, auf welche Back-Ends ein einzelner Back-End-Dienst verweisen kann:
Eine zonale Backend-Ressource pro Zone.
Eine Cluster-Backend-Ressource pro Cluster. Dies kann nicht mit den Projekt-Backends kombiniert werden.
Back-Ends: Ein zonales Objekt, das die Endpunkte angibt, die als Back-Ends für die erstellten Back-End-Dienste dienen. Back-End-Ressourcen müssen auf eine Zone beschränkt sein. Endpunkte mithilfe von Labels auswählen Wählen Sie ein Projekt oder einen Cluster für den Selektor aus:
Ein Projekt-Backend ist ein Backend, für das das Feld ClusterName nicht angegeben ist. In diesem Fall gelten die angegebenen Labels für alle Arbeitslasten im angegebenen Projekt, in der angegebenen VPC einer Zone. Die Labels werden auf VM- und Pod-Arbeitslasten in mehreren Clustern angewendet. Wenn ein Backend-Dienst ein Projekt-Backend verwendet, können Sie in diesem Backend-Dienst nicht auf ein anderes Backend für diese Zone verweisen.
Ein Cluster-Back-End ist ein Back-End, für das das Feld ClusterName angegeben ist. In diesem Fall gelten die angegebenen Labels für alle Arbeitslasten im benannten Cluster im angegebenen Projekt. Sie können in einem einzelnen Back-End-Dienst maximal ein Back-End pro Zone und Cluster angeben.
Systemdiagnosen: Geben Sie die Prüfungen an, mit denen ermittelt wird, ob ein bestimmter Arbeitslastendpunkt im Back-End fehlerfrei ist. Der fehlerhafte Endpunkt wird aus dem Load-Balancer entfernt, bis er wieder fehlerfrei ist. Systemdiagnosen gelten nur für VM-Arbeitslasten. Pod-Arbeitslasten können den integrierten Kubernetes-Probe-Mechanismus verwenden, um festzustellen, ob ein bestimmter Endpunkt fehlerfrei ist.
Wenn Sie den Kubernetes-Dienst direkt verwenden, nutzen Sie das Service-Objekt anstelle der zuvor aufgeführten Komponenten. Sie können nur Arbeitslasten in dem Cluster als Ziel festlegen, in dem das Service-Objekt erstellt wird.
Externes und internes Load-Balancing
GDC-Anwendungen haben Zugriff auf die folgenden Netzwerkdiensttypen:
Interner Load Balancer (ILB): Damit können Sie einen Dienst für andere Cluster in der Organisation verfügbar machen.
Externer Load Balancer (ELB): Weist eine virtuelle IP-Adresse aus einem Bereich zu, der von externen Arbeitslasten aus weitergeleitet werden kann, und stellt Dienste außerhalb der GDC-Organisation bereit, z. B. andere Organisationen innerhalb oder außerhalb der GDC-Instanz.
Virtuelle IP-Adressen des Dienstes
Bei ILBs werden VIP-Adressen zugewiesen, die nur intern für die Organisation sind. Diese VIP-Adressen sind von außerhalb der Organisation nicht erreichbar. Sie können sie daher nur verwenden, um Dienste für andere Anwendungen innerhalb einer Organisation verfügbar zu machen. Diese IP-Adressen können sich zwischen Organisationen in derselben Instanz überschneiden.
ELBs weisen hingegen VIP-Adressen zu, die von außerhalb der Organisation extern erreichbar sind. Aus diesem Grund müssen ELB-VIP-Adressen für alle Organisationen eindeutig sein. In der Regel stehen der Organisation weniger ELB-VIP-Adressen zur Verfügung.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[],[],null,["# Manage load balancers\n\nGoogle Distributed Cloud (GDC) air-gapped appliance provides load balancers that enable\napplications to expose services to one another. Load balancers allocate a stable\nvirtual IP (VIP) address that balances traffic over a set of backend workloads.\nLoad balancers in GDC perform layer four (L4) load balancing, which means they\nmap a set of configured frontend TCP or UDP ports to corresponding backend\nports. Load balancers are configured at the project level.\n\nLoad balancers are configured for the following workload types:\n\n- Workloads running on VMs.\n- Containerized workloads inside the Kubernetes cluster.\n\nThere are three ways to configure load balancers in\nGDC:\n\n- Use the [Networking Kubernetes Resource Model (KRM)\n API](/distributed-cloud/hosted/docs/latest/appliance/apis/service/networking/networking-api-overview). You can use this API to create load balancers.\n- Use the [gdcloud CLI](/distributed-cloud/hosted/docs/latest/appliance/resources/gdcloud-overview). You can use this API to create load balancers.\n- Use the Kubernetes Service directly from the Kubernetes cluster. This method only creates zonal load balancers.\n\nLoad balancer components\n------------------------\n\nWhen you use the KRM API or gdcloud CLI to configure the load\nbalancer, you use an L4 passthrough load balancer:\n\n- L4 means the protocol is either TCP or UDP.\n- Passthrough means there is no proxy between workload and client.\n\nThe load balancer consists of the following configurable components:\n\n- **Forwarding rules**: specify what traffic is forwarded, and to which\n backend service. Forwarding rules have the following specifications:\n\n - Consists of three tuples, CIDR, port and protocol, for the client to access.\n - Supports TCP and UDP protocols.\n - Offers internal and external forwarding rules. Clients can access internal forwarding rules from within the Virtual Private Cloud (VPC). Clients can access external forwarding rules from outside the GDC platform or from within by workloads that have `EgressNAT` value defined.\n - Forwarding rules connect to a backend service. You can point multiple forwarding rules to point to the same backend service.\n- **Backend services**: are the load balancing hub that link forwarding rules,\n health checks and backends together. A backend service references a backend\n object, that identifies the workloads the load balancer forwards the traffic\n to. There are limitations on what backends a single backend service can\n reference:\n\n - One zonal backend resource per zone.\n - One cluster backend resource per cluster. This cannot be mixed with the project backends.\n- **Backends**: a zonal object that specifies the endpoints that serve as the backends for the created backend services. Backend resources must be scoped to a zone. Select endpoints using labels. Scope the selector to a project or cluster:\n\n - A project backend is is a backend that does not have the `ClusterName` field specified. In this case the specified labels apply to all of the workloads in the specific project, in the specific VPC of a zone. The labels are applied to VM and pod workloads across multiple clusters. When a backend service uses a project backend, you can't reference another backend for that zone in that backend service.\n\n - A cluster backend is a backend that has the `ClusterName` field specified. In this case, the specified labels apply to all the workloads in the named cluster in the specified project. You can specify, at most, one backend per zone per cluster in a single backend service.\n\n- **Health checks**: specify the probes to determine whether a given\n workload endpoint in the backend is healthy. The unhealthy endpoint is\n taken out from the load balancer, until it becomes healthy again. Health\n checks are only applicable to VM workloads. Pod workloads can use the built-in Kubernetes probe mechanism to determine if a specific endpoint is healthy.\n\nWhen using the Kubernetes Service directly, you use the `Service` object instead of the previously listed components. You can only target workloads in the cluster where the `Service` object is created.\n\nExternal and internal load balancing\n------------------------------------\n\nGDC applications have access to the following\nnetworking service types:\n\n- **Internal Load Balancer (ILB)**: lets you expose a service to other clusters within the organization.\n- **External Load Balancer (ELB)**: allocates a VIP address from a range that is routable from external workloads and exposes services outside of the GDC organization, such as other organizations inside or outside of the GDC instance.\n\nService virtual IP addresses\n----------------------------\n\nILBs allocate VIP addresses that are internal only to the organization. These\nVIP addresses are not reachable from outside the organization; therefore, you\ncan only use them to expose services to other applications within an\norganization. These IP addresses may overlap between organizations in the same\ninstance.\n\nOn the other hand, ELBs allocate VIP addresses that are externally reachable\nfrom outside the organization. For this reason, ELB VIP addresses must be unique\namong all organizations. Typically, fewer ELB VIP addresses will be available\nfor use by the organization.\n\nWhat's next\n-----------\n\n- [Configure internal load balancers](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/ilb-service)\n- [Configure external load balancers](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/elb-service)"]]
