Istio Hands-on Study [1기] - 4주차 - Observability

스터디/Istio Hands-on Study

Istio Hands-on Study [1기] - 4주차 - Observability - 8장 (작성 중)

Nowon9159 2025. 4. 29. 22:50

8. 관찰가능성 Observability : Visualizing network behavior with Grafana, Jaeger, and Kiali

This chapter covers

그라파나를 사용해 메트릭을 시각적으로 관찰하기 Using Grafana to observe metrics visually
예거를 사용한 분산 트레이싱 계측하기 Distributed tracing instrumentation with Jaeger
키알리로 네트워크 호출 그래프 시각화하기 Visualizing the network call graph with Kiali

들어가며

이번 장에서는 앞 장에서 구축한 기반을 바탕으로 몇 가지 도구를 사용해 서비스 메시의 데이터를 시각화해본다.
이스티오의 데이터 플레인과 컨트롤 플레인 구성 요소가 아주 유용한 대량의 운영 메트릭을 어떻게 노출하는지, 이를 프로메테우스 같은 시계열 시스템에 어떻게 긁어올 수 있는지 등을 살펴봤다.
지금부터는 그라파나와 키알리 같은 도구를 사용해 이런 메트릭들을 시각화해본다.
이는 메시 그 자체와 더불어 메시 내 서비스들의 동작을 더 잘 이해하기 위해서다.
또한 분산 트레이싱 도구를 사용해 네트워크 호출 그래프를 시각화하는 방법도 살펴본다.

8.1 Using Grafana to visualize Istio service and control-plane metrics 그라파나로 이스티오 서비스와 컨트롤 플레인 메트릭 시각화

8.1.1 Setting up Istio’s Grafana dashboards 이스티오의 그라파나 대시보드 설정하기 (실습~)

그파라나 웹 접속 : admin / prom-operator

# Grafana 접속 : admin / prom-operator
open http://127.0.0.1:30002
open http://127.0.0.1:30002/dashboards

# 반복 호출 해두기
while true; do curl -s http://webapp.istioinaction.io:30000/api/catalog ; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; echo; done

책 제공 소스 코드에 대시보드를 추가 설정 or 공개 대시보드에서 검색 - Link , Search

#
cd ch8

kubectl -n prometheus create cm istio-dashboards \
--from-file=pilot-dashboard.json=dashboards/\
pilot-dashboard.json \
--from-file=istio-workload-dashboard.json=dashboards/\
istio-workload-dashboard.json \
--from-file=istio-service-dashboard.json=dashboards/\
istio-service-dashboard.json \
--from-file=istio-performance-dashboard.json=dashboards/\
istio-performance-dashboard.json \
--from-file=istio-mesh-dashboard.json=dashboards/\
istio-mesh-dashboard.json \
--from-file=istio-extension-dashboard.json=dashboards/\
istio-extension-dashboard.json

# 확인
cd ..
kubectl describe cm -n prometheus  istio-dashboards

# Grafana (오퍼레이터)가 configmap(istio-dashboards)을 마운트(인식) 하도록 레이블 지정
kubectl label -n prometheus cm istio-dashboards grafana_dashboard=1

# (참고) Grafana 대시보드 추가
kubectl stern -n prometheus prom-grafana
prom-grafana-d7f5cb646-555zp grafana-sc-dashboard [2025-04-27 05:58:21] File in configmap istio-extension-dashboard.json ADDED
prom-grafana-d7f5cb646-555zp grafana-sc-dashboard [2025-04-27 05:58:21] File in configmap istio-mesh-dashboard.json ADDED
prom-grafana-d7f5cb646-555zp grafana-sc-dashboard [2025-04-27 05:58:21] File in configmap istio-performance-dashboard.json ADDED
prom-grafana-d7f5cb646-555zp grafana-sc-dashboard [2025-04-27 05:58:21] File in configmap istio-service-dashboard.json ADDED
prom-grafana-d7f5cb646-555zp grafana-sc-dashboard [2025-04-27 05:58:21] File in configmap istio-workload-dashboard.json ADDED
prom-grafana-d7f5cb646-555zp grafana-sc-dashboard [2025-04-27 05:58:21] File in configmap pilot-dashboard.json ADDED
...

http://127.0.0.1:30002/dashboards 접속

8.1.2 Viewing control-plane metrics 컨트롤 플레인 메트릭 보기 ⇒ 상세 메트릭 Blog 참고

그라파나 대시보드 → Istio Control Plane Dashboard 선택 : 앞 장에서 컨트롤 플레인을 긁어가도록 ServiceMonitor 리소스 설정
CPU, 메모리, 고루틴 같은 정보뿐 아니라 컨트롤 플레인 오류, 설정 동기화 문제, 활성 데이터 플레인 커넥션 갯수 등에 대한 데이터도 보인다.
아래 그림 처럼 그래프 중 하나의 세부 사항을 누르고 Explore 로 그래프를 만들어내는 데 사용하는 원본 쿼리를 살펴보자.

sum(irate(pilot_xds_pushes{type="rds"}[1m]))

8.1.3 Viewing data-plane metrics 데이터 플레인 메트릭 보기 ⇒ 상세 메트릭 Blog 참고

그라파나 대시보드 → Istio Service Dashboard 선택 : webapp.. 등 특정 서비스를 선택 가능

이 그래프들은 이스티오 표준 메트릭으로 채워지며, 이를 변경하고 조정하거나 다른 메트릭에 대한 새 그래프를 추가할 수 있다.
커스텀 메트릭이나 특정 엔보이 메트릭을 활성화하는 방법은 7장을 참조하자.

8.2 Distributed tracing 분산 트레이싱

들어가며 : 분산 트레이싱 필요성

더 많은 애플리케이션을 마이크로서비스로 구축할수록, 그림 8.6처럼 비즈니스 목표를 달성하기 위해 협업하는 분산 구성 요소의 네트워크를 만들어가는 것이다.
요청 경로에서 문제가 발생하기 시작하면, 무슨 일이 일어나고 있는지 이해하는 것은 매우 중요하다.
그래야 빠르게 진단하고 고칠 수 있기 때문이다.
앞 절에서는 이스티오가 애플리케이션 대신에 네트워크 관련 메트릭과 텔레메트리를 수집하는 데 어떻게 도움이 되는지 살펴봤다.
이번 절에서는 분산 트레이싱이라는 개념을 살펴보고, 이 개념이 마이크로서비스 망을 통과할 때 오동작하는 요청을 진단하는 데 어떻게 도움이 되는지 살펴본다.

모놀리스에서는 무언가 오동작하기 시작하면 친숙한 도구를 사용해 디버깅할 수 있다.
런타임 프로파일러, 메모리 분석 도구를 사용해 코드의 어떤 부분이 지연이나 오작동을 유발하는지 찾을 수 있다.
반면 분산 구조로 이뤄진 애플리케이션에서는 같은 일을 하려면 새로운 도구들이 필요하다.
분산 트레이싱을 사용하면 요청을 처리하는 데 관여한 분산 시스템의 구성 요소에 대한 통찰력을 얻을 수 있다.
분산 트레이싱은 구글 대퍼 Google Dapper 논문 ‘Dapper, a LargeScale Distributed Systems Tracing Insfrastructure (2010)‘에서 도입한 개념이며 요청에 주석을 붙이는 작업이 포함된다.
https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/
이때 붙이는 주석은 서비스 간 호출을 나타내는 상관관계 correlation ID와 서비스 간 호출 그래프를 거치는 특정 요청을 나타내는 트레이스 trace ID 이다.
이스티오의 데이터 플레인은 요청이 데이터 플레인을 통과할 때 이런 메타데이터를 요청에 추가할 수 있다 (그리고 인식할 수 없거나 외부 개체에서 온 메타데이터는 제거한다는 점이 중요하다)(and, importantly, remove them when they are unrecognized or come from external entities)
예) istio 의 경우 (Jaeger/Zipkin) ~ x-request-id
오픈텔레메트리 OpenTelemetry 는 커뮤니티 주도 프레임워크로, 오픈트레이싱을 포함한다.
- *https://opentelemetry.io/ OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.*
여기서 오픈트레이싱 OpenTracing 이란 분산 트레이싱과 관련된 개념 및 API를 정의하는 사양을 말한다.

분산 트레이싱은 어느 정도 개발자에게 의존하는데, 코드를 계측하는 작업이나 애플리케이션에서 요청을 처리하고 다른 시스템으로 새로운 요청을 보낼 때 요청에 주석을 붙이는 작업이 필요하기 때문이다.
- 모니터링을 위한 코드(instrumenting code) 삽입
- 요청에 어노테이션 (correlation id, trace Id 등) 추가
트레이싱 엔진은 요청 흐름의 전체 상황을 파악하는 데 도움이 되며, 이와 같은 특성은 아키텍처에서 오동작하는 영역을 식별하는 데 유용하다.
이스티오를 사용하면, 개발자가 직접 구현해야 하는 부담을 크게 덜어줄 수 있으며 분산 트레이싱을 서비스 메시의 일부로 제공할 수 있다.

**8.2.1 How does distributed tracing work?* 분산 트레이싱은 어떻게 작동하는가?**

가장 단순한 형태의 오픈트레이싱을 활용한 분산 트레이싱은 애플리케이션이 스팬을 생성하고, 이를 오픈트레이싱 엔진과 공유하며, 뒤이어 호출하는 서비스로 트레이스 콘텍스트를 전파하는 것으로 이뤄진다.
- At its simplest form, distributed tracing with OpenTracing consists of applications creating Spans, sharing those Spans with an OpenTracing engine, and propagating a trace context to any of the services it subsequently calls.
스팬 span 이란 서비스나 구성 요소 내에서 작업 단위를 나타내는 데이터 모음을 말한다.
- A Span is a collection of data representing a unit of work within a service or component.
이 데이터에는 작업 시작 시각, 종료 시각, 작업 이름, 태그 및 로그 집합 등이 포함된다.
업스트림 서비스도 동일한 작업을 수행한다. In turn, those upstream services do the same thing
요청 중 자신이 처리하는 부분을 나타내는 스팬을 만들고, 이를 오픈트레이싱 엔진에 보내고, 트레이스 콘텍스트를 다른 서비스로 전파한다.
- create a Span capturing its part of the request, send that to the OpenTracing engine, and further propagate the trace context to other services.
분산 트레이싱 엔진은 이런 스팬과 트레이스 콘텍스트를 사용해 트레이스를 구축할 수 있다. (Span 과 Trace context ⇒ Trace)
- Using these Spans and the trace context, the distributed-tracing engine can construct a Trace.
여기서 트레이스란 서비스 간의 인과 관계를 말하며 방향, 타이밍과 기타 디버깅 정보를 보여준다.
스팬에는 스팬 ID와 트레이스 ID가 있다.
이러한 ID들은 서비스 간의 작업 상관관계를 파악하는 데 사용되며 서비스 간에 전파돼야 한다. 그림 8.7은 이를 설명해준다.

분산 트레이싱을 사용하면, 네트워크 홉마다 스팬을 수집하고 이를 종합적인 트레이스에 담아 호출 그래프 내의 문제를 디버깅하는 데 사용할 수 있다.
오픈트레이싱 구현체에는 다음과 같은 시스템들이 있다.
- 예거 Jaeger
- 집킨 Zipkin
- 라이트스텝 Lightstep
- 인스타나 Instana
이스티오는 스팬을 분산 트레이싱 엔진으로 보낼 수 있으므로, 이 작업을 위해 언어 전용 라이브러리나 애플리케이션 전용 설정이 필요 없다.
요청이 이스티오 서비스 프록시를 통과할 때, 이미 진행 중인 트레이스가 없다면 트레이스를 새로 시작하고 요청의 시작 및 종료 시각을 스팬의 일부로 기록한다.
이스티오는 후속 스팬을 전체 트레이스에 연관 짓는데 사용할 수 있도록, 보통 집킨 트레이싱 헤더 Zipkin tracing header 라고 하는 HTTP 헤더를 요청에 덧붙인다.
- Istio appends HTTP headers, commonly known as the Zipkin tracing headers, to the request that can be used to correlate subsequent Span objects to the overall Trace.
요청이 서비스로 들어왔을 때 이스티오 프록시가 분산 트레이싱 헤더를 인식하면 프록시는 트레이스가 진행 중인 것으로 취급해 트레이스를 새로 만들지 않는다.
이스티오와 분산 트레이싱 기능에서 사용하는 집킨 트레이싱 헤더는 다음과 같다.
- x-request-id
- x-b3-traceid
- x-b3-spanid
- x-b3-parentspanid
- x-b3-sampled
- x-b3-flags
- x-ot-span-context

이스티오가 제공하는 분산 트레이싱 기능이 요청 호출 그래프 전체에 걸쳐 작동하려면, 각 애플리케이션이 이 헤더들이 자신이 하는 모든 호출에 전파해야 한다. (그림 8.8 참고)

요청이 들어온다.
오! 트레이싱 헤더가 없는 것을 보니 새로운 요청이다.
- 요청이 서비스 사이를 오가는 과정을 추적할 수 있도록 트레이스 헤더를 생성해두자
트레이스 헤더가 요청 헤더에 추가됐다. x-request-id: c9421…
애플리케이션이 다른 서비스를 호출할 때 트레이스 헤더를 전파해야 한다.
트레이스 헤더를 전파한다. x-request-id: c9421…
이스티오 프록시는 기존 트레이스 헤더를 애플리케이션으로 전파한다.
만약 애플리케이션이 요청 헤더를 전파하지 않으면…
요청에 트레이스 헤더가 누락된다. 앱이 전파하지 않았기 때문이다.

이스티오는 어떤 호출이 어떤 수신 요청의 결과물인지 모르기 때문이다.
업스트림 호출과 서비스로 들어온 호출을 올바르게 연결하려면, 애플리케이션이 반드시 이런 헤더를 전파하는 역할을 맡아야 한다.
대부분의 경우 기본 RPC 프레임워크는 오픈트레이싱과 통합되거나 오픈트레이싱을 직접 지원해 이런 헤더를 자동으로 전파해준다.
어느 방식이든 애플리케이션은 이런 헤더가 전파됨을 보장해야 한다.

8.2.2 Installing a distributed tracing system 분산 트레이싱 시스템 설치하기 (실습~)

예거 설치는 복잡하여 데이터베이스가 필요하다.
이런 이유로 이 책에서는 예거의 일체형 all-in-one 배포 샘플을 그대로 사용한다.
이 샘플은 zipkin 쿠버네티스 서비스도 만드는데, 이스티오가 기대하는 기본 설정에 맞춰 만들어지는 덕분에 바로 연결할 수 있다.
분산 트레이싱 기능 커스터마이징에 대한 자세한 설명은 8.2.5절을 참조한다.
또한 완전한 운영 환경 배포 단계는 예거 문서를 참조하자. https://www.jaegertracing.io/docs/1.22/operator/#production-strategy
이스티오 sample 디렉터리에서 예거 일체형 배포를 설치해보자.

# myk8s-control-plane 진입 후 설치 진행
docker exec -it myk8s-control-plane bash
-----------------------------------
# 설치 파일 확인
pwd
ls istio-$ISTIOV/samples/addons
cat istio-$ISTIOV/samples/addons/jaeger.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: jaeger
  namespace: istio-system
  labels:
    app: jaeger
spec:
  selector:
    matchLabels:
      app: jaeger
  template:
    metadata:
      labels:
        app: jaeger
        sidecar.istio.io/inject: "false"
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "14269"
    spec:
      containers:
        - name: jaeger
          image: "docker.io/jaegertracing/all-in-one:1.35"
          env:
            - name: BADGER_EPHEMERAL
              value: "false"
            - name: SPAN_STORAGE_TYPE
              value: "badger"
            - name: BADGER_DIRECTORY_VALUE
              value: "/badger/data"
            - name: BADGER_DIRECTORY_KEY
              value: "/badger/key"
            - name: COLLECTOR_ZIPKIN_HOST_PORT
              value: ":9411"
            - name: MEMORY_MAX_TRACES
              value: "50000"
            - name: QUERY_BASE_PATH
              value: /jaeger
          livenessProbe:
            httpGet:
              path: /
              port: 14269
          readinessProbe:
            httpGet:
              path: /
              port: 14269
          volumeMounts:
            - name: data
              mountPath: /badger
          resources:
            requests:
              cpu: 10m
      volumes:
        - name: data
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: tracing
  namespace: istio-system
  labels:
    app: jaeger
spec:
  type: ClusterIP
  ports:
    - name: http-query
      port: 80
      protocol: TCP
      targetPort: 16686
    # Note: Change port name if you add '--query.grpc.tls.enabled=true'
    - name: grpc-query
      port: 16685
      protocol: TCP
      targetPort: 16685
  selector:
    app: jaeger
---
# Jaeger implements the Zipkin API. To support swapping out the tracing backend, we use a Service named Zipkin.
apiVersion: v1
kind: Service
metadata:
  labels:
    name: zipkin
  name: zipkin
  namespace: istio-system
spec:
  ports:
    - port: 9411
      targetPort: 9411
      name: http-query
  selector:
    app: jaeger
---
apiVersion: v1
kind: Service
metadata:
  name: jaeger-collector
  namespace: istio-system
  labels:
    app: jaeger
spec:
  type: ClusterIP
  ports:
  - name: jaeger-collector-http
    port: 14268
    targetPort: 14268
    protocol: TCP
  - name: jaeger-collector-grpc
    port: 14250
    targetPort: 14250
    protocol: TCP
  - port: 9411
    targetPort: 9411
    name: http-zipkin
  selector:
    app: jaeger
    
# 설치
kubectl apply -f istio-$ISTIOV/samples/addons/jaeger.yaml
deployment.apps/jaeger created
service/tracing created
service/zipkin created
service/jaeger-collector created

# 빠져나오기
exit
-----------------------------------

# 설치 확인 : 예거는 집킨 형식과 호환됨 Jaeger is compatible with the Zipkin format.
# https://www.jaegertracing.io/docs/1.22/features/#backwards-compatibility-with-zipkin
kubectl get deploy,pod,svc,ep -n istio-system

# NodePort 변경 및 nodeport tracing(30004) 변경
kubectl describe svc -n istio-system tracing
...
Port:                     http-query  80/TCP
TargetPort:               16686/TCP
NodePort:                 http-query  31345/TCP
Endpoints:                10.10.0.20:16686
...

kubectl patch svc -n istio-system tracing -p '{"spec": {"type": "NodePort", "ports": [{"port": 80, "targetPort": 16686, "nodePort": 30004}]}}'

# tracing 접속 : 예거 트레이싱 대시보드
open http://127.0.0.1:30004

8.2.3 Configuring Istio to perform distributed tracing 분산 트레이싱을 수행하도록 이스티오 설정하기

이스티오에서 분산 트레이싱은 메시 전체, 네임스페이스, 특정 워크로드 수준으로 설정할 수 있다.
이번 장에서는 전체 및 워크로드 트레이싱 설정을 다룬다.

Note
이스티오 1.12는 ‘로깅, 메트릭, 트레이싱’에 좀 더 세분화된 API인 텔레메트리 Telemetry API를 도입했다.

설치 전 트레이싱 설정하기 : 방법 1 사용

이스티오는 집킨, 데이터독, 예거(집킨 호환)등 분산 트레이싱 백엔드를 지원한다.
- Istio supports distributed tracing backends including Zipkin, Datadog, Jaeger (Zipkin compatible), and others.
방법 1 : 다음은 이스티오를 설치할 때 IstioOperator 리소스를 사용하는 샘플 설정으로, 다양한 분산 트레이싱 백엔드를 설정한다.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
spec:
  meshConfig:
    defaultConfig:
      tracing:
        lightstep: {}
        zipkin: {}
        datadog: {}
        stackdriver: {}

예를 들어 집킨 호환형인 예거를 사용하려면 다음과 같이 설정한다. → 현재 실습 설정

#
cat ch8/install-istio-tracing-zipkin.yaml
---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
spec:
  meshConfig:
    defaultConfig:
      tracing:
        sampling: 100
        zipkin:
          address: zipkin.istio-system:9411

# 기존 설정 확인
kubectl get IstioOperator -n istio-system installed-state -o json        
kubectl describe cm -n istio-system istio
...
defaultConfig:
  discoveryAddress: istiod.istio-system.svc:15012
  proxyMetadata: {}
  tracing:
    zipkin:
      address: zipkin.istio-system:9411
...

# 적용
docker exec -it myk8s-control-plane bash
-----------------------------------
# 
cat << EOF > install-istio-tracing-zipkin.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
spec:
  meshConfig:
    defaultConfig:
      tracing:
        sampling: 100
        zipkin:
          address: zipkin.istio-system:9411
EOF

istioctl install -y -f install-istio-tracing-zipkin.yaml

exit
-----------------------------------

# 확인
kubectl describe cm -n istio-system istio
...
  tracing:
    sampling: 100
    zipkin:
      address: zipkin.istio-system:9411
...

방법 2 : istio configmap 설정 - MeshConfig 를 이용한 트레이싱 설정 ⇒ 실습은 Skip

# 
kubectl edit cm -n istio-system istio
...

메시 범위의 기본 설정은 어떤 것이라도 defaultConfig.tracing 부분에서 업데이트 할 수 있다.

방법 3 : 워크로드별로 트레이싱 설정하기 : 파드 Spec에 애노테이션 설정

# 
apiVersion: apps/v1
kind: Deployment
...
spec:
  template:
    metadata:
      annotations:
        proxy.istio.io/config: |
          tracing:
            zipkin:
              address: zipkin.istio-system:9411
...

기본 트레이싱 헤더 살펴보기 : 헤더와 ID 자동 주입 확인

이 시점에서 트레이스를 올바를 위치에 보내도록 분산 트레이싱 엔진과 이스티오를 설정했다.
이스티오가 생성하는 트레이싱용 집킨 헤더가 우리가 예상하는 대로인지 확인하기 위해 몇 가지 테스트를 해보자.
이스티오가 오픈트레이싱 헤더와 상관관계 ID를 자동으로 주입한다는 것을 보여주고자 이스티오 인그레스 게이트웨이를 사용해 외부 httpbin 서비스를 호출하고 요청 헤더를 표시하는 엔드포인트를 호출할 것이다.
- 실습에서는 httpbin.istioinaction.io 요청 시 외부 서비스 http://httpbin.org 를 호출.
- http://httpbin.org 은 simple HTTP 테스트 서비스로 응답 시 헤더 정보를 출력.
이렇게 라우팅하는 이스티오 Gateway, VirtualService 리소스를 배포해보자.

#
cat ch8/tracing/thin-httpbin-virtualservice.yaml
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: coolstore-gateway
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "webapp.istioinaction.io"
    - "httpbin.istioinaction.io"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: thin-httbin-virtualservice
spec:
  hosts:
  - "httpbin.istioinaction.io"
  gateways:
  - coolstore-gateway
  http:
  - route:
    - destination:
        host: httpbin.org
---        
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: external-httpbin-org
spec:
  hosts:
  - httpbin.org 
  ports:
  - number: 80
    name: http
    protocol: HTTP
  location: MESH_EXTERNAL
  resolution: DNS

#
kubectl apply -n istioinaction -f ch8/tracing/thin-httpbin-virtualservice.yaml

# 확인
kubectl get gw,vs,serviceentry -n istioinaction

# 도메인 질의를 위한 임시 설정 : 실습 완료 후에는 삭제 해둘 것
echo "127.0.0.1       httpbin.istioinaction.io" | sudo tee -a /etc/hosts
cat /etc/hosts | tail -n 5

호스트에서 호출 시, 어떻게 외부 서비스로 전달되는지 살펴보자. 원래 요청에서 사용된 헤더를 반환해야 한다.
- client (curl) → istio-ingress-gateway → httpbin.org (외부)

#
curl -s http://httpbin.istioinaction.io:30000/headers | jq
{
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.istioinaction.io",
    "User-Agent": "curl/8.7.1",
    "X-Amzn-Trace-Id": "Root=1-680de9d9-33db643526404d6b0dc37527",
    "X-B3-Sampled": "1",
    "X-B3-Spanid": "3726f7dcb215ac12",
    "X-B3-Traceid": "9a4a7076cf8b5f633726f7dcb215ac12",
    "X-Envoy-Attempt-Count": "1",
    "X-Envoy-Decorator-Operation": "httpbin.org:80/*",
    "X-Envoy-Internal": "true",
    "X-Envoy-Peer-Metadata": "ChQKDkFQUF9DT05UQUlORVJTEgIaAAoaCgpDTFVTVEVSX0lEEgwaCkt1YmVybmV0ZXMKHAoMSU5TVEFOQ0VfSVBTEgwaCjEwLjEwLjAuMjIKGQoNSVNUSU9fVkVSU0lPThIIGgYxLjE3LjgKnAMKBkxBQkVMUxKRAyqOAwodCgNhcHASFhoUaXN0aW8taW5ncmVzc2dhdGV3YXkKEwoFY2hhcnQSChoIZ2F0ZXdheXMKFAoIaGVyaXRhZ2USCBoGVGlsbGVyCjYKKWluc3RhbGwub3BlcmF0b3IuaXN0aW8uaW8vb3duaW5nLXJlc291cmNlEgkaB3Vua25vd24KGQoFaXN0aW8SEBoOaW5ncmVzc2dhdGV3YXkKGQoMaXN0aW8uaW8vcmV2EgkaB2RlZmF1bHQKMAobb3BlcmF0b3IuaXN0aW8uaW8vY29tcG9uZW50EhEaD0luZ3Jlc3NHYXRld2F5cwoSCgdyZWxlYXNlEgcaBWlzdGlvCjkKH3NlcnZpY2UuaXN0aW8uaW8vY2Fub25pY2FsLW5hbWUSFhoUaXN0aW8taW5ncmVzc2dhdGV3YXkKLwojc2VydmljZS5pc3Rpby5pby9jYW5vbmljYWwtcmV2aXNpb24SCBoGbGF0ZXN0CiIKF3NpZGVjYXIuaXN0aW8uaW8vaW5qZWN0EgcaBWZhbHNlChoKB01FU0hfSUQSDxoNY2x1c3Rlci5sb2NhbAouCgROQU1FEiYaJGlzdGlvLWluZ3Jlc3NnYXRld2F5LTk5NmJjNmJiNi03bG5oNwobCglOQU1FU1BBQ0USDhoMaXN0aW8tc3lzdGVtCl0KBU9XTkVSElQaUmt1YmVybmV0ZXM6Ly9hcGlzL2FwcHMvdjEvbmFtZXNwYWNlcy9pc3Rpby1zeXN0ZW0vZGVwbG95bWVudHMvaXN0aW8taW5ncmVzc2dhdGV3YXkKFwoRUExBVEZPUk1fTUVUQURBVEESAioACicKDVdPUktMT0FEX05BTUUSFhoUaXN0aW8taW5ncmVzc2dhdGV3YXk=",
    "X-Envoy-Peer-Metadata-Id": "router~10.10.0.22~istio-ingressgateway-996bc6bb6-7lnh7.istio-system~istio-system.svc.cluster.local"
  }
}

# (참고) X-Envoy-Peer-Metadata 정보 디코딩 확인
echo "ChQKDkFQUF9DT05UQUlORVJTEgIaAAoaCgpDTFVTVEVSX0lEEgwaCkt1YmVybmV0ZXMKHAoMSU5TVEFOQ0VfSVBTEgwaCjEwLjEwLjAuMjIKGQoNSVNUSU9fVkVSU0lPThIIGgYxLjE3LjgKnAMKBkxBQkVMUxKRAyqOAwodCgNhcHASFhoUaXN0aW8taW5ncmVzc2dhdGV3YXkKEwoFY2hhcnQSChoIZ2F0ZXdheXMKFAoIaGVyaXRhZ2USCBoGVGlsbGVyCjYKKWluc3RhbGwub3BlcmF0b3IuaXN0aW8uaW8vb3duaW5nLXJlc291cmNlEgkaB3Vua25vd24KGQoFaXN0aW8SEBoOaW5ncmVzc2dhdGV3YXkKGQoMaXN0aW8uaW8vcmV2EgkaB2RlZmF1bHQKMAobb3BlcmF0b3IuaXN0aW8uaW8vY29tcG9uZW50EhEaD0luZ3Jlc3NHYXRld2F5cwoSCgdyZWxlYXNlEgcaBWlzdGlvCjkKH3NlcnZpY2UuaXN0aW8uaW8vY2Fub25pY2FsLW5hbWUSFhoUaXN0aW8taW5ncmVzc2dhdGV3YXkKLwojc2VydmljZS5pc3Rpby5pby9jYW5vbmljYWwtcmV2aXNpb24SCBoGbGF0ZXN0CiIKF3NpZGVjYXIuaXN0aW8uaW8vaW5qZWN0EgcaBWZhbHNlChoKB01FU0hfSUQSDxoNY2x1c3Rlci5sb2NhbAouCgROQU1FEiYaJGlzdGlvLWluZ3Jlc3NnYXRld2F5LTk5NmJjNmJiNi03bG5oNwobCglOQU1FU1BBQ0USDhoMaXN0aW8tc3lzdGVtCl0KBU9XTkVSElQaUmt1YmVybmV0ZXM6Ly9hcGlzL2FwcHMvdjEvbmFtZXNwYWNlcy9pc3Rpby1zeXN0ZW0vZGVwbG95bWVudHMvaXN0aW8taW5ncmVzc2dhdGV3YXkKFwoRUExBVEZPUk1fTUVUQURBVEESAioACicKDVdPUktMT0FEX05BTUUSFhoUaXN0aW8taW5ncmVzc2dhdGV3YXk=" | base64 -d
...

이스티오 인그레스 게이트웨이를 호출했을 때 간단한 HTTP 테스트 서비스인 외부 URL(httpbin.org)로 라우팅됐다.
이 서비스의 /headers 엔드포인트로 GET 요청을 하면 요청에 사용한 요청 헤더를 반환하여, x-b3-* 집킨 헤더가 요청에 자동으로 붙었음을 분명히 알 수 있다.
이 집킨 헤더들은 스팬을 만드는 데 쓰이며 예거로 보내진다.

8.2.4 Viewing distributed tracing data 분산 트레이싱 데이터 보기 (예거 UI)

스팬이 예거(혹은 기타 오픈트레이싱 엔진)로 보내질 때, 트레이스 및 관련 스팬을 쿼리하고 볼 수 있는 방법이 필요하다.
기본 예거 UI를 사용하자.
Service 에서 istio-ingressgateway 를 선택한다. 좌측 하단에 Find Traces 를 누르자.

트레이스가 아무것도 보이지 않으면 curl 트래픽을 조금 보내두자.

curl -s http://httpbin.istioinaction.io:30000/headers | jq
curl -s http://httpbin.istioinaction.io:30000/headers | jq
...

curl -s http://webapp.istioinaction.io:30000/api/catalog | jq
curl -s http://webapp.istioinaction.io:30000/api/catalog | jq
...

트레이스 콘텍스트 및 헤더 전파하기 Propagating trace context and headers : 올바른 동작을 위해 아래와 같은 헤더 전파 필요
- x-request-id
- x-b3-traceid
- x-b3-spanid
- x-b3-parentspanid
- x-b3-sampled
- x-b3-flags
- x-ot-span-context
⇒ 즉, 애플리케이션 코드가 요청을 받아 처리를 시작할 때 이 헤더와 그 값을 저장했다가 애플리케이션이 수행해야 하는 모든 발신 요청에 삽입해야 한다는 것이다. 이 작업은 프록시에서 자동으로 수행할 수 없다.

**8.2.5 Trace sampling, force traces, and custom tags* 트레이스 샘플링, 강제 트레이스, 커스텀 태그**

분산 트레이싱 및 스팬 수집은 시스템에 상당한 성능 저하를 초래할 수 있으므로, 서비스가 올바르게 실행 중일 때 분산 트레이싱 수집 빈도를 제한하도록 선택할 수 있다.
앞서 데모 프로필로 이스티오를 설치했는데, 이 프로필은 **분산 트레이싱의 샘플링을 100%**로 설정했다.
시스템에서 수집할 트레이스 비율을 설정함으로써 트레이스 샘플링을 제어할 수 있다.

메시의 트레이스 샘플링 비율 조정하기 TUNING THE TRACE SAMPLING FOR THE MESH

백엔드 분산 트레이싱을 설치할 때, 런타임에 혹은 워크로드별로 설정했던 것처럼 샘플링 비율도 마찬가지로 설정할 수 있다.
트레이싱 설정이 다음과 같아지도록 istio-system 네임스페이스에 있는 istio configmap 의 MeshConfig 를 수정해보자.

# 
KUBE_EDITOR="nano" kubectl edit -n istio-system cm istio
...
     sampling: 10  # <-- from 100
...

# 샘플링 적용은 istio-ingressgateway 재배포 필요 참고.
kubectl rollout restart deploy -n istio-system istio-ingressgateway
...
=> 확인은 못해봄. rollout restart 로 적용되는지, 혹은 파드 삭제가 필요한지 확인해보자.

이로써 서비스 메시 내 모든 워크로드에서 샘플링 비율이 전역적으로 10%로 바뀐다.
전역 설정 대신 애노테이션으로 워크로드별로도 설정할 수 있다.
여기서는 트레이싱 설정을 포함하도록 디플로이먼트 파드 템플릿의 애노테이션을 편집한다.

#
cat ch8/webapp-deployment-zipkin.yaml
...
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      annotations:
        proxy.istio.io/config: |
          tracing:
            sampling: 10 # 퍼센트 직접 수정 후 적용 해보세요!
            zipkin:
              address: zipkin.istio-system:9411
...

# 적용 시 파드 재생성으로 위 애노테이션 적용으로 짐작.. 확인은 못해봄...
kubectl apply -f ch8/webapp-deployment-zipkin.yaml -n istioinaction


# 호출 테스트
curl -s http://webapp.istioinaction.io:30000/api/catalog | jq
curl -s http://webapp.istioinaction.io:30000/api/catalog | jq
curl -s http://webapp.istioinaction.io:30000/api/catalog | jq
...

호출 테스트 후 예거 UI에서 샘플링 비율 대로 수집되는지 확인해보자.

**클라이언트에서 트레이싱 강제하기* FORCE-TRACING FROM THE CLIENT**

운영 환경에서는 트레이스의 샘플링 비율을 최소한으로 설정한 후 문제가 있을 때만 특정 워크로드에 대해 활성화하는 것이 이치에 맞다.
가끔은 **특정 요청(건)**에 트레이싱을 활성화해야 하는 경우가 있다.
이스티오에서는 특정 요청에만 트레이싱을 강제하도록 설정할 수 있다.
예를 들어 애플리케이션에서 요청에 x-envoy-force-trace 헤더를 추가해, 요청이 만드는 호출 그래프의 스팬과 트레이스를 이스티오가 포착하도록 만들 수 있다.
샘플 애플리케이션에서 한번 시도해보자.

#
curl -s -H "x-envoy-force-trace: true" http://webapp.istioinaction.io:30000/api/catalog -v
curl -s -H "x-envoy-force-trace: true" http://webapp.istioinaction.io:30000/api/catalog -v
curl -s -H "x-envoy-force-trace: true" http://webapp.istioinaction.io:30000/api/catalog -v
...

이 x-envoy-force-trace 헤더를 보낼 때마다 해당 요청과 그 요청의 호출 그래프 전체에 대해 트레이싱을 트리거한다.
특정 요청에 대해 더 많은 정보를 얻고 싶을 때 이 헤더를 주입할 수 있는 API 게이트웨이와 진단 서비스 같은 도구를 이스티오 위에 구축할 수 있다.

트레이스의 태그 커스터마이징하기 CUSTOMIZING THE TAGS IN A TRACE

스팬에 태그를 추가하는 것은 애플리케이션이 트레이스에 추가 메타데이터를 첨부(부여)하는 방법이다.
태그는 단순한 키-값 쌍을 말하는 것으로, 애플리케이션 혹은 조직별 커스텀 정보를 담고 있으며 백엔드 분산 트레이싱 엔진으로 보내는 스팬에 추가된다.
이 책을 저술하는 시점 기준으로는 세 가지 유형의 커스텀 태그를 설정할 수 있다.
- 명시적으로 값 지정하기 Explicitly specifying a value
- 환경 변수에서 값 가져오기 Pulling a value from environment variables
- 요청 헤더에서 값 가져오기 Pulling a value from request headers
예를 들어 webapp 서비스의 스팬에 커스텀 태그를 추가하려면, 해당 워크로드의 Deployment 리소스에 다음과 같이 애노테이션을 추가할 수 있다.

#
cat ch8/webapp-deployment-zipkin-tag.yaml
...
  template:
    metadata:
      annotations:
        proxy.istio.io/config: |
          tracing:
            sampling: 100
            customTags:
              custom_tag: # 커스텀 태그의 키
                literal:
                  value: "Test Tag" # 커스텀 태그의 값
            zipkin:
              address: zipkin.istio-system:9411
...

# webapp 에 커스텀 태그 적용
kubectl apply -n istioinaction -f ch8/webapp-deployment-zipkin-tag.yaml

# 호출
for in in {1..10}; do curl -s http://webapp.istioinaction.io:30000/api/catalog ; sleep 0.5; done
for in in {1..10}; do curl -s http://webapp.istioinaction.io:30000/api/catalog ; sleep 0.5; done
...

커스텀 태그는 보고 reporting, 필터링 filtering, 트레이싱 데이터 탐색에 사용할 수 있다.
스팬이나 트레이스에 포함되는 태그를 커스터마이징하는 방법은 이스티오 문서를 참조하자.
https://istio.io/v1.17/docs/tasks/observability/distributed-tracing/

백엔드 분산 트레이싱 엔진 커스터마이징하기 CUSTOMIZING THE BACKEND DISTRIBUTED TRACING ENGINE

분산 트레이싱에 대한 마지막 절인 여기서는 분산 트레이싱 엔진에 연결하는 백엔드 설정을 어떻게 수행하는지 알아보자.
앞서 언급했드시 이스티오는 1.12 버전에서 트레이싱을 포함하는 새로운 텔레메트리용 알파 API를 릴리스했으므로, 트레이싱 설정 면에서 사용자 경험이 개선될 것이라고 기대할 수 있다.
단, 이 절에서 다루는 내용은 다소 심화된 내용이므로 독자의 사용 사례에는 적용되지 않을 수 있다.
지금까지의 예제에서는 백엔드 트레이싱 엔진의 호스트네임과 포트로 이스티오를 설정했다.
그런데 더 많은 설정을 조정해야 하는 경우에는 어떻게 할까?
예를 들어, 예거의 집긴 호환성을 사용하려면 예거 수집기의 특정 엔드포인트로 추적을 전송해야 한다.
기본적으로는 이스티오 프록시에서 정적 설정으로 설정한다.
집킨 기반 트레이싱 엔진의 기본 트레이싱 설정을 살펴보자

# 
docker exec -it myk8s-control-plane bash
----------------------------------------
# deploy/webapp 트레이싱 설정 조회 : 현재 기본 설정
istioctl pc bootstrap -n istioinaction deploy/webapp -o json | jq .bootstrap.tracing
{
  "http": {
    "name": "envoy.tracers.zipkin",
    "typedConfig": {
      "@type": "type.googleapis.com/envoy.config.trace.v3.ZipkinConfig",
      "collectorCluster": "zipkin",
      "collectorEndpoint": "/api/v2/spans",
      "traceId128bit": true,
      "sharedSpanContext": false,
      "collectorEndpointVersion": "HTTP_JSON"
    }
  }
}

exit
----------------------------------------

현재 기본 설정
- tracing enging 은 Zipkin-based
- Span 은 /api/v2/spans 로 전달
- JSON 엔드포인트로 처리
기본 설정은 커스텀 부트스트랩 설정으로 변경 할 수 있다.
이를 위해 configmap 에서 튜닝하고자 하는 설정 스니펫을 지정한다.

# 해당 configmap 은 collectorEndpoint 를 변경한 설정 스니펫
cat ch8/istio-custom-bootstrap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-custom-zipkin
data:
  custom_bootstrap.json: |
    {
      "tracing": {
        "http": {
          "name": "envoy.tracers.zipkin",
          "typedConfig": {
            "@type": "type.googleapis.com/envoy.config.trace.v3.ZipkinConfig",
            "collectorCluster": "zipkin",
            "collectorEndpoint": "/zipkin/api/v1/spans",
            "traceId128bit": "true",
            "collectorEndpointVersion": "HTTP_JSON"
          }
        }
      }
    }

# 이 부트스트랩 설정을 덮어 쓰려는 워크로드가 있는 네임스페이스에 configmap 을 적용할 수 있다.
kubectl apply -n istioinaction -f ch8/istio-custom-bootstrap.yaml

# 확인
kubectl get cm -n istioinaction

# 해당 configmap 을 참조하는 Deployment 리소스의 파드 템플릿에 애노테이션을 추가
cat ch8/webapp-deployment-custom-boot.yaml
...
  template:
    metadata:
      annotations:
        sidecar.istio.io/bootstrapOverride: "istio-custom-zipkin" # 부트스트랩 설정을 istio-custom-zipkin 사용
        proxy.istio.io/config: |
          tracing:
            sampling: 10
            zipkin:
              address: zipkin.istio-system:9411
      labels:
        app: webapp
...

# 변경된 설정으로 webapp을 재배포 합니다
kubectl apply -n istioinaction -f ch8/webapp-deployment-custom-boot.yaml


#
docker exec -it myk8s-control-plane bash
----------------------------------------
# deploy/webapp 트레이싱 설정 조회 : 현재 기본 설정
istioctl pc bootstrap -n istioinaction deploy/webapp -o json | jq .bootstrap.tracing
{
  "http": {
    "name": "envoy.tracers.zipkin",
    "typedConfig": {
      "@type": "type.googleapis.com/envoy.config.trace.v3.ZipkinConfig",
      "collectorCluster": "zipkin",
      "collectorEndpoint": "/zipkin/api/v1/spans",
      "traceId128bit": true,
      "collectorEndpointVersion": "HTTP_JSON"
    }
  }
}

exit
----------------------------------------

# 호출
for in in {1..10}; do curl -s http://webapp.istioinaction.io:30000/api/catalog ; sleep 0.5; done
for in in {1..10}; do curl -s http://webapp.istioinaction.io:30000/api/catalog ; sleep 0.5; done
...

JAEGER 대시보드 확인 : webapp 추적 시 collectorEndpoint 에 잘못된 경로 설정으로 webapp Span이 출력되지 않습니다

다음 실습을 위해 다시 설정 원복

# istio-custom-zipkin 어노테이션이 없는 webapp으로 재배포
kubectl apply -n istioinaction -f services/webapp/kubernetes/webapp.yaml

# 호출
for in in {1..10}; do curl -s http://webapp.istioinaction.io:30000/api/catalog ; sleep 0.5; done
for in in {1..10}; do curl -s http://webapp.istioinaction.io:30000/api/catalog ; sleep 0.5; done
...

JAEGER 대시보드 확인

8.3 Visualization with Kiali 키알리를 이용한 시각화 - https://kiali.io/

들어가며 : Kiali - The Console for Istio Service Mesh

이스티오는 오픈소스 프로젝트 키알리의 강력한 시각화 대시보드를 함께 사용할 수 있는데, 이는 런타임에 서비스 메시를 이해하는 데 도움을 줄 수 있다.
키알리는 프로메테우스와 기반 플랫폼에서 많은 양의 메트릭을 가져와 메시 내 구성 요소의 런타임 그래프를 구성하는데, 이 그래프가 서비스 간의 통신 상황을 시각적으로 이해하는 데 도움이 된다.
또한 그래프와 상화작용해 문제가 될 수 있는 영역을 파고들어 무슨 일이 일어나고 있는지 자세히 알아볼 수도 있다.
키알리는 그라파나와 다른데, 키알리는 실시간으로 갱신되는 메트릭을 사용해 서비스가 서로 어떻게 통신하는지에 대한 방향 그래프 directed graph 를 구축하는데 집중하기 때문이다.
그라파나는 게이지, 카운터, 차트 등이 포함된 대시보드에는 훌륭하지만, 클러스터 내 서비스에 대한 상호작용형 그림이나 지도를 보여주지는 않는다.
이 절에서는 키알리 대시보드의 기능을 살펴본다.

8.3.1 Installing Kiali 키알리 설치하기 (실습)

프로메테우스나 그라파나와 마찬가지로 이스티오는 키알리 샘플 버전을 기본적으로 제공한다.
그러나 이스티오 팀과 키알리 팀은 실제로 배포할 때는 키알리 오퍼레이터를 사용하길 권장한다. https://github.com/kiali/kiali-operator
이번 절에서도 이 방식을 사용할 것이다. 키알리 설치에 대한 자세한 내용은 공식 설치 가이드를 참조하자.
https://v1-41.kiali.io/docs/installation/installation-guide/
먼저 키알리 오퍼레이터 설치부터 시작한다 - 참고 Blog , Helm

# helm repo
helm repo add kiali https://kiali.org/helm-charts
helm repo update 

# kiali-operator install : 책은 1.40.1
helm install --namespace kiali-operator --create-namespace --version 1.63.2 kiali-operator kiali/kiali-operator

# kiali-operator 확인
kubectl get pod -n kiali-operator
NAME                             READY   STATUS    RESTARTS   AGE
kiali-operator-584858fb7-zcjv2   1/1     Running   0          61s

istio-system 네임스페이스에 키알리 인스턴스 배포 : 웹 대시보드를 갖춘 실제 애플리케이션

# 앞 절에서 배포했던 프로메테우스와 예거에 연결할 수 있게 설정
cat ch8/kiali.yaml
apiVersion: kiali.io/v1alpha1
kind: Kiali
metadata:
  namespace: istio-system
  name: kiali
spec:
  istio_namespace: "istio-system"  
  istio_component_namespaces:
    prometheus: prometheus
  auth:    
    strategy: anonymous # 익명 접근 허용
  deployment:
    accessible_namespaces:
    - '**'
  external_services:    
    prometheus: # 클러스터 내에서 실행 중인 프로메테우스 설정
      cache_duration: 10
      cache_enabled: true
      cache_expiration: 300
      url: "http://prom-kube-prometheus-stack-prometheus.prometheus:9090"    
    tracing: # 클러스터 내에서 실행 중인 예거 설정
      enabled: true
      in_cluster_url: "http://tracing.istio-system:16685/jaeger"
      use_grpc: true

# 키알리 인스턴스(대시보드) 설치
kubectl apply -f ch8/kiali.yaml


# 확인
kubectl get deploy,svc -n istio-system kiali
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/kiali   1/1     1            1           36s

NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)              AGE
service/kiali   ClusterIP   10.200.1.179   <none>        20001/TCP,9090/TCP   35s

# NodePort 변경 및 nodeport kiali(30003)
kubectl patch svc -n istio-system kiali -p '{"spec": {"type": "NodePort", "ports": [{"port": 20001, "targetPort": 20001, "nodePort": 30003}]}}'

# Kiali 접속 1 : NodePort
open http://127.0.0.1:30003

프로메테우스와 예거 모두 기본적인 통신 보안 전략이 따로 있지는 않으며, 앞 단에 리버스 프록시를 둘 것을 권장한다.
키알리에서는 프로메테우스에 연결할 때 TLS와 기본적인 인증을 사용할 수 있다.

트래픽 확인을 위해서 반복 호출

while true; do curl -s http://webapp.istioinaction.io:30000/api/catalog ; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; echo; done

Graph : 서비스 매시의 트래픽 흐름을 보여주는 방향 그래프 ⇒ Display 체크
- 트래픽의 이동과 흐름 Traversal and flow of traffic
- 바이트 수, 요청 개수 등 Number of bytes, requests, and so on
- 여러 버전에 대한 여러 트래픽 흐름(예: 카나리 릴리스나 가중치 라우팅)
- 초당 요청 수 Requests/second; 총량 대비 여러 버전의 트래픽 비율
- 네트워크 트래픽에 기반한 애플리케이션 상태 health
- HTTP/TCP 트래픽
- 빠르게 식별할 수 있는 네트워크 실패

Workloads → Traces 선택

트레이스, 메트릭, 로그의 연관성 CORRELATION OF TRACES, METRICS, AND LOGS

Workloads 메뉴

Overview : Pods of the service, Istio configuration applied to it, and a graph of the upstreams and downstreams
Traffic : Success rate of inbound and outbound traffic
Logs : Application logs, Envoy access logs, and spans correlated together Inbound Metrics and Outbound Metrics Correlated with spans
Traces : The traces reported by Jaeger
Envoy : The Envoy configuration applied to the workload, such as clusters, listeners, and routes

Kiali workload vs. application 차이

워크로드
- A workload is a running binary that can be deployed as a set of identical running replicas. For example, in Kubernetes, this would be the Pods part of a deployment. A service A deployment with three replicas would be a workload.
애플리케이션
- An application is a grouping of workloads and associated constructs like services and configuration. In Kubernetes, this would be a service A along with a service B and maybe a database. Each would be its own workload, and together they would make up a Kiali application.

Kiali is useful for service mesh operators 키알리가 운영에 도움을 주는 것

VirtualService pointing to non-existent Gateway
Routing to destinations that do not exist
More than one VirtualService for the same host
Service subsets not found

8.3.2 Conclusion

Summary

그라파나는 Istio 제어 평면과 데이터 평면을 위한 기본 대시보드를 포함한 Istio 메트릭을 시각화하는 데 사용할 수 있습니다.
- Grafana can be used to visualize Istio metrics, including using out-of-the-box dashboards for the Istio control plane and data plane.
분산 추적은 요청을 처리하는 데 관련된 구성 요소에 대한 인사이트를 제공합니다. 이를 위해 서비스 프록시에서 추적 헤더로 요청에 주석을 달 수 있습니다.
- Distributed tracing gives us insights into the components involved in serving a request. To do so, it annotates requests with trace headers at the service proxy.
애플리케이션은 요청을 전체적으로 보기 위해 트레이스 헤더를 전파해야 합니다.
- Applications need to propagate trace headers in order to get a full view of a request.
트레이스는 분산 시스템에서 지연 시간을 디버깅하고 홉을 요청하는 데 사용할 수 있는 스팬 모음입니다.
- A trace is a collection of spans that can be used to debug latency and request hops in a distributed system.
Istio는 Istio 설치 중에 defaultConfig을 사용하여 추적 헤더를 라우팅하도록 구성할 수 있으며, 이는 전체 메쉬에 적용됩니다. 또는 주석 proxy.istio.io/config 을 사용하여 workload 단위로 동일한 구성을 적용할 수 있습니다.
- Istio can be configured to route tracing headers using defaultConfig during Istio installation, which applies to the entire mesh; or the same configuration can be applied on a per-workload basis using the annotation proxy.istio.io/config.
키알리 연산자는 프로메테우스의 메트릭과 예거의 트레이스를 읽도록 구성할 수 있습니다.
- The Kiali Operator can be configured to read metrics from Prometheus and traces from Jaeger.
Kiali는 디버깅을 돕기 위한 네트워킹 그래프와 메트릭 상관관계를 포함하여 Istio 관련 디버깅 대시보드를 꽤 많이 보유하고 있습니다.
- Kiali has quite a few Istio-specific debugging dashboards, including a networking graph and metric correlation to aid debugging.

저작자표시