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

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

개요

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

Google 관리 Envoy 사이드카 인젝터는 Envoy 사이드카 프록시를 Google Kubernetes Engine 포드에 추가합니다. Envoy 사이드카 인젝터가 프록시를 추가할 때는 애플리케이션 트래픽 처리를 위해 해당 프록시를 설정하고 구성을 위해 Cloud Service Mesh에 연결합니다.

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

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

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

기본 요건

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

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

공유 VPC를 사용하는 추가 기본 요건

공유 VPC 환경에서 Cloud Service Mesh를 설정하는 경우 다음을 확인합니다.

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

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

IAM 역할 구성

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

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 네트워크 뷰어 역할만으로도 충분합니다.

프로젝트 정보 구성

아직 Google Cloud 프로젝트를 만들거나 Google Cloud CLI를 설치하지 않았으면 다음 안내를 따르세요. 아직 kubectl을 설치하지 않았으면 다음 안내를 따르세요.

# The project that contains your GKE cluster.
export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_NUMBER_HERE
# The name of your GKE cluster.
export CLUSTER=YOUR_CLUSTER_NAME
# The channel of your GKE cluster. Eg: rapid, regular, stable. This channel
# should match the channel of your GKE cluster.
export CHANNEL=YOUR_CLUSTER_CHANNEL
# The location of your GKE cluster, Eg: us-central1 for regional GKE cluster,
# us-central1-a for zonal GKE cluster
export LOCATION=ZONE

# The network name of the traffic director load balancing API.
export MESH_NAME=default
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/global/networks/${MESH_NAME}

gcloud config set project ${CLUSTER_PROJECT_ID}

새 서비스 라우팅 API를 사용하는 경우 다음 안내에 따라 MESH_NAME, MESH_PROJECT_NUMBER, TARGET을 설정합니다.

# The mesh name of the traffic director load balancing API.
export MESH_NAME=YOUR_MESH_NAME
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/locations/global/meshes/${MESH_NAME}

대부분 시나리오에서 CLUSTER_PROJECT_ID 및 MESH_PROJECT_NUMBER는 동일한 프로젝트를 나타냅니다. 하지만 공유 VPC를 사용할 때와 같이 다른 프로젝트를 설정한 경우 CLUSTER_PROJECT_ID는 GKE 클러스터가 포함된 프로젝트 ID를 나타내고 MESH_PROJECT_NUMBER는 리소스가 포함된 프로젝트 번호를 나타냅니다. 삽입된 envoy가 구성을 검색할 수 있는 적합한 권한을 구성했는지 확인합니다.

Mesh Config API 사용 설정

Google 관리 사이드카 인젝터를 시작하려면 다음 API를 사용 설정합니다.

gcloud services enable --project=${CLUSTER_PROJECT_ID} meshconfig.googleapis.com

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

GKE 클러스터는 Cloud Service Mesh를 지원하기 위한 다음 요구사항을 충족해야 합니다.

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

GKE 클러스터 만들기

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

gcloud container clusters create YOUR_CLUSTER_NAME \
  --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

변형 웹훅을 위한 구성 적용

다음 섹션에서는 클러스터에 MutatingWebhookConfiguration을 적용하기 위한 안내를 제공합니다. 포드가 생성되면 클러스터 내 허용 컨트롤러가 호출됩니다. 허용 컨트롤러는 관리형 사이드카 인젝터에 연결하여 Envoy 컨테이너를 포드에 추가합니다.

다음 변형 웹훅 구성을 클러스터에 적용합니다.

cat <<EOF | kubectl apply -f -
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  labels:
    app: sidecar-injector
  name: td-mutating-webhook
webhooks:
- admissionReviewVersions:
  - v1beta1
  - v1
  clientConfig:
    url: https://meshconfig.googleapis.com/v1internal/projects/${CLUSTER_PROJECT_ID}/locations/${LOCATION}/clusters/${CLUSTER}/channels/${CHANNEL}/targets/${TARGET}:tdInject
  failurePolicy: Fail
  matchPolicy: Exact
  name: namespace.sidecar-injector.csm.io
  namespaceSelector:
    matchExpressions:
    - key: td-injection
      operator: Exists
  reinvocationPolicy: Never
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: '*'
  sideEffects: None
  timeoutSeconds: 30
EOF

사이드카 삽입 사용 설정

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

kubectl label namespace default td-injection=enabled

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

kubectl get namespace -L td-injection

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

NAME              STATUS   AGE     TD-INJECTION
default           Active   7d16h   enabled

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

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

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

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: client
  name: busybox
spec:
  replicas: 1
  selector:
    matchLabels:
      run: client
  template:
    metadata:
      labels:
        run: client
    spec:
      containers:
      - name: busybox
        image: busybox
        command:
        - sh
        - -c
        - while true; do sleep 1; done
EOF

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:
…

Cloud Service Mesh 프록시

관리형 사이드카 인젝터는 Cloud Service Mesh 프록시 이미지를 프록시로 사용합니다. Cloud Service Mesh 프록시는 메시가 사용 설정된 인스턴스에 대해 envoy 프록시를 시작하는 사이드카 컨테이너입니다. 프록시 이미지는 envoy를 시작하고, 부트스트랩 구성을 제공하고, envoy 상태를 확인하는 프록시 에이전트와 함께 OSS envoy 이미지를 사용합니다. Cloud Service Mesh 프록시 이미지 버전은 OSS Envoy 버전과 일치합니다. 사용 가능한 프록시 이미지는 https://gcr.io/gke-release/asm/csm-mesh-proxy에서 추적할 수 있습니다.

삽입되는 Cloud Service Mesh 메시 프록시는 사용자가 GKE 클러스터에 선택한 채널에 따라 달라집니다. Envoy 버전은 현재 OSS Envoy 출시 버전에 따라 정기적으로 업데이트되며 호환성 확인을 위해 특정 GKE 출시 버전으로 테스트되었습니다.

Cloud Service Mesh 프록시 버전

다음 표에서는 Cloud Service Mesh 프록시 버전에 대한 현재 GKE 클러스터 채널 매핑을 보여줍니다.

채널	Cloud Service Mesh 프록시 버전
신속	1.29.9-gke.3
일반	1.28.7-gke.3
안정	1.27.7-gke.3

Cloud Service Mesh 프록시 업그레이드

최신 버전으로 업그레이드하는 것이 좋습니다. 제어 영역과 프록시의 버전이 서로 달라도 서비스 메시에는 문제가 없지만 새 Cloud Service Mesh 버전으로 구성되도록 프록시를 업데이트하는 것이 좋습니다.

관리형 사이드카 인젝터는 Google에서 확인된 최신 Envoy 버전을 삽입하는 Envoy 버전이 사용되는지 확인합니다. Cloud Service Mesh 프록시 버전이 이 프록시 버전보다 최신이면 서비스에 대해 프록시를 다시 시작합니다.

kubectl rollout restart deployment -n YOUR_NAMESPACE_HERE

테스트용 Kubernetes 서비스 배포

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

NEG로 GKE 서비스 구성

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": "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를 찾아서 다음 섹션에 Cloud Service Mesh 구성의 이름을 기록합니다.

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 구성요소로 Cloud Service Mesh 구성

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

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

상태 확인. 상태 확인에 대한 자세한 내용은 상태 확인 개념 및 상태 확인 만들기를 참조하세요.
백엔드 서비스. 백엔드 서비스에 대한 자세한 내용은 백엔드 서비스를 참조하세요.
라우팅 규칙 맵. 여기에는 전달 규칙, 대상 HTTP 프록시, URL 맵 만들기가 포함됩니다. 자세한 내용은 Cloud Service Mesh에 전달 규칙 사용, Cloud Service Mesh에 대상 프록시 사용, 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 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.
Cloud Service Mesh 페이지로 이동
서비스 탭에서 서비스 만들기를 클릭합니다.
계속을 클릭합니다.
서비스 이름으로 td-gke-service를 입력합니다.
Cloud Service Mesh 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 프록시를 사용하여 Cloud Service Mesh를 구성하는 경우 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
```

라우팅 규칙 맵 만들기

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

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

콘솔

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

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

이 시점에서 Cloud Service Mesh는 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 사이드카 프록시가 있습니다.
사이드카 프록시가 요청을 가로챘습니다.
URL 맵을 사용하여 Envoy가 td-gke-service Cloud Service Mesh 서비스와 일치하는 service-test 호스트 이름을 찾았습니다.
Envoy가 td-gke-service와 연결된 네트워크 엔드포인트 그룹에서 엔드포인트를 선택했습니다.
Envoy가 service-test Kubernetes 서비스와 연결된 포드로 요청을 전송했습니다.

관리형 사이드카 인젝터로 마이그레이션하는 방법

이 튜토리얼에서는 GKE의 애플리케이션을 기존 Cloud Service Mesh 사이드카 인젝터(클러스터 내 사이드카 인젝터 사용)에서 관리형 사이드카 인젝터로 마이그레이션하는 과정을 안내합니다.

클러스터 내 사이드카 삽입 사용 중지

다음 명령어는 기본 네임스페이스에 대해 기존 클러스터 내 사이드카 인젝터를 사용 중지합니다.

kubectl label namespace default istio-injection-

클러스터 내 사이드카 인젝터 정리

기존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

클러스터 내 사이드카 인젝터 리소스 삭제

kubectl delete -f specs/

다음 단계

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