이 페이지에서는 Kubernetes LoadBalancer 서비스 매니페스트를 적용할 때 Google Kubernetes Engine(GKE)에서 Google Cloud 부하 분산기를 만들고 관리하는 방법을 간략하게 설명합니다. 다양한 유형의 부하 분산기와 externalTrafficPolicy 및 L4 내부 부하 분산기용 GKE 하위 설정 같은 설정에 따라 부하 분산기의 구성 방법이 결정되는 방식을 설명합니다.
이 페이지를 읽기 전에 GKE 네트워킹 개념을 숙지해야 합니다.
개요
LoadBalancer 서비스를 만들 때 GKE는 특성이 서비스 매니페스트의 매개변수에 따라 달라지는 Google Cloud 패스스루 부하 분산기를 구성합니다.
LoadBalancer 서비스 선택
사용할 LoadBalancer 서비스 구성을 선택할 때는 다음 특성을 고려하세요.
- LoadBalancer의 IP 주소 유형. 부하 분산기는 내부 또는 외부 IP 주소를 가질 수 있습니다.
- LoadBalancer가 지원하는 노드 수 및 유형
네트워크 아키텍처 요구사항을 결정한 후 다음 결정 트리를 사용하여 네트워크 구성에 대해 선택할 LoadBalancer 서비스를 결정합니다.
외부 부하 분산과 내부 부하 분산 비교
GKE에서 LoadBalancer 서비스를 만들 때 부하 분산기에 내부 또는 외부 주소가 포함되는지 지정합니다.
클라이언트가 동일한 VPC 네트워크 또는 클러스터에 연결된 네트워크(VPC 네트워크)에 있으면 내부 LoadBalancer 서비스를 사용합니다. 내부 LoadBalancer 서비스는 내부 패스 스루 네트워크 부하 분산기를 사용하여 구현됩니다. 동일한 VPC 네트워크 또는 클러스터의 VPC 네트워크에 연결된 네트워크에 위치한 클라이언트는 부하 분산기의 IP 주소를 사용하여 이 서비스에 액세스할 수 있습니다.
내부 LoadBalancer 서비스를 만들려면 서비스 매니페스트의
metadata.annotations[]에 다음 주석 중 하나를 포함합니다.networking.gke.io/load-balancer-type: "Internal"(GKE 1.17 이상)cloud.google.com/load-balancer-type: "Internal"(1.17 이전 버전)
클라이언트가 VPC 네트워크 외부에 있으면 외부 LoadBalancer 서비스를 사용합니다. 인터넷에서 액세스할 수 있는 다음 유형의 외부 패스 스루 네트워크 부하 분산기 중 하나를 사용할 수 있습니다(내부 액세스 권한이 있는 Google Cloud VM 포함).
- (권장) 매니페스트의
metadata.annotations[]에 다음을 포함하여 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기를 만듭니다.cloud.google.com/l4-rbs: "enabled"
- (권장) 매니페스트의
cloud.google.com/l4-rbs: "enabled"주석을 생략하여 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기를 만듭니다.
externalTrafficPolicy의 효과
externalTrafficPolicy를 Local 또는 Cluster로 설정하여 준비 또는 제공 상태의 포드가 있는 노드에 패킷이 라우팅되는 방법을 정의할 수 있습니다. externalTrafficPolicy를 정의할 때 다음 시나리오를 고려하세요.
원래 클라이언트 IP 주소를 보존하거나 클러스터에 제공 중인 포드 없이 노드 수가 변경될 때 중단을 최소화하려는 경우
externalTrafficPolicy: Local을 사용합니다.클러스터에 제공 상태의 포드 없이 전체 노드 수가 일정하게 유지되지만 제공 상태의 포드가 있는 노드 수가 변경될 경우
externalTrafficPolicy: Cluster를 사용합니다. 이 옵션은 원래 클라이언트 IP 주소를 보존하지 않습니다.
externalTrafficPolicy가 노드 내에서 패킷 라우팅에 미치는 영향에 대한 자세한 내용은 패킷 처리를 참조하세요.
GKE 하위 설정
L4 내부 부하 분산기용 GKE 하위 설정 클러스터 전체 구성 옵션 또는 GKE 하위 설정은 부하 분산기 백엔드의 노드 엔드포인트를 더 효율적으로 그룹화하여 내부 패스 스루 네트워크 부하 분산기의 확장성을 개선합니다.
다음 다이어그램은 노드 3개가 있고 GKE 하위 설정이 사용 설정된 영역 클러스터의 서비스 2개를 보여줍니다. 서비스마다 2개의 포드가 있습니다.
GKE는 서비스마다 하나의 GCE_VM_IP 네트워크 엔드포인트 그룹(NEG)을 만듭니다. 각 NEG의 엔드포인트는 각 서비스의 제공 포드를 포함하는 노드입니다.
클러스터를 만들거나 기존 클러스터를 수정하여 GKE 하위 설정을 사용할 수 있습니다. 사용 설정되면 GKE 하위 집합을 사용 중지할 수 없습니다. 자세한 내용은 GKE 하위 설정을 참조하세요.
GKE 하위 집합을 사용하려면 다음이 필요합니다.
- GKE 버전 1.18.19-gke.1400 이상.
- 클러스터에 사용 설정된
HttpLoadBalancing부가기능. 이 부가기능은 기본적으로 사용 설정되어 있습니다. 클러스터에서 백엔드 서비스를 사용하는 부하 분산기를 관리할 수 있습니다.
GKE 하위 설정을 사용 설정할 때 노드 수 고려사항
권장사항에 따라 내부 LoadBalancer 서비스를 만들어야 할 경우 GKE 하위 설정을 사용 설정해야 합니다. GKE 하위 설정을 사용하면 클러스터에서 더 많은 노드를 지원할 수 있습니다.
클러스터에 GKE 하위 설정이 사용 중지되어 있으면 모든 노드 풀에서 총 노드를 250개 넘게 만들지 않아야 합니다. 클러스터에서 총 노드를 250개 넘게 만들면 내부 LoadBalancer 서비스에서 트래픽 분산이 고르지 않거나 연결이 완전히 손실될 수 있습니다.
클러스터에 GKE 하위 설정이 사용 설정되어 있으면 제공 상태의 포드가 하나 이상 있는 고유 노드의 개수가 250개를 초과하지 않는 한
externalTrafficPolicy: Local또는externalTrafficPolicy: Cluster를 사용할 수 있습니다. 제공 상태의 포드가 없는 노드는 관련이 없습니다. 제공 상태의 포드가 하나 이상 있는 노드가 250개를 초과하면externalTrafficPolicy: Cluster를 사용해야 합니다.
GKE에서 생성된 내부 패스 네트워크 스루 부하 분산기는 250개 이하의 백엔드 노드 VM에만 패킷을 분산할 수 있습니다. 이러한 제한은 부하 분산기 백엔드 하위 설정이 사용 중지된 경우 GKE에 부하 분산기 백엔드 하위 설정이 사용되지 않고 내부 패스 스루 네트워크 부하 분산기가 250개 미만 백엔드로 패킷을 분산하도록 제한되기 때문입니다.
노드 그룹화
서비스 매니페스트 주석 및 내부 LoadBalancer 서비스의 경우 GKE 하위 설정의 상태에 따라 결과적으로 발생하는 Google Cloud 부하 분산기와 백엔드 유형이 결정됩니다. Google Cloud 패스스루 부하 분산기의 백엔드는 특정 노드 또는 포드 IP 주소가 아닌 GKE 노드의 네트워크 인터페이스(NIC)를 식별합니다. 부하 분산기와 백엔드 유형에 따라 노드가 GCE_VM_IP NEG, 인스턴스 그룹 또는 대상 풀로 그룹화되는 방식이 결정됩니다.
| GKE LoadBalancer 서비스 | 결과 Google Cloud 부하 분산기 | 노드 그룹화 방법 |
|---|---|---|
| GKE 하위 설정이 사용 설정된 클러스터에서 생성된 내부 LoadBalancer 서비스1 | 백엔드 서비스가 GCE_VM_IP 네트워크 엔드포인트 그룹(NEG) 백엔드를 사용하는 내부 패스 스루 네트워크 부하 분산기 |
노드 VM은 서비스의 서비스의 |
| GKE 하위 설정이 사용 중지된 클러스터에서 생성된 내부 LoadBalancer 서비스 | 백엔드 서비스가 영역 비관리형 인스턴스 그룹 백엔드를 사용하는 내부 패스 스루 네트워크 부하 분산기 | 모든 노드 VM은 GKE가 내부 패스 스루 네트워크 부하 분산기의 백엔드 서비스에 백엔드로 사용하는 영역 비관리형 인스턴스 그룹에 배치됩니다. 서비스의 단일 부하 분산 인스턴스 그룹 제한사항으로 인해 동일한 비관리형 인스턴스 그룹이 클러스터에서 생성된 다른 부하 분산기 백엔드 서비스에 사용됩니다. |
cloud.google.com/l4-rbs: "enabled" 주석이 있는 외부 LoadBalancer 서비스2
|
백엔드 서비스가 영역 비관리형 인스턴스 그룹 백엔드를 사용하는 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기 | 모든 노드 VM은 GKE가 외부 패스 스루 네트워크 부하 분산기의 백엔드 서비스에 백엔드로 사용하는 영역 비관리형 인스턴스 그룹에 배치됩니다. 서비스의 단일 부하 분산 인스턴스 그룹 제한사항으로 인해 동일한 비관리형 인스턴스 그룹이 클러스터에서 생성된 다른 부하 분산기 백엔드 서비스에 사용됩니다. |
cloud.google.com/l4-rbs: "enabled" 주석3 없는 외부 LoadBalancer 서비스
|
대상 풀에 클러스터의 모든 노드가 포함된 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기 | 대상 풀은 인스턴스 그룹에 의존하지 않는 기존 API입니다. 모든 노드의 대상 풀에는 직접 멤버십이 포함됩니다. 서비스의 |
1 GKE 하위 설정을 사용 설정한 후에 생성된 내부 패스 스루 네트워크 부하 분산기만 GCE_VM_IP NEG를 사용합니다. GKE 하위 설정을 사용하기 전에 생성된 모든 내부 LoadBalancer 서비스는 비관리형 인스턴스 그룹 백엔드를 계속 사용합니다. 예시 및 구성 안내는 내부 LoadBalancer 서비스 만들기를 참조하세요.
2GKE는 기존 외부 LoadBalancer 서비스를 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기에서 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기로 자동으로 마이그레이션하지 않습니다. 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기로 구동되는 외부 LoadBalancer 서비스를 만들려면 생성 시 서비스 매니페스트에 cloud.google.com/l4-rbs: "enabled" 주석을 포함해야 합니다.
3백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기로 구동되는 기존 외부 LoadBalancer 서비스에서 cloud.google.com/l4-rbs: "enabled" 주석을 삭제해도 GKE가 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기를 만들지 않습니다. 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기로 구동되는 외부 LoadBalancer 서비스를 만들려면 생성 시 서비스 매니페스트에서 cloud.google.com/l4-rbs: "enabled" 주석을 생략해야 합니다.
GCE_VM_IP NEG 백엔드의 노드 멤버십
클러스터에 GKE 하위 설정이 사용 설정된 경우 GKE는 각 내부 LoadBalancer 서비스의 각 영역에 고유한 GCE_VM_IP NEG를 만듭니다. 인스턴스 그룹과 달리 노드는 부하 분산 GCE_VM_IP NEG 둘 이상의 구성원일 수 있습니다. 서비스의 externalTrafficPolicy와 클러스터의 노드 수에 따라 서비스의 GCE_VM_IP NEG에 엔드포인트로 추가되는 노드가 결정됩니다.
클러스터의 제어 영역은 다음 표에 요약된 대로 서비스의 externalTrafficPolicy 값 및 클러스터의 노드 수에 따라 GCE_VM_IP NEG에 노드를 엔드포인트로 추가합니다.
externalTrafficPolicy |
클러스터에 있는 노드 수 | 엔드포인트 멤버십 |
|---|---|---|
Cluster |
노드 1~25개 | GKE는 노드에 서비스 제공 포드가 포함되어 있지 않더라도 클러스터의 모든 노드를 서비스 NEG의 엔드포인트로 사용합니다. |
Cluster |
노드 25개 초과 | GKE는 노드에 서비스 제공 포드가 포함되지 않은 경우에도 노드 최대 25개의 임의 하위 집합을 서비스 NEG의 엔드포인트로 사용합니다. |
Local |
노드 수1 | GKE는 서비스의 제공 포드 중 하나 이상이 서비스 NEG의 엔드포인트로 있는 노드만 사용합니다. |
1내부 LoadBalancer 서비스에 대한 제공 포드가 있는 노드 250개로 제한됩니다. 클러스터에 250개를 초과하는 노드가 있을 수 있지만 내부 패스 스루 네트워크 부하 분산기 백엔드 하위 설정이 사용 중지되면 내부 패스 스루 네트워크 부하 분산기가 백엔드 VM 250개에만 배포합니다. GKE 하위 설정을 사용 설정해도 GKE는 내부 패스 스루 네트워크 부하 분산기 백엔드 하위 설정으로 내부 패스 스루 네트워크 부하 분산기를 구성하지 않습니다. 이 한도에 대한 자세한 내용은 내부 백엔드 서비스당 최대 VM 인스턴스 수를 참조하세요.
단일 부하 분산 인스턴스 그룹 제한사항
Compute Engine API는 VM이 부하 분산 인스턴스 그룹 둘 이상의 구성원이 되는 것을 방지합니다. GKE 노드에 이 제약조건이 적용됩니다.
비관리형 인스턴스 그룹 백엔드를 사용하는 경우 GKE는 클러스터가 사용하는 각 영역의 모든 노드 풀에서 모든 노드를 포함하는 비관리형 인스턴스 그룹을 만들거나 업데이트합니다. 이러한 비관리형 인스턴스 그룹은 다음 용도로 사용됩니다.
- GKE 하위 설정이 사용 중지된 경우 내부 LoadBalancer 서비스에 생성된 내부 패스 스루 네트워크 부하 분산기
cloud.google.com/l4-rbs: "enabled"주석을 사용하여 외부 LoadBalancer 서비스에 대해 생성된 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기- 컨테이너 기반 부하 분산이 아닌 GKE 인그레스 컨트롤러를 사용하여 외부 GKE 인그레스 리소스용으로 생성된 외부 애플리케이션 부하 분산기
노드 VM은 부하 분산 인스턴스 그룹 둘 이상의 구성원이 될 수 없으므로 GKE는 다음 중 하나가 참인 경우 내부 패스 스루 네트워크 부하 분산기, 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기 및 GKE 인그레스 리소스에 대해 생성된 외부 애플리케이션 부하 분산기를 만들고 관리할 수 없습니다.
- GKE 외부에서 백엔드 서비스 기반 부하 분산기를 하나 이상 만들고 클러스터의 관리형 인스턴스 그룹을 부하 분산기 백엔드 서비스의 백엔드로 사용했습니다.
- GKE 외부에서 클러스터 노드의 일부 또는 전체를 포함하는 커스텀 비관리형 인스턴스 그룹을 만든 다음 해당 커스텀 비관리형 인스턴스 그룹을 부하 분산기의 백엔드 서비스에 연결합니다.
이러한 제한사항을 해결하기 위해 가능한 경우 GKE에 NEG 백엔드를 사용하도록 지시할 수 있습니다.
- GKE 하위 설정을 사용합니다. 그 결과 새로운 내부 LoadBalancer 서비스는
GCE_VM_IPNEG를 대신 사용합니다. - 컨테이너 기반 부하 분산을 사용하도록 외부 GKE 인그레스 리소스를 구성합니다. 자세한 내용은 GKE 컨테이너 기반 부하 분산을 참조하세요.
부하 분산기 상태 점검
모든 GKE LoadBalancer 서비스에는 부하 분산기 상태 점검이 필요합니다. 부하 분산기의 상태 점검은 클러스터 외부에서 구현되며 준비 또는 활성 프로브와 다릅니다.
서비스의 externalTrafficPolicy는 부하 분산기의 상태 점검 작동 방식을 정의합니다. 모든 경우 부하 분산기의 상태 점검 프로버는 각 노드에서 실행 중인 kube-proxy 소프트웨어로 패킷을 보냅니다. 부하 분산기의 상태 점검은 포드가 존재하는지, 실행 중인지, 준비 프로브를 통과했는지 여부와 같은 kube-proxy에서 수집하는 정보의 프록시입니다. LoadBalancer 서비스의 상태 점검은 제공 포드로 라우팅될 수 없습니다. 부하 분산기의 상태 점검은 새 TCP 연결을 노드로 전달하도록 설계되었습니다.
다음 표에서는 상태 점검 동작을 설명합니다.
externalTrafficPolicy |
상태 점검을 통과하는 노드 | 사용되는 포트 |
|---|---|---|
Cluster |
클러스터의 모든 노드는 노드에 서빙 포드가 없더라도 상태 점검을 통과합니다. 노드에 서빙 포드가 하나 이상 있으면 서빙 포드가 종료되거나 준비 프로브에 실패하더라도 노드는 부하 분산기의 상태 점검을 통과합니다. | 부하 분산기 상태 점검 포트는 TCP 포트 10256이어야 합니다. 이는 맞춤설정할 수 없습니다. |
Local |
준비된 종료되지 않은 서빙 포드가 하나 이상 있는 노드만 부하 분산기의 상태 점검을 통과합니다. 서빙 포드가 없는 노드, 서빙 포드가 모두 준비 프로브에 실패하는 노드, 서빙 포드가 모두 종료되는 노드는 부하 분산기의 상태 점검에 실패합니다. 상태 전환 중에 노드는 부하 분산기의 비정상 기준에 도달할 때까지 부하 분산기의 상태 점검을 통과합니다. 전환 상태는 노드의 모든 서빙 포드가 준비 프로브에 실패하기 시작하거나 노드의 모든 서빙 포드가 종료될 때 발생합니다. 이 상황에서 패킷이 처리되는 방식은 GKE 버전에 따라 다릅니다. 자세한 내용은 다음 섹션인 패킷 처리를 참조하세요. |
상태 점검 포트는 커스텀 상태 점검 포트를 지정하지 않는 한 TCP 포트 10256입니다. |
패킷 처리
다음 섹션에서는 부하 분산기와 클러스터 노드가 함께 작동하여 LoadBalancer 서비스에 대해 수신된 패킷을 라우팅하는 방법을 설명합니다.
패스스루 부하 분산
Google Cloud 패스스루 부하 분산기는 GKE 클러스터 노드의 nic0 인터페이스로 패킷을 라우팅합니다. 노드에서 수신하는 각 부하 분산 패킷의 특징은 다음과 같습니다.
- 패킷의 대상 IP 주소가 부하 분산기의 전달 규칙 IP 주소와 일치합니다.
- 패킷의 프로토콜 및 대상 포트가 다음 두 가지 모두와 일치합니다.
- 서비스 매니페스트의
spec.ports[]에 지정된 프로토콜 및 포트 - 부하 분산기의 전달 규칙에 구성된 프로토콜 및 포트
- 서비스 매니페스트의
노드의 대상 네트워크 주소 변환
노드는 패킷을 수신한 후 추가 패킷 처리를 수행합니다. GKE Dataplane V2가 사용 설정되지 않은 GKE 클러스터에서 노드는 iptables를 사용하여 부하 분산 패킷을 처리합니다. GKE Dataplane V2가 사용 설정된 GKE 클러스터에서 노드는 대신 eBPF를 사용합니다. 노드 수준 패킷 처리에는 항상 다음 작업이 포함됩니다.
- 노드가 패킷에서 대상 네트워크 주소 변환(DNAT)을 수행하여 대상 IP 주소를 제공 포드 IP 주소로 설정합니다.
- 노드가 패킷의 대상 포트를 해당 서비스
spec.ports[]의targetPort로 변경합니다.
노드의 소스 네트워크 주소 변환
externalTrafficPolicy에 따라 노드 수준 패킷 처리가 패킷이 노드에서 Pod로 이동하는 경로뿐만 아니라 소스 네트워크 주소 변환 (SNAT)을 수행하는지도 결정됩니다.
externalTrafficPolicy |
노드 SNAT 동작 | 라우팅 동작 |
|---|---|---|
Cluster |
노드는 부하 분산 패킷의 소스 IP 주소를 부하 분산기에서 수신한 노드의 IP 주소와 일치하도록 변경합니다. | 노드가 모든 제공 포드로 패킷을 라우팅합니다. 제공 포드는 동일한 노드에 있거나 없을 수 있습니다. 부하 분산기에서 패킷을 수신하는 노드에 준비 및 제공 포드가 없으면 노드는 준비 및 제공 포드가 포함된 다른 노드로 패킷을 라우팅합니다. 포드의 응답 패킷은 노드에서 다시 부하 분산기로부터 요청 패킷을 수신한 노드로 라우팅됩니다. 그런 다음 첫 번째 노드가 직접 서버 반환을 사용하여 응답 패킷을 원래 클라이언트로 보냅니다. |
Local |
노드는 부하 분산된 패킷의 소스 IP 주소를 변경하지 않습니다. | 대부분의 경우 노드는 부하 분산기에서 패킷을 수신한 노드에서 실행 중인 제공 포드로 패킷을 라우팅합니다. 이 노드는 직접 서버 반환을 사용하여 원래 클러스터에 응답 패킷을 전송합니다. 이것이 트래픽 정책 유형의 기본 인텐트입니다. 노드에 서비스에 대해 준비된 종료되지 않은 제공 포드가 없어도 부하 분산기에서 패킷을 수신하는 경우가 있습니다. 이러한 상황은 부하 분산기의 상태 점검이 아직 실패 기준점에 도달하지 않았지만 이전에 준비된 제공 포드가 더 이상 준비되어 있지 않거나 종료되는 경우(예: 순차적 업데이트를 수행할 때) 발생합니다. 이 상황에서 패킷이 처리되는 방식은 GKE 버전, 클러스터가 GKE Dataplane V2를 사용하는지 여부,
|
가격 및 할당량
네트워크 가격 책정은 부하 분산기에서 처리되는 패킷에 적용됩니다. 자세한 내용은 Cloud Load Balancing 및 전달 규칙 가격 책정을 참조하세요. Google Cloud 가격 계산기를 사용하여 예상 청구액을 계산할 수도 있습니다.
만들 수 있는 전달 규칙의 수는 부하 분산기 할당량에 따라 제어됩니다.
- 내부 패스 스루 네트워크 부하 분산기는 프로젝트별 백엔드 서비스 할당량, 프로젝트별 상태 점검 할당량, Virtual Private Cloud 네트워크별 내부 패스 스루 네트워크 부하 분산기 전달 규칙 할당량을 사용합니다.
- 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기는 프로젝트별 백엔드 서비스 할당량, 프로젝트별 상태 점검 할당량, 프로젝트별 외부 패스 스루 네트워크 부하 분산기 전달 규칙 할당량을 사용합니다.
- 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기는 프로젝트별 대상 풀 할당량, 프로젝트별 상태 점검 할당량, 프로젝트별 외부 패스 스루 네트워크 부하 분산기 전달 규칙 할당량을 사용합니다.