이스티오 (Istio) 자습서 v0.5.0

이스티오 (Istio)
이스티오를 설명하는 자습서 (v0.5.0)

이스티오는 서비스 메시 도구로서 트래픽 관리, 옵저빌리티와 같은 기능을
제공합니다. istioctl을 통해 간편하게 설치할 수 있으며, CRD를 통해서도 설치가
가능하다는 장점이 있습니다. VirtualService와 Gateway를 통해 인그레스 트래픽을
처리할 수 있으며, 중간에 filter를 활용해서 트래픽 제어가 가능합니다. 같이 배포되는
키알리(Kiali)i 대시보드를 통해 서비스 트래픽 흐름을 웹 UI로 확인할 수 있습니다.
이스티오 사용 시 사이드카 패턴을 파드에 적용하여 엔보이(Envoy) 프록시가 붙기 때문에
CPU나 메모리 추가로 리소스를 사용한다는 우려가 있습니다. 최근 추가된 기능인
이스티오 엠비언트 메시(Ambient Mesh) 를 통해서 엔보이 프록시가 사이드카 패턴으로
파드에 붙는 구조가 아닌 노드에 ztunnel(제로 트러스트 터널)이라는 데몬을 통해서,
쿠버네티스 클러스터가 사용가능한 CPU와 메모리를 절감하면서 서비스 메시 구성이
가능합니다.
[그림 1] 키알리 대시보드를 통해서 확인되는 서비스 트래픽 흐름
1. 이스티오 배포
이스티오를 배포하는 방법은 크게 2가지로 나눌 수 있습니다.
2

직접 배포하거나, 관리형 또는 설치형으로 패키지되어 있는 제품을 사용하는 것입니다.
[그림 2] 업체마다 관리형 또는 설치형으로 패키지되어 있는 이스티오
(https://istio.io/latest/about/ecosystem/)
따라서 이 문서에서는 범용성을 위해서 직접 설치/배포 하는 방법으로 진행하도록 하겠습니다.
1.1. 이스티오 요구 사항
이스티오 설치를 위해 다양한 요구 사항이 있으나, 대부분의 CSP 및 on-prem 환경에서는 이를
충족합니다. 하지만 구성에 따라 Port를 선택적으로 구성해야 해야 할 수 있으니 확인을
먼저하는 것이 좋습니다.
3

일반적으로 이 부분 보다 구성시에 생각보다 많이 발생하는 CPU와 Memory에 대한 고려가
필요하며, 이스티오 구성시에 함께 구성되는 애플리케이션에 대한 고려가 더 중요합니다.
예를 들면 프로메테우스(Prometheus)가 기존에 배포된 것이 있다면 이스티오 구성에서 이를
제외하고 기존 것에서 메트릭을 가지고 오도록 구성해야 합니다.
이스티오 1.16.1을 기준으로 이스티오 배포시에 다음과 같은 리소스를 사용하며,
애플리케이션에 따라 사용하는 리소스는 균등하게 증가하게 됩니다.
이스티오 설치 전 (e2-standard-2 / 2 vCPU, 8GB)
➜ ~ (☸️ |hj-istio-classic:default) kubectl top node --use-protocol-buffers
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
gke-istio-classic-p-e5ef5921-o0yt 112m 5% 668Mi 11%
gke-istio-classic-p-e5ef5921-osfg 68m 3% 611Mi 10%
gke-istio-classic-p-e5ef5921-vp1c 68m 3% 616Mi 10%
이스티오 설치 후 (e2-standard-8 / 8 vCPU, 32GB)
➜ ~ (☸️ |hj-gke-istio:default) k top node --use-protocol-buffers
NAME CPU(cores) CPU% MEMORY(bytes)
MEMORY%
gke-istio-pool-default-pool-79cada87-8x1m 99m 1% 817Mi 2%
gke-istio-pool-default-pool-79cada87-r03v 110m 1% 800Mi 2%
1.2. 이스티오 배포 모델
이스티오는 다음과 같이 단일 클러스터로 구성도 가능합니다.
[그림 3] 1개의 서비스 메시로 단일 클러스터를 관리
4

하지만 실무 환경에서 고가용성(HA, High Availability)를 고려한다면 멀티 클러스터 구성하는
것이 좋습니다.
[그림 4] 1개의 서비스 메시로 멀티 클러스터를 관리
5

이에 대한 자세한 예제는 다음의 링크를 참조하시기 바랍니다.
1.3. 이스티오 설치
이스티오는 일반적으로 istioctl을 통해서 진행합니다.
따라서 istioctl 바이너리를 내려받아야 하는데, 다음과 같은 방법으로 이를 내려 받습니다.
1.3.1 내려받을 디렉터리로 이동합니다. 현재는 홈디렉터리를 이용합니다.
➜ ~ (☸️ |hj-istio-classic:default) cd ~
1.3.2 istioctl을 포함한 패키지를 내려받습니다.
➜ ~ (☸️ |hj-istio-classic:default) curl -L https://istio.io/downloadIstio
| ISTIO_VERSION=1.16.1 TARGET_ARCH=x86_64 sh -
6

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 101 100 101 0 0 366 0 --:--:-- --:--:-- --:--:-- 378
100 4856 100 4856 0 0 8028 0 --:--:-- --:--:-- --:--:-- 8028
Downloading istio-1.16.1 from
https://github.com/istio/istio/releases/download/1.16.1/istio-1.16.1-osx.tar.gz ...
Istio 1.16.1 Download Complete!
Istio has been successfully downloaded into the istio-1.16.1 folder on your system.
Next Steps:
See https://istio.io/latest/docs/setup/install/ to add Istio to your Kubernetes
cluster.
To configure the istioctl client tool for your workstation,
add the /Users/mz01-hj/tmp/istio-1.16.1/bin directory to your environment path
variable with:
export PATH="$PATH:/Users/mz01-hj/tmp/istio-1.16.1/bin"
Begin the Istio pre-installation check by running:
istioctl x precheck
Need more information? Visit https://istio.io/latest/docs/setup/install/
1.3.3 내려받은 디렉터리로 이동한 후에 istioctl을 바로 실행할 수 있도록 istioctl을 실행
디렉터리에 복사합니다.
➜ ~ (☸️ |hj-istio-classic:default) cd istio-1.16.1
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) cp bin/istioctl
/usr/local/bin
1.3.4 구성된 istioctl을 버전을 확인하기 위해서 istioctl을 실행합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl version
no running Istio pods in "istio-system"
1.16.1
7

(optional) 설치 전에 현재 클러스터에 istio를 설치하는데 문제가 있는지 파악하길 원한다면,
다음의 명령어를 수행하시기 바랍니다. .
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl x precheck
✔ No issues found when checking the cluster. Istio is safe to install or upgrade!
To get started, check out https://istio.io/latest/docs/setup/getting-started/
1.3.5 이스티오 설치
이스티오 설치에는 demo 프로파일(profile)을 사용하지만, 테스트 성격에 따라 더 적은 구성
요소를 설치하는 프로파일을 선택할 수 있습니다. 예를 들면 default 프로파일로 진행하는
경우에는 istio-egressgateway가 설치되지 않습니다. 이에 대한 자세한 내용은 설치 후에 설정
부분에서 살펴 보겠습니다.
[표 1] 이스티오 프로파일 별 설치되는 구성 요소 (링크)
또한 openshift 와 같은 특정 플랫폼에 적합한 프로파일도 선택 가능합니다.
[그림 5] 이스티오 구성을 위한 플랫폼 별 가이드 (링크)
8

그러면 demo 프로파일을 통해서 이스티오를 설치합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl install --set profile=demo
-y
✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Egress gateways installed
✔ Installation complete
Making this installation the default for injection and validation.
Thank you for installing Istio 1.16. Please take a few minutes to tell us about
your install/upgrade experience! https://forms.gle/99uiMML96AmsXY5d6
1.3.6 이스티오가 default 네임스페이스 내에서 동작할 수 있도록 설정
정확히 말하자면 default 네임스페이스 엔보이(Envoy)로 이루어진 사이드카(Sidecar)를
자동으로 삽입할 수 있도록 설정하는 것인데, 필요하다면 수동으로 이를 주입할 수 있습니다.
이에 대해서는 다음의 문서를 참고하시기 바랍니다.
9

➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl label namespace default
istio-injection=enabled
namespace/default labeled
1.3.7 설치된 이스티오 구성 요소 확인
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get po,svc -n istio-system
NAME READY STATUS RESTARTS AGE
pod/istio-egressgateway-79598956cf-bk5t6 1/1 Running 0 118s
pod/istio-ingressgateway-854c9d9c5f-zpkvr 1/1 Running 0 118s
pod/istiod-fd94754fb-6j6bd 1/1 Running 0 2m7s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
AGE
service/istio-egressgateway ClusterIP 10.112.12.251 <none> 80/TCP,443/TCP
118s
service/istio-ingressgateway LoadBalancer 10.112.12.147 34.67.165.125
15021:32058/TCP,80:31561/TCP,443:30443/TCP,31400:30750/TCP,15443:30994/TCP 118s
service/istiod ClusterIP 10.112.15.136 <none>
15010/TCP,15012/TCP,443/TCP,15014/TCP 2m7s
1.4. 이스티오 동작 확인을 위한 샘플 애플리케이션 배포 및 노출
이스티오의 구성 요소들이 동작하는 것을 확인하기 위해서 샘플 애플리케이션을 배포해
보겠습니다.
배포할 애플리케이션은 이스티오에서 공식적으로 제공하는 bookinfo 이며, 아키텍처는 다음과
같습니다.
[그림 6] bookinfo 애플리케이션 기본 아키텍처 [링크]
10

1.4.1 bookinfo 샘플 애플리케이션 배포
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f
samples/bookinfo/platform/kube/bookinfo.yaml
service/details created
serviceaccount/bookinfo-details created
deployment.apps/details-v1 created
service/ratings created
serviceaccount/bookinfo-ratings created
deployment.apps/ratings-v1 created
service/reviews created
serviceaccount/bookinfo-reviews created
deployment.apps/reviews-v1 created
11

service/productpage created
serviceaccount/bookinfo-productpage created
deployment.apps/productpage-v1 created
[그림 7] bookinfo 애플리케이션에 이스티오 구성 요소가 추가된 아키텍처 [링크]
1.4.2 배포한 bookinfo 애플리케이션 확인
pod/details-v1-5ffd6b64f7-z8drw 2/2 Running 0 38s
pod/productpage-v1-979d4d9fc-q7vgf 2/2 Running 0 34s
pod/ratings-v1-5f9699cfdf-4p7rn 2/2 Running 0 37s
pod/reviews-v1-569db879f5-h2c2m 2/2 Running 0 36s
pod/reviews-v2-65c4dc6fdc-k4mhx 2/2 Running 0 35s
pod/reviews-v3-c9c4fb987-bcktq 2/2 Running 0 35s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/details ClusterIP 10.112.12.255 <none> 9080/TCP 39s
service/kubernetes ClusterIP 10.112.0.1 <none> 443/TCP 136m
service/productpage ClusterIP 10.112.1.204 <none> 9080/TCP 35s
12

service/ratings ClusterIP 10.112.11.95 <none> 9080/TCP 38s
service/reviews ClusterIP 10.112.1.237 <none> 9080/TCP 37s
1.4.3 클러스터 내부에서 배포된 앱의 웹페이지가 보이는지 확인
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl exec
"$(kubectl get pod -l app=ratings -o
jsonpath='{.items[0].metadata.name}')" -c ratings -- curl -sS
productpage:9080/productpage | grep -o "<title>.*</title>"
<title>Simple Bookstore App</title>
1.4.4 외부에서 접속할 수 있도록 애플리케이션을 노출
기본(classic)에서는 apiVersion: networking.istio.io를 사용하지만, 중장기적으로는
apiVersion: gateway.networking.k8s.io를 사용할 것으로 예상됩니다. gateway로 구성하는
예제는 부록을 참고하시기 바랍니다.
[그림 7] Istio Ingress Gateway (링크)
13

이스티오 ingress gateway를 통해서 배포된 앱이 접속되도록 Istio Gateway와 VirtualService를
설정합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f
samples/bookinfo/networking/bookinfo-gateway.yaml
gateway.networking.istio.io/bookinfo-gateway created
virtualservice.networking.istio.io/bookinfo created
1.4.5 배포된 Istio Gateway와 VirtualService 설정을 확인
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get
gateways.networking.istio.io
NAME AGE
bookinfo-gateway 7m47s
virtualservices.networking.istio.io
NAME GATEWAYS HOSTS AGE
bookinfo ["bookinfo-gateway"] ["*"] 7m54s
14

1.4.6 이스티오에서 제공하는 분석 도구로 구성에 이슈가 없는지 분석
만약 다른 네임스페이스를 하고 싶다면 -n <네임스페이스 이름>을 통해서 가능합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl analyze
✔ No validation issues found when analyzing namespace: default.
Tip!☸ istio-injection=enabled 레이블이 활성화 되어 있지 않는다면, 다음과 같은 정보를
표시합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl analyze
Info [IST0102] (Namespace default) The namespace is not enabled for Istio
injection. Run 'kubectl label namespace default istio-injection=enabled' to enable
it, or 'kubectl label namespace default istio-injection=disabled' to explicitly
mark it as not needing injection.
1.4.7 외부에서 bookinfo에 접속할 수 있는 IP와 포트를 확인하기 위해 이미 배포된 이스티오
ingress gateway의 IP와 포트 정보를 다시 확인합니다. CSP따라 EXTERNAL-IP가 도메인 형태로
제공될 수 있습니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get svc -n
istio-system
AGE
istio-egressgateway ClusterIP 10.112.12.251 <none>
80/TCP,443/TCP 17h
istio-ingressgateway LoadBalancer 10.112.12.147 34.67.165.125
15021:32058/TCP,80:31561/TCP,443:30443/TCP,31400:30750/TCP,15443:30994/TCP 17h
istiod ClusterIP 10.112.15.136 <none>
15010/TCP,15012/TCP,443/TCP,15014/TCP 17h
1.4.8 배포된 bookinfo가 외부에서 보이는지 확인
IP와 포트를 확인했다면, 다음의 명령어로 출력 값이 정상적으로 뜨는지 확인합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) curl -s
http://34.67.165.125/productpage | grep /title
15

그리고 해당 IP와 포트를 웹브라우저에 입력해서 다음과 같은 화면이 나오는지 확인합니다.
[그림 8] bookinfo의 productpage
Tip!☸ IP와 포트등을 인자로 받아오기 위해서는 다음의 명령어를 사용해 보는 것도 좋습니다.
# IP로 되어 있는 경우
$ export INGRESS_HOST_IP=$(kubectl -n istio-system get service istio-ingressgateway
-o jsonpath='{.status.loadBalancer.ingress[0].ip}')
# Domain 이름으로 되어 있는 경우
export INGRESS_HOST_NAME=$(kubectl -n istio-system get service istio-ingressgateway
-o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
$ export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o
jsonpath='{.spec.ports[?(@.name=="http2")].port}')
$ export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service
istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].port}')
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) curl -s
http://$INGRESS_HOST_IP:$INGRESS_PORT/productpage | grep /title
1.5. 이스티오 동작을 좀 더 면밀하게 확인하기 위한 애드온 설치
16

애드온을 설치하는 가장 큰 목적은 이스티오를 통해서 파악된 마이크로 서비스 아키텍처(MSA)
형태의 애플리케이션의 통신 상태를 파악하고, 필요에 따라 이를 조치하고자 함에 있습니다.
이를 위해 도입부에서 언급한 키알리 대시보드와 그에 필요한 추가 OSS를 함께 설치하고
확인해 보겠습니다.
1.5.1 키알리 대시보드 노출 변경
기본 설정으로 배포하게 되면 키알리가 ClusterIP로 배포되기 때문에 접근을 위해서 다시
port-forward를 해줘야 하는 불편함이 있습니다. 그래서 노출을 LoadBalancer로 변경하기
위해서 다음의 스크립트를 실행합니다. *주의* 해당 설정은 이스티오 1.6.1에만 적용되므로
다른 버전을 사용하는 경우에는 직접 서비스를 변경해 주어야 합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) awk 'NR==424{print " type:
LoadBalancer # "}1' samples/addons/kiali.yaml > kiali+LB.yaml
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) cp kiali+LB.yaml
samples/addons/kiali.yaml
변경 후에 파일을 확인하면, 424번 줄에 LoadBalancer 설정이 추가되어 있음을 확인할 수
있습니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) cat samples/addons/kiali.yaml | nl
| grep LoadBalancer
424 type: LoadBalancer # Change from clusterIP to LoadBalancer
1.5.2 이스티오 애드온 설치
Kiali dashboard, Prometheus, Grafana 그리고 Jaeger 를 개별 설치 구성하길 원한다면,
개별 링크를 참조하시기 바랍니다. 그리고 Jaeger가 아니라 Zipkin으로 구성하길 원한다면,
samples/addons/extras/zipkin.yaml을 Jaeger 대신에 구성하길 바랍니다. 다만 이 경우
Jaeger-collector를 따로 구성해 줘야 합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f samples/addons
serviceaccount/grafana created
configmap/grafana created
17

service/grafana created
deployment.apps/grafana created
configmap/istio-grafana-dashboards created
configmap/istio-services-grafana-dashboards created
deployment.apps/jaeger created
service/tracing created
service/zipkin created
service/jaeger-collector created
serviceaccount/kiali created
configmap/kiali created
clusterrole.rbac.authorization.k8s.io/kiali-viewer created
clusterrole.rbac.authorization.k8s.io/kiali created
clusterrolebinding.rbac.authorization.k8s.io/kiali created
role.rbac.authorization.k8s.io/kiali-controlplane created
rolebinding.rbac.authorization.k8s.io/kiali-controlplane created
service/kiali created
deployment.apps/kiali created
serviceaccount/prometheus created
configmap/prometheus created
clusterrole.rbac.authorization.k8s.io/prometheus created
clusterrolebinding.rbac.authorization.k8s.io/prometheus created
service/prometheus created
deployment.apps/prometheus created
1.5.3 배포된 이스티오 애드온을 확인
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get po,svc -n istio-system
pod/grafana-56bdf8bf85-2hx5b 1/1 Running 0 3m19s
pod/istio-egressgateway-79598956cf-bk5t6 1/1 Running 0 24h
pod/istio-ingressgateway-854c9d9c5f-zpkvr 1/1 Running 0 24h
pod/istiod-fd94754fb-6j6bd 1/1 Running 0 24h
pod/jaeger-c4fdf6674-brk6r 1/1 Running 0 3m14s
pod/kiali-849958788-ghtxm 1/1 Running 0 2m55s
pod/prometheus-85949fddb-bt4lv 2/2 Running 0 2m46s
NAME TYPE CLUSTER-IP EXTERNAL-IP
PORT(S) AGE
service/grafana ClusterIP 10.112.7.128 <none>
3000/TCP 3m22s
service/istio-egressgateway ClusterIP 10.112.12.251 <none>
80/TCP,443/TCP 24h
service/istio-ingressgateway LoadBalancer 10.112.12.147 34.67.165.125
15021:32058/TCP,80:31561/TCP,443:30443/TCP,31400:30750/TCP,15443:30994/TCP 24h
service/istiod ClusterIP 10.112.15.136 <none>
18

15010/TCP,15012/TCP,443/TCP,15014/TCP 24h
service/jaeger-collector ClusterIP 10.112.8.242 <none>
14268/TCP,14250/TCP,9411/TCP 3m10s
service/kiali LoadBalancer 10.112.11.184 34.72.240.154
20001:31461/TCP,9090:32663/TCP 2m58s
service/prometheus ClusterIP 10.112.8.140 <none>
9090/TCP 2m48s
service/tracing ClusterIP 10.112.6.73 <none>
80/TCP,16685/TCP 3m13s
service/zipkin ClusterIP 10.112.6.194 <none>
9411/TCP 3m12s
Tip!☸ 배포된 구성 요소들을 개별적으로 접근해서 확인하고자 한다면, istioctl dashboard
<이름> 명령어를 통해서 Port Forward를 구성할 수 있습니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl dashboard grafana
http://localhost:3000
[그림 8] istioctl dashboard grafana를 통해서 접근한 그라파나 대시보드
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl dashboard prometheus
http://localhost:9090
19

[그림 9] istioctl dashboard prometheus를 통해서 접근한 프로메테우스 대시보드
1.5.4 배포된 키알리 대시보드에 접속해서 동작 상태를 확인
키알리 대시보드는 20001번 포트를 사용합니다.
[그림 10] 로드밸런서로 노출된 키알리 대시보드
1.5.5 키알리 대시보드의 Graph 메뉴로 이동하고 default 네임스페이스를 선택
현재는 발생한 부하가 없기 때문에 표시되는 애플리케이션 서비스 메시가 없는 것이
정상입니다.
[그림 11] 키알리 대시보드의 그래프 메뉴
20

1.5.6 부하발생기(loadgenerator)를 내려받고 실행
주소:
https://github.com/sysnet4admin/_Lecture_k8s_learning.kit/blob/main/A/A.011/01.istio/loa
dgenerator.sh
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) curl -LO
https://raw.githubusercontent.com/sysnet4admin/_Lecture_k8s_learning.kit/main/A/A.0
11/01.istio/loadgenerator.sh
100 240 100 240 0 0 906 0 --:--:-- --:--:-- --:--:-- 930
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) sh loadgenerator.sh
1.5.7 키알리 대시보드의 그래프 메뉴로 돌아가서 애플리케이션에 대한 서비스 메시가 잘
그려지는지 확인
[그림 12] 키알리 대시보드의 그래프 메뉴에 그려진 bookinfo 서비스 메시
21

Tip!☸ 다소 시간이 흐른 후에 확인했다면 위와 같은 화면을 볼 수 없기 때문에 이런 경우에는
다시 한번 loadgenerator.sh를 실행하고 키알리 대시보드를 확인하면 됩니다.
2. 이스티오 메뉴
이번에는 이스티오 메뉴들을 살펴보면서 이스티오에서 제공하는 서비스들을 살펴보도록
하겠습니다. 다만 일부 서비스들은 계속 트래픽이 발생하는 상태에서 동작이 확인되기 때문에
우선 현재 bookinfo에 메뉴를 살펴보는 동안 계속 트래픽이 발생하도록 설정하기 위해서
다음의 스크립트를 내려받고 실행합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) curl -LO
https://raw.githubusercontent.com/sysnet4admin/_Lecture_k8s_learning.kit/main/A/A.0
11/01.istio/loadgenerator-infinite.sh
100 308 100 308 0 0 7620 0 --:--:-- --:--:-- --:--:-- 9058
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) sh loadgenerator-infinite.sh
Press CTRL+C to stop...
22

이제 이스티오 메뉴를 살펴볼 준비가 모두 완료되었습니다.
2.1. Overview(처음 접속 화면)
처음 접속 화면에서는 네임스페이스 별로 간단한 상태를 확인할 수 있습니다.
따라서 상태를 확인할 수 있는 시간 범위 및 측정 단위 시간을 지정할 수 있습니다.
기본 값으로는 15초마다 상태 값을 수집하고 1분 전까지의 상태를 보여줍니다.
[그림 13] 키알리 대시보드의 접속 화면
[그림 14] 많은 네임스페이스가 생성되어 있는 쿠버네티스 클러스터
23

Tip!☸ 현재 버전에서 오른쪽 위에 발생하는 경보는 Grafana 정보를 가져오지 못해서 발생하는
것이며, 이는 매니페스트(Manifest)가 아닌 helm으로 배포시에 grafana의 주소를 추가함으로써
해결할 수 있습니다.
[그림 15] 키알리 대시보드의 메시지 센터에서 보이는 그라파나 URL 관련 에러
24

2.2. Graph
이스티오를 통해서 모니터링되는 애플리케이션들의 통신 구성을 네임스페이스 별로 확인할 수
있습니다.
또한 워크로드(Workloads)와 서비스(Services)를 아이콘 형태로 구분할 수 있으며, 묶여진
애플리케이션(Applications)도 쉽게 그래프에서 확인 가능합니다.
[그림 16] 키알리 대시보드의 그래프 메뉴
이렇게 확인된 아이콘을 누르게 되면. 아이콘에 해당 하는 연결 경로 및 추가적인 정보를 파악할
수 있습니다.
[그림 17] 키알리 대시보드의 그래프 메뉴에서 특정 워크로드(v2)를 선택한 경우 표시되는 화면
25

추가적으로 표시하는 방법을 다양하게 바꿀 수 있는데 그 중에서 Show Edge Labels - Traffic
Distribution, Traffic Rate, Show - Traffic Animation, Security를 눌러서 확인해 보면 어떤
역할을 하는지 시각적으로 알 수 있습니다.
[그림 18] 키알리 대시보드의 그래프 메뉴에서 표시 옵션을 추가한 경우 변경 표시되는 화면
26

2.3. Applications
이스티오를 통해서 모니터링되는 애플리케이션들 별로 사용되는 gateway와 virtualserivce를
알 수 있습니다.
[그림 19] 키알리 대시보드의 애플리케이션 메뉴
27

또한 자세히 보고자 원하는 애플리케이션을 선택하는 경우 Traffic, Metrics 그리고 Traces에
관한 자세한 내용도 함께 확인할 수 있습니다.
[그림 20] 애플리케이션 productpage의 Overview 메뉴
[그림 21] 애플리케이션 productpage의 Traffic, Inbound와Outbound Metrics 그리고
Traces
28

이 중에 특히 Traces는 애플리케이션의 병목(Bottleneck) 현상을 줄이고 성능 극대화 하는
자료로 매우 적합합니다. 이와 같은 Trace 관련 정보를 확인하기 위해서는 표시된 원형 Traces
중에 자세히 보고자 하는 것을 선택해서 누르게 되면, 자세한 Trace 내용 및 관련된 정보를
확인할 수 있습니다.
[그림 22] 특정 Trace의 자세한 내용
29

이것을 Span 단위로 확인하기 위해서는 바로 옆의 메뉴인 Span Details을 누르면, 되게 여기서
필요한 부분을 확인해서 조치하면 됩니다.
[그림 23] 특정 Trace의 Span 별로 확인 가능한 자세한 내용
30

2.4. Workloads
워크로드(번역: 작업량)는 애플리케이션에서 실제 업무를 수행하는 단위를 부르는 명칭입니다.
따라서 쿠버네티스의 관점으로 볼 때 Pod들을 모아서 동작시키는 Deployment와 같은
오브젝트들이 이에 해당 한다고 볼 수 있습니다.
[그림 24] 키알리 대시보드의 워크로드 메뉴
31

또한 자세히 보고자 원하는 워크로드를 선택하는 경우 Traffic, Metrics, Traces 외에도 Logs와
Envoy 관한 자세한 내용도 확인할 수 있습니다.
[그림 25] 워크로드 productpage-v1의 Overview 메뉴
[그림 26] 워크로드 productpage-v1의 Logs 메뉴
32

[그림 27] 워크로드 productpage-v1의 Envoy 메뉴
33

2.5. Services
서비스는 노출된 워크로드를 부르는 명칭입니다. 실제로 쿠버네티스에서 만들어진 워크로드를
노출할 수 있도록 생성하는 서비스와 동일한 개념입니다.
[그림 28] 키알리 대시보드의 서비스 메뉴
자세히 보고자 원하는 서비스를 선택하는 경우 Traffic, Inbound Metrics, Traces 에 관한
세부적인 내용도 확인할 수 있습니다.
[그림 29] 서비스 productpage의 Overview 메뉴
34

[그림 30] 서비스 productpage의 Traffic과 Inbound Metrics 메뉴
2.6. Istio Config
이스티오의 고유 구성 요소인 VirtualService와 Gateway에 대해서 매니페스트(Manifest, YAML)
수준으로 볼 수 있습니다.
[그림 31] 이스티오 설정(Config) 메뉴
35

[그림 32] VirtualService 타입의 YAML 내용
[그림 33] Gateway 타입의 YAML 내용
36

3. 이스티오 기능 별 구분
이스티오의 메뉴들을 살펴보았으니, 이제 이스티오에서 제공하는 기능 별로 구성하여 해당
내용을 살펴볼 차례입니다. 우선 진행하기에 앞서 현재 배포되어 있는 bookinfo가 혼동의
소지가 있으니 이를 삭제하고 확인한 후에 진행하도록 하겠습니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete -f
samples/bookinfo/platform/kube/bookinfo.yaml
service "details" deleted
serviceaccount "bookinfo-details" deleted
deployment.apps "details-v1" deleted
service "ratings" deleted
serviceaccount "bookinfo-ratings" deleted
deployment.apps "ratings-v1" deleted
service "reviews" deleted
serviceaccount "bookinfo-reviews" deleted
deployment.apps "reviews-v1" deleted
service "productpage" deleted
serviceaccount "bookinfo-productpage" deleted
deployment.apps "productpage-v1" deleted
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete -f
37

samples/bookinfo/networking/bookinfo-gateway.yaml
gateway.networking.istio.io "bookinfo-gateway" deleted
virtualservice.networking.istio.io "bookinfo" deleted
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get po,svc
service/kubernetes ClusterIP 10.112.0.1 <none> 443/TCP 141d
3.1. 트래픽 관리 (Traffic management)
트래픽 라우팅은 단일 클러스터 내에서나 클러스터 간에 성능에
영향을 미치는 요소이며, 더 나은 배포 전략을 필요로 할 수
있습니다. Istio의 트래픽 라우팅 규칙을 사용하면 서비스 간
트래픽 및 API 호출의 흐름을 쉽게 제어할 수 있습니다. Istio는
Circuit Breaker, Timeout, 재시도(retries)와 같은 서비스 수준
속성의 구성을 간소화하고, 백분율 기반 트래픽 분할을 통해 A/B
테스트, 카나리(canary) 배포, 단계적 롤아웃(rollouts)과 같은
중요한 작업을 쉽게 설정할 수 있게 해줍니다.
[출처: https://istio.io/latest/about/service-mesh/ ]
3.3.1 단순 서비스를 통해 2개의 Pod로 트래픽 분산
2개의 Pod가 1개의 서비스로 연결되어 트래픽이 양쪽 Pod로 배포되는 것을 확인합니다.
3.3.1.1 hello Pod 및 curl 사용을 위한 net Pod 배포
hello-v1과 hello-v2를 응답해 주는 Pod를 배포합니다. 그리고 클러스터 내부에서 curl 명령을
사용하기 위한 net Pod를 배포합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: hello-v1
labels:
app: hello
version: v1
spec:
38

containers:
- image: sysnet4admin/hello:v1
name: hello-v1
---
apiVersion: v1
kind: Pod
metadata:
name: hello-v2
labels:
app: hello
version: v2
spec:
containers:
- image: sysnet4admin/hello:v2
name: hello-v2
---
apiVersion: v1
kind: Pod
metadata:
name: net
labels:
app: net
spec:
containers:
- image: sysnet4admin/net-tools-ifn
name: net
EOF
pod/hello-v1 created
pod/hello-v2 created
pod/net created
3.3.1.2 배포된 hello Pod(s) 및 동작 확인
배포된 것을 확인합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get po,svc
pod/hello-v1 2/2 Running 0 92s
pod/hello-v2 2/2 Running 0 90s
pod/net 2/2 Running 0 88s
39

배포된 Pod들의 label을 확인합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get po --show-labels
NAME READY STATUS RESTARTS AGE LABELS
hello-v1 2/2 Running 0 56m
app=hello,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=hello,ser
vice.istio.io/canonical-revision=v1,version=v1
net 2/2 Running 0 56m
app=net,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=net,service
.istio.io/canonical-revision=latest
배포된 Pod의 label 중에 version을 사용하여 각 Pod 별로 응답이 오는지 다음의 명령으로
확인합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl exec -it net -- curl
$(kubectl get po -l version=v1 -o wide | awk 'NR==2' | awk '{print $6}')
hello-v1
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl exec -it net -- curl
$(kubectl get po -l version=v2 -o wide | awk 'NR==2' | awk '{print $6}')
hello-v2
3.3.1.3 hello 서비스를 연결
기본 서비스에서는 라운드로빈(Round-Robin)으로 응답합니다.
배포된 Pod들의 label 중에 app을 확인합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get po --show-labels
NAME READY STATUS RESTARTS AGE LABELS
net 2/2 Running 0 56m
40

app=net,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=net,service
.istio.io/canonical-revision=latest
app을 selector로 사용하여 hello 서비스를 생성합니다.
apiVersion: v1
kind: Service
metadata:
name: hello-svc
labels:
app: hello
spec:
selector:
app: hello
ports:
- name: http
protocol: TCP
port: 80
EOF
service/hello-svc created
생성된 서비스를 통해서 응답이 잘 분배되는지 확인합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) for i in {1..10}; do kubectl exec
-it net -- curl hello-svc.default.svc.cluster.local; done | tee /tmp/hello-svc ;
echo -e "n-=- RESULT -=-" ;
echo "v1: $(grep v1 /tmp/hello-svc | wc -l)" ;
rm -f /tmp/hello-svc
hello-v1
hello-v2
hello-v1
hello-v2
hello-v2
hello-v1
hello-v2
hello-v2
hello-v1
hello-v1
41

-=- RESULT -=-
v1: 5
v2: 5
Tip!☸ 언제나 5:5로 분배되지는 않습니다. 이와 가깝게 분배되는 것이 정상적인 동작입니다.
3.3.2 VirtualService로 트래픽 균등 분산
VirtualService CRD를 통해서 기본으로 가는 경로를 hello-v1으로 하고 URI의 prefix가 v2 이면
hello-v2로 연결되도록 구성합니다.
3.3.2.1 VirtualService 생성
apiVersion: v1
kind: Service
metadata:
name: hello-svc-v1
labels:
app: hello
spec:
selector:
app: hello
version: v1
ports:
- name: http
protocol: TCP
port: 80
---
apiVersion: v1
kind: Service
metadata:
name: hello-svc-v2
labels:
app: hello
spec:
selector:
app: hello
version: v2
ports:
- name: http
protocol: TCP
port: 80
---
42

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: hello-vs
spec:
hosts:
- "hello-svc.default.svc.cluster.local"
http:
- match:
- uri:
prefix: /v2
route:
- destination:
host: "hello-svc-v2.default.svc.cluster.local"
- route:
- destination:
EOF
service/hello-svc-v1 created
service/hello-svc-v2 created
virtualservice.networking.istio.io/hello-vs created
Tip!☸ route는 ACL(Access Control List) 적용과 유사하게 위에서부터 순서대로 아래로
내려오며 적용됩니다. 따라서 좁은 범위에서 넓은 범위로 적용되어야 합니다.
3.3.2.2 배포된 VirtualService 확인
배포된 VirtualService의 내용을 확인합니다.
virtualservices.networking.istio.io -o yaml | grep -A12 spec:
spec:
hosts:
- hello-svc.default.svc.cluster.local
http:
- route:
- destination:
host: hello-svc-v1.default.svc.cluster.local
- match:
- uri:
prefix: /v2
route:
43

- destination:
3.3.2.3 생성한 VirtualService에 트래픽을 발생시키기
hello-svc.default.svc.cluster.local로 트래픽을 발생 후 확인
echo "-=- RESULT -=-" ;
hello-v1
hello-v1
hello-v1
hello-v1
hello-v1
hello-v1
hello-v1
hello-v1
hello-v1
hello-v1
-=- RESULT -=-
v1: 10
v2: 0
hello-svc.default.svc.cluster.local/v2 로 트래픽을 발생 후 확인
-it net -- curl hello-svc.default.svc.cluster.local/v2; done | tee /tmp/hello-svc ;

hello-v2 (URI: /v2)
hello-v2 (URI: /v2)
hello-v2 (URI: /v2)
44

hello-v2 (URI: /v2)
hello-v2 (URI: /v2)
hello-v2 (URI: /v2)
hello-v2 (URI: /v2)
hello-v2 (URI: /v2)
hello-v2 (URI: /v2)
hello-v2 (URI: /v2)
-=- RESULT -=-
v1: 0
v2: 10
3.3.3 VirtualService에 weight를 붙여서 트래픽 비율을 조정
단순히 경로만 지정하는 것이 아니라 분산되는 트래픽을 양을 weight 값으로 조절해 봅니다.
3.3.3.1 우선 적용된 VirtualService가 서비스로 트래픽을 바로 넘겨 버리기 때문에 현재
상태에서는 가중치 별로 부하 분산 테스트를 할 수 없습니다. 따라서 기존의 VirtualService를
삭제합니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete
virtualservices.networking.istio.io hello-vs
virtualservice.networking.istio.io "hello-vs" deleted
3.3.3.2 가중 치에 따른 트래픽 분산 테스트를 위한 VirtualService를 적용(apply)합니다.
metadata:
name: hello-vs-canary
spec:
hosts:
- "hello-svc.default.svc.cluster.local"
http:
- route:
- destination:
weight: 90
- destination:
weight: 10
45

EOF
virtualservice.networking.istio.io/hello-vs-canary configured
Tip!☸ 카나리(canary)는 일부 트래픽만 새로운 애플리케이션에 보내서 확인하는
대표적인 안전 배포 방법입니다.
3.3.3.2 VirtualService에 적용되어 있는 내용 확인
virtualservices.networking.istio.io -o yaml | grep -A16 spec:
spec:
hosts:
- hello-svc.default.svc.cluster.local
http:
- route:
- destination:
weight: 90
- destination:
weight: 10
kind: List
metadata:
resourceVersion: ""
selfLink: ""
3.3.3.3 트래픽 분배가 가중치에 따라 다르게 적용되는지 확인
hello-v1
hello-v1
hello-v1
hello-v1
hello-v1
hello-v2
hello-v1
hello-v1
46

hello-v1
hello-v1
-=- RESULT -=-
v1: 9
v2: 1
Tip!☸ 언제나 9:1로 분배되지는 않습니다. 이와 가깝게 트래픽이 분배되는 것이 정상적인
동작입니다.
배포한 VirtualService를 삭제합니다. 이는 다음에 진행할 DestinationRule보다
VirtualSerivce가 먼저 적용되기 때문입니다.
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete vs hello-vs-canary
virtualservice.networking.istio.io "hello-vs-canary" deleted
Tip!☸ vs는 VirtualSerivce의 약자입니다.
3.3.4 DestinationRule
가중치와 같은 방법으로 트래픽을 분산하는 것이 외에, 트래픽에 도달하는 방법 자체를 정의할
수 있습니다. 그 중에 가장 많이 사용되는 로드밸런서를 단순히 사용하는게 아니라
로드밸런싱의 방법을 바꿔가면서 테스트하여 DestinatioRule을 이해해 보겠습니다.
3.3.4.1 간단한 방식(simple)
최소한의 알고리즘이 없는 경우 5:5 또는 6:4가 아니라 7:3 혹은 그 이상 안 좋은 결과를 보여줄
수 있습니다. 그러니 가능한 간단한 로직이라도 넣는게 좋습니다.
Round-Robin 방식을 적용하고 테스트합니다.
kind: DestinationRule
metadata:
name: hello-dr-rr
spec:
host: hello-svc.default.svc.cluster.local
47

trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
EOF
destinationrule.networking.istio.io/hello-dr-rr created
hello-v1
hello-v1
hello-v2
hello-v2
hello-v1
hello-v1
hello-v2
hello-v1
hello-v2
hello-v1
-=- RESULT -=-
v1: 6
v2: 4
적용된 DestinationRule인 hello-dr-rr을 삭제합니다.
destinationrules.networking.istio.io hello-dr-rr
destinationrule.networking.istio.io "hello-dr-rr" deleted
LEAST_REQUEST 방식을 적용하고 테스트합니다.
metadata:
name: hello-dr-lr
spec:
trafficPolicy:
48

loadBalancer:
simple: LEAST_REQUEST
EOF
destinationrule.networking.istio.io/hello-dr-lr created
hello-v1
hello-v2
hello-v2
hello-v1
hello-v2
hello-v1
hello-v1
hello-v2
hello-v1
hello-v2
-=- RESULT -=-
v1: 5
v2: 5
Tip!☸ 2개의 방식 차이 그리고 다른 방식에 대해서는 다음의 링크를 참조하세요
적용된 DestinationRule인 hello-dr-lr을 삭제합니다.
destinationrules.networking.istio.io hello-dr-lr
destinationrule.networking.istio.io "hello-dr-lr" deleted
3.3.4.2 해시를 사용하는 방식 (consistentHash)
useSourceIp를 적용하고 테스트합니다.
metadata:
name: hello-dr-hash-sip
spec:
trafficPolicy:
49

loadBalancer:
consistentHash:
useSourceIp: true
EOF
destinationrule.networking.istio.io/hello-dr-hash-sip created
hello-v2
hello-v2
hello-v2
hello-v2
hello-v2
hello-v2
hello-v2
hello-v2
hello-v2
hello-v2
-=- RESULT -=-
v1: 0
v2: 10
적용된 DestinationRule인 hello-dr-hash-sip을 삭제합니다.
destinationrules.networking.istio.io hello-dr-hash-sip
destinationrule.networking.istio.io "hello-dr-hash-sip" deleted
maglev를 적용하고 테스트합니다.
metadata:
name: hello-dr-hash-maglev
spec:
trafficPolicy:
50

loadBalancer:
consistentHash:
maglev:
EOF
destinationrule.networking.istio.io/hello-dr-hash-maglev created
hello-v2
hello-v2
hello-v2
hello-v1
hello-v1
hello-v1
hello-v1
hello-v1
hello-v2
hello-v1
-=- RESULT -=-
v1: 6
v2: 4
Tip!☸ 2개의 방식 차이 그리고 다른 방식에 대해서는 다음의 링크를 참조하세요
다음 진행을 위해 적용된 DestinationRule인 hello-dr-hash-maglev을 삭제합니다.
destinationrules.networking.istio.io hello-dr-hash-maglev
destinationrule.networking.istio.io "hello-dr-hash-maglev" deleted
3.3.4.3 subset
다음과 같이 레이블에 따라 로드밸런서 설정을 다르게 가지고 갈 수 있습니다.
이 부분은 샘플만 이해하고 넘어가도록 하겠습니다.
metadata:
name: bookinfo-ratings-dr-sbs
51

spec:
host: ratings.prod.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: LEAST_REQUEST # 기본 로드밸런서
subsets:
- name: testversion
labels:
version: v3
trafficPolicy:
loadBalancer:
consistentHash:
useSourceIp: true # 레이블 version: v3인 경우 적용되는 로드밸런서
EOF
3.3.4.4 connectionPool & outlierDetection (Circuit breaking)
문제가 지속적으로 발생하는 경우 문제 발생 지점으로 계속 연결시켜주기 보다 더이상 연결이
되지 않도록 하는 것이 좋습니다. 이를 위해서 Connection Pool과 Outlier Detection을 다음과
같이 설정할 수 있습니다.
metadata:
name: bookinfo-redis
spec:
host: myredissrv.prod.svc.cluster.local
trafficPolicy:
connectionPool: # 접속 pool 사이즈 조정
Tcp: # tcp 말고 http도 가능
maxConnections: 100 # TCP 최대 접속수
connectTimeout: 30ms # TCP timeout 값
outlierDetection: # 서킷 브레이커 동작 조건 나열
consecutiveErrors: 3 # 3번이 넘어가지는 체크
interval: 30s # 3번의 문제가 얼마의 기간동안 발생하는지 체크
baseEjectionTime: 30m # 얼마나 오랫동안 접속이 안되도록 할 것인가 설정
maxEjectionPercent: 50 # 완전히 서비스를 중단하는게 아니라 50%는 놔두도록 설정
EOF
52

3.3.5 Gateway
도달하는 순서로 본다면 외부에서 가장 처음에 도달하게 되는 Ingressgateway 이고 그 이후에
이를 실제로 내부와 연결해주는 역할을 하는 것이 gateway 입니다. 따라서 실제로 서비스
메시인 istio의 내부 경로를 만들어주는 첫 단계라고 볼 수 있습니다. 그리고 독립적인
사용보다는 VirtualService와의 연동을 통해서 내부 Pod와 연결되게 됩니다.
이를 표현하면 다음과 같은 단계를 통해서 접속되게 됩니다.
사용자 ->
istio-ingressgateway (LB) -> Gateway -> Virtual Service -> Destination Rules
-> Pod(s)
3.3.5.1 hello 앱에 접속하기 위핸 Gateway와 Virtual Service를 배포
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: hello-gw
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
metadata:
name: hello-vs
spec:
hosts:
- "*"
53

gateways:
- hello-gw
http:
- match:
- uri:
prefix: /v2
route:
- destination:
- route:
- destination:
EOF
gateway.networking.istio.io/hello-gw created
virtualservice.networking.istio.io/hello-vs created
3.3.5.2 배포된 Gateway(gw)와 Virtual Service(vs) 확인
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get gw,vs
NAME AGE
gateway.networking.istio.io/hello-gw 3m29s
virtualservice.networking.istio.io/hello-vs ["hello-gw"] ["*"] 3m29s
3.3.5.3 외부에서 접속하는 IP (다른 CSP는 도메인) 확인
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get svc -n istio-system
grafana ClusterIP 10.112.7.128 <none> 3000/TCP
istio-egressgateway ClusterIP 10.112.12.251 <none> 80/TCP,443/TCP
istio-ingressgateway LoadBalancer 10.112.12.147 xx.67.xxx.xxx X
istiod ClusterIP 10.112.15.136 <none> X
jaeger-collector ClusterIP 10.112.8.242 <none> X
kiali LoadBalancer 10.112.11.184 xx.72.xxx.xxx X
prometheus ClusterIP 10.112.8.140 <none> 9090/TCP
tracing ClusterIP 10.112.6.73 <none> 80/TCP,16685/TCP
zipkin ClusterIP 10.112.6.194 <none> 9411/TCP
54

3.3.5.4 편리한 사용을 위해 IP를 변수로 치환
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istio_ingress_IP=$(kubectl get svc
-n istio-system istio-ingressgateway -o
jsonpath="{.status.loadBalancer.ingress[0].ip}")
3.3.5.5 외부에서 HTTP 호출이 되는지 확인
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) curl $istio_ingress_IP
hello-v1
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) curl $istio_ingress_IP/v2
hello-v2 (URI: /v2)
3.3.5.6 사용한 모든 앱과 서비스 그리고 이스티오 CRD 리소스 삭제
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete po,svc -l app=hello
pod "hello-v1" deleted
pod "hello-v2" deleted
service "hello-svc" deleted
service "hello-svc-v1" deleted
service "hello-svc-v2" deleted
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete gw hello-gw
gateway.networking.istio.io "hello-gw" deleted
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete vs hello-vs
virtualservice.networking.istio.io "hello-vs" deleted
3.2. 관측 가능성 (Observability)
서비스의 복잡성이 증가함에 따라 사용 패턴과 성능을 파악하기가
어려워지고 있습니다. Istio는 서비스 메시 내의 모든 통신에 대한
상세한 텔레메트리(Telemetry)를 생성합니다. 이러한
텔레메트리는 서비스 동작에 대한 관측 가능성(Observability)을
제공하여 운영자가 애플리케이션을 문제 해결, 유지 관리,
최적화할 수 있도록 지원합니다. 더 좋은 점은 애플리케이션을
변경할 필요 없이 거의 모든 계측 기능을 사용할 수 있다는
55

것입니다. 운영자는 Istio를 통해 모니터링되는 서비스가 상호 작용하는 방식을 전반적으로
이해할 수 있습니다.
Istio의 텔레메트리에는 상세한 메트릭(metrics), 분산 추적(distributed traces), 전체 접속
로그(access logs)가 포함됩니다. Istio를 사용하면 철저하고 종합적인 서비스 메시에 대한 관측
가능성을 확보할 수 있습니다.
3.2.1 stan의 로봇 샵 배포 (Stan's Robot Shop)
IBM Instana 관측 가능성을 위해 제작된 MSA 앱을 배포
3.2.1.1 MSA 디렉터리를 생성하고 이동한 후에 로봇 샵을 git clone 함
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) mkdir MSA
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) cd MSA
➜ MSA (☸️ |hj-istio-classic:default) git clone
https://github.com/instana/robot-shop.git
Cloning into 'robot-shop'...
remote: Enumerating objects: 2949, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 2949 (delta 0), reused 3 (delta 0), pack-reused 2943
Receiving objects: 100% (2949/2949), 103.14 MiB | 10.68 MiB/s, done.
Resolving deltas: 100% (1570/1570), done.
3.2.1.2 로봇 샵의 레포지토리에서 헬름 디렉터리로 이동한 후에 해당 내용을 확인
➜ MSA (☸️ |hj-istio-classic:default) cd robot-shop/K8s/helm
➜ helm git:(master) (☸️ |hj-istio-classic:default) ls -rlt
total 32
-rw-r--r-- 1 mz01-hj staff 137 Jun 29 12:21 Chart.yaml
-rw-r--r-- 1 mz01-hj staff 6652 Jun 29 12:21 README.md
56

drwxr-xr-x 30 mz01-hj staff 960 Jun 29 12:21 templates
-rw-r--r-- 1 mz01-hj staff 1108 Jun 29 12:21 values.yaml
3.2.1.3 로봇 샵을 위한 robot-shop 네임스페이스를 만들고, 해당 네임스페이스 이스티오
인젝션을 주입
➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl create ns robot-shop
namespace/robot-shop created
➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl label namespace
robot-shop istio-injection=enabled
namespace/robot-shop labeled
3.2.1.4 헬름으로 로봇 샵을 배포
➜ helm git:(master) (☸️ |hj-istio-classic:default) helm install robot-shop
--namespace robot-shop .
NAME: robot-shop
LAST DEPLOYED: Thu Jun 29 13:02:32 2023
NAMESPACE: robot-shop
STATUS: deployed
REVISION: 1
TEST SUITE: None
3.2.1.5 배포되어진 로봇 샵 관련 Pod와 서비스를 확인
➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl get po,svc -n
robot-shop
pod/cart-7d568797bf-96cnb 2/2 Running 0 2m13s
pod/catalogue-7675c4c9f6-m6vxk 2/2 Running 0 2m12s
pod/dispatch-684fcb8f68-gppbm 2/2 Running 0 2m13s
pod/mongodb-769dcffb9f-cvq8x 2/2 Running 0 2m13s
pod/mysql-77f486876b-zcf6f 2/2 Running 0 2m13s
pod/payment-7d67fb95cb-vpp7x 2/2 Running 0 2m13s
pod/rabbitmq-58ff49565-xkmnj 2/2 Running 0 2m13s
pod/ratings-b47dd9576-64cql 1/2 Running 0 2m13s
pod/redis-0 2/2 Running 0 2m13s
pod/shipping-58f86cd444-2d4n2 1/2 Running 0 2m13s
pod/user-864784697b-g2lm6 2/2 Running 0 2m13s
pod/web-5bb847c66b-vqd9w 2/2 Running 0 2m13s
57

service/cart ClusterIP 10.112.8.234 <none> 8080/TCP
service/catalogue ClusterIP 10.112.1.84 <none> 8080/TCP
service/dispatch ClusterIP None <none> 55555/TCP
service/mongodb ClusterIP 10.112.6.1 <none> 27017/TCP
service/mysql ClusterIP 10.112.13.219 <none> 3306/TCP
service/payment ClusterIP 10.112.6.179 <none> 8080/TCP
service/rabbitmq ClusterIP 10.112.3.186 <none> X
service/ratings ClusterIP 10.112.5.5 <none> 80/TCP
service/redis ClusterIP 10.112.2.125 <none> 6379/TCP
service/shipping ClusterIP 10.112.15.87 <none> 8080/TCP
service/user ClusterIP 10.112.12.148 <none> 8080/TCP
service/web LoadBalancer 10.112.6.225 xx.27.xx.xx 8080:30423/TCP
3.2.1.6 배포된 로봇 샵 MSA를 웹브라우저에 web 서비스의 IP를 입력해서 확인
3.2.1.7 로봇 샵이 이스티오를 통해서 외부와 연결되고 동작할 수 있도록 게이트웨이와
버추얼서비스 배포
➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl -n robot-shop apply -f
../Istio/gateway.yaml
gateway.networking.istio.io/robotshop-gateway created
virtualservice.networking.istio.io/robotshop created
3.2.1.8 배포된 게이트웨이와 버추얼서비스를 확인
➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl get gw,vs -n
58

robot-shop
NAME AGE
gateway.networking.istio.io/robotshop-gateway X
virtualservice.networking.istio.io/robotshop ["robotshop-gateway"] ["*"] X
3.2.1.9 외부에서 이스티오의 ingressgateway를 통해서 접속 가능한지 확인하기 위해 IP 주소
확인
➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl -n istio-system get
svc istio-ingressgateway
istio-ingressgateway LoadBalancer 10.112.12.147 xx.67.xxx.xxx X
3.2.1.10 웹브라우저에 ingressgateway IP를 입력한 후에 아이템 몇개를 `add to cart` 버튼을
통해서 카트에 넣음
3.2.1.11 로봇 샵 MSA의 동작을 확인하기 위해 이스티오 키알리 대시보드의 IP 주소를 확인
➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl -n istio-system get
svc kiali
kiali LoadBalancer 10.112.11.184 xx.74.xxx.xxx 20001
59

3.2.1.12 확인한 키알리 대시보드의 IP를 웹브라우저에 입력하고 Graph로 이동
Tip!☸ 위와 같이 나오지 않는 경우 부하가 발생하지 않은 경우임으로, 3.1.2.10 `add to cart`를
다시 진행한 후에 확인합니다.
3.2.1.13 확인이 모두 끝났다면 다음 진행을 위해서 배포한 리소스를 삭제
➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl -n robot-shop delete
-f ../Istio/gateway.yaml
gateway.networking.istio.io "robotshop-gateway" deleted
virtualservice.networking.istio.io "robotshop" deleted
➜ helm git:(master) (☸️ |hj-istio-classic:default) helm uninstall -n robot-shop
robot-shop
release "robot-shop" uninstalled
➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl delete ns robot-shop
namespace "robot-shop" deleted
60

Tip!☸ 리소스의 여유가 있다면, 꼭 삭제하지 않아도 됩니다.
다만 추후 진행되는 랩에서 실습이 진행되는 네임스페이스는 반드시 분리되어야 합니다.
➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl top node
--use-protocol-buffers
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
gke-istio-classic-p-e5ef5921-58mv 255m 13% 2051Mi 33%
gke-istio-classic-p-e5ef5921-n9e6 211m 10% 2194Mi 36%
gke-istio-classic-p-e5ef5921-oqvk 176m 9% 1733Mi 28%
3.2.1 구글 클라우드의 앤토스 은행
3.2.3.1 MSA 디렉터리로 이동한 후에 온라인 브티크를 online-boutique 이름으로 git clone 함
https://github.com/GoogleCloudPlatform/bank-of-anthos.git
Cloning into 'bank-of-anthos'...
➜ MSA (☸️ |hj-istio-classic:default)
➜ MSA (☸️ |hj-istio-classic:default) cd bank-of-anthos
➜ bank-of-anthos git:(main) (☸️ |hj-istio-classic:default) kubectl apply -f
./extras/jwt/jwt-secret.yaml
secret/jwt-key created
➜ bank-of-anthos git:(main) (☸️ |hj-istio-classic:default) kubectl apply -f
./kubernetes-manifests
configmap/accounts-db-config created
service/accounts-db created
statefulset.apps/accounts-db created
service/balancereader created
61

deployment.apps/balancereader created
configmap/environment-config created
configmap/service-api-config created
configmap/demo-data-config created
serviceaccount/bank-of-anthos created
service/contacts created
deployment.apps/contacts created
service/frontend created
deployment.apps/frontend created
configmap/ledger-db-config created
service/ledger-db created
statefulset.apps/ledger-db created
service/ledgerwriter created
deployment.apps/ledgerwriter created
deployment.apps/loadgenerator created
service/transactionhistory created
deployment.apps/transactionhistory created
service/userservice created
deployment.apps/userservice created
3.2.2.3 배포된 파드와 서비스를 확인함. 특히 frontend-external의 External-IP를 확인
➜ online-boutique git:(main) (☸️ |hj-istio-classic:default) kubectl get po,svc
pod/accounts-db-0 2/2 Running 0 7m10s
pod/balancereader-84cc84cff9-jsts6 2/2 Running 0 7m6s
pod/contacts-675865b4bd-bq2kx 2/2 Running 0 7m7s
pod/frontend-5c7bd5c94b-6qm55 2/2 Running 0 7m6s
pod/ledger-db-0 2/2 Running 0 7m5s
pod/ledgerwriter-69b446d5b8-pztrf 2/2 Running 0 7m4s
pod/loadgenerator-84dcf4dfcb-stm7v 2/2 Running 0 7m4s
pod/transactionhistory-6c69cf5759-swjsd 2/2 Running 0 7m2s
pod/userservice-8b588679c-tvqrb 2/2 Running 0 7m2s
service/accounts-db ClusterIP 10.112.15.190 <none> 5432/TCP 7m10s
service/balancereader ClusterIP 10.112.12.80 <none> 8080/TCP 7m10s
service/contacts ClusterIP 10.112.3.10 <none> 8080/TCP 7m7s
service/frontend LoadBalancer 10.112.6.19 34.170.55.76 80:31252/TCP 7m6s
service/ledger-db ClusterIP 10.112.15.176 <none> 5432/TCP 7m5s
service/ledgerwriter ClusterIP 10.112.14.65 <none> 8080/TCP 7m4s
service/transactionhistory ClusterIP 10.112.15.53 <none> 8080/TCP 7m3s
service/userservice ClusterIP 10.112.14.240 <none> 8080/TCP 7m2s
62

3.2.2.4 배포된 애플리케이션을 frontend-external의 External-IP의 주소로 접속해 확인
3.2.3.5 서비스 메시의 상태를 확인하기 위해, 키알리 대시보드 주소를 확인
➜ bank-of-anthos git:(main) (☸️ |hj-istio-classic:default) kubectl -n
istio-system get svc kiali
63

3.2.3.6 확인된 주소로 이동한 후에 메뉴에서 Graph - default 네임스페이스를 선택
64

3.2.3.7 키알리 default 네임스페이스에 보여지는 앤토스 은행의 연결 구조를 확인
➜ bank-of-anthos git:(main) (☸️ |hj-istio-classic:default) kubectl delete -f
./kubernetes-manifests
configmap "accounts-db-config" deleted
service "accounts-db" deleted
statefulset.apps "accounts-db" deleted
service "balancereader" deleted
deployment.apps "balancereader" deleted
configmap "environment-config" deleted
configmap "service-api-config" deleted
configmap "demo-data-config" deleted
serviceaccount "bank-of-anthos" deleted
service "contacts" deleted
deployment.apps "contacts" deleted
service "frontend" deleted
deployment.apps "frontend" deleted
configmap "ledger-db-config" deleted
service "ledger-db" deleted
statefulset.apps "ledger-db" deleted
service "ledgerwriter" deleted
65

deployment.apps "ledgerwriter" deleted
deployment.apps "loadgenerator" deleted
service "transactionhistory" deleted
deployment.apps "transactionhistory" deleted
service "userservice" deleted
deployment.apps "userservice" deleted
➜ bank-of-anthos git:(main) (☸️ |hj-istio-classic:default) kubectl delete -f
./extras/jwt/jwt-secret.yaml
secret "jwt-key" deleted
66

3.2.3 구글 클라우드의 온라인 부티크
구글 클라우드 플랫폼에서 마이크로서비스를 위해 데모로 작성한 애플리케이션
[그림] 온라인 부티크의 아키택처
➜ robot-shop git:(master) (☸️ |hj-istio-classic:default) cd ~/istio-1.16.1/MSA
https://github.com/GoogleCloudPlatform/microservices-demo.git online-boutique
Cloning into 'online-boutique'...
➜ MSA (☸️ |hj-istio-classic:default)
67

3.2.3.2 내려받은 온라인 부디크 디렉터리로 이동한 후에 메니페스트를 통해 애플리케이션을
배포
➜ online-boutique git:(main) (☸️ |hj-istio-classic:default) kubectl apply -f
./release/kubernetes-manifests.yaml
deployment.apps/emailservice created
service/emailservice created
deployment.apps/checkoutservice created
service/checkoutservice created
deployment.apps/recommendationservice created
service/recommendationservice created
deployment.apps/frontend created
service/frontend created
service/frontend-external created
deployment.apps/paymentservice created
service/paymentservice created
deployment.apps/productcatalogservice created
service/productcatalogservice created
deployment.apps/cartservice created
service/cartservice created
deployment.apps/loadgenerator created
deployment.apps/currencyservice created
service/currencyservice created
deployment.apps/shippingservice created
service/shippingservice created
deployment.apps/redis-cart created
service/redis-cart created
deployment.apps/adservice created
service/adservice created
3.2.3.3 배포된 파드와 서비스를 확인함. 특히 frontend-external의 External-IP를 확인
➜ online-boutique git:(main) (☸️ |hj-istio-classic:default) kubectl get po,svc
pod/adservice-5464cc8db4-f8m7n 2/2 Running 0 3m36s
pod/cartservice-6458db7c7c-8lbzv 2/2 Running 0 3m51s
pod/checkoutservice-55b497bfb8-n8dk6 2/2 Running 0 4m8s
pod/currencyservice-6f868d85d8-mf4n5 2/2 Running 0 3m46s
pod/emailservice-5cf5fc5898-9lx98 2/2 Running 0 4m11s
pod/frontend-bfdf66596-c4txn 2/2 Running 0 4m2s
pod/loadgenerator-6568b868f-slfjd 2/2 Running 0 3m47s
pod/paymentservice-5ff68d9c7d-gfwdj 2/2 Running 0 3m57s
pod/productcatalogservice-5b9c9f6488-wpxvb 2/2 Running 0 3m54s
pod/recommendationservice-c58857d6-28bkh 2/2 Running 0 4m5s
68

pod/redis-cart-79b899577-47msg 2/2 Running 0 3m39s
pod/shippingservice-6f65f85b8b-lw8d7 2/2 Running 0 3m43s
service/adservice ClusterIP 10.112.9.239 <none> 9555/TCP 3m36s
service/cartservice ClusterIP 10.112.12.212 <none> 7070/TCP 3m50s
service/checkoutservice ClusterIP 10.112.2.75 <none> 5050/TCP 4m7s
service/currencyservice ClusterIP 10.112.2.98 <none> 7000/TCP 3m45s
service/emailservice ClusterIP 10.112.15.61 <none> 5000/TCP 4m11s
service/frontend ClusterIP 10.112.12.97 <none> 80/TCP 4m1s
service/frontend-external LoadBalancer 10.112.13.102 34.31.23.25 80:32084/TCP 4m
service/paymentservice ClusterIP 10.112.8.120 <none> 50051/TCP 3m56s
service/productcatalogservice ClusterIP 10.112.1.199 <none> 3550/TCP 3m53s
service/recommendationservice ClusterIP 10.112.1.193 <none> 8080/TCP 4m4s
service/redis-cart ClusterIP 10.112.1.101 <none> 6379/TCP 3m39s
service/shippingservice ClusterIP 10.112.14.55 <none> 50051/TCP 3m42s
3.2.3.4 배포된 애플리케이션을 frontend-external의 External-IP의 주소로 접속해 확인
69

3.2.3.5 서비스 메시의 상태를 확인하기 위해, 키알리 대시보드 주소를 확인
➜ online-boutique git:(main) (☸️ |hj-istio-classic:default) kubectl -n
istio-system get svc kiali
3.2.3.6 확인된 주소로 이동한 후에 메뉴에서 Graph - default 네임스페이스를 선택
70

3.2.3.7 키알리 default 네임스페이스에 보여지는 온라인 부티크의 연결 구조를 확인
3.2.3.8 간단하게 배포된 애플리케이션 삭제
➜ online-boutique git:(main) (☸️ |hj-istio-classic:default) kubectl delete -f
./release/kubernetes-manifests.yaml
deployment.apps "emailservice" deleted
service "emailservice" deleted
deployment.apps "checkoutservice" deleted
service "checkoutservice" deleted
deployment.apps "recommendationservice" deleted
service "recommendationservice" deleted
deployment.apps "frontend" deleted
service "frontend" deleted
service "frontend-external" deleted
deployment.apps "paymentservice" deleted
service "paymentservice" deleted
deployment.apps "productcatalogservice" deleted
service "productcatalogservice" deleted
deployment.apps "cartservice" deleted
service "cartservice" deleted
deployment.apps "loadgenerator" deleted
deployment.apps "currencyservice" deleted
service "currencyservice" deleted
deployment.apps "shippingservice" deleted
service "shippingservice" deleted
71

deployment.apps "redis-cart" deleted
service "redis-cart" deleted
deployment.apps "adservice" deleted
service "adservice" deleted
3.2.3.9 애플리케이션 삭제 이후에 키알리 대시보드에서도 보이지 않는지 확인
72

3.3. 보안 기능들 (Security capabilities)
마이크로서비스는 중간자 공격에 대한 보호(man-in-the-middle
attacks), 유연한 액세스 제어, 감사 도구, 상호 TLS 등 특별한 보안
요구 사항들이 필요합니다. Istio에는 운영자가 이러한 모든
문제들을 해결할 수 있는 포괄적인 보안 솔루션이 포함되어
있습니다. 강력한 신원 확인, 강력한 정책, TLS 암호화, 인증, 권한
부여 및 감사(AAA) 들을 위한 도구를 제공하여 서비스와 데이터를
보호합니다.
Istio의 보안 모델은 기본적으로 안전을 기반으로 하여, 신뢰할 수 없는 네트워크에서도 보안을
고려한 애플리케이션을 배포할 수 있도록 강력한 보호 기능을 제공하려고 합니다.
4. 이스티오 앰비언트 메시
부록
➜ istio-1.16.1 (☸️ |hj-istio-classic:default) TBD
73

이스티오 (Istio) 자습서 v0.5.0

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 이스티오 (Istio) 자습서 v0.5.0

Similar to 이스티오 (Istio) 자습서 v0.5.0 (20)

More from Jo Hoon

More from Jo Hoon (20)

Recently uploaded

Recently uploaded (6)

이스티오 (Istio) 자습서 v0.5.0