[메인 참고]
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로 분기
- 버전 별 응답 차이 확인
맥북 기준으로 진행
# 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를 사용한 구성과 무엇이 다르냐는 것!!!
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
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
직접 구성해보기! 이 보너스 단계와 관련된 내용은 1번 단계의 bookinfo와 관련되어 있습니다!
- 추가적으로, OpenTelemetry 설정을 커스터마이징하거나, trace 비율을 조정하는 등 추가적인 테스트를 해보셨으면 합니다.
중간에 kr2 콘솔 로그인 권한이 없어져서 일부 검증이 불가능하였지만,
어려운 내용이 아니기에 잘 진행은 될것으로 보입니다.
추가적으로 공부하면서 궁금했던 내용은 chatgpt한테 물어봤는데요,
댓글에 적어두었으니 참고하시면 좋을것 같습니다!
화이팅입니다!!
1번 단계의 추가 질문 대한 chatgpt의 답변!
와, 정말 핵심을 찌르는 질문이야! 👍
Istio + Bookinfo + Ingress Gateway
의 구성이 단순Nginx + Ingress Controller
와 무엇이 다른지는,Service Mesh의 존재 이유 자체랑 맞닿아 있어.
✅ 1. 공통점: Ingress Gateway를 통해
/productpage
로 진입둘 다 결국 사용자는 브라우저에서
http://<external-ip>/productpage
로 접속해.그럼 Ingress 리소스가 동작해서 내부 서비스로 요청을 전달해 주지.
/productpage
❗️2. 결정적 차이점: Istio는 Sidecar Proxy + Control Plane이 있음
👉 nginx ingress는 그냥 "들어오는 요청만 라우팅"
Service A
로 넘겨줌👉 Istio는 요청 흐름 전체에 "관찰 + 제어"를 추가함
🔍 예시 비교:
/productpage
요청 흐름🧠 결론 요약
다음 질문으로 이어가 볼까?
혹시 "사이드카 프록시가 하는 일" 이 궁금하거나,
Bookinfo 내부 트래픽이 어떻게 흐르는지 도식으로 설명해줄까? 😊