서비스 메쉬 관측 플랫폼

인기·2025년 3월 21일
0

개인 프로젝트

목록 보기
1/1

참고

[메인 참고]
1. https://bluehorn07.github.io/2024/02/02/install-istio-and-addons/
2. https://chatgpt.com/c/67dd1ed3-8b88-8012-a7c0-5323c2760fad
3. chatgpt.com

[서브 참고]
1. https://nginxstore.com/blog/istio/kubernetes%ec%97%90-istio-sidecar-%ec%99%80-nginx-plus-ingress-controller-%ed%86%b5%ed%95%a9/
2. https://nginxstore.com/blog/istio/istio-service-mesh-%ED%99%98%EA%B2%BD%EC%97%90-kiali%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%B4-%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B0%84-%ED%98%B8%EC%B6%9C-%EC%B6%94%EC%A0%81-%EC%A7%84%ED%96%89/

역할 정리

1. Istio

  • 역할
    서비스 메쉬를 구성해 트래픽 관리, 보안, 모니터링, 트레이싱을 지원.
    서비스 앞에 Envoy proxy(Sidecar) 를 주입해 네트워크 트래픽을 제어함.
  • 세부 기능:
    Ingress Gateway: 외부 트래픽 진입점
    VirtualService & DestinationRule: 트래픽 라우팅, 버전 분기 등
    Telemetry: Envoy proxy가 Prometheus, OpenTelemetry로 메트릭 및 트레이싱을 수집함
    Security: mTLS, 인증/인가, JWT 처리 등

2. OpenTelemetry Collector

  • 역할
    Istio/Envoy가 수집한 트레이싱 데이터(Span) 를 수신해서 다양한 백엔드로 전달.
    Jaeger, Zipkin, NewRelic, OTLP 등으로 멀티 백엔드 export가 가능.
  • 세부 기능
    receivers: 데이터를 수신 (예: OTLP, Zipkin)
    processors: 가공 및 필터링 (선택사항)
    exporters: 백엔드로 전달 (예: Jaeger, Prometheus Remote Write)
    service.pipelines: 위 구성들을 연결

3. Kiali

  • 역할
    Istio 서비스 메쉬의 시각화 도구. 실시간 트래픽 흐름, 라우팅 정책, 오류율, 성능 등을 볼 수 있음.
  • 세부 기능
    실시간 서비스 맵
    요청 수, 지연 시간, 오류율 등 시각화
    Istio 설정(VirtualService, DestinationRule 등) 검토 가능
    서비스 간 의존성 확인 (디버깅에 매우 유용)

단계적 구성을 위한 순서 요약

단계 1: 기본 Istio 환경 구축 + 샘플 앱 배포

목적: Istio Ingress → 서비스 A → 서비스 B 흐름을 직접 체험
→ 트래픽이 잘 들어오고, 서비스 간 호출이 어떻게 연결되는지 확인하는 게 포인트

  • Istio demo 프로파일 설치
  • Sidecar Injection 활성화된 네임스페이스 준비
  • Bookinfo 또는 httpbin + sleep 샘플 앱 배포
  • Ingress Gateway로 트래픽 진입 테스트
  • kubectl port-forward로 서비스 접속

단계 2: Kiali, Prometheus, Grafana로 메트릭 시각화

목적: 실시간 트래픽 흐름과 지연시간/요청수/에러율 파악
→ "내가 배포한 서비스가 어떻게 보이고 있는가"를 직접 시각적으로 체험

  • Kiali 설치 후 port-forward 접속 (http://localhost:20001)
  • 실시간 서비스 맵 확인 (Bookinfo 등)
  • Prometheus 메트릭 조회
  • Grafana에서 기본 Istio 대시보드 확인

단계 3: OpenTelemetry Collector + Jaeger 연동

목적: 서비스 간 호출의 "트레이스 흐름"을 추적 가능하게 만들기
→ "서비스 간 호출이 어떻게 연결되는가"를 실제 트랜잭션 수준에서 이해

  • OTEL Collector 배포 (ConfigMap + Deployment)
  • Istio가 OTEL Collector로 Span 전송하도록 설정 (sampling=100%)
  • Jaeger UI로 접속해 트레이스 확인 (http://localhost:16686)
  • 호출 시 어떤 서비스가 몇 ms 걸리는지, 어디서 병목이 있는지 파악

보너스 단계: 트래픽 제어 (A/B 테스트, Canary 등)

목적: Istio의 트래픽 라우팅 기능 활용해 운영 전략 실습
→ Istio를 사용하는 주 목적은 이 트래픽 제어 기능임을 이해

  • VirtualService, DestinationRule 작성
  • 50% 트래픽은 v1, 나머지는 v2로 분기
  • 버전 별 응답 차이 확인

구성 시작

맥북 기준으로 진행

1. 기본 Istio 환경 구축 + 샘플 앱 배포

# brew로 istioctl 설치
brew install istioctl

# istioctl 버전 확인을 진행하여 설치 확인
istioctl version

# Istio demo 프로파일로 설치
# → Prometheus, Kiali, Jaeger, Grafana 포함
istioctl install --set profile=demo -y
# Tech CS 분들은 여기서 오류 발생 가능! VPN 연결 후 재시도해 보세요

# 카카오클라우드로 진행 시 failed to call Webhook 발생
# https://kko.kakao.com/NwPwmdCDcA
# deploy 전체 spec 설정이 아닌 pod spec 설정에서 수정해 주세요.
kubectl edit deployment -n istio-system istiod
#***
#spec:
#    hostNetwork: true # 추가
#    dnsPolicy: ClusterFirstWithHostNet
#containers:
#***

# default 네임스페이스에 istio-injection label 추가
kubectl label namespace default istio-injection=enabled

# Bookinfo 샘플 앱 배포
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.21/samples/bookinfo/platform/kube/bookinfo.yaml

# Gateway + 트래픽 라우팅 정의 적용
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.21/samples/bookinfo/networking/bookinfo-gateway.yaml

# Istio Ingress Gateway의 EXTERNAL-IP 확인
# 주소 확인 후 웹브라우저에서 접속
kubectl get svc istio-ingressgateway -n istio-system
# 예: http://<EXTERNAL-IP>/productpage

이 1번 구성에서 가장 중요하게 생각해 봐야될 점은,
Istio + Bookinfo + Ingress Gateway를 사용한 구성이
Nginx+Ingress controller를 사용한 구성과 무엇이 다르냐는 것!!!

2. Kiali, Prometheus, Grafana로 메트릭 시각화

Prometheus : Istio에서 수집한 메트릭 데이터를 저장
Grafana : Prometheus 데이터를 시각화 (대시보드)
Kiali : Istio 메시에 연결된 서비스 간 관계/트래픽 흐름 시각화

# observability 네임스페이스 생성 (선택)
kubectl create namespace observability
# 필요 시 생성하고, 아래의 파드 생성 시 선택적으로 네임스페이스 변경하여 진행.
# 기본적으로 istio-system 네임스페이스에 생성됨. 변경하는 법은 따로 기재하지 않음.

# Istio에서 제공하는 애드온 매니페스트 적용
# Prometheus, Grafana, Kiali 포함
# istio-system 네임스페이스에 관련 Pod들을 배포
# 이 3개는 모두 생략 가능
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/addons/grafana.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/addons/kiali.yaml

# 모두 running 되고 있는지 확인
kubectl get pods -n istio-system

# 접근 테스트 (포트포워딩)
# 내부 서비스이기에 서비스화 시키지 않고 포트포워딩 하여 사용합니다!
# 이는 비슷한 구성은 카카오클라우드 grafana 기술문서에도 나와있습니다.

# Kiali (서비스 맵 보기)
# http://localhost:20001
kubectl port-forward svc/kiali -n istio-system 20001:20001
# Grafana (대시보드)
# http://localhost:3000
kubectl port-forward svc/grafana -n istio-system 3000:3000
# Prometheus (메트릭 확인)
# http://localhost:9090
kubectl port-forward svc/prometheus -n istio-system 9090:9090

3. 트레이스 추적

OpenTelemetry Collector : Istio에서 수집한 trace 데이터를 수집/가공/전송
Jaeger : 트레이스 데이터를 저장하고 시각화하는 UI 제공
Istio : Envoy 사이드카에서 trace 생성, OpenTelemetry에 전달

# Jaeger 배포 (생략 가능)
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/addons/jaeger.yaml

# OpenTelemetry Collector 배포
# 이 구성은 OpenTelemetry Collector가 4317 포트로 OTLP 데이터를 수신하고, 
# 수신한 트레이스를 Jaeger에 전달하도록 설정되어 있음
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/addons/extras/opentelemetry.yaml

# 포트포워딩으로 UI 확인
# http://localhost:16686
kubectl port-forward svc/jaeger -n istio-system 16686:16686

# 테스트 명령어 -> 몇번 실행 후 Jaeger UI에서 서비스 간 호출 경로, 요청 지연 시간 등 확인 가능
kubectl exec "$(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name})" \
    -c productpage -- curl -s http://localhost:9080/productpage

4. 보너스 단계

직접 구성해보기! 이 보너스 단계와 관련된 내용은 1번 단계의 bookinfo와 관련되어 있습니다!

  • 추가적으로, OpenTelemetry 설정을 커스터마이징하거나, trace 비율을 조정하는 등 추가적인 테스트를 해보셨으면 합니다.

중간에 kr2 콘솔 로그인 권한이 없어져서 일부 검증이 불가능하였지만,
어려운 내용이 아니기에 잘 진행은 될것으로 보입니다.

추가적으로 공부하면서 궁금했던 내용은 chatgpt한테 물어봤는데요,
댓글에 적어두었으니 참고하시면 좋을것 같습니다!

화이팅입니다!!

3개의 댓글

comment-user-thumbnail
2025년 4월 8일

1번 단계의 추가 질문 대한 chatgpt의 답변!


와, 정말 핵심을 찌르는 질문이야! 👍
Istio + Bookinfo + Ingress Gateway의 구성이 단순 Nginx + Ingress Controller무엇이 다른지는,
Service Mesh의 존재 이유 자체랑 맞닿아 있어.


✅ 1. 공통점: Ingress Gateway를 통해 /productpage로 진입

둘 다 결국 사용자는 브라우저에서 http://<external-ip>/productpage로 접속해.
그럼 Ingress 리소스가 동작해서 내부 서비스로 요청을 전달해 주지.

항목공통 구성 요소
URL 엔드포인트/productpage
외부 → 내부 연결Ingress (Istio Ingress Gateway 또는 nginx ingress)
클러스터 내 서비스Bookinfo productpage

❗️2. 결정적 차이점: Istio는 Sidecar Proxy + Control Plane이 있음

👉 nginx ingress는 그냥 "들어오는 요청만 라우팅"

  • 요청만 받아서 Service A로 넘겨줌
  • 트래픽 제어, 보안, 모니터링은 별도 구성 필요

👉 Istio는 요청 흐름 전체에 "관찰 + 제어"를 추가함

  • Ingress Gateway도 Envoy 기반
  • 모든 서비스마다 Sidecar(Envoy Proxy) 가 붙음
  • 네트워크 트래픽을 가로채서 분석, 모니터링, 제어 가능

🔍 예시 비교: /productpage 요청 흐름

항목Nginx IngressIstio
Ingress Controllernginx 컨트롤러Envoy 기반 Istio Ingress Gateway
내부 서비스 라우팅Kubernetes 서비스로 전달Istio가 Envoy proxy를 통해 sidecar로 라우팅
트래픽 관찰기본은 없음 (추가 설정 필요)Prometheus, Kiali, Jaeger에서 시각화 가능
TLS, mTLS직접 설정 필요mTLS 자동 관리 가능 (PeerAuthentication)
라우팅 정책간단한 path 기반 라우팅버전 기반, A/B 테스트, Canary 배포 등 고급 라우팅 지원
트래픽 분석외부 도구 필요내장된 Telemetry와 연동 가능

🧠 결론 요약

질문요약
단순 nginx ingress와 뭐가 달라?Istio는 요청을 단순히 넘겨주는 게 아니라, 관찰하고, 분석하고, 제어할 수 있음
왜 Istio가 필요한가?마이크로서비스 환경에서, 트래픽의 흐름을 중앙에서 통제하고 관찰할 수 있는 기능이 필요해서
단순한 웹서비스면?nginx ingress로도 충분함
운영 복잡도가 높은 서비스면?Istio 같은 서비스 메쉬가 진가를 발휘함

다음 질문으로 이어가 볼까?
혹시 "사이드카 프록시가 하는 일" 이 궁금하거나,
Bookinfo 내부 트래픽이 어떻게 흐르는지 도식으로 설명해줄까? 😊

1개의 답글