Istio in Action 책을 기반으로, CloudNet@ 팀 가시다님의 Istio Hands-on Study 스터디를 정리한 글입니다.
Istio 개요
서비스 메쉬(Service Mesh)의 등장
서비스 메쉬의 필요성은 컨테이너 기술의 발전과 함께 부각되었다. 서비스가 점점 더 작아지고, 그 개수는 늘어나면서 전체 시스템을 모니터링하는 일이 점점 어려워졌다. 특히 서비스 운영 중 발생하는 장애나 병목의 원인을 파악하기 힘든 상황이 자주 발생하게 되었다. 그래서 이러한 문제들을 해결하기 위해 서비스 메쉬가 등장했다.
서비스 메쉬는 옵저버빌리티외에도, 개발자가 서비스 본연의 로직에만 집중할 수 있게 도와주는 역할도 수행한다.
만약 서비스마다 보안(mTLS), 트래픽 제어, 장애 복구, 모니터링 같은 기능을 직접 구현해야 한다고 생각해 보자.
게다가 각각 다른 언어와 프레임워크를 쓰고 있다면? 유지보수와 운영비용은 기하급수적으로 올라갈 수밖에 없다.
서비스 메쉬는 이런 공통적인 인프라 기능을 애플리케이션 바깥쪽에서 대신 처리해 준다.
즉, 서비스 자체는 비즈니스 로직만 신경 쓰고, 네트워크 관련 문제는 Istio와 같은 메쉬가 알아서 처리하는 구조다.
Istio란
Istio는 가장 대표적으로 사용되는 오픈 소스 서비스 메시 솔루션이다.
Envoy 프록시를 기반으로 모든 서비스 간 트래픽을 프록시 레이어를 통해 처리함으로써, 어플리케이션의 변경 없이 네트워크 레벨의 기능을 제공한다.
언제 Istio를 도입해야 할까?
Istio는 트래픽 제어, mTLS 보안, 모니터링까지 한 번에 해결할 수 있는 강력한 서비스 메시 프레임워크다.
하지만 “Istio를 쓰면 탈모가 온다”는 말이 괜히 있는 게 아니다. 그만큼 배워야 할 것도 많고, 설정도 만만치 않다.
결국 중요한 건, 우리 팀, 우리 서비스에 과연 맞는 도구인가?라는 걸 먼저 생각해봐야 한다.
실무에서는 후자에 상황에 더 가까워, 아직 Istio를 도입하진 않았지만, SRE의 끝판왕이라 불리는 Istio는, 계속 눈길이 가고, 언젠간 제대로 써보고 싶은 그런 존재다..
Istio 기본 개념
Envoy Proxy
Istio에서 Envoy Proxy는 가장 핵심적으로 사용되는 기술이다.
Envoy란 무엇인가?
• C++로 개발된 고성능 프록시 서버이다.
• xDS API(gRPC)를 통해 Envoy 프록시의 설정을 동적으로 변경할 수 있다.
• CNCF에서 세 번째로 Gratuation을 통과한 프로젝트이다(근본 그 자체.)
이러한 장점들로 많은 네트워크 관련 서비스에서 Envoy를 백엔드 서비스로 사용하고 있다.(istio, Gloo Gateway 등 )
Istio에서의 Envoy 역할
Istio는 애플리케이션 파드에 Envoy 프록시를 사이드카(Sidecar) 형태로 주입하며, 이를 통해 모든 인바운드/아웃바운드 트래픽을 가로채고 제어할 수 있게 된다.
정리하자면, Istio는 쿠버네티스 리소스를 통해 Envoy 사이드카를 제어하는 서비스 메쉬 컨트롤러라고 할 수 있다.
Istio 구성요소
Istio는 서비스 메시에 필요한 다양한 기능을 수행하기 위해 여러 컴포넌트를 제공한다.
이 구성요소들은 크게 제어 플레인(Control Plane), 게이트웨이(Gateway), 관측 도구(Observability) 세 가지로 나눌 수 있다.
Istiod(istio의 컨트롤 플레인)
과거 Istio는 Galley, Citadel, Pilot 등 여러 개의 컴포넌트로 구성되어 있었지만, 현재는 이 모든 기능이 단일 컴포넌트인 istiod로 통합되었으며, 주요 기능은 다음과 같다.
- 🔍 Discovery
클러스터 내에서 실행 중인 서비스를 동적으로 인식하고, Envoy 사이드카에 라우팅 정보를 전파한다. - ⚙️ Configuration
트래픽 제어 규칙, 서비스 간 통신 방식, 로드밸런싱 전략 등을 관리하며, 이를 Envoy에 실시간 반영한다. - 🔐 Certificates
mTLS 통신을 위한 인증서 발급 및 자동 갱신을 지원하여, 서비스 간 보안 연결을 유지한다.
Ingress / Egress Gateway
Istio가 트래픽을 제어하고 모니터링할 수 있도록 도와주는 진입점 역할을 하는 게이트웨이 리소스를 제공
관측 도구 (Observability)
Istio는 모니터링과 트레이싱을 위한 다양한 도구와 통합되어 있어, 서비스 간 통신 흐름을 쉽게 파악할 수 있습니다.
• Jaeger: 분산 트레이싱 도구로, 서비스 호출 간의 흐름을 시각화하고 병목을 분석
• Prometheus: Envoy 및 Istio 메트릭 데이터를 수집 및 저장하며, 실시간 상태 모니터링을 가능하게 한다.
• Grafana: Prometheus와 연동하여 대시보드 기반 시각화를 제공한다.
• Kiali: Istio의 서비스 메쉬 상태를 시각화하고, 네트워크 흐름, 라우팅 설정 등을 관리할 수 있다.
Sidecar vs ambient
Istio의 트래픽을 관리하는 방법에는 두 가지 방식이 존재한다.
1. Sidecar 모드
• 각 애플리케이션 Pod에 사이드카 프록시(Envoy)를 주입하여 트래픽을 제어하는 방식
• 모든 트래픽을 사이드카 프록시를 통해 통신하므로, 세밀한 제어와 모니터링을 할 수 있다. 하지만, 각 Pod마다 프록시를 추가하기 때문에, 리소스 소비가 증가하고, 관리의 복잡도가 증가한다..
2. Ambient 모드
• 사이드카를 사용하지 않는 새로운 접근 방식으로, ztunnel이 각 노드에 배치되어 서비스 간 네트워크 트래픽을 관리한다.
• 사이드카의 주입이 필요 없기 때문에, 애플리케이션 변경 없이 메쉬를 적용할 수 있으며, 리소스 사용 측면에서 더 효율적입니다.
• 하지만, 사이드카 모드에 비해 세밀한 트래픽 제어나 보안 기능이 제한될 수 있다.
• 최근 1.24 버전에서 GA 됨)
Sidecar 모드는 더 세밀한 보안과 제어가 필요한 경우 적합하고, Ambient 모드는 리소스 효율성을 중시하며 배포의 용이성을 원하는 경우 유리하다.
이번 포스팅에서는 Sidecar 모드를 사용한다.
Istio 설치 및 실습환경 구성
Istio 설치
버전 정보
• Kubernetes(KinD): 1.32.2
• istio: 1.25.1
Istio는 Istioctl, Helm, Operator 등 다양한 설치 방법을 지원하였지만, Operator 방식은 Deprecated 되었다고 한다. 이번 실습에서는 istioctl 도구를 사용한다.
쿠버네티스 클러스터 설치(kind)
#
kind create cluster --name myk8s --image kindest/node:v1.32.2 --config - <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraPortMappings:
- containerPort: 30000 # Sample Application
hostPort: 30000
- containerPort: 30001 # Prometheus
hostPort: 30001
- containerPort: 30002 # Grafana
hostPort: 30002
- containerPort: 30003 # Kiali
hostPort: 30003
- containerPort: 30004 # Tracing
hostPort: 30004
- containerPort: 30005 # kube-ops-view
hostPort: 30005
networking:
podSubnet: 10.10.0.0/16
serviceSubnet: 10.200.1.0/24
EOF
# 설치 확인
docker ps
# 노드에 기본 툴 설치
docker exec -it myk8s-control-plane sh -c 'apt update && apt install tree psmisc lsof wget bridge-utils net-tools dnsutils tcpdump ngrep iputils-ping git vim -y'
# 노드 확인
kubectl get node -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
myk8s-control-plane Ready control-plane 6h37m v1.32.2 192.168.107.2 <none> Debian GNU/Linux 12 (bookworm) 6.12.9-orbstack-00297-gaa9b46293ea3 containerd://2.0.3
istio 1.25.1 설치(mac)
brew install istioctl
istioctl version --remote=false
#
export ISTIOV=1.25.1
curl -s -L https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIOV sh -
# 샘플 코드 확인
cd istio-$ISTIOV
tree
code .
# default 프로파일 배포
cat <<EOF | istioctl install -y -f -
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
profile: demo
components:
ingressGateways:
- name: istio-ingressgateway
enabled: true
egressGateways:
- name: istio-egressgateway
enabled: false
EOF
AddOn 구성
addon 설치 및 실습 환경을 위한 구성을 설정한다.
• kind 클러스터에서 노출을 위해 노드 포트 변경
• addon 설치 목록
• prometheus
• grafana
• kiali
• jaeger
kind 클러스터에서 노출을 위해 노드 포트 변경(30000~)
# 설치 확인 : istiod(데몬, 컨트롤플레인), istio-ingressgateway, crd 등
kubectl get all,svc,ep,sa,cm,secret,pdb -n istio-system
kubectl get crd | grep istio.io | sort
# istio-ingressgateway 서비스 NodePort 변경 및 nodeport 30000로 지정 변경
kubectl patch svc -n istio-system istio-ingressgateway -p '{"spec": {"type": "NodePort", "ports": [{"port": 80, "targetPort": 8080, "nodePort": 30000}]}}'
kubectl get svc -n istio-system istio-ingressgateway
# istio-ingressgateway 서비스 externalTrafficPolicy 설정 : ClientIP 수집 확인 용도
kubectl patch svc -n istio-system istio-ingressgateway -p '{"spec":{"externalTrafficPolicy": "Local"}}'
kubectl describe svc -n istio-system istio-ingressgateway
addon 설치
# addon 설치
kubectl apply -f samples/addons
kubectl rollout status deployment/kiali -n istio-system
#
kubectl get pod,svc -n istio-system
# NodePort 변경 및 nodeport 30001~30003으로 변경 : prometheus(30001), grafana(30002), kiali(30003), tracing(30004)
kubectl patch svc -n istio-system prometheus -p '{"spec": {"type": "NodePort", "ports": [{"port": 9090, "targetPort": 9090, "nodePort": 30001}]}}'
kubectl patch svc -n istio-system grafana -p '{"spec": {"type": "NodePort", "ports": [{"port": 3000, "targetPort": 3000, "nodePort": 30002}]}}'
kubectl patch svc -n istio-system kiali -p '{"spec": {"type": "NodePort", "ports": [{"port": 20001, "targetPort": 20001, "nodePort": 30003}]}}'
kubectl patch svc -n istio-system tracing -p '{"spec": {"type": "NodePort", "ports": [{"port": 80, "targetPort": 16686, "nodePort": 30004}]}}'
브라우저에서 접속
# Prometheus 접속 : envoy, istio 메트릭 확인
open http://127.0.0.1:30001
# Grafana 접속
open http://127.0.0.1:30002
# Kiali 접속 1 : NodePort
open http://127.0.0.1:30003
# (옵션) Kiali 접속 2 : Port forward
kubectl port-forward deployment/kiali -n istio-system 20001:20001 &
open http://127.0.0.1:20001
# tracing 접속 : 예거 트레이싱 대시보드
open http://127.0.0.1:30004
실습 애플리케이션 구성
책에서 제공하는 샘플 애플리케이션을 통해 Istio 실습들을 진행하도록 한다.
webapp(프론트), catalog(백엔드) MSA 서비스로 구성되어 있으며, 간단한 웹 페이지를 제공한다.
Istio를 통해 트래픽을 인입하여 해당 서비스로 연결하여 트래픽을 관리해 보자.
서비스 메시(Istio)에 실습 애플리케이션 애플리케이션 배포
사이드카 인젝션(Sidecar Injection)이란? 파드에 추가적인 istio-proxy(Envoy) 컨테이너를 자동으로 추가하는 방법이다. 네임스페이스에 istio-injection=enabled 라벨을 설정하면 해당 네임스페이스에서 새로 스케줄링되는 파드는 사이드카 형태로 istio-proxy(Envoy) 컨테이너가 자동으로 주입된다.
애플리케이션을 배포하기 전에, istioinaction 네임스페이스를 새로 생성하고, 해당 네임스페이스에 Auto Injection을 할 수 있도록 라벨을 추가 한다.
kubectl create ns istioinaction
kubectl label namespace istioinaction istio-injection=enabled
kubectl get ns --show-labels
mutatingwebhookconfiguration 의해 사이드카 인젝션이 구현된다. 이 웹훅은 새로운 파드가 생성될 때마다 호출되어, 정의한 라벨이 있을 경우, 파드의 명세를 수정하여 사이드카 컨테이너를 추가한다.
# istio mutatingwebhookconfiguration 확인
kubectl get mutatingwebhookconfiguration istio-sidecar-injector
NAME WEBHOOKS AGE
istio-sidecar-injector 4 36m
실습 애플리케이션을 배포하기 위해, 예제 코드가 있는 레포지토리를 클론 한다.
git clone https://github.com/AcornPublishing/istio-in-action
cd istio-in-action/book-source-code-master
# 폴더 구성 확인
tree -L 1
.
├── README.md
├── appendices
├── bin
├── ch10
├── ch11
├── ch12
├── ch13
├── ch14
├── ch2
├── ch3
├── ch4
├── ch5
├── ch6
├── ch7
├── ch8
├── ch9
└── services
샘플코드를 통해 애플리케이션을 배포한다. 배포 후, 파드들을 확인해보면, 컨테이너가 2개이며, istio-proxy 사이드카 컨테이너가 잘 주입됨을 확인할 수 있다.
cat services/catalog/kubernetes/catalog.yaml
kubectl apply -f services/catalog/kubernetes/catalog.yaml -n istioinaction
cat services/webapp/kubernetes/webapp.yaml
kubectl apply -f services/webapp/kubernetes/webapp.yaml -n istioinaction
#
kubectl get pod -n istioinaction
NAME READY STATUS RESTARTS AGE
catalog-6cf4b97d-jx8xw 2/2 Running 0 29s
webapp-7685bcb84-zlxmv 2/2 Running 0 29s
# krew plugin
kubectl images
[Summary]: 1 namespaces, 2 pods, 6 containers and 3 different images
+--------------------------+-------------------+--------------------------------+
| Pod | Container | Image |
+--------------------------+-------------------+--------------------------------+
| catalog-5899bbc954-fdkg8 | catalog | istioinaction/catalog:latest |
+ +-------------------+--------------------------------+
| | istio-proxy | docker.io/istio/proxyv2:1.25.1 |
+ +-------------------+ +
| | (init) istio-init | |
+--------------------------+-------------------+--------------------------------+
| webapp-7c96945758-hj4zj | webapp | istioinaction/webapp:latest |
+ +-------------------+--------------------------------+
| | istio-proxy | docker.io/istio/proxyv2:1.25.1 |
+ +-------------------+ +
| | (init) istio-init | |
+--------------------------+-------------------+--------------------------------+
istio의 mutatingwebhook에 의해 파드에 istio의 설정이 추가된 것을 확인할 수 있다.
포트포워딩을 통해 브라우저에서 서비스 접속해 본다.
kubectl port-forward -n istioinaction deploy/webapp 8080:8080
Istio 기본 트레픽 제어 실습
Istio observability 도구 살펴보기
Istio 기본 트래픽 제어 실습을 진행하면서 트래픽을 좀 시각적으로 확인하기 위해 observability 도구들을 간단히 살펴보자.
Istio 프록시가 통신 구간 양쪽에 위치하는 덕분에 애플리케이션 사이에 무슨 일이 일어나는지에 대해 많은 텔레메트리를 수집하고 가시성을 확보할 수있다.
Istio는 addon을 통해 별도의 설정 없이 옵저버빌리티 도구들을 손쉽게 제공한다.
아마도, Addon으로 제공되는 옵저버빌리티 도구들은 빠른 실습과 테스트를 위한 샘플 수준의 매니페스트에 이기에, 운영 환경에서는 더욱더 상세한 설정들을 필요하기 때문에, 직접 구축하여 연동하여 사용해야겠죠..?
Prometheus
Envoy 및 Istio 메트릭 데이터를 수집 및 저장하며, 실시간 상태 모니터링(Grafana와의 연동)을 가능하게 한다.
istio 관련 메트릭이 자동으로 수집되고 있음을 확인할 수 있다.
Grafana
Prometheus와 연동하여 대시보드 기반 시각화를 제공한다.
프로메테우스를 통해 수집된 메트릭이 연동된 Istio 대시보드 또한, 자동으로 구성되어 있음 확인할 수 있다.
Kiali
Istio의 서비스 메쉬 상태를 시각화하고, 네트워크 흐름, 라우팅 설정 등을 관리할 수 있다.
최신 버전에서는 Mesh라는 신메뉴를 제공하며, Mesh 네트워크를 한눈에 파악할 수 있도록 토폴로지도 제공한다.
Jaeger
분산 트레이싱 도구로, 서비스 호출 간의 흐름을 시각화하고 병목을 분석 - 오픈트레이싱을 통한 분산 트레이싱
Istio for resiliency : catalog에 의도적으로 500 에러를 재현하고 retry로 복원력 높이기
Resilience(복원력)는 마이크로서비스 환경에서 서비스 장애나 네트워크 오류가 발생하더라도, 전체 시스템이 안정적으로 동작할 수 있는 능력을 의미한다.
예를 들어, LCK와 같은 티켓팅 서비스에서 일시적인 네트워크 오류로 사용자가 에러 화면을 보거나, 티켓팅 실패로 이어진다면 치명적인 문제가 된다. 애플리케이션 로직에서 retry를 구현할 수도 있지만, 이는 코드 복잡도 증가와 유지보수 비용을 유발한다.
Istio는 이러한 재시도(Resilience) 로직을 애플리케이션 코드 수정 없이, 사이드카 프록시 Envoy를 통해 처리할 수 있다.
Envoy는 트래픽을 가로채고, 네트워크 오류나 5xx 응답 발생 시 자동으로 재시도(Retry)를 수행한다.
에러 시뮬레이션: 의도적으로 50% 확률로 500 에러코드를 출력하도록 스크립트를 실행한다
# 예제코드 경로 확인
pwd
~/istio-in-action/book-source-code-master
kubectl config set-context $(kubectl config current-context) --namespace=istioinaction
# chaos.sh <에러코드> <확률>
./chaos.sh 500 50
그리고 curl을 통해 지속적으로 트래픽을 발생시켜 응답 결과를 모니터링한다
# 0.5초마다 애플리케이션 반복 접속
while true; do curl -s http://127.0.0.1:30000/api/catalog -I | head -n 1 ; date "+%Y-%m-%d %H:%M:%S" ; sleep 0.5; echo; done
약 50% 정도의 확률로 catalog 서비스와의 응답 성공률을 보여준다.
Retry 설정 적용 : VirtualService에 retry를 적용하고 다시 관찰해 보자.
• 아래 VirtualService 설정을 통해 5xx 응답에 대해 최대 3번까지, 각 요청당 2초 타임아웃을 주고 재시도하도록 구성한다.
# catalog 3번까지 요청 재시도 할 수 있고, 각 시도에는 2초의 제한 시간이 있음.
cat <<EOF | kubectl -n istioinaction apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: catalog
spec:
hosts:
- catalog
http:
- route:
- destination:
host: catalog
retries:
attempts: 3
retryOn: 5xx
perTryTimeout: 2s
EOF
결과 확인
webapp 서비스에서 catalog로의 요청이 실패하더라도, Istio는 이를 즉시 클라이언트에 실패로 반환하지 않는다.
대신, webapp → catalog 구간에서 재시도(Retry)를 수행하고, 그 결과 성공 응답을 받을 수 있다면 클라이언트에는 정상 응답을 전달한다.
이러한 흐름 덕분에, 클라이언트에서 바라보는 서비스는 보다 안정적이며, 최종 응답 성공률이 눈에 띄게 향상된다.
즉, 일시적인 장애나 네트워크 오류가 있어도 사용자는 이를 인지하지 못하게, 시스템의 복원력이 강화할 수 있다.
5xx 에러는 감소하고, 성공률이 현저히 향상된 것을 확인할 수 있다
Istio for Traffic Routing : 신규 버전을 테스트할 수 있도록 단계적으로 릴리스하기
Istio의 트래픽 라우팅(Traffic Routing) 기능은 단순한 서비스 간 통신을 넘어서, 조건부 분기, 트래픽 분산, 버전 기반 라우팅 등 다양한 설정을 지원하여, 세밀한 제어가 가능하다.
다음과 같은 상황에 Traffic Routing을 사용하면 유용하다.
• 트래픽의 일부만 신규 버전(v2)으로 분기
• 특정 요청 헤더나 쿠키, 사용자 정보에 따라 라우팅 분기
• Canary 배포, A/B 테스트 시나리오 구현
• 버전 별 로드밸런싱 및 요청 분산 전략 설정
실습 시나리오
새로운 릴리즈(catalog v2)를 출시하기 전, 기존 버전과 공존하며 QA팀이 신규 버전을 테스트할 수 있도록 단계적으로 릴리스한다고 가정하자.
이런 상황에서는 모든 사용자에게 바로 V2를 노출시키는 대신, 기본 사용자는 기존 버전(V1)을 사용하고, 특정 조건(예: 특정 헤더가 있는 요청)에만 V2로 트래픽을 라우팅 하여 검증이 가능해야 한다. 이를 통해 안정성과 사용자 경험을 해치지 않으면서 신규 기능에 대한 사전 검증을 수행할 수 있다.
새로운 버전(V2) catalog 배포
• catalog 서비스에 새로운 버전(V2)을 배포한다.
• 실제로는 새로운 이미지가 아닌, SHOW_IMAGE 환경변수에 따라 프론트에서 표시되는 이미지가 분기된다.
# catalog v2 배포
cat <<EOF | kubectl -n istioinaction apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: catalog
version: v2
name: catalog-v2
spec:
replicas: 1
selector:
matchLabels:
app: catalog
version: v2
template:
metadata:
labels:
app: catalog
version: v2
spec:
containers:
- env:
- name: KUBERNETES_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: SHOW_IMAGE
value: "true"
image: istioinaction/catalog:latest
imagePullPolicy: IfNotPresent
name: catalog
ports:
- containerPort: 3000
name: http
protocol: TCP
securityContext:
privileged: false
EOF
# 이전 실습, 500 에러 발생 꺼두기!
cd /istiobook/bin/
./chaos.sh 500 delete
exit
app=catalog 라벨을 사용하는 모든 파드는 기본적으로 같은 catalog 서비스로 묶이며, Kubernetes의 서비스 라운드로빈 전략에 따라 트래픽이 v1과 v2 파드로 약 50%씩 분산된다.
Istio에서 트래픽을 세밀하게 제어하려면 DestinationRule과 VirtualService를 정의해야 한다.
• DestinationRule은 특정 라벨을 가진 파드(서브셋)를 명시해 라우팅 대상 그룹을 정의한다.
• subset에 사용되는 라벨은 서비스 라벨이 아닌 파드 라벨 기준이다.
• 그 이유는, catalog라는 하나의 서비스가 여러 버전의 파드를 포함하기 때문. 따라서, 실제 라우팅은 파드의 라벨로 분기해야 한다.
먼저, V1만 접속하도록 설정
v1 파드로만 트래픽이 전달되도록 VirtualService를 생성한다.
cat <<EOF | kubectl -n istioinaction apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: catalog
spec:
host: catalog
subsets:
- name: version-v1
labels:
version: v1
- name: version-v2
labels:
version: v2
EOF
반복 호출로 실제 응답을 확인해 보자:
while true; do curl -s http://127.0.0.1:30000/api/catalog | jq; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; echo; done
결과: catalog 서비스는 오직 v1 파드로만 라우팅 된다.
특정 헤더를 V2, 그 외에는 v1접속을 설정
VirtualService 수정: 특정 헤더를 가진 요청만 V2로 보내고, 나머지는 V1으로 라우팅 하는 설정
match.headers필드를 통해 특정 헤더(x-dark-launch: v2)로 요청이 들어올 경우에만 Version V2 애플리케이션으로 라우팅
# 라우팅 VS 수정(업데이트)
cat <<EOF | kubectl -n istioinaction apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: catalog
spec:
hosts:
- catalog
http:
- match:
- headers:
x-dark-launch:
exact: "v2"
route:
- destination:
host: catalog
subset: version-v2
- route:
- destination:
host: catalog
subset: version-v1
EOF
x-dark-launch: v2 헤더를 포함하여 요청
# catalog v2는 imageUrl 필드 추가 : v2 응답에는 imageUrl 필드가 포함되어 있는 것으로 구분할 수 있다.
curl -s http://127.0.0.1:30000/api/catalog -H "x-dark-launch: v2" | jq
[
{
"id": 1,
"color": "amber",
"department": "Eyewear",
"name": "Elinor Glasses",
"price": "282.00",
"imageUrl": "http://lorempixel.com/640/480"
}
...
while true; do curl -s http://127.0.0.1:30000/api/catalog -H "x-dark-launch: v2" | jq; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; echo; done
kiali 확인 : V2로 라우팅 확인
최종적으로, Istio에서 트래픽 대한 리소스 상관관계에 대해 도식화를 해보았다.
다음 포스팅에서는 Circuit Breaking, Fault Injection, Traffic Shifting 등 Istio의 고급 트래픽 제어 기능을 다룰 예정이다.
결론
아직 사내에서는 Istio를 실무에 도입하진 않았지만,
트래픽이 많고 서비스 간 연동이 복잡한 서비스를 다루게 되었을 때를 가정해,
Istio를 실제로 사용한다는 마음가짐으로 학습해보자.
이번 글에서는 Istio의 전반적인 개념과 핵심 기능을 간단히 훑어봤고,
다음 주차부터는 각 기능별로 보다 세부적으로 정리해나갈 예정이다.
'Kubernetes > Istio' 카테고리의 다른 글
| Istio 시리즈 # 6 – 메트릭과 트레이싱으로 살펴보는 Istio Observability (1) | 2025.05.04 |
|---|---|
| Istio 시리즈 # 5 – 네트워크 복원력 강화하기(Resilience) (0) | 2025.04.27 |
| Istio 시리즈 # 4 – 세밀하게 트래픽 제어하기(Traffic Control) (0) | 2025.04.27 |
| Istio 시리즈 # 3 – 외부 트래픽 진입점, Ingress Gateway 알아보기 (0) | 2025.04.20 |
| Istio 시리즈 # 2 - Istio의 핵심, Envoy Proxy를 이해하자 (0) | 2025.04.20 |
