수동 Envoy 삽입으로 Google Kubernetes Engine pod용 Traffic Director 설정

이 가이드에서는 Google Kubernetes Engine 또는 Kubernetes pod 호스트와 Traffic Director에 필요한 부하 분산 구성요소를 구성하는 방법을 보여줍니다.

이 가이드의 안내를 따르기 전에 Traffic Director 설정 준비를 검토하고 기본 요건을 완료했는지 확인하세요.

Compute Engine 부하 분산 SDK 또는 REST API를 사용하여 Traffic Director를 구성할 수 있습니다. 부하 분산 API 및 gcloud 참조를 확인하세요.

Traffic Director용 GKE/Kubernetes 클러스터 구성

이 섹션에서는 Traffic Director와 연동하도록 GKE/Kubernetes 클러스터를 사용 설정하는 데 필요한 단계를 설명합니다.

GKE 클러스터 만들기

GKE 클러스터는 다음과 같은 요구사항을 충족해야 합니다.

  • 네트워크 엔드포인트 그룹 지원을 사용 설정해야 합니다. 자세한 내용과 예시는 독립형 네트워크 엔드포인트 그룹을 참조하세요. 독립형 NEG 기능은 Traffic Director의 일반 안정화 버전으로 제공됩니다.
  • 클러스터 노드 인스턴스의 서비스 계정에 Traffic Director API에 액세스할 권한이 있어야 합니다. 필요한 권한에 대한 자세한 내용은 서비스 계정에 Traffic Director API 액세스 권한 부여를 참조하세요.
  • 컨테이너는 OAuth 인증으로 보호되는 Traffic Director API에 액세스할 수 있어야 합니다. 자세한 내용은 호스트 구성을 참조하세요.

다음 예시에서는 us-central1-a 영역에 traffic-director-cluster라는 GKE 클러스터를 만드는 방법을 보여줍니다.

Console

Cloud Console을 사용하여 클러스터를 만들려면 다음 단계를 수행하세요.

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

    Google Kubernetes Engine 메뉴로 이동

  2. 클러스터 만들기를 클릭합니다.

  3. 다음 필드를 작성하세요.

    • 이름: traffic-director-cluster를 입력합니다.
    • 위치 유형: Zonal
    • 영역: us-central1-a
  4. 탐색창의 노드 풀에서 default-pool을 클릭합니다.

  5. 크기 필드에는 클러스터에서 만들 노드 수가 표시됩니다. 노드 및 해당 리소스(예: 방화벽 경로)에 사용 가능한 리소스 할당량이 있어야 합니다.

  6. 탐색창의 default-pool에서 노드를 클릭합니다.

  7. 머신 유형 필드에는 인스턴스에 사용할 Compute Engine 머신 유형이 표시됩니다. 요금은 머신 유형마다 다르게 청구됩니다. 머신 유형별 가격 정보는 Compute Engine 가격 책정 페이지를 참조하세요.

  8. 탐색창의 default-pool에서 보안을 클릭합니다.

  9. 액세스 범위에서 모든 Cloud APIs에 대해 전체 액세스 허용을 클릭합니다.

  10. 필요에 따라 클러스터를 맞춤설정합니다.

  11. 만들기를 클릭합니다.

Cloud Console에서 클러스터를 만든 후 클러스터와 상호작용하려면 kubectl을 구성해야 합니다. 자세한 내용은 kubeconfig 항목 생성을 참조하세요.

gcloud

gcloud container clusters create traffic-director-cluster \
  --zone us-central1-a \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

필수 GKE 클러스터 권한 가져오기

GKE의 경우 다음 명령어를 실행하여 방금 만든 클러스터(2)로 전환합니다. 그러면 kubectl이 올바른 클러스터를 가리킵니다.

gcloud container clusters get-credentials traffic-director-cluster \
    --zone us-central1-a

GKE/Kubernetes 서비스 구성

이 섹션에서는 Traffic Director와 연동하도록 Kubernetes 배포 사양을 준비하는 방법을 보여줍니다. 이는 NEG로 서비스를 구성하고 Traffic Director에서 관리하는 서비스에 액세스해야 하는 pod에 사이드카 프록시를 삽입하는 것으로 구성됩니다.

방화벽 규칙 구성

백엔드 pod가 실행 중인지 확인하려면 상태 검사기 IP 주소 범위를 허용하는 방화벽 규칙을 구성해야 합니다.

Console

  1. Google Cloud Console의 방화벽 페이지로 이동합니다.
    방화벽 페이지로 이동
  2. 방화벽 규칙 만들기를 클릭합니다.
  3. 방화벽 규칙 만들기 페이지에서 다음 정보를 입력합니다.
    • 이름: 규칙의 이름을 입력합니다. 이 예시에서는 fw-allow-health-checks를 사용합니다.
    • 네트워크: VPC 네트워크를 선택합니다.
    • 우선순위: 우선순위의 번호를 입력합니다. 숫자가 낮을수록 우선순위가 높습니다. 방화벽 규칙이 인그레스 트래픽을 거부할 수 있는 다른 규칙보다 높은 우선 순위를 갖도록 해야 합니다.
    • 트래픽 방향: 인그레스를 선택합니다.
    • 일치 시 작업: 허용을 선택합니다.
    • 대상: 네트워크의 모든 인스턴스를 선택합니다.
    • 소스 필터: IP 범위를 선택합니다.
    • 소스 IP 범위: 35.191.0.0/16,130.211.0.0/22
    • 허용되는 프로토콜 및 포트: tcp을 사용합니다. TCP는 모든 상태 확인 프로토콜의 기본 프로토콜입니다.
    • 만들기를 클릭합니다.

gcloud

  1. 다음 gcloud 명령어를 사용하여 allow-health-checks 태그로 네트워크에서 인스턴스에 대한 수신 연결을 허용하는 fw-allow-health-checks라는 이름의 방화벽 규칙을 만듭니다. NETWORK_NAME을 네트워크 이름으로 바꿉니다.

    gcloud compute firewall-rules create fw-allow-health-checks \
        --network NETWORK_NAME \
        --action ALLOW \
        --direction INGRESS \
        --source-ranges 35.191.0.0/16,130.211.0.0/22 \
        --rules tcp

자세한 내용은 상태 확인에 대한 방화벽 규칙 구성을 참조하세요.

NEG로 GKE / Kubernetes 서비스 구성

NEG로 GKE/Kubernetes 서비스를 구성하는 첫 번째 단계는 Traffic Director에서 관리해야 하는 서비스를 노출하는 것입니다. NEG를 통해 노출하려면 각 사양에 노출할 포트와 일치하는 다음 주석이 있어야 합니다.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"80":{}}}'

각 서비스에 독립형 NEG가 생성됩니다. 여기에 포함되는 엔드포인트는 pod의 IP 주소와 포트입니다. 자세한 내용과 예시는 독립형 네트워크 엔드포인트 그룹을 참조하세요.

데모용으로 80 포트에서 HTTP를 통해 호스트 이름을 제공하는 샘플 서비스를 배포해 보겠습니다.

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \
| kubectl apply -f -

새 서비스 호스트 이름이 생성되었고 애플리케이션 pod가 실행 중인지 확인합니다.

kubectl get svc

이는 다음을 반환합니다.

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-test     ClusterIP   10.71.9.71   none          80/TCP    41m
[..skip..]

kubectl get pods

이는 다음을 반환합니다.

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       1/1       Running   0          6m
[..skip..]

NEG 이름 기록

위 예시에서 생성된 NEG를 찾아서 NEG의 이름을 기록합니다.

콘솔

네트워크 엔드포인트 그룹의 목록을 보려면 Google Cloud Console의 네트워크 엔드포인트 그룹 페이지로 이동하세요.
네트워크 엔드포인트 그룹 페이지로 이동

gcloud

gcloud beta compute network-endpoint-groups list

이는 다음을 반환합니다.

NAME                                           LOCATION       ENDPOINT_TYPE   SIZE
k8s1-7e91271e-default-service-test-80-a652810c  us-central1-a  GCE_VM_IP_PORT  1

NEG 이름을 NEG_NAME 변수에 저장합니다. 예를 들면 다음과 같습니다.

NEG_NAME=$(gcloud beta compute network-endpoint-groups list \
| grep service-test | awk '{print $1}')

Traffic Director용 Google Cloud 부하 분산 구성요소 구성

이 섹션의 안내는 다른 Google Cloud Load Balancing 제품과 유사한 부하 분산 구성을 사용하여 Traffic Director에서 서비스 VIP 부하 분산을 통해 GKE 서비스에 액세스할 수 있도록 합니다.

다음 구성요소를 구성해야 합니다.

다음 Traffic Director 구성 예시에서는 다음과 같이 가정합니다.

  1. NEG 및 다른 모든 리소스는 us-central1-a 영역의 default 네트워크에서 자동 모드로 생성됩니다.
  2. 클러스터의 NEG 이름은 ${NEG_NAME} 변수에 저장됩니다.

상태 확인 만들기

상태 확인을 만듭니다.

Console

  1. Google Cloud Console의 상태 확인 페이지로 이동합니다.
    상태 확인 페이지로 이동
  2. 상태 확인 생성을 클릭합니다.
  3. 이름에 td-gke-health-check를 입력합니다.
  4. 프로토콜에서 HTTP를 선택합니다.
  5. 만들기를 클릭합니다.

gcloud

gcloud compute health-checks create http td-gke-health-check \
  --use-serving-port

백엔드 서비스 만들기

부하 분산 스키마가 INTERNAL_SELF_MANAGED인 글로벌 백엔드 서비스를 만듭니다. Cloud Console에서 부하 분산 스키마는 암시적으로 설정됩니다. 백엔드 서비스에 상태 확인을 추가합니다.

Console

  1. Cloud Console에서 Traffic Director 페이지로 이동합니다.

    Traffic Director 페이지로 이동

  2. 서비스 탭에서 서비스 만들기를 클릭합니다.

  3. 계속을 클릭합니다.

  4. 서비스 이름으로 td-gke-service를 입력합니다.

  5. 백엔드 유형네트워크 엔드포인트 그룹을 선택합니다.

  6. 생성한 네트워크 엔드포인트 그룹을 선택합니다.

  7. 최대 RPS5로 설정합니다.

  8. 완료를 클릭합니다.

  9. 상태 확인에서 앞에서 생성한 상태 확인 td-gke-health-check을 선택합니다.

  10. 계속을 클릭합니다.

gcloud

  1. 백엔드 서비스를 만들고 상태 확인을 백엔드 서비스에 연결합니다.

    gcloud compute backend-services create td-gke-service \
     --global \
     --health-checks td-gke-health-check \
     --load-balancing-scheme INTERNAL_SELF_MANAGED
    
  2. 백엔드 서비스에 백엔드 NEG를 추가합니다.

    gcloud compute backend-services add-backend td-gke-service \
     --global \
     --network-endpoint-group ${NEG_NAME} \
     --network-endpoint-group-zone us-central1-a \
     --balancing-mode RATE \
     --max-rate-per-endpoint 5
    

라우팅 규칙 맵 만들기

다음 안내에 따라 Traffic Director 구성을 위한 라우팅 규칙, 전달 규칙, 내부 IP 주소를 만듭니다.

내부 IP 주소로 전송되는 트래픽은 Envoy 프록시에 의해 가로채기를 당하고 호스트 및 경로 규칙에 따라 적절한 서비스로 전송됩니다.

전달 규칙은 load-balancing-schemeINTERNAL_SELF_MANAGED로 설정된 글로벌 전달 규칙으로 생성됩니다.

전달 규칙의 주소를 0.0.0.0으로 설정할 수 있습니다. 그러면 호스트 이름이 확인하는 실제 IP 주소와 관계없이 URL 맵에 구성된 HTTP 호스트 이름 및 경로 정보를 기반으로 트래픽이 라우팅됩니다. 이 경우 호스트 규칙에 구성된 서비스의 URL(호스트 이름 및 URL 경로)이 서비스 메시 구성 내에서 고유해야 합니다. 즉, 동일한 호스트 이름과 경로 조합을 사용하는 서로 다른 백엔드 집합은 서로 다른 두 개의 서비스를 가질 수 없습니다.

또는, 서비스의 실제 대상 VIP를 기반으로 라우팅을 사용 설정할 수 있습니다. 서비스의 VIP를 전달 규칙의 address 매개변수로 구성하면 이 주소로 전송되는 요청만 URL 맵에 지정된 HTTP 매개변수를 기반으로 라우팅됩니다.

Console

Console에서 대상 프록시는 전달 규칙과 결합됩니다. 전달 규칙을 만들면 Google Cloud가 자동으로 대상 HTTP 프록시를 만들어 URL 맵에 연결합니다.

라우팅 규칙은 전달 규칙과 호스트 및 경로 규칙(URL 맵이라고도 함)으로 구성됩니다.

  1. Cloud Console에서 Traffic Director 페이지로 이동합니다.

    Traffic Director 페이지로 이동

  2. 라우팅 규칙 맵을 클릭합니다.

  3. 라우팅 규칙 만들기를 클릭합니다.

  4. URL 맵의 이름으로 td-gke-url-map을 입력합니다.

  5. 전달 규칙 추가를 클릭합니다.

  6. 전달 규칙 이름으로 td-gke-forwarding-rule을 입력합니다.

  7. 네트워크를 선택합니다.

  8. 내부 IP를 선택합니다.

  9. 저장을 클릭합니다.

  10. 원하는 경우 커스텀 호스트 및 경로 규칙을 추가하거나 경로 규칙을 기본값으로 그대로 둡니다.

  11. 호스트를 service-test로 설정합니다.

  12. 저장을 클릭합니다.

gcloud

  1. 백엔드 서비스를 사용하는 URL 맵을 만듭니다.

    gcloud compute url-maps create td-gke-url-map \
       --default-service td-gke-service
    
  2. URL 맵 경로 일치자와 호스트 규칙을 만들어 호스트 이름과 경로를 기반으로 서비스 트래픽을 라우팅합니다. 이 예시에서는 service-test를 서비스 이름으로 사용하고 이 호스트(/*)의 모든 경로 요청과 일치하는 기본 경로 일치자를 사용합니다. service-test는 위의 샘플 구성에 사용되는 Kubernetes 서비스의 구성 이름이기도 합니다.

    gcloud compute url-maps add-path-matcher td-gke-url-map \
       --default-service td-gke-service \
       --path-matcher-name td-gke-path-matcher
    
    gcloud compute url-maps add-host-rule td-gke-url-map \
       --hosts service-test \
       --path-matcher-name td-gke-path-matcher
    
  3. 대상 HTTP 프록시를 만듭니다.

    gcloud compute target-http-proxies create td-gke-proxy \
       --url-map td-gke-url-map
    
  4. 전달 규칙을 만듭니다.

    gcloud compute forwarding-rules create td-gke-forwarding-rule \
      --global \
      --load-balancing-scheme=INTERNAL_SELF_MANAGED \
      --address=0.0.0.0 \
      --target-http-proxy=td-gke-proxy \
      --ports 80 --network default
    

이 시점에서 Traffic Director는 네트워크 엔드포인트 그룹의 백엔드에서 URL 맵에 지정된 서비스의 트래픽을 부하 분산하도록 구성됩니다.

마이크로서비스가 네트워크에 분산되는 방식에 따라 더 많은 전달 규칙이나 호스트 및 경로 규칙을 URL 맵에 추가해야 할 수 있습니다.

테스트용 샘플 클라이언트를 배포하여 구성 확인

이 섹션에서는 클라이언트 애플리케이션이 Traffic Director 백엔드에 연결되는 방법을 보여줍니다.

기능 예시를 위해 Busybox를 실행하는 샘플 pod를 배포해 볼 수 있습니다. pod는 이전 섹션에서 생성되고 Traffic Director에 의해 부하 분산된 트래픽을 수신하는 service-test에 액세스할 수 있습니다.

GKE / Kubernetes pod에 사이드카 프록시 삽입

Traffic Director에서 관리하는 서비스에 액세스하려면 pod에 xDS API 호환 사이드카 프록시가 설치되어 있어야 합니다.

이 예시에서는 참조 사양을 사용하여 Istio-proxy 사이드카 및 배포에 초기화 컨테이너가 추가된 Busybox 클라이언트를 배포합니다.

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_sample.yaml \
| kubectl apply -f -

Busybox pod에는 실행 중인 컨테이너가 두 개입니다. 첫 번째 컨테이너는 Busybox 이미지를 기반으로 하는 클라이언트이고 두 번째 컨테이너는 사이드카로 삽입된 Envoy 프록시입니다. 다음 명령어를 실행하여 pod에 대한 자세한 정보를 얻을 수 있습니다.

kubectl describe pods -l run=client

백엔드 서비스 도달

구성이 완료되면 사이드카 프록시가 삽입된 pod의 애플리케이션이 Traffic Director 서비스에서 관리하는 서비스에 액세스할 수 있습니다. 구성을 확인하기 위해 컨테이너 중 하나에서 셸에 액세스할 수 있습니다.

이 가이드에 제공된 데모 구성을 사용한 경우 다음 확인 명령어를 실행하면 제공 pod의 호스트 이름이 반환되는지 확인할 수 있습니다.

# Get name of the pod with busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

사이드카 프록시에 의한 트래픽 가로채기 이해

이 예시에서 Busybox 클라이언트가 백엔드 서비스에 요청을 수행하면 각 요청이 사이드카 프록시에 의해 프록시됩니다.

이 데모 애플리케이션은 Envoy 프록시를 사용하므로 클라이언트의 서버 응답 헤더에 'server: envoy'가 표시됩니다.

이를 확인하려면 다음 명령어를 사용합니다.

# Get the name of the pod with Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to send a request to service-test and output server response headers.
TEST_CMD="wget -S --spider service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

이 예시에서는 VIP 주소 0.0.0.0을 사용하여 전달 규칙을 만들었습니다. 즉, Traffic Director가 Host 헤더만을 기반으로 요청을 백엔드로 전달합니다. 이 경우 요청 호스트 헤더가 URL 맵 service-test에 정의된 호스트와 일치하는 경우 대상 IP 주소가 모든 주소가 될 수 있습니다.

확인하려면 다음 테스트 명령어를 실행합니다.

# Get name of the pod with Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to send a request to service-test setting the Host header and using a random IP address.
TEST_CMD="wget -q --header 'Host: service-test' -O - 1.2.3.4; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"