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