Google Distributed Cloud (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 서비스를 직접 사용하는 경우 이전에 나열된 구성요소 대신 Service 객체를 사용합니다. Service 객체가 생성된 클러스터의 워크로드만 타겟팅할 수 있습니다.
외부 및 내부 부하 분산
GDC 애플리케이션은 다음 네트워킹 서비스 유형에 액세스할 수 있습니다.
내부 부하 분산기 (ILB): 조직 내 다른 클러스터에 서비스를 노출할 수 있습니다.
외부 부하 분산기(ELB): 외부 워크로드에서 라우팅할 수 있는 범위에서 VIP 주소를 할당하고 GDC 조직 외부의 서비스(예: GDC 인스턴스 내부 또는 외부의 다른 조직)를 노출합니다.
서비스 가상 IP 주소
ILB는 조직 내부 전용 VIP 주소를 할당합니다. 이러한 VIP 주소는 조직 외부에서 연결할 수 없으므로 조직 내의 다른 애플리케이션에 서비스를 노출하는 데만 사용할 수 있습니다. 이러한 IP 주소는 동일한 인스턴스의 조직 간에 겹칠 수 있습니다.
반면 ELB는 조직 외부에서 외부적으로 연결할 수 있는 VIP 주소를 할당합니다. 따라서 ELB VIP 주소는 모든 조직에서 고유해야 합니다. 일반적으로 조직에서 사용할 수 있는 ELB VIP 주소가 더 적습니다.
[[["이해하기 쉬움","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)"],[],[],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)"]]
