Anthos Service Mesh와 Traffic Director가 이제 Cloud Service Mesh로 통합되었습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

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

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

이 가이드의 안내를 따르기 전에 Envoy 및 프록시리스 워크로드로 서비스 라우팅 API 설정 준비에 설명된 필수 작업을 완료하세요.

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

Cloud Service Mesh용 GKE/Kubernetes 클러스터 구성

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

GKE 클러스터 만들기

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

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

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

콘솔

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

Google Cloud 콘솔에서 Kubernetes Engine 메뉴로 이동합니다.

Google Kubernetes Engine 메뉴로 이동
클러스터 만들기를 클릭합니다.
다음 필드를 작성하세요.
- 이름: traffic-director-cluster를 입력합니다.
- 위치 유형: Zonal
- 영역: us-central1-a
탐색창의 노드 풀에서 default-pool을 클릭합니다.
크기 필드에는 클러스터에서 만들 노드 수가 표시됩니다. 노드 및 해당 리소스(예: 방화벽 경로)에 사용 가능한 리소스 할당량이 있어야 합니다.
탐색창의 default-pool에서 노드를 클릭합니다.
머신 유형 필드에는 인스턴스에 사용할 Compute Engine 머신 유형이 표시됩니다. 요금은 머신 유형마다 다르게 청구됩니다. 머신 유형별 가격 정보는 Compute Engine 가격 책정 페이지를 참조하세요.
탐색창의 default-pool에서 보안을 클릭합니다.
액세스 범위에서 모든 Cloud APIs에 대해 전체 액세스 허용을 클릭합니다.
필요에 따라 클러스터를 맞춤설정합니다.
만들기를 클릭합니다.

Google Cloud 콘솔에서 클러스터를 만든 후 클러스터와 상호작용하려면 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 서비스 구성

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

방화벽 규칙 구성

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

콘솔

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

gcloud

다음 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 서비스 구성

Cloud Service Mesh 백엔드 서비스의 백엔드로 구성할 수 있도록 GKE 서비스가 네트워크 엔드포인트 그룹(NEG)을 통해 노출되어야 합니다. Kubernetes 서비스 사양에 NEG 주석을 추가하고 나중에 쉽게 찾을 수 있도록 아래 샘플에서 NEG-NAME을 바꿔서 이름을 선택합니다. Cloud Service Mesh 백엔드 서비스에 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

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

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

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       1/1       Running   0          6m
[..skip..]

NEG의 이름 저장

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

Console

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

gcloud

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 Service Mesh용 Google Cloud 부하 분산 구성요소 구성

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

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

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

다음 Cloud Service Mesh 구성 예시에서는 다음을 가정합니다.

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

상태 확인 만들기

상태 확인을 만듭니다.

콘솔

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

gcloud

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

백엔드 서비스 만들기

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

콘솔

Google Cloud 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.
Cloud Service Mesh 페이지로 이동
서비스 탭에서 서비스 만들기를 클릭합니다.
계속을 클릭합니다.
서비스 이름으로 td-gke-service를 입력합니다.
백엔드 유형에 네트워크 엔드포인트 그룹을 선택합니다.
생성한 네트워크 엔드포인트 그룹을 선택합니다.
최대 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를 추가합니다.

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

라우팅 규칙 맵 만들기

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

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

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

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

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

콘솔

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

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

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

gcloud

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

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

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

대상 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

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

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

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

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

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

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

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

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

이전 API를 사용하는 경우 PROJECT_NUMBER 및 NETWORK_NAME 변수를 프로젝트 번호와 네트워크 이름으로 바꿉니다.

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_sample_xdsv3.yaml
sed -i "s/NETWORK_NAME/NETWORK_NAME/g" trafficdirector_client_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_sample_xdsv3.yaml

현재 미리보기 상태인 새 서비스 라우팅 API를 사용하는 경우 PROJECT_NUMBER 및 MESH_NAME 변수를 프로젝트 번호 및 Mesh 이름으로 바꿉니다.

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/MESH_NAME/MESH_NAME/g" trafficdirector_client_new_api_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_new_api_sample_xdsv3.yaml

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

kubectl describe pods -l run=client

백엔드 서비스 도달

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

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

# 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을 사용하여 전달 규칙을 만들었습니다. 즉, Cloud Service Mesh는 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"

다음 단계

고급 트래픽 관리 알아보기
Cloud Service Mesh 배포 문제 해결 방법 알아보기
Envoy로 관측 가능성 설정 방법 알아보기