내부 TCP/UDP 부하 분산

이 페이지에서는 Google Kubernetes Engine에서 Compute Engine 내부 TCP/UDP 부하 분산기를 만드는 방법을 설명합니다.

개요

내부 TCP/UDP 부하 분산을 사용하면 동일한 VPC 네트워크를 사용하고 같은 Google Cloud 리전에 위치한 클러스터 외부의 애플리케이션에 클러스터 서비스가 액세스할 수 있습니다. 예를 들어 us-west1 리전에 클러스터가 있고 서비스 중 하나가 이 리전의 동일한 VPC 네트워크에서 실행 중인 Compute Engine VM 인스턴스에 액세스할 수 있도록 한다고 가정합니다.

cloud.google.com/load-balancer-type: "Internal" 주석 및 type: LoadBalancer 사양으로 서비스 리소스를 만들어 내부 TCP/UDP 부하 분산기를 만들 수 있습니다. 아래의 안내와 예시에서 이를 수행하는 방법을 설명합니다.

내부 TCP/UDP 부하 분산이 없으면 클러스터 외부에 있는 애플리케이션에 액세스할 수 있도록 외부 부하 분산기와 방화벽 규칙을 설정해야 합니다.

내부 TCP/UDP 부하 분산은 동일한 VPC 네트워크와 컴퓨팅 리전의 클라이언트에서 오는 트래픽을 수신하는 서비스의 내부 IP 주소를 만듭니다. 전역 액세스를 사용 설정하면 동일한 VPC 네트워크의 모든 리전에 있는 클라이언트가 서비스에 액세스할 수 있습니다. 또한 VPC 네트워크 피어링을 통해 LoadBalancer 네트워크에 연결된 VPC 네트워크의 클라이언트는 서비스에 액세스할 수도 있습니다.

가격 책정

Compute Engine의 가격 책정 모델에 따라 비용이 청구됩니다. 자세한 내용은 부하 분산 및 전달 규칙 가격 책정 및 Google Cloud 가격 계산기에 대한 Compute Engine 페이지를 참조하세요.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

다음 방법 중 하나를 사용하여 기본 gcloud 설정을 진행합니다.

  • gcloud init를 사용하여 기본값 설정 과정을 진행합니다.
  • gcloud config를 사용하여 프로젝트 ID, 영역, 리전을 개별적으로 설정합니다.

gcloud init 사용

One of [--zone, --region] must be supplied: Please specify location 오류가 표시되면 이 섹션을 완료합니다.

  1. gcloud init를 실행하고 다음 안내를 따르세요.

    gcloud init

    원격 서버에서 SSH를 사용하는 경우 --console-only 플래그를 사용하여 다음 명령어로 브라우저를 실행하지 못하게 할 수 있습니다.

    gcloud init --console-only
  2. 안내를 따라 gcloud에서 Google Cloud 계정을 사용하도록 승인합니다.
  3. 새 구성을 만들거나 기존 구성을 선택합니다.
  4. Google Cloud 프로젝트를 선택합니다.
  5. 기본 Compute Engine 영역을 선택합니다.

gcloud config 사용

  • 기본 프로젝트 ID를 설정합니다.
    gcloud config set project project-id
  • 영역 클러스터를 사용하는 경우 기본 컴퓨팅 영역을 설정합니다.
    gcloud config set compute/zone compute-zone
  • 리전 클러스터를 사용하는 경우 기본 컴퓨팅 리전을 설정합니다.
    gcloud config set compute/region compute-region
  • gcloud를 최신 버전으로 업데이트합니다.
    gcloud components update

배포 만들기

다음 매니페스트에서는 Hello World 앱의 복제본 3개를 실행하는 배포를 설명합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
spec:
  selector:
    matchLabels:
      app: hello
  replicas: 3
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: "gcr.io/google-samples/hello-app:2.0"

이 샘플 앱의 소스 코드와 Dockerfile은 GitHub에 있습니다. PORT 환경 변수를 지정하지 않았으므로 컨테이너는 기본 포트인 8080에서 리슨합니다.

배포를 만들려면 매니페스트에서 my-deployment.yaml 파일을 만든 후 셸 또는 터미널 창에서 다음 명령어를 실행합니다.

kubectl apply -f my-deployment.yaml

내부 TCP 부하 분산기 만들기

다음 섹션에서는 서비스를 사용하여 내부 TCP 부하 분산기를 만드는 방법을 설명합니다.

서비스 구성 파일 작성

다음은 내부 TCP 부하 분산기를 만드는 서비스의 예시입니다.

apiVersion: v1
kind: Service
metadata:
  name: ilb-service
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
  labels:
    app: hello
spec:
  type: LoadBalancer
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

최소 서비스 요구사항

매니페스트에는 다음이 포함되어야 합니다.

  • Service의 name: 이 경우는 ilb-service입니다.
  • cloud.google.com/load-balancer-type: "Internal" 주석: 내부 TCP/UDP 부하 분산기를 구성하도록 지정합니다.
  • type: LoadBalancer
  • spec: selector 필드: 서비스 대상 Pod를 지정합니다(예: app: hello).
  • porttargetPort: Service가 노출되는 포트 및 컨테이너가 수신 대기하는 포트입니다.

서비스 배포

내부 TCP 부하 분산기를 만들려면 매니페스트에서 my-service.yaml 파일을 만든 후 셸 또는 터미널 창에서 다음 명령어를 실행합니다.

kubectl apply -f my-service.yaml

서비스 검사

배포 후에는 서비스가 성공적으로 구성되었는지 검사합니다.

서비스에 대한 자세한 정보를 가져옵니다.

kubectl get service ilb-service --output yaml

출력에서 status.loadBalancer.ingress 아래에 내부 부하 분산기의 IP 주소가 표시됩니다. 이 값은 clusterIP의 값과 다릅니다. 이 예시에서 부하 분산기의 IP 주소는 10.128.15.193입니다.

apiVersion: v1
kind: Service
metadata:
  ...
  labels:
    app: hello
  name: ilb-service
  ...
spec:
  clusterIP: 10.0.9.121
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 30835
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: hello
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 10.128.15.193

app: hello 라벨이 있는 모든 Pod가 서비스의 구성원입니다. 내부 부하 분산기로 전송된 요청의 최종 수신자가 될 수 있는 Pod입니다.

클라이언트는 서비스 매니페스트의 port 필드에 지정된 loadBalancer IP 주소 및 TCP 포트를 사용하여 서비스를 호출합니다. 요청은 targetPort 필드에 지정된 TCP 포트의 구성원 Pod 중 하나로 전달됩니다. 이전 예시와 같이, 클라이언트가 TCP 포트 80으로 10.128.15.193에서 서비스를 호출합니다. 요청은 TCP 포트 8080에서 구성원 Pod 중 하나로 전달됩니다. 구성원 Pod에는 포트 8080에서 수신 대기하는 컨테이너가 있어야 합니다.

nodePort 값 30835는 내부 부하 분산기와 관련이 없는 값입니다.

부하 분산기의 전달 규칙 보기

내부 부하 분산기는 전달 규칙으로 구현됩니다. 전달 규칙에는 인스턴스 그룹이 있는 백엔드 서비스가 있습니다.

앞의 예시에서 내부 부하 분산기 주소 10.128.15.193은 전달 규칙 주소와 동일합니다. 내부 부하 분산기를 구현하는 전달 규칙을 보려면 먼저 프로젝트의 모든 전달 규칙을 나열합니다.

gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"

출력에서 이 예시의 내부 부하 분산기 10.128.15.193과 동일한 주소를 가진 전달 규칙을 찾습니다.

NAME                          ... IP_ADDRESS  ... TARGET
...
aae3e263abe0911e9b32a42010a80008  10.128.15.193   us-central1/backendServices/aae3e263abe0911e9b32a42010a80008

연결된 백엔드 서비스(이 예시의 경우 ae3e263abe0911e9b32a42010a80008)가 출력에 표시됩니다.

백엔드 서비스를 설명합니다.

gcloud compute backend-services describe aae3e263abe0911e9b32a42010a80008 --region us-central1

연결된 인스턴스 그룹(이 예시의 경우 k8s-ig--2328fa39f4dc1b75)이 출력에 표시됩니다.

backends:
- balancingMode: CONNECTION
  group: .../us-central1-a/instanceGroups/k8s-ig--2328fa39f4dc1b75
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...

서비스 추상화 작동 방식

전달 규칙으로 처리된 패킷은 클러스터 노드 중 하나로 전달됩니다. 패킷이 클러스터 노드에 도착했을 때 주소와 포트는 다음과 같습니다.

대상 IP 주소 이 예시의 전달 규칙 10.128.15.193
대상 TCP 포트 서비스 port 필드(이 예시의 경우 80)

전달 규칙, 즉 내부 부하 분산기는 대상 IP 주소나 대상 포트를 변경하지 않습니다. 대신 클러스터 노드의 iptables 규칙이 패킷을 적절한 Pod로 라우팅합니다. iptables 규칙은 대상 IP 주소를 Pod IP 주소로, 대상 포트를 서비스의 targetPort 값(이 예시의 경우 8080)으로 변경합니다.

내부 TCP 부하 분산기 확인

SSH를 통해 VM 인스턴스에 연결하고 다음 명령어를 실행합니다.

curl load-balancer-ip

여기서 load-balancer-ipLoadBalancer Ingress IP 주소입니다.

응답에 hello-app 출력이 표시됩니다.

Hello, world!
Version: 2.0.0
Hostname: hello-app-77b45987f7-pw54n

동일한 VPC 네트워크 외부 또는 동일한 리전 외부에서 명령어를 실행하면 타임아웃 오류가 발생합니다. 전역 액세스를 구성하면 동일한 VPC 네트워크의 모든 리전에 있는 클라이언트가 부하 분산기에 액세스할 수 있습니다.

삭제

kubectl delete 또는 Cloud Console을 사용하여 Deployment와 Service를 삭제할 수 있습니다.

kubectl

배포 삭제

배포를 삭제하려면 다음 명령어를 실행합니다.

kubectl delete deployment hello-app

서비스 삭제

서비스를 삭제하려면 다음 명령어를 실행합니다.

kubectl delete service ilb-service

콘솔

배포 삭제

Deployment를 삭제하려면 다음 단계를 수행하세요.

  1. Cloud Console에서 Google Kubernetes Engine 워크로드 메뉴로 이동합니다.

    워크로드 메뉴로 이동

  2. 메뉴에서 원하는 워크로드를 선택합니다.

  3. 삭제를 클릭합니다.

  4. 확인 대화상자 메뉴에서 삭제를 클릭합니다.

서비스 삭제

Service를 삭제하려면 다음 단계를 수행하세요.

  1. Cloud Console에서 Google Kubernetes Engine 서비스 메뉴로 이동합니다.

    서비스 메뉴로 이동

  2. 메뉴에서 원하는 서비스를 선택합니다.

  3. 삭제를 클릭합니다.

  4. 확인 대화상자 메뉴에서 삭제를 클릭합니다.

기존 Ingress 고려사항

내부 TCP/UDP 부하 분산기와 분산 모드 UTILIZATION을 사용하는 인그레스를 모두 가질 수 없습니다. 인그레스와 내부 TCP/UDP 부하 분산을 모두 사용하려면 인그레스가 분산 모드 RATE를 사용해야 합니다.

클러스터에 Kubernetes 버전 1.7.1 이하로 생성된 기존 인그레스 리소스가 있으면 내부 TCP/UDP 부하 분산기와 호환되지 않습니다. Kubernetes 인그레스 리소스 객체에서 생성된 이전 BackendService 리소스는 분산 모드를 지정하지 않은 상태에서 생성되었습니다. 기본적으로 API에서는 HTTP 부하 분산기에 분산 모드 UTILIZATION이 사용되었습니다. 그러나 내부 TCP/UDP 부하 분산기는 UTILIZATION을 사용하는 다른 부하 분산기가 있는 인스턴스 그룹을 가리킬 수 없습니다.

인그레스 분산 모드 확인

인그레스 분산 모드가 실행되고 있는지 확인하려면 셸 또는 터미널 창에서 다음 명령어를 실행합니다.

GROUPNAME=`kubectl get configmaps ingress-uid -o jsonpath='k8s-ig--{.data.uid}' --namespace=kube-system`
gcloud compute backend-services list --format="table(name,backends[].balancingMode,backends[].group)" | grep $GROUPNAME

이러한 명령어는 클러스터의 인스턴스 그룹 이름을 가져오는 셸 변수 GROUPNAME을 내보냅니다. 그러면 프로젝트의 Compute Engine backend service 리소스가 폴링되고 $GROUPNAME 콘텐츠를 기준으로 결과 범위가 좁아집니다.

출력은 다음과 비슷합니다.

k8s-be-31210--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...
k8s-be-32125--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...

출력에서 RATE 항목 또는 0개 항목이 반환되면 내부 부하 분산기가 호환되므로 추가 작업이 필요하지 않습니다.

출력에 UTILIZATION으로 표시된 항목이 반환되면 인그레스가 호환되지 않습니다.

인그레스 리소스가 내부 TCP/UDP 부하 분산기와 호환되도록 업데이트하려면 Kubernetes 버전 1.7.2 이상을 실행하는 새 클러스터를 만든 후 서비스를 이 클러스터로 마이그레이션하면 됩니다.

서비스 매개변수

GKE 내부 LoadBalancer 서비스에는 다음 매개변수가 지원됩니다.

기능 요약 서비스 필드 GKE 버전 지원
로컬 외부 트래픽 정책 외부 트래픽이 GKE 노드에 부하 분산되는지 여부를 구성합니다. spec:externalTrafficPolicy:Local GKE 1.14 이상
부하 분산기 소스 범위 GKE 및 VPC에서 특정 소스 범위만 허용하도록 선택적 방화벽 규칙을 구성합니다. spec:loadBalancerSourceRanges 지원되는 모든 버전
부하 분산기 IP 부하 분산기의 IP를 지정합니다. spec:loadBalancerIP 지원되는 모든 버전
부하 분산기 서브넷 부하 분산기가 자동으로 IP를 프로비저닝해야 하는 서브넷을 지정합니다. metadata:annotations: networking.gke.io/internal-load-balancer-subnet GKE 1.17 이상 및 1.16.8-gke.10 이상에서 베타
전역 액세스 GCP 리전에서 클라이언트가 TCP/UDP 부하 분산기 VIP에 액세스할 수 있도록 허용합니다. metadata:annotations: networking.gke.io/internal-load-balancer-allow-global-access GKE 1.16 이상의 베타 버전
GKE 1.17.9-gke.600 이상의 일반 안정화 버전
All-ports TCP/UDP 부하 분산기가 특정 포트 대신 모든 포트를 전달하는 기능입니다. 해당 없음 기본 지원 없음

외부 트래픽 정책

externalTrafficPolicy는 GKE 노드로 들어오는 트래픽이 부하 분산되는지 여부와 그 방법을 정의하는 표준 서비스 옵션입니다. Cluster는 기본 정책이지만 Local은 클러스터 노드로 들어오는 트래픽의 소스 IP를 보존하는 데 자주 사용됩니다. Local은 클러스터 노드에서 부하 분산을 효과적으로 사용 중지하여 로컬 Pod가 수신하는 트래픽에 원래 소스 주소가 표시되도록 합니다.

externalTrafficPolicy는 내부 LoadBalancer 서비스(TCP/UDP 부하 분산기 사용)에서 지원되지만 부하 분산 동작은 트래픽이 발생하는 위치와 구성된 트래픽 정책에 따라 다릅니다.

클러스터 외부 소스에서 TCP/UDP 부하 분산기로 오는 트래픽의 경우 클러스터에 정상 서비스 Pod가 하나 이상 있으면 다음과 같은 동작이 발생합니다.

  • Cluster 정책: 트래픽이 클러스터의 정상 GKE 노드로 부하 분산된 다음 kube-proxy가 트래픽을 Pod가 있는 노드로 전송합니다.
  • Local 정책: 백엔드 Pod 중 하나가 없는 노드는 TCP/UDP 부하 분산기에 비정상으로 표시됩니다. 트래픽은 Pod가 있는 나머지 정상 클러스터 노드 중 하나로만 전송됩니다. 트래픽은 kube-proxy에 의해 다시 라우팅되지 않고 대신 IP 헤더 정보가 그대로 있는 로컬 Pod로 직접 전송됩니다.

지정된 LoadBalancer 서비스 IP로 오는 트래픽의 소스가 클러스터 내의 GKE 노드인 경우 트래픽 동작이 다릅니다. 다음 표에는 클러스터 내의 노드 또는 Pod가 소스이고 LoadBalancer 서비스의 구성원 Pod로 가는 트래픽의 트래픽 동작이 요약되어 있습니다.

externalTrafficPolicy 트래픽이 발생하는 노드와 동일한 노드에서 실행되는 서비스 구성원 Pod인가? 트래픽 동작
클러스터 패킷이 노드 또는 다른 노드의 모든 구성원 Pod로 전달됩니다.
클러스터 아니요 패킷이 다른 노드에 있는 모든 구성원 Pod로 전달됩니다.
로컬 패킷이 동일한 노드의 모든 구성원 Pod로 전달됩니다.
로컬 아니요

Kubernetes 1.14 및 이전 버전: 패킷이 삭제됩니다.

Kubernetes 1.15 이상: 패킷이 다른 노드에 있는 구성원 Pod로 전달됩니다.

부하 분산기 소스 범위

spec: loadBalancerSourceRanges 배열은 하나 이상의 내부 IP 주소 범위를 지정합니다. loadBalancerSourceRanges는 부하 분산기를 통해 이 필드에서 지정된 IP로 트래픽을 제한합니다. 이 구성을 사용하면 kube-proxy는 Kubernetes 노드에서 해당 iptables 규칙을 만듭니다. 또한 GKE는 VPC 네트워크에 자동으로 방화벽 규칙을 생성합니다. 이 필드를 생략하면 서비스에서 모든 IP 주소(0.0.0.0/0)의 트래픽을 허용합니다.

서비스 사양에 대한 자세한 내용은 서비스 API 참조를 확인하세요.

부하 분산기 IP

spec: loadBalancerIP를 사용하면 부하 분산기의 특정 IP 주소를 선택할 수 있습니다. IP 주소는 다른 내부 TCP/UDP 부하 분산기 또는 서비스에서 사용되지 않아야 합니다. 생략되면 임시 IP가 할당됩니다. 자세한 내용은 고정 내부 IP 주소 예약을 참조하세요.

부하 분산기 서브넷(베타)

기본적으로 GKE는 노드 서브넷 범위를 사용하여 내부 TCP/UDP 부하 분산기를 배포합니다. 서브넷은 networking.gke.io/internal-load-balancer-subnet 주석을 사용하여 서비스별로 사용자가 지정할 수 있습니다. 이는 노드 IP에서 내부 부하 분산기 IP를 별도로 방화벽 설정하거나 여러 GKE 클러스터에서 동일한 서비스 서브넷을 공유하는 데 유용합니다. 이 매개변수는 내부 TCP/UDP LoadBalancer 서비스에만 관련됩니다.

GKE가 서브넷 자체의 수명 주기를 관리하지 않으므로 서비스 리소스에서 참조하기 전에 서브넷이 있어야 합니다. 서브넷은 GKE 클러스터와 동일한 VPC 및 리전에 있어야 합니다. 이 단계에서는 GKE에서 대역 외로 생성됩니다.

gcloud compute networks subnets create gke-vip-subnet \
    --network=default \
    --range=10.23.0.0/24 \
    --region=us-central1

다음 서비스 정의는 internal-load-balancer-subnet을 사용하여 이름으로 서브넷을 참조합니다. 기본적으로 서브넷에서 사용 가능한 IP가 자동으로 선택됩니다. loadBalancerIP를 지정할 수도 있지만 참조된 서브넷의 일부여야 합니다.

이 내부 부하 분산기 서브넷을 공유하여 다양한 사용 사례를 달성하는 방법에는 여러 가지가 있습니다.

  • 동일한 클러스터의 서비스 그룹에 여러 서브넷
  • 클러스터의 모든 서비스에 단일 서브넷
  • 여러 클러스터 및 여러 서비스에서 공유되는 단일 서브넷
apiVersion: v1
kind: Service
metadata:
  name: ilb-service
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
    networking.gke.io/internal-load-balancer-subnet: "gke-vip-subnet"
  labels:
    app: hello
spec:
  type: LoadBalancer
  loadBalancerIP: 10.23.0.15
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

전역 액세스

전역 액세스는 VPC 네트워크의 모든 리전 클라이언트가 내부 TCP/UDP 부하 분산기에 액세스할 수 있도록 허용하는 내부 LoadBalancer 서비스의 선택적 매개변수입니다. 전역 액세스가 없으면 VPC 네트워크의 클라이언트에서 발생하는 트래픽이 부하 분산기와 동일한 리전에 있어야 합니다. 전역 액세스는 모든 리전의 클라이언트가 부하 분산기에 액세스하도록 허용합니다. 그래도 백엔드 인스턴스는 부하 분산기와 동일한 리전에 있어야 합니다.

전역 액세스는 networking.gke.io/internal-load-balancer-allow-global-access: "true" 주석을 사용하여 서비스별로 사용 설정됩니다.

기존 네트워크에서는 전역 액세스가 지원되지 않습니다. 리전 간에 전역 액세스를 사용할 때는 일반 리전 간 트래픽 비용이 적용됩니다. 리전 간 이그레스의 네트워크 가격 책정에 대한 자세한 내용은 네트워크 가격 책정을 참조하세요. 전역 액세스는 GKE 클러스터 1.16 이상의 베타 버전과 1.17.9-gke.600 이상의 일반 안정화 버전에서 제공됩니다.

공유 IP(베타)

내부 TCP/UDP 부하 분산기는 여러 전달 규칙 간에 가상 IP 주소를 공유할 수 있습니다. 이는 동일한 IP에서 동시 포트 수를 확장하거나 동일한 IP에서 UDP 트래픽과 TCP 트래픽을 허용하는 데 유용합니다. IP 주소당 노출된 포트를 최대 50개까지 허용합니다. 공유 IP는 기본적으로 GKE 클러스터에서 내부 LoadBalancer 서비스를 통해 지원됩니다. 배포 시 서비스의 loadBalancerIP 필드는 서비스 간에 공유되어야 하는 IP를 나타내는 데 사용됩니다.

제한사항

여러 부하 분산기의 공유 IP에는 다음 제한사항과 기능이 있습니다.

  • 각 서비스(또는 전달 규칙)는 포트를 최대 5개까지 포함할 수 있습니다.
  • 서비스(전달 규칙) 최대 10개에서 IP 주소 하나를 공유할 수 있습니다. 따라서 포트는 공유 IP당 최대 50개까지 사용됩니다.
  • 프로토콜/포트 튜플은 동일한 IP를 공유하는 서비스 간에 겹칠 수 없습니다.
  • 동일한 공유 IP에서 TCP 전용 서비스와 UDP 전용 서비스를 조합할 수 있지만 동일한 서비스에서 TCP 포트와 UDP 포트를 모두 노출할 수 없습니다.

공유 IP 사용 설정

내부 LoadBalancer 서비스에서 공통 IP를 공유하려면 다음 단계를 따르세요.

  1. --purpose SHARED_LOADBALANCER_VIP로 고정 내부 IP를 만듭니다. IP 주소를 공유하려면 이 용도로 IP 주소를 만들어야 합니다.

  2. loadBalancerIP 필드에 이 고정 IP를 사용하여 내부 LoadBalancer 서비스를 최대 10개까지 배포합니다. 내부 TCP/UDP 부하 분산기는 GKE 서비스 컨트롤러에서 조정되고 동일한 프런트엔드 IP를 통해 배포됩니다.

다음 예시에서는 동일한 내부 부하 분산기 IP에 대해 여러 TCP 포트와 UDP 포트를 지원하기 위해 이를 수행하는 방법을 보여줍니다.

  1. GKE 클러스터와 동일한 리전에 고정 IP를 만듭니다. 서브넷은 부하 분산기가 사용하는 서브넷과 동일해야 하며, 이는 기본적으로 GKE 클러스터 노드 IP에서 사용하는 서브넷입니다.

    gcloud beta compute addresses create internal-10-128-2-98 \
        --region=us-central1 \
        --subnet=default \
        --addresses=10.128.2.98 \
        --purpose=SHARED_LOADBALANCER_VIP
    
  2. 다음 TCP 서비스 구성을 tcp-service.yaml이라는 파일에 저장한 후 클러스터에 배포합니다. 여기서는 공유 IP 10.128.2.98을 사용합니다.

    apiVersion: v1
    kind: Service
    metadata:
      name: tcp-service
      namespace: default
      annotations:
        cloud.google.com/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      loadBalancerIP: 10.128.2.98
      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
    
  3. 이 서비스 정의를 클러스터에 적용합니다.

    kubectl apply -f tcp-service.yaml
    
  4. 다음 UDP 서비스 구성을 udp-service.yaml이라는 파일에 저장한 후 배포합니다. 여기서도 공유 IP 10.128.2.98을 사용합니다.

    apiVersion: v1
    kind: Service
    metadata:
      name: udp-service
      namespace: default
      annotations:
        cloud.google.com/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      loadBalancerIP: 10.128.2.98
      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
    
  5. 이 파일을 클러스터에 적용합니다.

    kubectl apply -f udp-service.yaml
    
  6. LB 전달 규칙을 나열하고 고정 IP를 필터링하여 이들 규칙에서 VIP가 공유되는지 확인합니다. 그러면 공유 IP 주소 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
    

All-ports

주석이 있는 서비스를 사용하여 내부 TCP/UDP 부하 분산기를 만드는 경우 모든 포트를 사용하는 전달 규칙을 설정할 방법이 없습니다. 그러나 수동으로 내부 TCP/UDP 부하 분산기를 만드는 경우에는 Google Kubernetes Engine 노드의 인스턴스 그룹을 백엔드로 선택할 수 있습니다. ILB를 통해 type: NodePort 서비스를 사용할 수 있습니다.

내부 TCP/UDP 부하 분산기 제한사항

  • Kubernetes 버전 1.7.3 이하를 실행하는 클러스터의 경우 자동 모드 서브넷에만 내부 TCP/UDP 부하 분산기를 사용할 수 있지만 Kubernetes 버전 1.7.4 이상에서는 자동 모드 서브넷 외에 커스텀 모드 서브넷에도 내부 부하 분산기를 사용할 수 있습니다.
  • Kupernetes 1.7.X 이상을 실행하는 클러스터의 경우 clusterIP는 변경되지 않지만 내부 TCP/UDP 부하 분산기는 예약된 IP 주소를 사용할 수 없습니다. spec.loadBalancerIP 필드는 여전히 사용되지 않은 IP 주소로 정의하여 특정 내부 IP를 할당할 수 있습니다. 포트, 프로토콜 또는 세션 어피니티를 변경하면 IP 주소가 변경될 수 있습니다.

내부 UDP 부하 분산기 제한사항

  • 내부 UDP 부하 분산기에서는 sessionAffinity: ClientIP를 사용할 수 없습니다.

한도

type: Loadbalancercloud.google.com/load-balancer-type: Internal 주석이 있는 Kubernetes 서비스는 Kubernetes 서비스를 대상으로 하는 ILB를 만듭니다. 이러한 서비스의 수는 VPC 네트워크에서 만들 수 있는 내부 전달 규칙의 수에 따라 제한됩니다. 자세한 내용은 네트워크별 한도를 참조하세요.

GKE 클러스터에서 내부 전달 규칙은 클러스터의 모든 노드를 가리킵니다. 클러스터의 각 노드는 ILB의 백엔드 VM입니다. ILB의 최대 백엔드 VM 수는 VM과 인스턴스 그룹의 연결 방식에 관계없이 250개입니다. 따라서 ILB가 있는 GKE 클러스터의 최대 노드 수는 250개입니다. 클러스터에 자동 확장이 사용 설정된 경우 자동 확장으로 인해 클러스터가 250개 노드를 초과해서 확장되지 않도록 해야 합니다.

이러한 한도에 대한 자세한 내용은 VPC 리소스 할당량을 참조하세요.

다음 단계