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

개요

서비스 메시에서는 애플리케이션 코드가 네트워킹 구성에 대해 알 필요가 없습니다. 대신 애플리케이션은 서비스 네트워킹을 처리하는 제어 영역에 의해 구성된 데이터 영역을 통해 통신합니다. 이 가이드에서 Traffic Director는 제어 영역이고 Envoy 사이드카 프록시는 데이터 영역입니다.

Envoy 사이드카 인젝터를 사용하면 Google Kubernetes Engine pod에 Envoy 사이드카 프록시를 쉽게 추가할 수 있습니다. Envoy 사이드카 인젝터가 프록시를 추가할 때 애플리케이션 트래픽을 처리하고 구성을 위해 Traffic Director에 연결하도록 해당 프록시를 설정합니다.

이 가이드에서는 Google Kubernetes Engine으로 Traffic Director를 간단하게 설정하는 과정을 안내합니다. 다음 단계는 여러 Google Kubernetes Engine 클러스터(경우에 따라 Compute Engine VM)로 확장하는 서비스 메시와 같이 고급 사용 사례로 확장할 수 있는 기반을 제공합니다.

설정 프로세스는 다음과 같습니다.

  1. 워크로드를 위한 GKE 클러스터 만들기
  2. Envoy 사이드카 인젝터 설치 및 삽입 사용 설정
  3. 샘플 클라이언트 배포 및 삽입 확인
  4. 테스트용 Kubernetes 서비스 배포
  5. 테스트 서비스로 트래픽을 라우팅하도록 Cloud Load Balancing 구성요소를 사용하여 Traffic Director 구성
  6. 샘플 클라이언트에서 테스트 서비스로 요청을 전송하여 구성 확인
이 설정 가이드의 일부로 배포된 구성요소의 개요(확대하려면 클릭)
이 설정 가이드의 일부로 배포된 구성요소의 개요(확대하려면 클릭)

기본 요건

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

워크로드를 위한 GKE 클러스터 만들기

GKE 클러스터는 Traffic Director를 지원하려면 다음 요구사항을 충족해야 합니다.

GKE 클러스터 만들기

us-central1-a 영역에 traffic-director-cluster라는 GKE 클러스터를 만듭니다.

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

새로 만든 클러스터를 kubectl로 가리키기

다음 명령어를 실행하여 kubectl의 현재 컨텍스트를 새로 만든 클러스터로 변경합니다.

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

Envoy 사이드카 인젝터 설치

다음 섹션에서는 Envoy 사이드카 인젝터를 설치하는 방법을 설명합니다. 사이드카 인젝터가 사용 설정되면 신규 Google Kubernetes Engine 워크로드와 기존 Google Kubernetes Engine 워크로드 모두에 대해 사이드카 프록시를 자동으로 배포합니다. Envoy 사이드카 인젝터는 GKE 클러스터 내에서 실행되기 때문에 Traffic Director를 사용하여 멀티 클러스터 서비스 메시를 지원하는 경우 각 클러스터에 한 번만 설치해야 합니다.

사이드카 인젝터 다운로드

Envoy 사이드카 인젝터를 다운로드하고 압축을 풉니다.

wget https://storage.googleapis.com/traffic-director/td-sidecar-injector-xdsv3.tgz
tar -xzvf td-sidecar-injector-xdsv3.tgz
cd td-sidecar-injector-xdsv3

사이드카 인젝터 구성

specs/01-configmap.yaml을 수정해 사이드카 인젝터를 구성하여 다음을 수행합니다.

  • YOUR_PROJECT_NUMBER_HERE를 프로젝트의 프로젝트 번호로 바꿔서 TRAFFICDIRECTOR_GCP_PROJECT_NUMBER를 채웁니다. 프로젝트 번호는 프로젝트의 숫자 식별자입니다. 모든 프로젝트 목록을 가져오는 방법에 대한 자세한 내용은 프로젝트 식별을 참조하세요.
  • YOUR_NETWORK_NAME_HERE를 Traffic Director와 함께 사용할 Google Cloud Virtual Private Cloud 네트워크 이름으로 바꿔서 TRAFFICDIRECTOR_NETWORK_NAME을 채웁니다. 이 VPC 네트워크 이름은 나중에 Traffic Director를 구성할 때 필요하므로 기록해 둡니다.

예를 들어 파일이 다음과 같이 표시될 수 있습니다.

$ cat ./td-sidecar-injector-xdsv3/specs/01-configmap.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: injector-mesh
     namespace: istio-control
   data:
     mesh: |-
       defaultConfig:
         discoveryAddress: trafficdirector.googleapis.com:443

         # Envoy proxy port to listen on for the admin interface.
         proxyAdminPort: 15000

         proxyMetadata:
           # GCP Project number where Traffic Director resources are configured.
           # This is a numeric identifier of your project (e.g. "111222333444").
           # You can get a list of all your projects with their corresponding numbers by
           # using "gcloud projects list" command or looking it up under "Project info"
           # section of your GCP console.
           # If left empty, configuration will be attempted to be fetched for the GCP
           # project associated with service credentials.
           # Leaving empty is not recommended as it is not guaranteed to work in future
           # releases.
           TRAFFICDIRECTOR_GCP_PROJECT_NUMBER: "YOUR_PROJECT_NUMBER_HERE"

           # GCP VPC network name for which the configuration is requested (This is the VPC
           # network name referenced in the forwarding rule in GCP API). If left empty,
           # configuration will be attempted to be fetched for the VPC network over which
           # the request to Traffic Director (trafficdirector.googleapis.com) is sent out.
           # Leaving empty is not recommended as it is not guaranteed to work in future
           # releases.
           TRAFFICDIRECTOR_NETWORK_NAME: "YOUR_NETWORK_NAME_HERE"

경우에 따라 자동으로 삽입되는 각 프록시에 대해 로깅 및 추적을 사용 설정할 수도 있습니다. 이러한 구성에 대한 자세한 내용은 사이드카 프록시의 추가 속성 구성을 참조하세요. 사이드카 인젝터를 사용하는 경우 TRAFFICDIRECTOR_ACCESS_LOG_PATH 값은 /etc/istio/proxy/ 디렉터리에 있는 파일로만 설정할 수 있습니다. 예를 들어 /etc/istio/proxy/access.log 디렉터리는 유효한 위치입니다.

TRAFFICDIRECTOR_INTERCEPTION_PORT는 사이드카 인젝터에 이미 구성되어 있으므로 ConfigMap에서 구성할 수 없습니다.

사이드카 인젝터의 TLS 구성

이 섹션에서는 사이드카 인젝터에 TLS를 구성하는 방법을 보여줍니다.

사이드카 인젝터는 Kubernetes 허용 웹훅 변형을 사용하여 새 pod가 생성될 때 프록시를 삽입합니다. 이 웹훅은 HTTPS 엔드포인트이므로 TLS에 사용할 키와 인증서를 제공해야 합니다.

사이드카 인젝터를 보호하기 위해 openssl을 사용하여 비공개 키와 자체 서명 인증서를 만들 수 있습니다.

원하는 경우, 비공개 키와 신뢰할 수 있는 인증 기관(CA)에서 서명한 인증서가 있는 경우 다음 단계를 건너뛸 수 있습니다.

CN=istio-sidecar-injector.istio-control.svc

openssl req \
  -x509 \
  -newkey rsa:4096 \
  -keyout key.pem \
  -out cert.pem \
  -days 365 \
  -nodes \
  -subj "/CN=${CN}" \
  -addext "subjectAltName=DNS:${CN}"

cp cert.pem ca-cert.pem

이 예시에서 openssl 명령어는 비공개 4096비트 RSA 키를 key.pem에 출력하고 X.509 형식의 자체 서명 인증서를 cert.pem에 출력합니다. 인증서가 자체 서명되어 있으므로 인증서는 ca-cert.pem에 복사되고 서명 CA의 인증서로 간주됩니다. 인증서는 365일 동안 유효하며 암호는 필요하지 않습니다. 인증서 생성 및 서명에 대한 자세한 내용은 인증서 서명 요청에 대한 Kubernetes 문서를 참조하세요.

이 섹션의 단계는 매년 만료 전에 새 키와 인증서를 다시 생성하고 다시 적용해야 합니다.

키와 인증서를 만든 후 Kubernetes 보안 비밀을 만들고 사이드카 인젝터의 웹훅을 업데이트해야 합니다.

  1. Kubernetes 보안 비밀을 만들 네임스페이스를 만듭니다.

    kubectl apply -f specs/00-namespaces.yaml
    
  2. 사이드카 인젝터의 보안 비밀을 만듭니다.

    kubectl create secret generic istio-sidecar-injector -n istio-control \
      --from-file=key.pem \
      --from-file=cert.pem \
      --from-file=ca-cert.pem
    
  3. specs/02-injector.yaml에서 istio-sidecar-injector-istio-control이라는 사이드카 삽입 웹훅의 caBundle을 수정합니다.

    CA_BUNDLE=$(cat cert.pem | base64 | tr -d '\n')
    sed -i "s/caBundle:.*/caBundle:\ ${CA_BUNDLE}/g" specs/02-injector.yaml
    

GKE 클러스터에 사이드카 인젝터 설치

  1. 사이드카 인젝터를 배포합니다.

    kubectl apply -f specs/
    
  2. 사이드카 인젝터가 실행 중인지 확인합니다.

    kubectl get pods -A | grep sidecar-injector
    

    그러면 다음과 비슷한 출력이 표시됩니다.

    istio-control   istio-sidecar-injector-6b475bfdf9-79965  1/1 Running   0   11s
    istio-control   istio-sidecar-injector-6b475bfdf9-vntjd  1/1 Running   0   11s
    

비공개 클러스터에서 필요한 포트 열기

비공개 클러스터에 Envoy 사이드카 인젝터를 설치하는 경우 웹 방화벽이 제대로 작동하려면 방화벽 규칙에서 TCP 포트 9443을 마스터 노드에 열어야 합니다.

다음 단계에서는 방화벽 규칙을 업데이트하는 방법을 설명합니다. update 명령어가 기존 방화벽 규칙을 대체하므로 기본 포트 443(HTTPS) 및 10250(kubelet)은 물론 열려는 새 포트도 포함하도록 엽니다.

  1. 클러스터의 소스 범위(master-ipv4-cidr)를 찾습니다. 다음 명령어에서 CLUSTER_NAME을 클러스터 이름으로 바꿉니다.

    FIREWALL_RULE_NAME=$(gcloud compute firewall-rules list \
     --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master" \
     --format="value(name)")
    
  2. 방화벽 규칙을 업데이트하여 TCP 포트 9443을 열고 자동 삽입을 사용 설정합니다.

    gcloud compute firewall-rules update ${FIREWALL_RULE_NAME} \
     --allow tcp:10250,tcp:443,tcp:9443
    

사이드카 삽입 사용 설정

다음 명령어는 default 네임스페이스에 대한 삽입을 사용 설정합니다. 사이드카 인젝터는 사이드카 컨테이너를 이 네임스페이스로 만든 pod에 삽입합니다.

kubectl label namespace default istio-injection=enabled

다음을 실행하여 default 네임스페이스가 제대로 사용 설정되어 있는지 확인할 수 있습니다.

kubectl get namespace -L istio-injection

이는 다음을 반환해야 합니다.

NAME              STATUS   AGE     ISTIO-INJECTION
default           Active   7d16h   enabled
istio-control     Active   7d15h
istio-system      Active   7d15h

샘플 클라이언트 배포 및 삽입 확인

이 섹션에서는 Busybox를 실행하는 샘플 pod를 배포하는 방법을 보여줍니다. 이 샘플은 테스트 서비스에 도달하는 간단한 인터페이스를 제공합니다. 실제 배포에서는 자체 클라이언트 애플리케이션을 대신 배포합니다.

kubectl create -f demo/client_sample.yaml

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

kubectl describe pods -l run=client

이는 다음을 반환해야 합니다.

…
Init Containers:
# Istio-init sets up traffic interception for the pod.
  Istio-init:
…
Containers:
# busybox is the client container that runs application code.
  busybox:
…
# Envoy is the container that runs the injected Envoy proxy.
  envoy:
…

테스트용 Kubernetes 서비스 배포

다음 섹션에서는 이 가이드의 뒷부분에서 설정을 전반적으로 확인하는 데 사용할 수 있는 테스트 서비스를 설정하는 방법을 안내합니다.

NEG로 GKE 서비스 구성

Traffic Director 백엔드 서비스의 백엔드로 구성할 수 있도록 GKE 서비스가 네트워크 엔드포인트 그룹(NEG)를 통해 노출되어야 합니다. Kubernetes 서비스 사양에 NEG 주석을 추가하고 나중에 쉽게 찾을 수 있도록 아래 샘플에서 NEG-NAME을 바꿔서 이름을 선택합니다. Traffic Director 백엔드 서비스에 NEG를 연결할 때 이 이름이 필요합니다. NEG 주석에 대한 자세한 내용은 NEG 이름 지정을 참조하세요.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG-NAME"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

이 주석은 서비스 pod의 IP 주소와 포트에 해당하는 엔드포인트가 포함된 독립형 NEG를 만듭니다. 자세한 내용과 예시는 독립형 네트워크 엔드포인트 그룹을 참조하세요.

다음 샘플 서비스에는 NEG 주석이 포함되어 있습니다. 이 서비스는 포트 80에서 HTTP를 통해 호스트 이름을 제공합니다. 다음 명령어를 사용하여 서비스를 가져오고 GKE 클러스터에 배포합니다.

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..]

이 서비스와 연결된 애플리케이션 pod가 실행 중인지 확인합니다.

kubectl get pods
이는 다음을 반환합니다.
NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       2/2       Running   0          6m
[..skip..]

NEG의 이름 저장

위 예시에서 생성된 NEG를 찾아서 다음 섹션에 Traffic Director 구성의 이름을 기록합니다.

gcloud compute network-endpoint-groups list

이는 다음을 반환합니다.

NAME                 LOCATION          ENDPOINT_TYPE      SIZE
NEG-NAME           us-central1-a     GCE_VM_IP_PORT      1

NEG의 이름을 NEG_NAME 변수에 저장합니다.

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

Cloud Load Balancing 구성요소로 Traffic Director 구성

이 섹션에서는 Compute Engine 부하 분산 리소스를 사용하여 Traffic Director를 구성합니다. 그러면 샘플 클라이언트의 사이드카 프록시가 Traffic Director의 구성을 수신할 수 있습니다. 샘플 클라이언트의 아웃바운드 요청은 사이드카 프록시에 의해 처리되며 테스트 서비스로 라우팅됩니다.

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

상태 확인 및 방화벽 규칙 만들기

Console

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

  6. Google Cloud Console의 방화벽 페이지로 이동합니다.
    방화벽 페이지로 이동

  7. 방화벽 규칙 만들기를 클릭합니다.

  8. 방화벽 규칙 만들기 페이지에서 다음 정보를 입력합니다.

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

gcloud

  1. 상태 확인을 만듭니다.

    gcloud compute health-checks create http td-gke-health-check \
      --use-serving-port
    
  2. 상태 확인기 IP 주소 범위를 허용하는 방화벽 규칙을 만듭니다.

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

백엔드 서비스 만들기

부하 분산 스키마가 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(VIP) 주소와 호스트 기반 라우팅과 같은 연결된 트래픽 관리 규칙 집합을 구성합니다. 애플리케이션이 VIP에 요청을 전송하면 연결된 Envoy 사이드카 프록시는 다음을 수행합니다.

  1. 요청을 가로챕니다.
  2. URL 맵의 트래픽 관리 규칙에 따라 요청을 평가합니다.
  3. 요청의 호스트 이름을 기반으로 백엔드 서비스를 선택합니다.
  4. 선택한 백엔드 서비스와 연결된 백엔드 또는 엔드포인트를 선택합니다.
  5. 이 백엔드 또는 엔드포인트로 트래픽을 전송합니다.

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. td-gke-service를 기본 백엔드 서비스로 사용하는 URL 맵을 만듭니다.

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

    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는 service-test 호스트 이름을 지정하는 요청을 td-gke-service의 백엔드로 라우팅하도록 사이드카 프록시를 구성합니다. 이 경우 이러한 백엔드는 이전에 배포한 Kubernetes 테스트 서비스와 연결된 네트워크 엔드포인트 그룹의 엔드포인트입니다.

구성 확인

이 섹션에서는 샘플 Busybox 클라이언트에서 전송된 트래픽이 service-test Kubernetes 서비스로 라우팅되는지 확인하는 방법을 보여줍니다. 테스트 요청을 보내려면 컨테이너 중 하나의 셸에 액세스하여 다음 확인 명령어를 실행하면 됩니다. service-test pod는 제공 pod의 호스트 이름을 반환해야 합니다.

# Get the name of the pod running 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"

구성 확인 방법은 다음과 같습니다.

  • 샘플 클라이언트가 service-test 호스트 이름을 지정하는 요청을 보냈습니다.
  • 샘플 클라이언트에 Envoy 사이드카 인젝터가 삽입한 Envoy 사이드카 프록시가 있습니다.
  • 사이드카 프록시가 요청을 가로챘습니다.
  • 라우팅 규칙 맵에서 0.0.0.0을 VIP로 구성했으므로 Envoy는 요청의 호스트 이름을 검사했습니다.
  • Envoy가 URL 맵을 사용하여 service-test 호스트 이름을 td-gke-service Traffic Director 서비스에 일치시켰습니다.
  • Envoy가 td-gke-service와 연결된 네트워크 엔드포인트 그룹에서 엔드포인트를 선택했습니다.
  • Envoy가 service-test Kubernetes 서비스와 연결된 pod로 요청을 전송했습니다.

다음 단계

마이크로서비스가 네트워크에 분산되는 방식에 따라 더 많은 전달 규칙이나 호스트 및 경로 규칙을 URL 맵에 추가해야 할 수 있습니다. 전달 규칙 및 URL 맵에 대한 자세한 내용은 다음 문서를 참조하세요.