[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[[["\u003cp\u003eGoogle Distributed Cloud (GDC) air-gapped uses load balancers to manage traffic to backend workloads, assigning a stable virtual IP (VIP) address to balance traffic over a set of backend workloads.\u003c/p\u003e\n"],["\u003cp\u003eLoad balancers in GDC perform layer four (L4) load balancing for workloads running on VMs or containerized within the Kubernetes cluster, mapping frontend TCP or UDP ports to backend ports.\u003c/p\u003e\n"],["\u003cp\u003eLoad balancers can be configured using the Networking Kubernetes Resource Model (KRM) API, the gdcloud CLI, or the Kubernetes Service, with the KRM API and gdcloud CLI supporting both global and zonal load balancers while the Kubernetes Service only supports zonal load balancers.\u003c/p\u003e\n"],["\u003cp\u003eGDC provides Internal Load Balancers (ILBs) for services within the organization and External Load Balancers (ELBs) for services accessible from outside the organization.\u003c/p\u003e\n"],["\u003cp\u003eKey load balancer components include forwarding rules (defining traffic routing), backend services (linking forwarding rules, health checks, and backends), backends (specifying the target endpoints), and health checks (for VM workload health monitoring).\u003c/p\u003e\n"]]],[],null,["# Manage load balancers\n\nThis overview page explains how you can configure internal and external load\nbalancers in Google Distributed Cloud (GDC) air-gapped for both zonal and global network\nconfigurations.\n\nLoad balancing for GDC ensures efficient traffic\ndistribution across backend workloads, enhancing application availability and\nperformance.\n\nThis page is for network administrators within the\nplatform administrator group, or developers within the application operator\ngroup, who are responsible for managing network traffic for their organization.\nFor more information, see [Audiences for GDC air-gapped\ndocumentation](/distributed-cloud/hosted/docs/latest/gdch/resources/audiences).\n\nLoad balancing architecture\n---------------------------\n\nGDC 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/gdch/apis/service/networking/networking-api-overview). You can use this API to create global or zonal load balancers.\n- Use the [gdcloud CLI](/distributed-cloud/hosted/docs/latest/gdch/resources/gdcloud-overview). You can use this API to create global or zonal 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 can't 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 a backend that doesn't 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 from the Kubernetes user cluster,\nyou 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. Use session affinity for ELBs to ensure that requests from a client are consistently routed to the same backend.\n\nGlobal and zonal load balancers\n-------------------------------\n\nYou can create global or zonal load balancers. The scope of global load\nbalancers span across a GDC universe. Each\nGDC universe can consist of multiple\nGDC zones organized into regions that are interconnected\nand share a control plane. For example, a universe consisting two regions with\nthree zones each might look like: `us-virginia1-a`, `us-virginia1-b`,\n`us-virginia1-c` and `eu-ams1-a`, `eu-ams1-b`, `eu-ams1-c`.\n\nThe scope of zonal load balancers is limited to the zones specified at the time\nof creation. Each zone is an independent disaster domain. A zone manages\ninfrastructure, services, APIs, and tooling that use a local control plane.\n\nFor more information on global and zonal resources in a GDC universe, see\n[Multi-zone overview](/distributed-cloud/hosted/docs/latest/gdch/resources/multi-zone/mz-overview).\n\nYou can create global load balancers using the following methods:\n\n- Use the [Networking Kubernetes Resource Model (KRM)\n API](/distributed-cloud/hosted/docs/latest/gdch/apis/service/networking/networking-api-overview). Use the API version `networking.global.gdc.goog` to create global resources.\n- Use the [gdcloud CLI](/distributed-cloud/hosted/docs/latest/gdch/resources/gdcloud-overview). Use the `--global` flag when using the gdcloud CLI commands to specify a global scope.\n\nYou can create zonal load balancers using the following methods:\n\n- Use the [Networking Kubernetes Resource Model (KRM)\n API](/distributed-cloud/hosted/docs/latest/gdch/apis/service/networking/networking-api-overview). Use the API version `networking.gdc.goog` to create zonal resources.\n- Use the [gdcloud CLI](/distributed-cloud/hosted/docs/latest/gdch/resources/gdcloud-overview). Use the `--zone` flag when using the gdcloud CLI commands to specify which zones to create load balancers for.\n- Use the Kubernetes Service directly from the Kubernetes cluster.\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 are available\nfor use by the organization.\n\nLimitations\n-----------\n\n- The `BackendService` resource must not be configured with a `HealthCheck` resource for pod workloads. Note that the `HealthCheckName` in the `BackendService` specification is optional and must be omitted when configuring a load balancer with pods.\n\n- A load balancer configuration can't target mixed workloads involving pods and VMs. Therefore, mixed backends involving pods and VMs in one `BackendService` resource is not allowed.\n\n- A global load balancer custom resource (`ForwardingRuleExternal`, `ForwardingRuleInternal`, `BackendService`, or `HealthCheck`) must not have the same name as these zonal load balancer custom resources.\n\n What's next\n -----------\n\n- [Configure internal load balancers](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/ilb-service)\n\n- [Configure external load balancers](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/elb-service)"]]
