자동 Envoy 삽입을 사용하여 Google Kubernetes Engine 포드 설정

개요

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

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

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

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

워크로드를 위한 GKE 클러스터 만들기
Envoy 사이드카 인젝터 설치 및 삽입 사용 설정
샘플 클라이언트 배포 및 삽입 확인
테스트용 Kubernetes 서비스 배포
테스트 서비스로 트래픽을 라우팅하도록 Cloud Load Balancing 구성요소를 사용하여 Traffic Director 구성
샘플 클라이언트에서 테스트 서비스로 요청을 전송하여 구성 확인

기본 요건

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

지원되는 Envoy 버전에 대한 자세한 내용은 Traffic Director 출시 노트를 참조하세요.

공유 VPC의 추가 기본 요건

공유 VPC 환경에서 Traffic Director를 설정하는 경우 다음을 확인해야 합니다.

공유 VPC에 대한 올바른 권한 및 역할이 있는지
올바른 프로젝트 및 청구를 설정했는지
프로젝트에서 결제가 사용 설정되었는지
호스트 프로젝트를 포함한 각 프로젝트에서 Traffic Director 및 GKE API를 사용 설정했는지
프로젝트별로 올바른 서비스 계정을 설정했는지
VPC 네트워크 및 서브넷을 만들었는지
공유 VPC를 사용 설정했는지

자세한 내용은 공유 VPC를 참조하세요.

IAM 역할 구성

이 IAM 역할 구성 예시에서는 공유 VPC의 호스트 프로젝트에 서브넷 두 개가 있고 공유 VPC에 서비스 프로젝트 두 개가 있다고 가정합니다.

Cloud Shell에서 작업 폴더(WORKDIR))를 만듭니다. 여기서 이 섹션과 관련된 파일을 만들게 됩니다.
```
mkdir -p ~/td-shared-vpc
cd ~/td-shared-vpc
export WORKDIR=$(pwd)
```

서비스 프로젝트가 공유 VPC의 리소스를 사용할 수 있도록 호스트 프로젝트에서 IAM 권한을 구성합니다.

이 단계에서는 서비스 프로젝트 1에서 subnet-1에 액세스할 수 있고 서비스 프로젝트 2에서 subnet-2에 액세스할 수 있도록 IAM 권한을 구성합니다. 각 서비스 프로젝트의 각 서브넷에서 Compute Engine Compute 기본 서비스 계정과 Google Cloud API 서비스 계정 모두에 Compute 네트워크 사용자 IAM 역할(roles/compute.networkUser)을 할당합니다.

서비스 프로젝트 1의 subnet-1에 IAM 권한을 구성합니다.

export SUBNET_1_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-1 --project ${HOST_PROJECT} --region ${REGION_1} --format=json | jq -r '.etag')

cat > subnet-1-policy.yaml <<EOF
bindings:
- members:
  - serviceAccount:${SVC_PROJECT_1_API_SA}
  - serviceAccount:${SVC_PROJECT_1_GKE_SA}
  role: roles/compute.networkUser
etag: ${SUBNET_1_ETAG}
EOF

gcloud beta compute networks subnets set-iam-policy subnet-1 \
subnet-1-policy.yaml \
    --project ${HOST_PROJECT} \
    --region ${REGION_1}

서비스 프로젝트 2의 subnet-2에 IAM 권한을 구성합니다.

export SUBNET_2_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-2 --project ${HOST_PROJECT} --region ${REGION_2} --format=json | jq -r '.etag')

cat > subnet-2-policy.yaml <<EOF
bindings:
- members:
  - serviceAccount:${SVC_PROJECT_2_API_SA}
  - serviceAccount:${SVC_PROJECT_2_GKE_SA}
  role: roles/compute.networkUser
etag: ${SUBNET_2_ETAG}
EOF

gcloud beta compute networks subnets set-iam-policy subnet-2 \
subnet-2-policy.yaml \
    --project ${HOST_PROJECT} \
    --region ${REGION_2}

서비스 프로젝트마다 호스트 프로젝트의 GKE 서비스 계정에 Kubernetes Engine 호스트 서비스 에이전트 사용자 IAM 역할(roles/container.hostServiceAgentUser)을 부여해야 합니다.
```
gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
    --member serviceAccount:${SVC_PROJECT_1_GKE_SA} \
    --role roles/container.hostServiceAgentUser

gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
    --member serviceAccount:${SVC_PROJECT_2_GKE_SA} \
    --role roles/container.hostServiceAgentUser
```
이 역할을 통해 서비스 프로젝트의 GKE 서비스 계정은 호스트 프로젝트의 GKE 서비스 계정을 사용하여 공유 네트워크 리소스를 구성할 수 있습니다.
서비스 프로젝트마다 Compute Engine 기본 서비스 계정에 호스트 프로젝트의 Compute 네트워크 뷰어 IAM 역할(roles/compute.networkViewer)을 부여합니다.
```
gcloud projects add-iam-policy-binding ${SVC_PROJECT_1} \
    --member serviceAccount:${SVC_PROJECT_1_COMPUTE_SA} \
    --role roles/compute.networkViewer

gcloud projects add-iam-policy-binding ${SVC_PROJECT_2} \
    --member serviceAccount:${SVC_PROJECT_2_COMPUTE_SA} \
    --role roles/compute.networkViewer
```
Envoy 사이드카 프록시가 xDS 서비스(Traffic Director API)에 연결되면 프록시는 Compute Engine 가상 머신(VM) 호스트 또는 GKE 노드 인스턴스의 서비스 계정을 사용합니다. 서비스 계정에는 compute.globalForwardingRules.get 프로젝트 수준 IAM 권한이 있어야 합니다. 이 단계에서는 Compute 네트워크 뷰어 역할만으로도 충분합니다.

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

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

네트워크 엔드포인트 그룹 지원을 사용 설정해야 합니다. 자세한 내용과 예시는 독립형 네트워크 엔드포인트 그룹을 참조하세요.
GKE 노드/포드의 서비스 계정에 Traffic Director API 액세스 권한이 있어야 합니다. 필요한 권한에 대한 자세한 내용은 서비스 계정이 Traffic Director API에 액세스하도록 사용 설정을 참조하세요.

GKE 클러스터 만들기

원하는 영역에 traffic-director-cluster라는 GKE 클러스터를 만듭니다(예: us-central1-a).

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

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

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

gcloud container clusters get-credentials traffic-director-cluster \
    --zone ZONE

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

사이드카 인젝터 구성

이전 API를 사용하는 경우 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를 구성할 때 필요하므로 기록해 둡니다.

현재 미리보기 상태인 새 서비스 라우팅 API를 사용하는 경우에는 다음을 수행합니다.

""를 서비스 메시 이름으로 바꿔서 TRAFFICDIRECTOR_MESH_NAME을 채워 서비스 메시 구성을 가져옵니다.
- Gateway를 구성하는 경우에는 사이드카 인젝터를 사용하지 않습니다. Envoy 프록시를 포드로 배포합니다.

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

$ cat 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:
# Google Cloud 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 Google Cloud console.
# If left empty, configuration will be attempted to be fetched for the Google Cloud
# 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"

# Google Cloud VPC network name for which the configuration is requested (This is the VPC
# network name referenced in the forwarding rule in Google Cloud 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: "default"

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

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

사이드카 인젝터의 TLS 구성

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

사이드카 인젝터는 Kubernetes 허용 웹훅 변형을 사용하여 새 포드가 생성될 때 프록시를 삽입합니다. 이 웹훅은 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 보안 비밀을 만들고 사이드카 인젝터의 웹훅을 업데이트해야 합니다.

Kubernetes 보안 비밀을 만들 네임스페이스를 만듭니다.
```
kubectl apply -f specs/00-namespaces.yaml
```

사이드카 인젝터의 보안 비밀을 만듭니다.

kubectl create secret generic istio-sidecar-injector -n istio-control \
  --from-file=key.pem \
  --from-file=cert.pem \
  --from-file=ca-cert.pem

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 클러스터에 사이드카 인젝터 설치

사이드카 인젝터를 배포합니다.
```
kubectl apply -f specs/
```

사이드카 인젝터가 실행 중인지 확인합니다.

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를 사용한 Traffic Director 서비스 보안 설정의 안내를 따랐다면 이 섹션을 건너뛰고 다음 섹션인 사이드카 삽입 사용 설정으로 넘어갈 수 있습니다.

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

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

클러스터의 소스 범위(master-ipv4-cidr)를 찾습니다. 다음 명령어에서 CLUSTER_NAME을 클러스터 이름(즉, traffic-director-cluster)으로 바꿉니다.
```
FIREWALL_RULE_NAME=$(gcloud compute firewall-rules list \
 --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master" \
 --format="value(name)")
```
방화벽 규칙을 업데이트하여 TCP 포트 9443을 열고 자동 삽입을 사용 설정합니다.
```
gcloud compute firewall-rules update ${FIREWALL_RULE_NAME} \
 --allow tcp:10250,tcp:443,tcp:9443
```

사이드카 삽입 사용 설정

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

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

Envoy를 사용하여 Traffic Director의 서비스 보안을 구성하려면 해당 설정 가이드의 테스트 서비스 설정 섹션으로 돌아갑니다.

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

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

kubectl create -f demo/client_sample.yaml

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

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": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

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

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

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

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

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       2/2       Running   0          6m
busybox-5dcf86f4c7-jvvdd    2/2       Running   0          10m
[..skip..]

NEG의 이름 저장

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

gcloud compute network-endpoint-groups list

이는 다음을 반환합니다.

NAME                       LOCATION            ENDPOINT_TYPE       SIZE
service-test-neg           ZONE     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의 구성을 수신할 수 있습니다. 샘플 클라이언트의 아웃바운드 요청은 사이드카 프록시에 의해 처리되며 테스트 서비스로 라우팅됩니다.

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

상태 확인. 상태 확인에 대한 자세한 내용은 상태 확인 개념 및 상태 확인 만들기를 참조하세요.
백엔드 서비스. 백엔드 서비스에 대한 자세한 내용은 백엔드 서비스를 참조하세요.
라우팅 규칙 맵. 여기에는 전달 규칙, 대상 HTTP 프록시, URL 맵 만들기가 포함됩니다. 자세한 내용은 Traffic Director의 전달 규칙 사용, Traffic Director의 대상 프록시 사용 ,URL 맵 사용을 참조하세요.

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

다음 안내에 따라 상태 점검 및 상태 점검 프로브에 필요한 방화벽 규칙을 만듭니다. 자세한 내용은 상태 확인을 위한 방화벽 규칙을 참조하세요.

콘솔

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

gcloud

상태 확인을 만듭니다.

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

상태 확인기 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인 글로벌 백엔드 서비스를 만듭니다. Google Cloud 콘솔에서 부하 분산 스키마는 암시적으로 설정됩니다. 백엔드 서비스에 상태 확인을 추가합니다.

콘솔

Google Cloud Console에서 Traffic Director 페이지로 이동합니다.
Traffic Director 페이지로 이동
서비스 탭에서 서비스 만들기를 클릭합니다.
계속을 클릭합니다.
서비스 이름으로 td-gke-service를 입력합니다.
Traffic Director ConfigMap에서 구성한 네트워크를 선택합니다.
백엔드 유형에 네트워크 엔드포인트 그룹을 선택합니다.
생성한 네트워크 엔드포인트 그룹을 선택합니다.
최대 RPS를 5로 설정합니다.
분산 모드를 비율로 설정합니다.
완료를 클릭합니다.
상태 확인에서 앞에서 생성한 상태 확인 td-gke-health-check를 선택합니다.
계속을 클릭합니다.

gcloud

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

gcloud compute backend-services create td-gke-service \
 --global \
 --health-checks td-gke-health-check \
 --load-balancing-scheme INTERNAL_SELF_MANAGED

이전에 만든 NEG를 백엔드 서비스에 백엔드로 추가합니다. 대상 TCP 프록시를 사용하여 Traffic Director를 구성하는 경우에는 UTILIZATION 분산 모드를 사용해야 합니다. HTTP 또는 HTTPS 대상 프록시를 사용하는 경우에는 RATE 모드를 사용할 수 있습니다.
```
gcloud compute backend-services add-backend td-gke-service \
 --global \
 --network-endpoint-group ${NEG_NAME} \
 --network-endpoint-group-zone ZONE \
 --balancing-mode [RATE | UTILIZATION] \
 --max-rate-per-endpoint 5
```

라우팅 규칙 맵 만들기

라우팅 규칙 맵은 Traffic Director가 메시의 트래픽을 라우팅하는 방법을 정의합니다. 라우팅 규칙 맵의 일부로 가상 IP(VIP) 주소와 호스트 기반 라우팅과 같은 연결된 트래픽 관리 규칙 집합을 구성합니다. 애플리케이션이 VIP에 요청을 전송하면 연결된 Envoy 사이드카 프록시는 다음을 수행합니다.

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

콘솔

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

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

Google Cloud Console에서 Traffic Director 페이지로 이동합니다.
Traffic Director 페이지로 이동
라우팅 규칙 맵을 클릭합니다.
라우팅 규칙 만들기를 클릭합니다.
URL 맵의 이름으로 td-gke-url-map을 입력합니다.
전달 규칙 추가를 클릭합니다.
전달 규칙 이름으로 td-gke-forwarding-rule을 입력합니다.
네트워크를 선택합니다.
내부 IP를 선택합니다.
저장을 클릭합니다.
원하는 경우 커스텀 호스트 및 경로 규칙을 추가하거나 경로 규칙을 기본값으로 그대로 둡니다.
호스트를 service-test로 설정합니다.
저장을 클릭합니다.

gcloud

td-gke-service를 기본 백엔드 서비스로 사용하는 URL 맵을 만듭니다.

gcloud compute url-maps create td-gke-url-map \
   --default-service td-gke-service

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
```

대상 HTTP 프록시를 만듭니다.

gcloud compute target-http-proxies create td-gke-proxy \
   --url-map td-gke-url-map

전달 규칙을 만듭니다.

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 포드는 제공 포드의 호스트 이름을 반환해야 합니다.

# 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 at
# the VIP 10.0.0.1. Because 0.0.0.0 is configured in the forwarding rule, this
# can be any VIP.
TEST_CMD="wget -q -O - 10.0.0.1; echo"

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

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

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

다음 단계

고급 트래픽 관리 알아보기
Traffic Director 서비스 보안 알아보기
Envoy로 관측 가능성 설정 방법 알아보기
Traffic Director 배포 문제 해결 방법 알아보기
자동 Envoy 삽입을 사용하는 Google Kubernetes Engine 포드 설정 옵션 알아보기