개요

Cloud Service Mesh는 서비스 간의 관측 가능하고 안전한 관리형 통신을 지원하여 선택한 인프라에서 여러 마이크로서비스로 구성된 강력한 엔터프라이즈 애플리케이션을 더 쉽게 개발할 수 있게 해주는 아키텍처입니다. 일관되고 강력한 도구를 사용하여 모니터링, 네트워킹, 보안과 같은 서비스 실행과 관련된 일반적인 요구사항을 관리하므로 서비스 개발자와 운영자는 사용자를 위한 훌륭한 애플리케이션을 만들고 관리하는 데 집중할 수 있습니다.

Cloud Service Mesh의 트래픽 관리 모델은 다음 두 가지 구성요소를 기반으로 합니다.

• 컨트롤 플레인: Envoy 프록시를 관리하고 구성하여 트래픽을 라우팅하고 정책을 적용합니다.
• 데이터 영역: 런타임에 Envoy 프록시가 실행하는 마이크로서비스 간의 모든 네트워크 통신을 포괄합니다.

이러한 구성요소는 다음을 비롯한 메시 트래픽 관리 기능을 지원합니다.

• 서비스 검색
• 부하 분산
• 트래픽 라우팅 및 제어

목표

이 실습에서는 다음 작업을 수행하는 방법을 알아봅니다.

• Istio 게이트웨이 구성 및 사용
• 사용 가능한 모든 버전에 기본 대상 규칙 적용
• 기본적으로 하나의 버전으로만 라우팅되도록 가상 서비스 적용
• 사용자 ID에 따라 특정 버전의 서비스로 라우팅
• 한 마이크로서비스 버전에서 다른 버전으로 트래픽을 점진적으로 전환
• Cloud Service Mesh 대시보드를 사용하여 여러 버전으로의 라우팅 보기
• 재시도, 회로 차단기, 제한 시간과 같은 네트워킹 권장사항 설정

설정 및 요건

이 작업에서는 실습을 위한 초기화 단계를 수행합니다.

각 실습에서는 정해진 기간 동안 새 Google Cloud 프로젝트와 리소스 집합이 무료로 제공됩니다.

1. 시크릿 창을 사용하여 Google Skills에 로그인합니다.

2. 실습 사용 가능 시간(예: 1:15:00)을 참고하여 해당 시간 내에 완료합니다. 일시중지 기능은 없습니다. 필요한 경우 다시 시작할 수 있지만 처음부터 시작해야 합니다.

3. 준비가 되면 실습 시작을 클릭합니다.

4. 실습 사용자 인증 정보(사용자 이름 및 비밀번호)를 기록해 두세요. Google Cloud Console에 로그인합니다.

5. Google Console 열기를 클릭합니다.

6. 다른 계정 사용을 클릭한 다음, 안내 메시지에 이 실습에 대한 사용자 인증 정보를 복사하여 붙여넣습니다. 다른 사용자 인증 정보를 사용하는 경우 오류가 발생하거나 요금이 부과됩니다.

7. 약관에 동의하고 리소스 복구 페이지를 건너뜁니다.

초기 로그인 단계를 완료하면 프로젝트 대시보드가 표시됩니다.

8. 프로젝트 선택을 클릭하고 GCP 프로젝트 ID를 강조 표시한 다음 열기를 클릭하여 프로젝트를 선택합니다.

Google Cloud Shell 활성화하기

Google Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다.

Google Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.

1. Cloud 콘솔의 오른쪽 상단 툴바에서 'Cloud Shell 열기' 버튼을 클릭합니다.

   

2. 계속을 클릭합니다.

환경을 프로비저닝하고 연결하는 데 몇 분 정도 소요됩니다. 연결되면 사용자가 미리 인증되어 프로젝트가 PROJECT_ID로 설정됩니다. 예:

gcloud는 Google Cloud의 명령줄 도구입니다. Cloud Shell에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.

• 다음 명령어를 사용하여 사용 중인 계정 이름을 나열할 수 있습니다.

gcloud auth list

출력:

Credentialed accounts: - @.com (active)

출력 예시:

Credentialed accounts: - google1623327_student@qwiklabs.net

• 다음 명령어를 사용하여 프로젝트 ID를 나열할 수 있습니다.

gcloud config list project

출력:

[core] project =

출력 예시:

[core] project = qwiklabs-gcp-44776a13dea667a6 참고: gcloud 전체 문서는 gcloud CLI 개요 가이드를 참조하세요.

작업 1. 트래픽 관리 사용 사례 검토

다양한 구성 옵션을 사용하여 다양한 트래픽 관리 기능을 사용 설정할 수 있습니다.

예: 트래픽 분할

서비스의 여러 버전으로 트래픽을 라우팅합니다.

예: 제한 시간

제한 시간(Istio가 요청에 대한 응답을 기다리는 시간)을 설정합니다. HTTP 요청의 제한 시간은 15초이지만 재정의할 수 있습니다.

예: 재시도

재시도는 작업을 완료하는 데 실패할 경우 여러 번 시도하는 것입니다. 최대 재시도 횟수 또는 기본 또는 재정의된 제한 시간 내에서 가능한 시도 횟수를 조정합니다.

예: 결함 주입: 지연 삽입

결함 주입은 오류 조건을 견디고 복구할 수 있는지 확인하기 위해 시스템에 오류를 도입하는 테스트 방법입니다.

이 예시에서는 ratings 마이크로서비스의 'v1' 버전에 대한 요청의 10%에 5초 지연을 도입합니다.

예: 결함 주입: 중단 삽입

위 예시는 ratings 서비스 'v1'에 대한 요청의 10%에 대해 HTTP 400 오류 코드를 반환합니다.

예: 조건부 라우팅: 소스 라벨 기반

reviews 서비스의 버전 v2를 구현하는 워크로드(포드)의 호출에만 적용되는 규칙을 지정할 수 있습니다.

예: 조건부 라우팅: 요청 헤더 기반

위 규칙은 문자열 'atharvak'가 포함된 커스텀 'end-user' 헤더를 포함하는 수신 요청에만 적용됩니다.

작업 2. 실습 설정 완료

이 실습 환경은 이미 부분적으로 구성되어 있습니다.

• gke라는 GKE 클러스터가 생성되었습니다.
• Cloud Service Mesh가 설치되었습니다.
• Bookinfo 멀티 서비스 샘플 애플리케이션이 배포되었습니다.

kubectl의 클러스터 액세스 구성

1. Zone 환경 변수를 설정합니다.

   CLUSTER_ZONE={{{ project_0.default_zone| "Zone added at lab start" }}}

2. Cloud Shell에서 환경 변수 클러스터 이름을 설정합니다.

   export CLUSTER_NAME=gke

3. 다음을 실행하여 kubectl 명령줄 액세스를 구성합니다.

   export GCLOUD_PROJECT=$(gcloud config get-value project) gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT

   메시지가 표시되면 승인 버튼을 클릭합니다.

클러스터 및 Cloud Service Mesh 설치 확인

4. 클러스터가 가동 중인지 확인합니다.

   gcloud container clusters list

   출력:

   NAME: gke LOCATION: {{{ project_0.default_zone| "Zone" }}} MASTER_VERSION: 1.24.8-gke.2000 MASTER_IP: 35.222.150.207 MACHINE_TYPE: e2-standard-4 NODE_VERSION: 1.24.8-gke.2000 NUM_NODES: 2 STATUS: RUNNING

5. Cloud Service Mesh 컨트롤 플레인의 Kubernetes 포드가 배포되었는지 확인합니다.

   kubectl get pods -n asm-ingress

출력:

NAME READY STATUS RESTARTS AGE istio-ingressgateway-69fc5475fd-4wglw 1/1 Running 0 22m istio-ingressgateway-69fc5475fd-stb7x 1/1 Running 0 22m istio-ingressgateway-69fc5475fd-vkxp4 1/1 Running 0 22m

포드 상태는 실행 중 또는 완료됨이어야 합니다.

6. Cloud Service Mesh 컨트롤 플레인의 해당 Kubernetes 서비스가 배포되었는지 확인합니다.

   kubectl get service -n asm-ingress

출력:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 34.118.232.124 34.75.207.190 15021:32645/TCP,80:31091/TCP,443:32092/TCP 30m

Bookinfo 배포 확인

8. 애플리케이션이 올바르게 배포되었는지 확인합니다.

   kubectl get pods

   출력:

   NAME READY STATUS details-v1-1520924117-48z17 2/2 Running productpage-v1-560495357-jk1lz 2/2 Running ratings-v1-734492171-rnr5l 2/2 Running reviews-v1-874083890-f0qf0 2/2 Running reviews-v2-1343845940-b34q5 2/2 Running reviews-v3-1813607990-8ch52 2/2 Running 참고: 각 포드에 어떤 컨테이너가 있는지 보이시나요? 바로 애플리케이션 컨테이너와 Istio 사이드카 프록시입니다.

9. 실행 중인 애플리케이션 서비스를 검토합니다.

   kubectl get services

   출력:

   NAME TYPE CLUSTER-IP EXTERNAL-IP ... details ClusterIP 10.7.248.49 kubernetes ClusterIP 10.7.240.1 productpage ClusterIP 10.7.248.22 ratings ClusterIP 10.7.247.26 reviews ClusterIP 10.7.246.22

작업 3. 게이트웨이를 설치하여 인그레스 사용 설정

Kubernetes 환경에서는 Kubernetes 인그레스 리소스를 사용하여 클러스터 외부에 노출해야 하는 서비스를 지정합니다. Cloud Service Mesh에서 더 나은 접근 방식은 게이트웨이 리소스를 사용하는 것이며, 이 방식은 Kubernetes 및 기타 환경에서도 작동합니다. 게이트웨이를 사용하면 클러스터로 들어오는 트래픽에 모니터링, mTLS, 고급 라우팅 기능 규칙과 같은 메시 기능을 적용할 수 있습니다.

게이트웨이는 L4~L6 사양을 L7에서 분리하여 Kubernetes 인그레스의 단점을 극복합니다. 게이트웨이는 노출할 포트나 사용할 프로토콜과 같은 L4~L6 기능을 구성합니다. 그런 다음 서비스 소유자가 VirtualService를 바인딩하여 경로, 헤더, 가중치 등을 기반으로 한 라우팅과 같은 L7 트래픽 라우팅 옵션을 구성합니다.

게이트웨이를 배포하는 방법으로는 공유 또는 전용이라는 두 가지 방법이 있습니다. 공유 게이트웨이는 여러 애플리케이션에서 여러 네임스페이스에 걸쳐 사용할 수 있는 단일 중앙 집중식 게이트웨이를 사용합니다. 아래 예시에서 인그레스 네임스페이스의 게이트웨이는 경로 소유권을 애플리케이션 네임스페이스에 위임하지만 TLS 구성에 대한 제어 권한은 유지합니다. 공유 TLS 인증서 또는 공유 인프라를 사용하는 경우에 적합합니다. 이 실습에서는 이 옵션을 사용합니다.

애플리케이션 네임스페이스에는 자체 전용 게이트웨이가 있으므로 전용 게이트웨이가 단일 네임스페이스에 대한 전체 제어 권한 및 소유권을 제공합니다. 이는 보안 또는 성능을 위해 격리가 필요한 애플리케이션에 적합합니다.

클러스터에 인그레스 게이트웨이 설치

1. 게이트웨이의 네임스페이스를 만듭니다.

   kubectl create namespace ingress

2. 자동 주입을 위해 게이트웨이 네임스페이스에 버전 라벨을 지정합니다.

   kubectl label namespace ingress istio.io/rev=asm-managed --overwrite

   버전 라벨은 사이드카 인젝터 웹훅에서 삽입된 프록시를 특정 컨트롤 플레인 버전과 연결하는 데 사용됩니다.

   출력에서 'istio-injection not found'라는 메시지는 무시해도 됩니다. 즉, 네임스페이스에 이전에 istio-injection 라벨이 사용되지 않았으며, Service Mesh를 새로 설치하거나 새로 배포해야 합니다.

   네임스페이스에 istio-injection 및 버전 라벨이 모두 포함된 경우 자동 주입이 실패하기 때문에 Service Mesh 문서의 모든 kubectl label 명령어에는 istio-injection 라벨 삭제가 포함됩니다.

3. 게이트웨이 구성 파일을 다운로드하고 적용합니다. 여기에는 클러스터 외부에서 수신 요청을 처음 수신하는 포드와 서비스가 포함됩니다.

cat <<'EOF' > ingress.yaml apiVersion: v1 kind: ServiceAccount metadata: name: istio-ingressgateway namespace: ingress --- apiVersion: v1 kind: Service metadata: name: istio-ingressgateway namespace: ingress labels: app: istio-ingressgateway istio: ingressgateway spec: ports: # status-port가 GKE Ingress 상태 점검과 사용될 수 있는 /healthz/ready 엔드포인트를 노출합니다 - name: status-port port: 15021 protocol: TCP targetPort: 15021 # 게이트웨이 리소스에 노출된 포트는 여기에 노출됩니다. - name: http2 port: 80 - name: https port: 443 selector: istio: ingressgateway app: istio-ingressgateway type: LoadBalancer --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: istio-ingressgateway namespace: ingress rules: - apiGroups: - "" resources: - secrets verbs: - get - watch - list --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: istio-ingressgateway namespace: ingress roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: istio-ingressgateway subjects: - kind: ServiceAccount name: istio-ingressgateway --- apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: istio-ingressgateway namespace: ingress spec: maxUnavailable: 1 selector: matchLabels: istio: ingressgateway app: istio-ingressgateway --- apiVersion: apps/v1 kind: Deployment metadata: name: istio-ingressgateway namespace: ingress spec: replicas: 1 selector: matchLabels: app: istio-ingressgateway istio: ingressgateway template: metadata: annotations: # 게이트웨이에 # 필요한 구성을 삽입하기 위해 필요합니다. inject.istio.io/templates: gateway labels: app: istio-ingressgateway istio: ingressgateway spec: containers: - name: istio-proxy image: auto # 포드가 시작할 때마다 이 이미지는 자동으로 업데이트됩니다. serviceAccountName: istio-ingressgateway --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: istio-ingressgateway namespace: ingress spec: maxReplicas: 5 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 80 minReplicas: 3 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: istio-ingressgateway EOF kubectl apply -n ingress -f ingress.yaml

4. 배포를 만든 후에 새 서비스가 작동하는지 확인합니다.

   kubectl get pod,service -n ingress

   리소스가 LoadBalancer임을 알 수 있습니다. 이 인그레스 게이트웨이는 GCP의 외부 TCP 부하 분산기를 사용합니다.

5. 게이트웨이를 배포하여 사용할 포트와 프로토콜을 지정합니다. 이 경우 게이트웨이는 포트 80을 통한 HTTP 트래픽을 사용 설정합니다.

   cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway namespace: ingress spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" EOF

   게이트웨이 리소스는 게이트웨이 배포와 동일한 네임스페이스에 있어야 합니다.

6. 방금 만든 게이트웨이 포드와 서비스에서 BookInfo 애플리케이션으로 트래픽을 라우팅하는 VirtualService를 배포합니다.

   cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bookinfo spec: hosts: - "*" gateways: - ingress/bookinfo-gateway http: - match: - uri: exact: /productpage - uri: prefix: /static - uri: exact: /login - uri: exact: /logout - uri: prefix: /api/v1/products route: - destination: host: productpage port: number: 9080 EOF

   VirtualService 리소스는 애플리케이션과 동일한 네임스페이스에 있어야 합니다. productpage 서비스가 기본 대상으로 설정됩니다.

7. 게이트웨이와 VirtualService가 생성되었는지 확인하고 VirtualService가 게이트웨이를 가리키는지 확인합니다.

   kubectl get gateway,virtualservice

8. 이 외부 IP를 Cloud Shell 환경에 저장합니다.

   export GATEWAY_URL=$(kubectl get svc -n ingress istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}') echo The gateway address is $GATEWAY_URL

참고: 게이트웨이 주소가 비어 있으면 1~2분 정도 기다린 후 마지막 명령어를 다시 시도하세요. $GATEWAY_URL 변수에 주소가 표시될 때까지 이 작업을 실행합니다.

백그라운드 트래픽 생성

Service Mesh 대시보드를 탐색할 때 흥미로운 데이터가 있도록 애플리케이션에 대한 백그라운드 트래픽을 생성합니다.

1. Cloud Shell에서 부하 생성 도구인 siege를 설치합니다.

   sudo apt install siege

2. siege를 사용하여 서비스에 대한 트래픽을 만듭니다.

   siege http://${GATEWAY_URL}/productpage

BookInfo 애플리케이션에 액세스

1. Cloud Shell에서 Cloud Shell 메뉴 바의 + 아이콘을 클릭하여 다른 탭을 엽니다.

2. Zone 환경 변수를 설정합니다.

   CLUSTER_ZONE={{{ project_0.default_zone| "Zone added at lab start" }}}

3. 새 Cloud Shell 탭을 초기화합니다.

   export CLUSTER_NAME=gke export GCLOUD_PROJECT=$(gcloud config get-value project) gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT export GATEWAY_URL=$(kubectl get svc istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}' -n ingress)

4. 클러스터 내의 포드(예: ratings)에서 Bookinfo 애플리케이션으로 curl 요청을 전송하여 Bookinfo 애플리케이션이 응답하는지 확인합니다.

   kubectl exec -it \ $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') \ -c ratings -- curl productpage:9080/productpage \ | grep -o "<title>.*</title>"

   출력:

   <title>Simple Bookstore App</title>

5. 이전에 저장한 외부 IP를 사용하여 클러스터 외부에서 전송된 curl 요청에 Bookinfo 앱이 응답하는지 확인합니다.

   curl -I http://${GATEWAY_URL}/productpage

   출력:

   HTTP/1.1 200 OK content-type: text/html; charset=utf-8 content-length: 5293 server: istio-envoy date: Wed, 01 Feb 2023 13:28:58 GMT x-envoy-upstream-service-time: 27

6. 브라우저에서 Bookinfo 애플리케이션을 엽니다. Cloud Shell에서 다음 명령어를 실행하여 전체 URL을 가져옵니다.

   echo http://${GATEWAY_URL}/productpage

수고하셨습니다. Bookinfo productpage 서비스의 HTTP 엔드포인트를 외부 트래픽에 노출했습니다. 게이트웨이 구성 리소스를 사용하면 외부 트래픽이 서비스 메시로 유입되고 에지 서비스에 트래픽 관리 및 정책 기능을 사용할 수 있습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 게이트웨이를 설치하여 인그레스를 사용 설정합니다.

작업 4. Service Mesh 대시보드를 사용하여 여러 버전으로의 라우팅 보기

Service Mesh 대시보드에서 데이터를 볼 때는 몇 가지 사항을 참고해야 합니다.

첫 번째는 대부분의 페이지에서 데이터가 표시되기까지 1~2분이 걸린다는 것입니다. 즉, 예상한 데이터가 페이지에 1~2분 동안 표시되지 않을 수 있습니다. 원하는 데이터가 표시되지 않으면 1분 정도 기다렸다가 페이지를 새로고침하세요.

또한 토폴로지 페이지에서는 데이터가 표시되기 전에 긴 초기 지연이 있습니다. 초기 데이터 세트를 사용할 수 있게 되기까지 5분 이상 걸릴 수 있습니다. 데이터가 없다는 메시지가 표시되면 잠시 기다린 후 페이지를 새로고침하고 토폴로지 보기로 돌아갑니다.

이전 단락에서는 기다렸다가 페이지를 새로고침하라고 안내합니다. 데이터가 도착하는 데 약간의 지연이 있을 뿐만 아니라 페이지를 새로고침하지 않으면 사용 가능한 데이터가 표시되지 않는 페이지도 많습니다. 제공될 것으로 예상한 데이터가 표시되지 않으면 브라우저에서 페이지를 새로고침하세요.

표 보기에서 라우팅 정보 보기

1. 탐색 메뉴에서 Kubernetes Engine > 기능 > Service Mesh를 선택합니다.

   

참고: 토폴로지 보기가 표시되지 않으면 브라우저 창을 새로고침하세요.

2. productpage 서비스를 클릭한 다음 왼쪽에 있는 연결된 서비스를 선택합니다.

3. 아웃바운드 탭을 선택하고 productpage 포드에서 호출하는 두 서비스를 확인합니다.

4. reviews 서비스를 클릭합니다.

   

5. 서비스 통계를 기록한 다음 왼쪽 메뉴에서 인프라 링크를 선택합니다.

reviews 서비스로 전송된 트래픽을 수신하는 여러 포드가 reviews 로직의 서로 다른 버전을 실행하고 있음을 알 수 있습니다.

6. 왼쪽 메뉴에서 트래픽을 클릭하면 다른 트래픽 분산 보기를 확인할 수 있습니다.

   

   애플리케이션 로직의 서로 다른 버전을 실행하는 세 개의 백엔드 포드에 트래픽이 비교적 균등하게 분산되어 있는 것을 확인할 수 있습니다.

토폴로지 보기에서 라우팅 정보 보기

1. 왼쪽 상단에 있는 Service Mesh 로고를 클릭하여 기본 대시보드 페이지로 돌아갑니다.

참고: 그래프에 사용할 수 있는 데이터가 없다는 오류 메시지가 표시되거나 예상 트래픽 중 일부가 포함되지 않은 차트가 표시되면 1~2분 정도 기다린 후 다시 시도하세요.

2. 다음 항목을 쉽게 볼 수 있도록 메시 그래프를 재정렬합니다.

   • productpage 서비스가 productpage 배포로 이동
   • productpage 배포가 reviews 서비스로 이동
   • reviews 서비스가 세 가지 버전의 reviews로 이동

   

3. reviews 서비스 노드를 클릭하고 각 백엔드 버전의 상대적 qps를 확인합니다.

   

작업 5. 사용 가능한 모든 버전에 기본 대상 규칙 적용

이 작업에서는 대상 규칙에서 사용 가능한 모든 버전(하위 집합이라고 함)을 정의합니다.

1. GitHub에 있는 구성을 검토합니다. 이 구성은 각 서비스마다 하나씩 총 4개의 DestinationRule 리소스를 정의합니다.

2. Cloud Shell에서 다음 명령어를 사용하여 구성을 적용합니다.

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/destination-rule-all.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' destination-rule-all.yaml kubectl apply -f destination-rule-all.yaml

   출력:

   destinationrule.networking.istio.io/productpage created destinationrule.networking.istio.io/reviews created destinationrule.networking.istio.io/ratings created destinationrule.networking.istio.io/details created

3. DestinationRule 리소스 4개가 정의되었는지 확인합니다.

   kubectl get destinationrules

   출력:

   NAME HOST AGE details details 1m productpage productpage 1m ratings ratings 1m reviews reviews 1m

4. 대상 규칙의 세부정보를 검토합니다.

   kubectl get destinationrules -o yaml

   subsets는 DestinationRule의 spec 내에 정의됩니다.

5. 1~2분 정도 기다린 후 Service Mesh 대시보드로 돌아갑니다.

6. 표 보기와 토폴로지 보기를 모두 살펴보고 트래픽이 세 가지 백엔드 버전에 계속 균등하게 분산되는지 확인합니다. 타임라인 표시를 클릭하여 차트에 표시되는 기간을 조정하면 관심 있는 데이터를 더 쉽게 파악할 수 있습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 대상 규칙을 적용합니다.

작업 6. 기본적으로 하나의 버전으로만 라우팅되도록 가상 서비스 적용

이 작업에서는 모든 트래픽을 서비스 워크로드의 v1로 라우팅하는 각 서비스에 가상 서비스를 적용합니다.

1. GitHub에 있는 구성을 검토합니다. 이 구성은 각 서비스마다 하나씩 총 4개의 VirtualService 리소스를 정의합니다.

2. Cloud Shell에서 다음 명령어를 사용하여 구성을 적용합니다.

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-all-v1.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-all-v1.yaml kubectl apply -f virtual-service-all-v1.yaml

   출력:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

   구성 전파는 eventual consistency가 있으므로 가상 서비스가 적용될 때까지 몇 초 정도 기다립니다.

3. 4개의 경로인 VirtualService 리소스가 정의되었는지 확인합니다.

   kubectl get virtualservices

   출력:

   NAME GATEWAYS HOSTS AGE bookinfo ["ingress/bookinfo-gateway"] ["*"] 19m details ["details"] 6s productpage ["productpage"] 7s ratings ["ratings"] 6s reviews ["reviews"] 7s

4. Cloud Shell에서 인그레스 게이트웨이의 외부 IP 주소를 가져옵니다.

   echo $GATEWAY_URL

5. Bookinfo UI를 사용하여 새 라우팅 구성을 테스트합니다.

   • 브라우저에서 Bookinfo 사이트를 엽니다. URL은 http://[GATEWAY_URL]/productpage입니다. 여기서 GATEWAY_URL은 인그레스의 외부 IP 주소입니다.

   • 페이지를 여러 번 새로고침하여 요청을 여러 개 실행합니다.

   페이지의 도서 리뷰 부분은 몇 번을 새로고침하든 별표 평점 없이 표시됩니다. 이는 reviews 서비스의 모든 트래픽을 reviews:v1 버전으로 라우팅하도록 메시를 구성했기 때문이며 이 서비스 버전은 별표 평점 서비스에 액세스하지 않습니다.

6. 1~2분 정도 기다린 후 탐색 메뉴 > Kubernetes Engine > Service Mesh > reviews > 인프라로 이동하여 Service Mesh 대시보드로 돌아갑니다.

7. 타임라인 표시를 선택하고 트래픽의 마지막 5분에 차트의 포커스를 맞춥니다. 트래픽이 균등하게 분산되다가 버전 1 워크로드로 100% 라우팅되는 것을 확인할 수 있습니다.

   

   트래픽 탭 또는 토폴로지 보기를 확인하여 새로운 트래픽 분산을 확인할 수도 있습니다. 하지만 두 가지 방법 모두 데이터가 표시되기까지 몇 분 정도 걸립니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 가상 서비스를 적용합니다.

작업 7. 사용자 ID에 따라 특정 버전의 서비스로 라우팅

이 작업에서는 특정 사용자의 모든 트래픽이 특정 서비스 버전으로 라우팅되도록 경로 구성을 변경합니다. 이 경우 jason 사용자의 모든 트래픽은 별표 평점 기능이 포함된 버전인 reviews:v2 서비스로 라우팅됩니다.

참고: Istio에는 사용자 ID에 관한 특별한 인식 기능이 내장되어 있지 않습니다. 이 예시가 가능한 이유는 productpage 서비스가 reviews 서비스에 대한 모든 아웃바운드 HTTP 요청에 커스텀 최종 사용자 헤더를 추가하기 때문입니다.

1. GitHub에 있는 구성을 검토합니다. 이 구성은 VirtualService 리소스 1개를 정의합니다.

2. Cloud Shell에서 다음 명령어를 사용하여 구성을 적용합니다.

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-test-v2.yaml kubectl apply -f virtual-service-reviews-test-v2.yaml

   출력:

   virtualservice.networking.istio.io/reviews configured

3. 규칙이 생성되었는지 확인합니다.

   kubectl get virtualservice reviews

   출력:

   NAME GATEWAYS HOSTS AGE reviews ["reviews"] 35m

4. Bookinfo UI를 사용하여 새 라우팅 구성을 테스트합니다.

   • Bookinfo 애플리케이션의 /productpage로 다시 이동합니다.

   • 이번에는 로그인을 클릭하고 비밀번호를 사용하여 jason이라는 사용자 이름을 사용합니다.

   • UI에 ratings 서비스의 별표가 표시됩니다.

   로그아웃한 후 다른 사용자로 로그인해 볼 수 있습니다. 리뷰에 별표가 더 이상 표시되지 않습니다.

새 트래픽 라우팅의 효과를 더 잘 시각화하려면 서비스에 대한 인증된 요청의 새 백그라운드 부하를 만들면 됩니다.

5. 첫 번째 세션의 트래픽 중 20%만 생성하되 모든 요청이 jason으로 인증되는 새로운 siege 세션을 시작합니다.

   curl -c cookies.txt -F "username=jason" -L -X \ POST http://$GATEWAY_URL/login cookie_info=$(grep -Eo "session.*" ./cookies.txt) cookie_name=$(echo $cookie_info | cut -d' ' -f1) cookie_value=$(echo $cookie_info | cut -d' ' -f2) siege -c 5 http://$GATEWAY_URL/productpage \ --header "Cookie: $cookie_name=$cookie_value"

6. 1~2분 정도 기다린 후 인프라 원격 분석을 보여주는 페이지를 새로고침하고, 현재 시간이 표시되도록 타임라인을 조정한 다음 Service Mesh 대시보드를 확인합니다. 지난 몇 분 동안의 요청 중 약 85%가 인증되지 않았기 때문에 버전 1로 이동한 것을 확인할 수 있습니다. jason으로 인증된 약 15%가 버전 2로 이동했습니다.

7. Cloud Shell에서 Ctrl+c를 입력하여 siege 세션을 취소합니다.

8. 애플리케이션 가상 서비스를 삭제하여 이 작업에서 정리합니다.

   kubectl delete -f virtual-service-all-v1.yaml

   출력:

   virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

9. 1~2분 정도 기다린 후 Service Mesh 대시보드를 새로고침하고, 현재 시간이 표시되도록 타임라인을 조정하고, 트래픽이 버전 간에 다시 균등하게 분산되는지 확인합니다.

   

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 사용자별 라우팅 구성

작업 8. 한 마이크로서비스 버전에서 다른 버전으로 트래픽을 점진적으로 전환

이 작업에서는 한 버전의 마이크로서비스에서 다른 버전의 마이크로서비스로 트래픽을 점진적으로 마이그레이션합니다. 예를 들어 이 방법을 사용하여 이전 버전에서 새 버전으로 트래픽을 이전할 수 있습니다.

트래픽의 50%는 reviews:v1로, 50%는 reviews:v3로 전송됩니다. 그런 다음 트래픽의 100%를 reviews:v3로 전송하여 마이그레이션을 완료합니다.

Service Mesh에서는 트래픽의 일부를 한 서비스 또는 다른 서비스로 라우팅하는 규칙 시퀀스를 구성하여 이 목표를 달성합니다.

1. Cloud Shell에서 모든 트래픽을 각 서비스의 v1 버전으로 라우팅합니다.

   kubectl apply -f virtual-service-all-v1.yaml

   출력:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. Bookinfo 애플리케이션의 /productpage로 다시 이동하고 리뷰에 별표가 표시되지 않는지 확인합니다. 모든 트래픽이 v1 백엔드로 라우팅됩니다.

3. 1분 정도 기다린 후 Service Mesh 대시보드를 새로고침하고, 타임라인을 조정하여 현재 시간을 표시한 다음, 모든 트래픽이 v1 백엔드로 라우팅되었는지 확인합니다.

4. 트래픽의 50%를 reviews:v1에서 reviews:v3로 이전합니다.

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-50-v3.yaml kubectl apply -f virtual-service-reviews-50-v3.yaml

   출력:

   virtualservice.networking.istio.io/reviews configured

5. Bookinfo 애플리케이션의 /productpage로 다시 이동합니다.

6. 보기를 새로고침하여 요청을 여러 개 실행합니다.

   v1의 별표가 없는 reviews 및 ratings 서비스에 액세스하는 v3의 빨간색 별점이 있는 리뷰가 거의 균등하게 분산되어 있습니다.

7. 1분 정도 기다린 후 페이지를 새로고침하고, 현재 시간이 표시되도록 타임라인을 조정하고, Service Mesh 대시보드에서 reviews 서비스로의 트래픽이 v1과 v3 간에 50/50으로 분할되었는지 확인합니다.

   

8. 트래픽의 나머지 50%를 reviews:v3로 전송합니다.

9. reviews:v3 서비스가 안정적이라고 판단되면 다음 가상 서비스를 적용하여 트래픽의 100%를 reviews:v3로 라우팅합니다.

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking//virtual-service-reviews-v3.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-v3.yaml kubectl apply -f virtual-service-reviews-v3.yaml

   출력:

   virtualservice.networking.istio.io/reviews configured

10. Bookinfo UI를 사용하여 새 라우팅 구성을 테스트합니다.

11. Bookinfo 애플리케이션의 /productpage로 다시 이동합니다.

12. /productpage를 새로고침합니다. 각 리뷰에 빨간색 별표 평점이 있는 도서 리뷰가 항상 표시됩니다.

13. 1분 정도 기다린 후 페이지를 새로고침하고 Service Mesh 대시보드에서 reviews 서비스로 향하는 모든 트래픽이 v3로 전송되는지 확인합니다.

    

14. 애플리케이션 가상 서비스를 삭제하여 이 연습을 정리합니다.

    kubectl delete -f virtual-service-all-v1.yaml

    출력:

    virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

이 작업에서는 Service Mesh의 가중치가 부여된 라우팅 기능을 사용하여 reviews 서비스의 이전 버전에서 새 버전으로 트래픽을 마이그레이션했습니다. 이는 인스턴스 조정을 통해 트래픽을 관리하는 컨테이너 조정 플랫폼의 배포 기능을 사용하여 버전 마이그레이션을 수행하는 것과는 매우 다릅니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. v1에서 v3로 트래픽을 마이그레이션합니다.

작업 9. 서비스 응답을 무한정 기다리지 않도록 제한 시간 추가

HTTP 요청 시간 제한은 라우팅 규칙의 시간 제한 필드를 사용하여 지정할 수 있습니다. 기본적으로 요청 제한 시간은 사용 중지되어 있지만 이 작업에서는 reviews 서비스 제한 시간을 1초로 재정의합니다. 하지만 효과를 확인하려면 ratings 서비스 호출에 인위적인 2초 지연도 도입해야 합니다. 먼저 지연을 적용하겠습니다.

1. Cloud Shell에서 모든 트래픽을 각 서비스의 v1 버전으로 라우팅합니다.

   kubectl apply -f virtual-service-all-v1.yaml

   출력:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. reviews 서비스의 v2, 즉, ratings 서비스를 호출하는 버전으로 요청을 라우팅합니다.

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v2 EOF

3. ratings 서비스 호출에 2초 지연을 추가합니다.

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - fault: delay: percent: 100 fixedDelay: 2s route: - destination: host: ratings subset: v1 EOF

4. 브라우저에서 Bookinfo URL http://$GATEWAY_URL/productpage을 엽니다. Bookinfo 애플리케이션이 정상적으로 작동하지만(별표 평점이 표시됨) 페이지를 새로고침할 때마다 2초의 지연이 발생합니다. (Bookinfo 애플리케이션이 정상적으로 작동하지 않으면 지연 시간을 1초로 변경하고 다시 시도하세요.)

5. reviews / metrics로 이동하여 지연 시간이 2초로 급증하는지 확인합니다. (지연 시간을 1초로 변경한 경우에는 지연 시간이 1초로 급증해야 합니다.)

   

6. 이제 reviews 서비스 호출에 0.5초의 요청 제한 시간을 추가합니다.

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v2 timeout: 0.5s EOF

7. Bookinfo 웹페이지를 새로고침합니다.

이제 2초 대신 약 1초 만에 반환되고 리뷰를 사용할 수 없다는 것을 알 수 있습니다.

참고: 제한 시간이 0.5초로 구성되어 있는데도 응답에 1초가 걸리는 이유는 productpage 서비스에 하드 코딩된 재시도가 있어서 반환 전에 제한 시간이 초과된 reviews 서비스를 두 번 호출하기 때문입니다. 재시도 설정을 변경하려면 아래에 표시된 명령어를 실행하여 VirtualService를 구성합니다. kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: productpage spec: hosts: - productpage http: - route: - destination: host: productpage subset: v1 retries: attempts: 1 perTryTimeout: 2s EOF

8. 애플리케이션 가상 서비스를 삭제하여 이 연습을 정리합니다.

   kubectl delete -f virtual-service-all-v1.yaml

   출력:

   virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

이 작업에서는 Istio를 사용하여 reviews 마이크로서비스 호출의 요청 제한 시간을 0.5초로 설정했습니다. 기본적으로 요청 시간 제한은 사용 중지되어 있습니다. reviews 서비스는 나중에 요청을 처리할 때 ratings 서비스를 호출하므로 Istio를 사용하여 ratings 호출에 2초 지연을 주입하고 reviews 서비스가 완료되는 데 0.5초 이상 걸리도록 했으므로 제한 시간이 작동하는 것을 확인할 수 있습니다.

페이지를 채우기 위해 reviews 서비스를 호출하는 Bookinfo 제품 페이지에 리뷰가 표시되는 대신 '죄송합니다. 현재 이 도서에 대한 제품 리뷰를 사용할 수 없습니다'라는 메시지가 표시되었습니다. 이는 reviews 서비스에서 시간 제한 오류를 수신했기 때문입니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. ratings 서비스에 대한 제한 시간을 추가합니다.

작업 10. 회로 차단기를 추가하여 마이크로서비스의 복원력 향상

이 작업에서는 연결, 요청, 이상치 감지를 위한 회로 차단을 구성하는 방법을 보여줍니다.

회로 차단은 복원력이 뛰어난 마이크로서비스 애플리케이션을 만드는 데 중요한 패턴입니다. 회로 차단을 사용하면 장애, 지연 시간 급증, 기타 바람직하지 않은 네트워크 특성의 영향을 제한하는 애플리케이션을 작성할 수 있습니다.

이 작업에서는 회로 차단 규칙을 구성한 다음 회로 차단기를 의도적으로 '트립'하여 구성을 테스트합니다.

1. Cloud Shell에서 모든 트래픽을 각 서비스의 v1 버전으로 라우팅합니다.

   kubectl apply -f virtual-service-all-v1.yaml

   출력:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. productpage 서비스를 호출할 때 회로 차단 설정을 적용하는 대상 규칙을 만듭니다.

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: productpage spec: host: productpage subsets: - name: v1 labels: version: v1 trafficPolicy: connectionPool: tcp: maxConnections: 1 http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 outlierDetection: consecutive5xxErrors: 1 interval: 1s baseEjectionTime: 3m maxEjectionPercent: 100 EOF

3. Cloud Shell에서 첫 번째 탭으로 이동하여 Ctrl+c를 실행하여 siege를 중지합니다.

4. productpage 서비스로 트래픽을 전송할 클라이언트를 만듭니다.

클라이언트는 fortio라는 간단한 부하 테스트 클라이언트입니다. Fortio를 사용하면 발신 HTTP 호출의 연결 수, 동시 실행, 지연을 제어할 수 있습니다. 이 클라이언트를 사용하여 DestinationRule에 설정된 회로 차단기 정책을 '트립'합니다.

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.9/samples/httpbin/sample-client/fortio-deploy.yaml

5. 클라이언트 포드에 로그인하고 fortio 도구를 사용하여 productpage를 호출합니다. 호출을 한 번만 수행하도록 지정하려면 curl을 전달하세요.

   export FORTIO_POD=$(kubectl get pods -lapp=fortio -o 'jsonpath={.items[0].metadata.name}') kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio curl -quiet http://${GATEWAY_URL}/productpage

6. 동시 연결 2개(-c 2)로 서비스를 호출하고 요청 20개(-n 20)를 전송합니다.

   kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 2 -qps 0 -n 20 -loglevel Warning http://${GATEWAY_URL}/productpage

   거의 모든 요청이 처리된 것을 확인할 수 있습니다. maxConnections: 1 및 http1MaxPendingRequests: 1이라는 점이 흥미롭습니다. 이러한 규칙은 연결이 두 개를 초과하고 요청이 동시에 수행되는 경우 istio-proxy가 추가 요청 및 연결을 위해 회로를 열 때 오류가 표시되어야 함을 나타냅니다.

   하지만 istio-proxy는 어느 정도 여유를 허용합니다.

   Code 200 : 17 (85.0 %) Code 503 : 3 (15.0 %)

7. 동시 연결 수를 최대 3까지 늘립니다.

   kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 3 -qps 0 -n 30 -loglevel Warning http://${GATEWAY_URL}/productpage

   이제 올바른 회로 차단 동작이 표시됩니다. 요청의 36.7%만 성공하고 나머지는 회로 차단에 의해 차단되었습니다.

   Code 200 : 11 (36.7 %) Code 503 : 19 (63.3 %)

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 회로 차단기를 추가합니다.

검토

이 실습에서는 다양한 목적에 사용되는 트래픽을 관리하고 라우팅하는 여러 가지 방법을 알아보았습니다. 또한 요청 헤더를 확인하는 일부 계층 7, 애플리케이션 계층, 라우팅을 비롯하여 트래픽 이동을 직접 조정하고 확인하는 실험도 진행했습니다.

다음 단계

• Istio 트래픽 관리에 대해 자세히 알아보기
• Istio에서 Istio를 사용한 카나리아 배포에 대해 자세히 알아보기

실습 종료하기

실습을 완료하면 실습 종료를 클릭합니다. Google Skills에서 사용된 리소스를 자동으로 삭제하고 계정을 지웁니다.

실습 경험을 평가할 수 있습니다. 해당하는 별표 수를 선택하고 의견을 입력한 후 제출을 클릭합니다.

별점의 의미는 다음과 같습니다.

• 별표 1개 = 매우 불만족
• 별표 2개 = 불만족
• 별표 3개 = 중간
• 별표 4개 = 만족
• 별표 5개 = 매우 만족

의견을 제공하고 싶지 않다면 대화상자를 닫으면 됩니다.

의견이나 제안 또는 수정할 사항이 있다면 지원 탭을 사용하세요.

Copyright 2026 Google LLC All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.