이 페이지에서는 Google Kubernetes Engine(GKE)에서 내부 패스 스루 네트워크 부하 분산기 또는 내부 부하 분산기를 만드는 방법을 설명합니다. 외부 패스 스루 네트워크 부하 분산기를 만들려면 LoadBalancer 유형의 서비스 만들기 방법에 대해 알아보세요.
내부 패스 스루 네트워크 부하 분산기 하위 설정 사용
내부 패스 스루 네트워크 부하 분산기를 사용하면 클러스터의 VPC 네트워크 내에 있는 클라이언트와 클러스터의 VPC 네트워크에 연결된 네트워크의 클라이언트가 클러스터 서비스에 액세스할 수 있습니다. 클라이언트가 클러스터 내에 있지 않아도 됩니다. 예를 들어 내부 LoadBalancer 서비스는 클러스터의 VPC 네트워크에 있는 가상 머신(VM) 인스턴스에 액세스할 수 있습니다.
GKE 하위 설정 사용
GKE 하위 설정은 인스턴스 그룹 대신 GCE_VM_IP 네트워크 엔드포인트 그룹(NEG)을 백엔드로 사용하므로 내부 LoadBalancer 서비스의 확장성을 개선합니다. GKE 하위 설정을 사용하면 GKE는 내부 LoadBalancer 서비스마다 컴퓨팅 영역당 하나의 NEG를 만듭니다.
NEG의 구성원 엔드포인트는 서비스 제공 포드가 하나 이상 있는 노드의 IP 주소입니다. GKE 하위 설정에 대한 자세한 내용은 노드 그룹화를 참조하세요.
요구사항 및 제한사항
GKE 하위 설정의 요구사항 및 제한사항은 다음과 같습니다.
- GKE 버전 1.18.19-gke.1400 이상의 새 표준 클러스터와 기존 표준 클러스터에서 GKE 하위 설정을 사용 설정할 수 있습니다. GKE 하위 설정을 사용 설정한 후에는 사용 중지할 수 없습니다.
- Autopilot 클러스터에서 GKE 하위 설정이 사용 중지됩니다.
- GKE 하위 설정을 사용하려면
HttpLoadBalancing부가기능이 사용 설정되어 있어야 합니다. 이 부가기능은 기본적으로 사용 설정되어 있습니다. Autopilot 클러스터에서는 이 필수 부가기능을 중지할 수 없습니다. - 네트워크 엔드포인트 그룹의 할당량이 적용됩니다. Google Cloud는 영역마다 내부 LoadBalancer 서비스당 하나의
GCE_VM_IPNEG를 만듭니다. - 전달 규칙, 백엔드 서비스, 상태 점검에 대한 할당량이 적용됩니다. 자세한 내용은 할당량 및 제한을 참조하세요.
- 여러 부하 분산기(
alpha.cloud.google.com/load-balancer-backend-share) 간에 백엔드 서비스를 공유하기 위해 주석과 함께 GKE 하위 설정을 사용할 수 없습니다. - Google Cloud CLI 버전 345.0.0 이상이 필요합니다.
시작하기 전에
시작하기 전에 다음 태스크를 수행했는지 확인합니다.
- Google Kubernetes Engine API를 사용 설정합니다. Google Kubernetes Engine API 사용 설정
- 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 initialize합니다. 이전에 gcloud CLI를 설치한 경우
gcloud components update를 실행하여 최신 버전을 가져옵니다.
새 Standard 클러스터에서 GKE 하위 설정 사용
Google Cloud CLI, Google Cloud 콘솔 또는 Terraform을 사용하여 GKE 하위 설정이 사용 설정된 Standard 클러스터를 만들 수 있습니다. GKE 하위 설정이 사용 설정된 상태로 생성된 클러스터는 항상 GKE 하위 설정을 사용합니다.
Console
Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.
add_box만들기를 클릭합니다.
원하는 대로 클러스터를 구성합니다.
탐색창의 클러스터에서 네트워킹을 클릭합니다.
L4 내부 부하 분산기에 하위 설정 사용 설정 체크박스를 선택합니다.
만들기를 클릭합니다.
gcloud
gcloud container clusters create CLUSTER_NAME \
--cluster-version=VERSION \
--enable-l4-ilb-subsetting \
--location=COMPUTE_LOCATION
다음을 바꿉니다.
CLUSTER_NAME: 새 클러스터의 이름VERSION: GKE 버전. 1.18.19-gke.1400 이상이어야 합니다.--release-channel옵션을 사용하여 출시 채널을 선택할 수도 있습니다. 출시 채널의 기본 버전은 1.18.19-gke.1400 이상이어야 합니다.COMPUTE_LOCATION: 클러스터의 Compute Engine 위치입니다.
기본이 아닌 네트워크 또는 서브네트워크를 사용하려면 다음 명령어를 실행합니다.
gcloud container clusters create CLUSTER_NAME \
--cluster-version=VERSION \
--network NETWORK_NAME \
--subnetwork SUBNETWORK_NAME \
--enable-l4-ilb-subsetting \
--location=COMPUTE_LOCATION
다음을 바꿉니다.
SUBNET_NAME: 새 서브넷의 이름입니다. GKE 버전 1.22.4-gke.100 이상에서는 이 필드에 정규화된 리소스 URL을 사용하여 다른 프로젝트의 서브넷을 지정할 수 있습니다.gcloud compute networks subnets describe명령어를 사용하여 정규화된 리소스 URL을 가져올 수 있습니다.NETWORK_NAME: 서브넷의 VPC 네트워크의 이름입니다.
Terraform
Terraform을 사용하여 GKE 하위 설정이 사용 설정된 Standard 클러스터를 만들려면 다음 예시를 참조하세요.
Terraform 사용에 대한 자세한 내용은 GKE에 대한 Terraform 지원을 참조하세요.
기존 Standard 클러스터에서 GKE 하위 설정 사용
gcloud CLI 또는 Google Cloud 콘솔을 사용하여 기존 Standard 클러스터에 GKE 하위 설정을 사용 설정할 수 있습니다. GKE 하위 설정을 사용 설정한 후에는 사용 중지할 수 없습니다.
콘솔
Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.
클러스터 목록에서 수정하려는 클러스터 이름을 클릭합니다.
네트워킹에서 L4 내부 부하 분산기의 하위 설정 필드 옆에 있는 edit L4 내부 부하 분산기 하위 설정 사용 설정을 클릭합니다.
L4 내부 부하 분산기에 하위 설정 사용 설정 체크박스를 선택합니다.
변경사항 저장을 클릭합니다.
gcloud
gcloud container clusters update CLUSTER_NAME \
--enable-l4-ilb-subsetting
다음을 바꿉니다.
CLUSTER_NAME: 클러스터의 이름
GKE 하위 설정을 사용 설정해도 기존 내부 LoadBalancer 서비스는 중단되지 않습니다. GCE_VM_IP NEG가 백엔드로 있는 백엔드 서비스를 사용하도록 기존 내부 LoadBalancer 서비스를 마이그레이션하려면 대체 서비스 매니페스트를 배포해야 합니다. 자세한 내용은 LoadBalancer 서비스 개념 문서의 노드 그룹화를 참조하세요.
워크로드 배포
다음 매니페스트는 샘플 웹 애플리케이션 컨테이너 이미지를 실행하는 배포를 설명합니다.
매니페스트를
ilb-deployment.yaml로 저장합니다.apiVersion: apps/v1 kind: Deployment metadata: name: ilb-deployment spec: replicas: 3 selector: matchLabels: app: ilb-deployment template: metadata: labels: app: ilb-deployment spec: containers: - name: hello-app image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0매니페스트를 클러스터에 적용합니다.
kubectl apply -f ilb-deployment.yaml
내부 LoadBalancer 서비스 만들기
다음 예시에서는 TCP 포트 80을 사용하여 내부 LoadBalancer 서비스를 만듭니다. GKE에서 전달 규칙이 포트 80을 사용하는 내부 패스 스루 네트워크 부하 분산기를 배포한 후 트래픽을 포트 8080의 백엔드 포드로 전달합니다.
매니페스트를
ilb-svc.yaml로 저장합니다.apiVersion: v1 kind: Service metadata: name: ilb-svc annotations: networking.gke.io/load-balancer-type: "Internal" spec: type: LoadBalancer externalTrafficPolicy: Cluster selector: app: ilb-deployment ports: - name: tcp-port protocol: TCP port: 80 targetPort: 8080매니페스트에는 다음이 포함되어야 합니다.
- 내부 LoadBalancer 서비스의
name(이 경우ilb-svc) - 내부 LoadBalancer 서비스가 필요한 경우 지정하는 주석입니다.
GKE 버전 1.17 이상에서는 예시 매니페스트에 표시된 것처럼
networking.gke.io/load-balancer-type: "Internal"주석을 사용합니다. 이전 버전에서는 대신cloud.google.com/load-balancer-type: "Internal"을 사용합니다. type: LoadBalancerspec: selector필드: 서비스 대상 포드를 지정합니다(예:app: hello).- 포트 정보:
port는 내부 패스 스루 네트워크 부하 분산기의 전달 규칙이 패킷을 수신하는 목적지 포트를 나타냅니다.targetPort는 각 제공 포드에 정의된containerPort와 일치해야 합니다.port값과targetPort값이 같을 필요는 없습니다. 노드가 항상 대상 NAT를 수행하고 대상 부하 분산기 전달 규칙 IP 주소 및port를 대상 포드 IP 주소 및targetPort로 변경합니다. 자세한 내용은 LoadBalancer 서비스 개념 문서의 노드의 목적지 네트워크 주소 변환을 참조하세요.
매니페스트에는 다음이 포함될 수 있습니다.
spec.ipFamilyPolicy및ipFamilies: GKE가 서비스에 IP 주소를 할당하는 방법을 정의합니다. GKE는 단일 스택(IPv4 또는 IPv6만) 또는 이중 스택 IP LoadBalancer 서비스를 지원합니다. 이중 스택 LoadBalancer 서비스는 IPv4 트래픽용과 IPv6 트래픽용의 두 가지 별도의 내부 패스 스루 네트워크 부하 분산기 전달 규칙으로 구현됩니다. GKE 이중 스택 LoadBalancer 서비스는 버전 1.29 이상에서 제공됩니다. 자세한 내용은 IPv4/IPv6 이중 스택 서비스를 참조하세요.
자세한 내용은 LoadBalancer 서비스 매개변수를 참조하세요.
- 내부 LoadBalancer 서비스의
매니페스트를 클러스터에 적용합니다.
kubectl apply -f ilb-svc.yaml서비스에 대한 자세한 정보를 가져옵니다.
kubectl get service ilb-svc --output yaml출력은 다음과 비슷합니다.
apiVersion: v1 kind: Service metadata: annotations: cloud.google.com/neg: '{"ingress":true}' cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}' kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}} networking.gke.io/load-balancer-type: Internal service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r creationTimestamp: "2022-07-22T17:26:04Z" finalizers: - gke.networking.io/l4-ilb-v2 - service.kubernetes.io/load-balancer-cleanup name: ilb-svc namespace: default resourceVersion: "51666" uid: d7a1a865-7972-44e1-aa9e-db5be23d6567 spec: allocateLoadBalancerNodePorts: true clusterIP: 10.88.2.141 clusterIPs: - 10.88.2.141 externalTrafficPolicy: Cluster internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: tcp-port nodePort: 30521 port: 80 protocol: TCP targetPort: 8080 selector: app: ilb-deployment sessionAffinity: None type: LoadBalancer status: loadBalancer: ingress: - ip: 10.128.15.245출력에는 다음과 같은 속성이 있습니다.
- 내부 패스 스루 네트워크 부하 분산기의 전달 규칙의 IP 주소는
status.loadBalancer.ingress에 포함됩니다. 이 IP 주소는clusterIP값과 다릅니다. 이 예시에서 부하 분산기의 전달 규칙 IP 주소는10.128.15.245입니다. app: ilb-deployment라벨이 있는 모든 포드가 이 서비스의 제공 포드입니다. 내부 패스 스루 네트워크 부하 분산기에서 라우팅한 패킷을 수신하는 포드입니다.- 클라이언트는 서비스 매니페스트의
port필드에 지정된loadBalancerIP 주소 및 TCP 목적지 포트를 사용하여 서비스를 호출합니다. 노드에서 패킷을 수신한 후 패킷이 라우팅되는 방법에 대한 자세한 내용은 패킷 처리를 참조하세요. - GKE가 서비스에
nodePort를 할당했습니다. 이 예시에서는 포트30521이 할당됩니다.nodePort는 내부 패스 스루 네트워크 부하 분산기와 관련이 없습니다.
- 내부 패스 스루 네트워크 부하 분산기의 전달 규칙의 IP 주소는
서비스 네트워크 엔드포인트 그룹을 검사합니다.
kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"출력은 다음과 비슷합니다.
{"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["ZONE_NAME"]}응답은 GKE가
k8s2-knlc4c77-default-ilb-svc-ua5ugas0이라는 네트워크 엔드포인트 그룹을 만들었음을 나타냅니다. 이 주석은 GKE 하위 설정을 사용하는LoadBalancer유형의 서비스에 있으며 GKE 하위 설정을 사용하지 않는 서비스에는 없습니다.
내부 패스 스루 네트워크 부하 분산기 구성요소 확인
내부 LoadBalancer 서비스 만들기 섹션에 포함된 예시에서 내부 패스 스루 네트워크 부하 분산기의 전달 규칙 IP 주소는 10.128.15.245입니다. Google Cloud CLI를 사용하여 클러스터 프로젝트의 전달 규칙 목록에 이 전달 규칙이 포함된 것을 확인할 수 있습니다.
gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"
출력에는 관련 내부 패스 스루 네트워크 부하 분산기 전달 규칙, IP 주소, 전달 규칙에서 참조하는 백엔드 서비스(이 예시에서는 k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r)가 포함됩니다.
NAME ... IP_ADDRESS ... TARGET
...
k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r 10.128.15.245 ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
Google Cloud CLI를 사용하여 부하 분산기의 백엔드 서비스를 설명할 수 있습니다.
gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION
COMPUTE_REGION을 백엔드 서비스의 컴퓨팅 리전으로 바꿉니다.
출력에는 서비스의 벡엔드 GCE_VM_IP NEG 또는 NEG가 포함됩니다(이 예시에서는 k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r).
backends:
- balancingMode: CONNECTION
group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...
서비스의 하위 집합에서 노드 목록을 확인하려면 다음 명령어를 사용합니다.
gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
--zone=COMPUTE_ZONE
다음을 바꿉니다.
NEG_NAME: GKE 컨트롤러에서 생성된 네트워크 엔드포인트 그룹의 이름입니다.COMPUTE_ZONE: 작업할 네트워크 엔드포인트 그룹의 컴퓨팅 영역입니다.
내부 패스 스루 네트워크 부하 분산기의 정상 노드 목록을 확인하려면 다음 명령어를 사용합니다.
gcloud compute backend-services get-health SERVICE_NAME \
--region=COMPUTE_REGION
다음을 바꿉니다.
SERVICE_NAME: 백엔드 서비스 이름입니다. 이 값은 GKE 컨트롤러에서 만든 네트워크 엔드포인트 그룹의 이름과 동일합니다.COMPUTE_REGION: 작업할 백엔드 서비스의 컴퓨팅 리전입니다.
내부 패스 스루 네트워크 부하 분산기에 대한 연결 테스트
클러스터와 동일한 VPC 네트워크 및 동일한 리전에 있는 VM 인스턴스에 SSH로 연결한 후 다음 명령어를 실행합니다.
curl LOAD_BALANCER_IP:80
LOAD_BALANCER_IP를 부하 분산기의 전달 규칙 IP 주소로 바꿉니다.
응답에 ilb-deployment의 출력이 표시됩니다.
Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n
내부 패스 스루 네트워크 부하 분산기는 동일한 VPC 네트워크(또는 연결된 네트워크) 내에서만 액세스할 수 있습니다. 기본적으로 부하 분산기의 전달 규칙은 전역 액세스를 사용하지 않으므로 클라이언트 VM, Cloud VPN 터널 또는 Cloud Interconnect 연결(VLAN)은 내부 패스 스루 네트워크 부하 부산기와 동일한 리전에 있어야 합니다. 모든 리전에서 클라이언트를 지원하려면 서비스 매니페스트에 전역 액세스 주석을 포함하여 부하 분산기의 전달 규칙에 전역 액세스를 사용 설정하면 됩니다.
내부 LoadBalancer 서비스 및 부하 분산기 리소스 삭제
kubectl delete 또는 Google Cloud 콘솔을 사용하여 Deployment와 Service를 삭제할 수 있습니다.
kubectl
배포 삭제
배포를 삭제하려면 다음 명령어를 실행합니다.
kubectl delete deployment ilb-deployment
서비스 삭제
서비스를 삭제하려면 다음 명령어를 실행합니다.
kubectl delete service ilb-svc
콘솔
배포 삭제
Deployment를 삭제하려면 다음 단계를 수행하세요.
Google Cloud 콘솔에서 워크로드 페이지로 이동합니다.
삭제하려는 배포를 선택하고 delete 삭제를 클릭합니다.
확인 메시지가 표시되면 선택한 배포와 연관된 수평형 포드 자동 확장 처리 삭제 체크박스를 선택하고 삭제를 클릭합니다.
서비스 삭제
서비스를 삭제하려면 다음 단계를 수행하세요.
Google Cloud 콘솔에서 서비스 및 인그레스 페이지로 이동합니다.
삭제할 서비스를 선택한 다음 delete 삭제를 클릭합니다.
확인 메시지가 나타나면 삭제를 클릭합니다.
공유 IP
내부 패스 스루 네트워크 부하 분산기는 여러 전달 규칙 간에 가상 IP 주소를 공유할 수 있습니다.
이는 동일한 IP에서 동시 포트 수를 확장하거나 동일한 IP에서 UDP 트래픽과 TCP 트래픽을 허용하는 데 유용합니다. 노출된 포트를 IP 주소당 최대 50개까지 허용합니다. 공유 IP는 기본적으로 GKE 클러스터에서 내부 LoadBalancer 서비스를 통해 지원됩니다.
배포 시 서비스의 loadBalancerIP 필드는 서비스 간에 공유되어야 하는 IP를 나타내는 데 사용됩니다.
제한사항
여러 부하 분산기의 공유 IP에는 다음 제한사항과 기능이 있습니다.
- 각 서비스(또는 전달 규칙)는 포트를 최대 5개까지 포함할 수 있습니다.
- 서비스(전달 규칙) 최대 10개에서 IP 주소 하나를 공유할 수 있습니다. 따라서 포트는 공유 IP당 최대 50개까지 사용됩니다.
- 동일한 IP 주소를 공유하는 각 전달 규칙은 프로토콜과 포트의 고유한 조합을 사용해야 합니다. 따라서 모든 내부 LoadBalancer 서비스는 고유한 프로토콜 및 포트 집합을 사용해야 합니다.
- 동일한 공유 IP에서 TCP 전용 서비스와 UDP 전용 서비스를 조합할 수 있지만 동일한 서비스에서 TCP 포트와 UDP 포트를 모두 노출할 수 없습니다.
공유 IP 사용 설정
내부 LoadBalancer 서비스에서 공통 IP를 공유하려면 다음 단계를 따르세요.
--purpose SHARED_LOADBALANCER_VIP로 고정 내부 IP를 만듭니다. IP 주소를 공유하려면 이 용도로 IP 주소를 만들어야 합니다. VPC에 고정 내부 IP 주소를 만드는 경우 공유 IP 주소의 값이 공유 VPC 네트워크의 선택한 공유 서브넷에서 사용 가능한 IP 주소의 범위에서 가져오더라도 IP 주소를 사용할 인스턴스와 동일한 서비스 프로젝트에 IP 주소를 만들어야 합니다. 자세한 내용은 공유 VPC 프로비저닝 페이지의 고정 내부 IP 예약을 참조하세요.loadBalancerIP필드에 이 고정 IP를 사용하여 내부 LoadBalancer 서비스를 최대 10개까지 배포합니다. 내부 패스 스루 네트워크 부하 분산기는 GKE 서비스 컨트롤러에서 조정되고 동일한 프런트엔드 IP를 통해 배포됩니다.
다음 예시에서는 동일한 내부 부하 분산기 IP에 대해 여러 TCP 포트와 UDP 포트를 지원하기 위해 이를 수행하는 방법을 보여줍니다.
GKE 클러스터와 동일한 리전에 고정 IP를 만듭니다. 서브넷은 부하 분산기가 사용하는 서브넷과 동일해야 하며, 이는 기본적으로 GKE 클러스터 노드 IP에서 사용하는 서브넷입니다.
클러스터와 VPC 네트워크가 동일한 프로젝트에 있으면 다음을 실행합니다.
gcloud compute addresses create IP_ADDR_NAME \ --project=PROJECT_ID \ --subnet=SUBNET \ --addresses=IP_ADDRESS \ --region=COMPUTE_REGION \ --purpose=SHARED_LOADBALANCER_VIP클러스터가 공유 VPC 서비스 프로젝트에 있지만 호스트 프로젝트에서 공유 VPC 네트워크를 사용하는 경우 다음을 실행합니다.
gcloud compute addresses create IP_ADDR_NAME \ --project=SERVICE_PROJECT_ID \ --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET \ --addresses=IP_ADDRESS \ --region=COMPUTE_REGION \ --purpose=SHARED_LOADBALANCER_VIP다음을 바꿉니다.
IP_ADDR_NAME: IP 주소 객체의 이름SERVICE_PROJECT_ID: 서비스 프로젝트의 IDPROJECT_ID: 프로젝트 ID(단일 프로젝트)HOST_PROJECT_ID: 공유 VPC 호스트 프로젝트의 프로젝트 IDCOMPUTE_REGION: 공유 서브넷을 포함하는 컴퓨팅 리전입니다.IP_ADDRESS: 선택한 서브넷의 기본 IP 주소 범위에서 사용되지 않은 내부 IP 주소입니다. IP 주소 지정을 생략하면 Google Cloud는 선택한 서브넷의 기본 IP 주소 범위에서 사용되지 않은 내부 IP 주소를 선택합니다. 자동으로 선택된 주소를 확인하려면gcloud compute addresses describe를 실행해야 합니다.SUBNET: 공유 서브넷의 이름
다음 TCP 서비스 구성을
tcp-service.yaml이라는 파일에 저장한 후 클러스터에 배포합니다.IP_ADDRESS를 이전 단계에서 선택한 IP 주소로 바꾸세요.apiVersion: v1 kind: Service metadata: name: tcp-service namespace: default annotations: networking.gke.io/load-balancer-type: "Internal" spec: type: LoadBalancer loadBalancerIP: IP_ADDRESS selector: app: myapp ports: - name: 8001-to-8001 protocol: TCP port: 8001 targetPort: 8001 - name: 8002-to-8002 protocol: TCP port: 8002 targetPort: 8002 - name: 8003-to-8003 protocol: TCP port: 8003 targetPort: 8003 - name: 8004-to-8004 protocol: TCP port: 8004 targetPort: 8004 - name: 8005-to-8005 protocol: TCP port: 8005 targetPort: 8005이 서비스 정의를 클러스터에 적용합니다.
kubectl apply -f tcp-service.yaml다음 UDP 서비스 구성을
udp-service.yaml이라는 파일에 저장한 후 배포하세요. 이 구성은 이전 단계에서 지정한IP_ADDRESS도 사용합니다.apiVersion: v1 kind: Service metadata: name: udp-service namespace: default annotations: networking.gke.io/load-balancer-type: "Internal" spec: type: LoadBalancer loadBalancerIP: IP_ADDRESS selector: app: my-udp-app ports: - name: 9001-to-9001 protocol: UDP port: 9001 targetPort: 9001 - name: 9002-to-9002 protocol: UDP port: 9002 targetPort: 9002이 파일을 클러스터에 적용합니다.
kubectl apply -f udp-service.yaml부하 분산기 전달 규칙을 나열하고 고정 IP를 필터링하여 이들 규칙에서 VIP가 공유되는지 확인합니다. 그러면 공유
IP_ADDRESS(이 예시에서는10.128.2.98)의 7개 포트에서 리슨하는 UDP 전달 규칙과 TCP 전달 규칙이 모두 있음을 알 수 있습니다.gcloud compute forwarding-rules list | grep 10.128.2.98 ab4d8205d655f4353a5cff5b224a0dde us-west1 10.128.2.98 UDP us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde acd6eeaa00a35419c9530caeb6540435 us-west1 10.128.2.98 TCP us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435
제한사항 및 한도
내부 패스 스루 네트워크 부하 분산기 제한사항
- Kubernetes 버전 1.7.4 이상을 실행하는 클러스터의 경우, 자동 모드 서브넷 외에도 커스텀 모드 서브넷에서 내부 부하 분산기를 사용할 수 있습니다.
--purpose플래그를SHARED_LOADBALANCER_VIP로 설정하여 예약 IP 주소를 만든 경우 Kubernetes 버전 1.7.X 이상을 실행하는 클러스터가 내부 패스 스루 네트워크 부하 분산기에 예약 IP 주소를 사용할 수 있습니다. 단계별 지침은 공유 IP 사용 설정을 참조하세요. GKE는 서비스가 해당 목적을 위해 내부 IP 주소를 참조하는 경우에만 내부 패스 스루 네트워크 부하 분산기의 IP 주소를 보존합니다. 그렇지 않으면 서비스가 업데이트되는 경우(예: 포트가 변경된 경우) GKE에서 부하 분산기의 IP 주소(spec.loadBalancerIP)를 변경할 수 있습니다.- 부하 분산기의 IP 주소가 변경되더라도(이전 지점 참조)
spec.clusterIP는 일정하게 유지됩니다.
내부 UDP 부하 분산기 제한사항
- 내부 UDP 부하 분산기에서는
sessionAffinity: ClientIP를 사용할 수 없습니다.
알려진 문제
10분마다 연결 제한 시간
하위 설정으로 생성된 내부 LoadBalancer 서비스는 약 10분마다 트래픽 중단을 관찰할 수 있습니다. 이 버그는 다음 버전에서 수정되었습니다.
- 1.18.19-gke.1700 이상
- 1.19.10-gke.1000 이상
- 1.20.6-gke.1000 이상
표준 등급에서 부하 분산기 생성 중에 발생한 오류
프로젝트 기본 네트워크 등급이 표준으로 설정된 프로젝트에서 내부 패스 스루 네트워크 부하 분산기를 만들면 다음 오류 메시지가 표시됩니다.
Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest
1.23.3-gke.900 이전 버전의 GKE에서 이 문제를 해결하려면 프로젝트 기본 네트워크 등급을 프리미엄으로 구성합니다.
이 문제는 GKE 버전 1.23.3-gke.900 이상에서 GKE 하위 설정이 사용 설정된 경우에 해결되었습니다.
GKE 컨트롤러는 프로젝트 기본 네트워크 등급이 표준으로 설정되어 있더라도 프리미엄 네트워크 등급에서 내부 패스 스루 네트워크 부하 분산기를 만듭니다.