이 개요 페이지에서는 영역 및 전역 네트워크 구성 모두에 대해 Google Distributed Cloud (GDC) 오프라인에서 내부 및 외부 부하 분산기를 구성하는 방법을 설명합니다.
GDC의 부하 분산은 백엔드 워크로드 전반에서 효율적인 트래픽 분산을 보장하여 애플리케이션 가용성과 성능을 향상시킵니다.
이 페이지는 플랫폼 관리자 그룹의 네트워크 관리자 또는 애플리케이션 운영자 그룹의 개발자를 대상으로 합니다. 이들은 조직의 네트워크 트래픽을 관리합니다.
자세한 내용은 GDC 오프라인 환경 문서 대상을 참고하세요.
부하 분산 아키텍처
GDC는 애플리케이션이 서로에게 서비스를 노출할 수 있도록 지원하는 부하 분산기를 제공합니다. 부하 분산기는 백엔드 워크로드 집합에서 트래픽을 분산하는 안정적인 가상 IP (VIP) 주소를 할당합니다.
GDC의 부하 분산기는 레이어 4 (L4) 부하 분산을 실행합니다. 즉, 구성된 프런트엔드 TCP 또는 UDP 포트 집합을 해당 백엔드 포트에 매핑합니다. 부하 분산기는 프로젝트 수준에서 구성됩니다.
gdcloud CLI를 사용합니다.
이 API를 사용하여 전역 또는 영역 부하 분산기를 만들 수 있습니다.
Kubernetes 클러스터에서 Kubernetes 서비스를 직접 사용합니다. 이 메서드는 영역 부하 분산기만 만듭니다.
부하 분산기 구성요소
KRM API 또는 gdcloud CLI를 사용하여 부하 분산기를 구성할 때는 L4 패스스루 부하 분산기를 사용합니다.
L4는 프로토콜이 TCP 또는 UDP임을 의미합니다.
패스스루는 워크로드와 클라이언트 사이에 프록시가 없음을 의미합니다.
부하 분산기는 다음과 같은 구성 가능한 구성요소로 구성됩니다.
전달 규칙: 전달되는 트래픽과 전달되는 백엔드 서비스를 지정합니다. 전달 규칙의 사양은 다음과 같습니다.
클라이언트가 액세스할 수 있는 CIDR, 포트, 프로토콜의 세 가지 튜플로 구성됩니다.
TCP 및 UDP 프로토콜을 지원합니다.
내부 및 외부 전달 규칙을 제공합니다. 클라이언트는 Virtual Private Cloud (VPC) 내에서 내부 전달 규칙에 액세스할 수 있습니다. 클라이언트는 GDC 플랫폼 외부에서 또는 EgressNAT 값이 정의된 워크로드를 통해 내부에서 외부 전달 규칙에 액세스할 수 있습니다.
전달 규칙은 백엔드 서비스에 연결됩니다. 여러 전달 규칙이 동일한 백엔드 서비스를 가리키도록 할 수 있습니다.
백엔드 서비스: 전달 규칙, 상태 점검, 백엔드를 함께 연결하는 부하 분산 허브입니다. 백엔드 서비스는 부하 분산기가 트래픽을 전달하는 워크로드를 식별하는 백엔드 객체를 참조합니다. 단일 백엔드 서비스가 참조할 수 있는 백엔드에는 제한사항이 있습니다.
영역당 하나의 영역 백엔드 리소스
클러스터당 하나의 클러스터 백엔드 리소스입니다. 프로젝트 백엔드와 혼합할 수 없습니다.
백엔드: 생성된 백엔드 서비스의 백엔드 역할을 하는 엔드포인트를 지정하는 영역 객체입니다. 백엔드 리소스는 영역으로 범위가 지정되어야 합니다. 라벨을 사용하여 엔드포인트를 선택합니다. 선택기의 범위를 프로젝트 또는 클러스터로 지정합니다.
프로젝트 백엔드는 ClusterName 필드가 지정되지 않은 백엔드입니다. 이 경우 지정된 라벨은 영역의 특정 VPC에 있는 특정 프로젝트의 모든 워크로드에 적용됩니다. 라벨은 여러 클러스터의 VM 및 포드 워크로드에 적용됩니다. 백엔드 서비스가 프로젝트 백엔드를 사용하는 경우 해당 백엔드 서비스에서 해당 영역의 다른 백엔드를 참조할 수 없습니다.
클러스터 백엔드는 ClusterName 필드가 지정된 백엔드입니다. 이 경우 지정된 라벨은 지정된 프로젝트의 명명된 클러스터에 있는 모든 워크로드에 적용됩니다. 단일 백엔드 서비스에서 클러스터당 영역당 백엔드를 최대 하나까지 지정할 수 있습니다.
상태 점검: 백엔드의 특정 워크로드 엔드포인트가 정상인지 여부를 확인하는 프로브를 지정합니다. 비정상 엔드포인트는 다시 정상 상태가 될 때까지 부하 분산기에서 제외됩니다. 상태 확인은 VM 워크로드에만 적용됩니다. 포드 워크로드는 기본 제공 Kubernetes 프로브 메커니즘을 사용하여 특정 엔드포인트가 정상인지 확인할 수 있습니다.
Kubernetes 사용자 클러스터에서 Kubernetes 서비스를 직접 사용하는 경우 앞에서 나열된 구성요소 대신 Service 객체를 사용합니다. Service 객체가 생성된 클러스터의 워크로드만 타겟팅할 수 있습니다.
외부 및 내부 부하 분산
GDC 애플리케이션은 다음 네트워킹 서비스 유형에 액세스할 수 있습니다.
내부 부하 분산기 (ILB): 조직 내 다른 클러스터에 서비스를 노출할 수 있습니다.
외부 부하 분산기 (ELB): 외부 워크로드에서 라우팅할 수 있는 범위에서 VIP 주소를 할당하고 GDC 조직 내부 또는 외부의 다른 조직과 같은 GDC 인스턴스 외부의 서비스를 노출합니다. ELB에 세션 어피니티를 사용하여 클라이언트의 요청이 항상 동일한 백엔드로 라우팅되도록 합니다.
전역 및 영역 부하 분산기
전역 또는 영역 부하 분산기를 만들 수 있습니다. 전역 부하 분산기의 범위는 GDC 유니버스에 걸쳐 있습니다. 각 GDC 유니버스는 상호 연결되고 컨트롤 플레인을 공유하는 리전으로 구성된 여러 GDC 영역으로 구성될 수 있습니다. 예를 들어 각 영역이 3개인 두 영역으로 구성된 유니버스는 us-virginia1-a, us-virginia1-b, us-virginia1-c 및 eu-ams1-a, eu-ams1-b, eu-ams1-c와 같이 표시될 수 있습니다.
영역 부하 분산기의 범위는 생성 시 지정된 영역으로 제한됩니다. 각 영역은 독립적인 재해 도메인입니다. 영역은 로컬 컨트롤 플레인을 사용하는 인프라, 서비스, API, 도구를 관리합니다.
GDC 유니버스의 전역 및 영역 리소스에 대한 자세한 내용은 다중 영역 개요를 참고하세요.
[[["이해하기 쉬움","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)"]]
