[Istio] Istio 소개, 첫걸음

xgro·2025년 4월 9일

Istio

목록 보기

1/17

📌 Notice

Istio Hands-on Study (=Istio)
직접 실습을 통해 Isito를 배포 및 설정하는 내용을 정리한 블로그입니다.

CloudNetaStudy 그룹에서 스터디를 진행하고 있습니다.

Gasida님께 다시한번 🙇 감사드립니다.

EKS 관련 이전 스터디 내용은 아래 링크를 통해 확인할 수 있습니다.

[AEWS] AWS EKS 스터디

[PKOS] KOPS를 이용한 AWS에 쿠버네티스 배포

[DOIK] Database Operator In Kubernetes study

[KANS3] Kubernetes Advanced Networking Study

📌 Summary

클라우드 네이티브 환경에서의 도전과제를 해결하기 위해 서비스 메시와 Istio의 필요성과 개념을 소개하며, Envoy 프록시 기반의 구성 요소들을 설명합니다.
실습 기반 접근으로 Kind 클러스터에 Istio를 설치 및 구성하고, 다양한 관찰 도구 및 복원력 실험을 통해 서비스 메시의 핵심 기능을 체험합니다.
트래픽 제어, 장애 주입, 버전 분기 등 Istio의 실제 활용 사례를 실습하며 클라우드 인프라의 안정성과 유연성을 높이는 방법을 학습합니다.

📌 서비스 메시와 이스티오: 클라우드 네이티브 환경의 복원력 아키텍처

클라우드 환경에서 분산 시스템을 운영하면서 많은 조직들이 공통적인 도전과제에 직면하고 있습니다.

서비스 요청 처리 시간의 불규칙성, 배포 자동화 테스트에서 발견되지 않는 버그, 팀별로 상이한 보안 정책 등 다양한 문제가 발생합니다. 이러한 도전과제를 해결하고 안정적인 시스템을 구축하기 위해 서비스 메시 아키텍처가 주목받고 있습니다.

이 글에서는 서비스 메시의 개념, 필요성, 그리고 대표적인 구현체인 이스티오(Istio)에 대해 알아보겠습니다.

👉 Step. 01 클라우드 네이티브 환경의 도전과제

✅ 인프라의 불확실성

클라우드 환경의 가장 큰 특징은 인프라의 일시성입니다.

언제든 리소스가 사용 불가능해질 수 있다는 전제 하에 애플리케이션을 설계해야 합니다.

예를 들어, 추천 서비스가 고객 서비스를 호출할 때 성능 저하가 발생하면, 그 원인은 서비스 과부하, 버그, 네트워크 문제, 하드웨어 오류 등 다양할 수 있습니다.

이런 문제는 서비스 간 의존성으로 인해 연쇄 장애를 일으킬 수 있으며, 대규모 클라우드 환경에서는 이러한 장애가 항상 발생할 수 있는 일상적인 상황이 됩니다.

✅ 복원력 있는 상호작용의 필요성

예기치 않은 장애에 대응하기 위해 여러 패턴이 발전해왔습니다:

클라이언트 측 로드 밸런싱: 클라이언트가 여러 엔드포인트 중 선택하여 호출
서비스 디스커버리: 정상 작동 중인 서비스 엔드포인트를 동적으로 찾는 메커니즘
서킷 브레이커: 문제가 있는 서비스에 일정 시간 부하를 차단하는 안전장치
격벽(Bulkheading): 리소스 사용량을 명시적 임계값으로 제한
타임아웃과 재시도: 요청에 시간 제한을 설정하고 실패한 요청을 적절히 재시도

👉 Step. 02 애플리케이션 라이브러리 접근법의 한계

초기에는 이러한 패턴들을 애플리케이션 내부에 라이브러리 형태로 구현했습니다. 대형 인터넷 기업들은 특정 언어에 대한 라이브러리와 프레임워크 개발에 상당한 자원을 투자했습니다.

넷플릭스의 OSS 스택(Hystrix, Ribbon, Eureka, Zuul)이 대표적인 예입니다.

하지만 이러한 접근법에는 몇 가지 중요한 한계가 있습니다:

✅ 주요 한계점

언어와 프레임워크 종속성: 많은 라이브러리들이 특정 프로그래밍 언어나 런타임만을 지원합니다.
언어 다양성 지원의 어려움: 다양한 언어를 사용하는 환경에서는 각 언어별로 동등한 기능의 라이브러리를 찾고 관리해야 합니다.
일관성 유지의 어려움: 여러 언어와 프레임워크에서 라이브러리를 일관되게 유지하는 것은 매우 어렵습니다.

이러한 한계로 인해, 분산화의 이점을 누리면서도 라이브러리 유지 관리 오버헤드를 줄일 수 있는 새로운 접근법이 필요하게 되었습니다.

👉 Step. 03 서비스 메시: 애플리케이션 네트워킹을 인프라로 이동

서비스 메시는 이러한 문제를 해결하기 위한 접근법으로, 애플리케이션 네트워킹 관심사를 인프라 레벨로 이동시킵니다.

✅ 서비스 메시의 개념

서비스 메시란 애플리케이션 대신 프로세스 외부에서 투명하게 네트워크 트래픽을 처리하는 분산형 애플리케이션 인프라를 말합니다. 크게 두 가지 핵심 구성요소로 이루어집니다:

데이터 플레인: 애플리케이션 계층 프록시(주로 엔보이 프록시)를 사용해 애플리케이션 대신 네트워킹 트래픽을 관리합니다. 메시를 거쳐가는 모든 트래픽을 처리하고 관찰합니다.
컨트롤 플레인: 프록시를 관리하고 설정하는 중앙 제어 시스템입니다. 메시의 두뇌 역할을 하며, 운영자가 네트워크 동작을 조작할 수 있는 API를 제공합니다.

✅ 애플리케이션 인식 서비스 프록시

서비스 메시의 핵심 요소는 애플리케이션을 인식할 수 있는 프록시입니다. 이러한 프록시는 단순히 커넥션과 패킷을 다루는 것을 넘어, 메시지와 요청 같은 애플리케이션 구조를 이해해야 합니다. 즉, OSI 7계층 프록시가 필요합니다.

엔보이(Envoy) 프록시는 오픈소스 애플리케이션 수준 프록시로, 언어나 프레임워크에 의존하지 않고 재시도, 타임아웃, 서킷 브레이커, 클라이언트 측 로드 밸런싱, 서비스 디스커버리, 보안, 메트릭 수집 등의 네트워크 관심사를 구현할 수 있습니다.

엔보이 프록시는 애플리케이션 인스턴스와 함께 사이드카 패턴으로 배포됩니다. 이는 모든 애플리케이션이 자신의 프록시를 통해 외부와 통신하게 하고, 들어오는 모든 트래픽도 프록시를 거치게 함으로써, 애플리케이션 코드 변경 없이 중요한 기능을 추가할 수 있게 합니다.

✅ 서비스 메시의 주요 기능

서비스 메시는 다음과 같은 중요한 기능을 제공합니다:

서비스 복원력: 재시도, 타임아웃, 서킷 브레이커 등을 구현해 장애에 강한 시스템을 구축합니다.
변화하는 인프라 대응: 서비스 디스커버리, 로드 밸런싱, 헬스 체크 등을 처리합니다.
트래픽 제어: 운영자가 트래픽을 명시적으로 제어하고 지시할 수 있습니다.
관찰 가능성: 요청 급증, 지연 시간, 처리량, 장애 등을 추적하여 네트워크 동작에 대한 상세한 정보를 제공합니다.
보안: 서비스 간 통신의 양쪽 끝을 제어하여 상호 인증을 통한 전송 계층 암호화(mTLS) 등 강력한 보안을 적용할 수 있습니다.

이 모든 기능은 애플리케이션 코드를 거의 또는 전혀 변경하지 않고도 제공됩니다.

👉 Step. 04 이스티오(Istio): 서비스 메시의 오픈소스 구현체

이스티오는 서비스 메시의 대표적인 오픈소스 구현체로, 구글, IBM, 리프트가 주도적으로 개발했습니다. 이스티오는 서비스 아키텍처에 복원력과 관찰 가능성을 투명한 방식으로 추가하는 데 도움이 됩니다.

✅ 이스티오의 구성요소

이스티오는 다음과 같은 요소로 구성됩니다:

데이터 플레인: 엔보이 프록시를 기반으로 한 서비스 프록시로, 애플리케이션과 함께 배포되어 정책을 구현하고 트래픽을 제어하며 메트릭과 트레이싱을 생성합니다.
컨트롤 플레인(istiod): 운영자가 데이터 플레인의 네트워크 동작을 제어할 수 있는 API를 제공하며, 다음 구성요소로 이루어져 있습니다:
- 파일럿(Pilot): 모든 엔보이 사이드카의 프록시 라우팅 규칙을 관리합니다.
- 갤리(Galley): 이스티오와 쿠버네티스를 연결하고 서비스 메시 구성 데이터를 검증합니다.
- 시타델(Citadel): 보안 기능을 담당하며, TLS 인증서 발급 및 관리를 수행합니다.

✅ 이스티오의 적용 범위

이스티오는 본래 쿠버네티스에서 실행할 목적으로 구축되었지만, 배포 플랫폼에 구애받지 않는 관점으로 작성되었습니다. 쿠버네티스, 오픈시프트와 같은 배포 플랫폼은 물론, 가상머신 같은 기존 배포 환경에서도 이스티오 기반 서비스 메시를 사용할 수 있습니다.

이스티오의 힘이 빛을 발하는 환경은 서비스 개수와 연결이 많고, 네트워크가 신뢰할 수 없는 클라우드 인프라 위에 있으며, 이런 구조가 여러 클러스터, 클라우드, 데이터센터에 걸쳐 확장되는 상황입니다. 또한 기존 레거시 환경에서도 배포할 수 있어 점진적인 현대화가 가능합니다.

👉 Step. 05 이스티오와 다른 기술의 관계

✅ 이스티오 vs 엔터프라이즈 서비스 버스(ESB)

서비스 지향 아키텍처(SOA) 시대의 ESB는 서비스 메시와 유사한 목적을 가졌지만, 중요한 차이점이 있습니다:

ESB는 중앙화된 배포 모델을 가졌고, 서비스 메시는 고도로 분산됩니다.
ESB는 애플리케이션 네트워킹과 서비스 중재 문제를 혼합했지만, 서비스 메시는 오직 애플리케이션 네트워킹 문제에만 집중합니다.
ESB는 복잡한 독점 벤더 소프트웨어 기반인 경우가 많았으나, 서비스 메시는 오픈소스 기반입니다.

✅ 이스티오 vs API 게이트웨이

API 게이트웨이와 서비스 메시는 일부 기능이 겹치지만, 중요한 차이점이 있습니다:

API 게이트웨이는 중앙집중식 접근 방식으로, 모든 트래픽이 게이트웨이를 통과하여 추가적인 네트워크 홉과 지연 시간을 초래할 수 있습니다.
서비스 메시에서는 프록시가 서비스와 함께 배치되어 추가 홉 없이 트래픽을 처리합니다.
서비스 메시는 탈중앙적이어서 각 애플리케이션이 자신의 프록시를 자신의 워크로드에 맞게 설정할 수 있습니다.

👉 Step. 06 서비스 메시 적용 시 고려사항

서비스 메시는 많은 이점을 제공하지만, 몇 가지 트레이드오프도 고려해야 합니다:

✅ 주요 고려사항

복잡성 증가: 요청 경로에 미들웨어(프록시)가 추가되어 디버깅이 복잡해질 수 있습니다.
테넌시 문제: 메시 내에 서비스가 많을수록 가치는 높아지지만, 잘못 구성하면 많은 서비스에 영향을 미칠 수 있습니다.
운영 오버헤드: 서비스 메시는 요청 경로의 중요한 요소가 되므로, 이를 적절히 설정하고 운영하는 방법을 이해해야 합니다.

📌 이스티오 첫걸음: 실습 기반 이해

이 문서는 『Istio in Action』 2장을 기반으로 한 실습 정리입니다.

실습 환경, 설치 명령어, 관찰 가능성 도구 연동, 복원력 실험 및 트래픽 제어까지 포함합니다.
Kind 기반 클러스터에서 Istio를 단계적으로 이해하고 적용해보는 데 목적이 있습니다.

📚 실습 환경

책이 출간된 시점(2022년 초)과 현재 환경(2025년 기준) 간의 격차로 인해, 실습은 책의 구성과 유사하지만 조금 더 최신의 쿠버네티스와 이스티오 버전을 사용해 진행하였습니다.

스터디 환경 기준
- Kubernetes: v1.23.17 (출처)
- Istio: 1.17.8 (릴리즈 노트)
- 클러스터: kind + docker desktop
- 경로: ~/Downloads/istio-in-action/book-source-code-master

👉 Step. 01 Kind 클러스터 구성 및 도구 설치

클러스터 구성
Istio 실습을 위한 Kind 기반의 로컬 Kubernetes 클러스터를 생성합니다.

kind create cluster --name myk8s --image kindest/node:v1.23.17 --config - <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 30000 # ingressgateway
    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
  extraMounts:
  - hostPath: /Users/사용자경로/istio-in-action/book-source-code-master
    containerPath: /istiobook
networking:
  podSubnet: 10.10.0.0/16
  serviceSubnet: 10.200.1.0/24
EOF

클러스터 내 기본 도구 설치

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'

(옵션) 편의성 도구 설치: kube-ops-view, metrics-server
클러스터 상태 시각화와 리소스 메트릭 수집을 위해 선택적으로 설치할 수 있는 도구들입니다.

# (옵션) kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set service.main.type=NodePort,service.main.ports.http.nodePort=30005 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl get deploy,pod,svc,ep -n kube-system -l app.kubernetes.io/instance=kube-ops-view


## kube-ops-view 접속 URL 확인
open "http://localhost:30005/#scale=1.5"
open "http://localhost:30005/#scale=1.3"


# (옵션) metrics-server
helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm install metrics-server metrics-server/metrics-server --set 'args[0]=--kubelet-insecure-tls' -n kube-system
kubectl get all -n kube-system -l app.kubernetes.io/instance=metrics-server

👉 Step. 02 Istio 설치 및 구성 확인

myk8s-control-plane 진입 후 설치 진행합니다.

istioctl 설치 및 환경 설정
Istio CLI 도구인 istioctl을 설치하고 사용할 Istio 버전을 환경 변수로 설정합니다.
docker exec -it myk8s-control-plane bash

export ISTIOV=1.17.8
echo 'export ISTIOV=1.17.8' >> /root/.bashrc

curl -sL https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIOV sh -
cp istio-$ISTIOV/bin/istioctl /usr/local/bin/istioctl

istioctl version --remote=false

Istio 설치 (default profile)
기본 프로파일을 사용해 Istio 컨트롤 플레인과 인그레스 게이트웨이를 클러스터에 설치합니다.
# default 프로파일 컨트롤 플레인 배포
istioctl x precheck # 설치 전 k8s 조건 충족 검사
istioctl profile list

istioctl install --set profile=default -y
✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

설치 후 다음 명령어로 정상 설치 여부를 확인합니다:
Istio 구성 요소가 정상적으로 배포되었는지 확인하고, 클러스터 상태를 점검합니다.
kubectl get all -n istio-system
istioctl verify-install

Istio 부가 도구 설치 (관찰 가능성 도구)
Prometheus, Grafana, Kiali, Jaeger 등 Istio의 관찰 가능성을 위한 도구들을 함께 설치합니다.
kubectl apply -f istio-$ISTIOV/samples/addons

👉 Step. 03 서비스 메시 내 첫 애플리케이션 배포

서비스 메시 구조를 이해하기 위해 간단한 애플리케이션을 Istio 환경에서 배포해 봅니다.

사이드카 프록시가 주입된 상태에서 트래픽 흐름을 관찰하고, 애플리케이션 간 통신이 올바르게 이루어지는지 확인합니다.

방법1: yaml에 sidecar 설정을 추가
istio-in-action/book-source-code-master 내부의 services/catalog/kubernetes/catalog.yaml 리소스를 이용하여 배포하는 방법
kubectl apply -f services/catalog/kubernetes/catalog.yaml -n istioinaction
kubectl apply -f services/webapp/kubernetes/webapp.yaml -n istioinaction

방법2: 네임스페이스 생성 및 사이드카 자동 주입 활성화
kubectl create ns istioinaction
kubectl label namespace istioinaction istio-injection=enabled

상태 확인
사이드카 주입이 활성화되었는지, 관련 Webhook 설정이 정상적으로 반영되었는지 확인합니다.

kubectl get mutatingwebhookconfiguration
NAME                         WEBHOOKS   AGE
istio-revision-tag-default   4          9m24s # 특정 revision의 사이드카 주입 설정 관리
istio-sidecar-injector       4          9m45s # Istio는 각 애플리케이션 Pod에 Envoy 사이드카 프록시를 자동으로 주입
                                              ## 네임스페이스나 Pod에 istio-injection=enabled 라벨이 있어야 작동 

kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml

테스트용 netshoot 파드 배포 및 접속 확인
네트워크 도구가 포함된 netshoot 파드를 배포하고, 이를 통해 다른 서비스(catalog, webapp)와의 연결 상태를 확인합니다.

#
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

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: netshoot
spec:
  containers:
  - name: netshoot
    image: nicolaka/netshoot
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF

# catalog 접속 확인
kubectl exec -it netshoot -- curl -s http://catalog.istioinaction/items/1 | jq
{
  "id": 1,
  "color": "amber",
  "department": "Eyewear",
  "name": "Elinor Glasses",
  "price": "282.00"
}

# webapp 접속 확인
kubectl exec -it netshoot -- curl -s http://webapp.istioinaction/api/catalog/items/1 | jq
{
  "id": 1,
  "color": "amber",
  "department": "Eyewear",
  "name": "Elinor Glasses",
  "price": "282.00"
}

파드 확인
웹 애플리케이션이 정상 동작하는지 포트포워딩을 통해 직접 웹 브라우저에서 확인할 수 있습니다.
# 아래 방법 대신 임시 사용
kubectl port-forward -n istioinaction deploy/webapp 8080:8080
확인 후 CTRL+C 로 종료

#
open http://localhost:8080

👉 Step. 04 Istio의 강력한 기능 탐색

Istio가 제공하는 프록시 상태 확인, 트래픽 라우팅 설정, 프록시 구성 조회 등의 기능을 통해

서비스 메시 내부의 네트워크 흐름과 구성을 깊이 있게 탐색해봅니다.

istioctl proxy-status : 단축어 ps 확인
사이드카 프록시가 Istiod와 정상적으로 동기화되었는지 확인할 수 있는 핵심 명령어입니다.
# istioctl proxy-status : 단축어 ps
docker exec -it myk8s-control-plane istioctl proxy-status
docker exec -it myk8s-control-plane istioctl ps

Gateway, VirtualService 배포
외부에서 클러스터 내부 서비스로 진입하기 위한 인그레스 게이트웨이 및 라우팅 설정을 적용합니다.

#
cat ch2/ingress-gateway.yaml
cat <<EOF | kubectl -n istioinaction apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: outfitters-gateway
  namespace: istioinaction
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: webapp-virtualservice
  namespace: istioinaction
spec:
  hosts:
  - "*"
  gateways:
  - outfitters-gateway
  http:
  - route:
    - destination:
        host: webapp
        port:
          number: 80
EOF

#
kubectl get gw,vs -n istioinaction
NAME                                             AGE
gateway.networking.istio.io/outfitters-gateway   126m

NAME                                                       GATEWAYS                 HOSTS   AGE
virtualservice.networking.istio.io/webapp-virtualservice   ["outfitters-gateway"]   ["*"]   126m

Gw, App등 상태를 확인할 수 있습니다.
프록시 동기화 상태, 라우팅, 클러스터 정보 등 다양한 프록시 구성을 proxy-config 명령어로 확인합니다.

# istioctl proxy-status : 단축어 ps
docker exec -it myk8s-control-plane istioctl proxy-status
NAME                                                  CLUSTER        CDS        LDS        EDS        RDS        ECDS         ISTIOD                      VERSION
catalog-6cf4b97d-nccfj.istioinaction                  Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-7df6ffc78d-bj7h7     1.17.8
istio-ingressgateway-996bc6bb6-mz544.istio-system     Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-7df6ffc78d-bj7h7     1.17.8
webapp-7685bcb84-c55ck.istioinaction                  Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-7df6ffc78d-bj7h7     1.17.8

ISTIOIGW=istio-ingressgateway-996bc6bb6-647tx.istio-system
WEBAPP=webapp-7685bcb84-nfntj.istioinaction

# istioctl proxy-config : 단축어 pc
docker exec -it myk8s-control-plane istioctl proxy-config all $ISTIOIGW
docker exec -it myk8s-control-plane istioctl proxy-config all $WEBAPP

docker exec -it myk8s-control-plane istioctl proxy-config listener $ISTIOIGW
docker exec -it myk8s-control-plane istioctl proxy-config route $ISTIOIGW
docker exec -it myk8s-control-plane istioctl proxy-config cluster $ISTIOIGW
docker exec -it myk8s-control-plane istioctl proxy-config endpoint $ISTIOIGW
docker exec -it myk8s-control-plane istioctl proxy-config log $ISTIOIGW

docker exec -it myk8s-control-plane istioctl proxy-config listener $WEBAPP
docker exec -it myk8s-control-plane istioctl proxy-config route $WEBAPP
docker exec -it myk8s-control-plane istioctl proxy-config cluster $WEBAPP
docker exec -it myk8s-control-plane istioctl proxy-config endpoint $WEBAPP
docker exec -it myk8s-control-plane istioctl proxy-config log $WEBAPP

# envoy 가 사용하고 있는 인증서 정보 확인
docker exec -it myk8s-control-plane istioctl proxy-config secret $ISTIOIGW
docker exec -it myk8s-control-plane istioctl proxy-config secret $WEBAPP


#
docker exec -it myk8s-control-plane istioctl proxy-config routes deploy/istio-ingressgateway.istio-system
NAME          DOMAINS     MATCH                  VIRTUAL SERVICE
http.8080     *           /*                     webapp-virtualservice.istioinaction
              *           /stats/prometheus*
              *           /healthz/ready*

Svc Nodeport 변경 및 ClientIP 수집 확인
istio-ingressgateway의 NodePort를 수동으로 설정하고, 클라이언트 IP를 파드에서 식별할 수 있도록 정책을 조정합니다.

# istio-ingressgateway 서비스 NodePort 변경 및 nodeport 30000로 지정 변경
kubectl get svc,ep -n istio-system istio-ingressgateway
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

#
kubectl stern -l app=webapp -n istioinaction
kubectl stern -l app=catalog -n istioinaction

Curl 요청 테스트
외부에서 Istio 인그레스를 통해 실제 서비스에 요청을 보내고 응답을 확인함으로써 라우팅 결과를 검증합니다.

#
curl -s http://127.0.0.1:30000/api/catalog | jq
curl -s http://127.0.0.1:30000/api/catalog/items/1 | jq
curl -s http://127.0.0.1:30000/api/catalog -I | head -n 1

# webapp 반복 호출
while true; do curl -s http://127.0.0.1:30000/api/catalog/items/1 ; sleep 1; echo; done
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 1; echo; done
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

✅ 01. 관찰 가능성 (Observability)

Istio는 다양한 관찰 도구들과 통합되어 트래픽 흐름, 지연 시간, 오류율 등을 시각적으로 분석할 수 있는 기능을 제공합니다.

이 단계에서는 Prometheus, Grafana, Kiali, Jaeger 등의 대시보드를 NodePort로 노출시켜 직접 확인할 수 있도록 구성합니다.

NodePort 설정 및 대시보드 접속
Istio에서 제공하는 주요 관찰 도구(Prometheus, Grafana, Kiali, Jaeger 등)에 접근할 수 있도록
각 서비스를 NodePort 타입으로 수정하고, 브라우저를 통해 직접 접속해 메트릭과 트레이스를 확인합니다.

# 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

✅ 02. 복원력 적용 (Resiliency)

분산 시스템에서는 일시적인 장애가 자주 발생할 수 있으므로, 서비스의 복원력은 매우 중요합니다.

이 단계에서는 Istio를 이용해 장애를 시뮬레이션하고, 재시도 설정 등을 통해 장애 대응 전략을 실습합니다.

카탈로그 서비스에 장애 주입 (Chaos Engineering)
임의의 HTTP 500 오류를 주입하여 실제 장애 상황을 시뮬레이션하고,
Kiali, Grafana, Tracing 등 관찰 도구를 통해 서비스의 반응을 모니터링합니다.

50% 비율로 500에러가 발생하도록 장애 상황을 발생시킵니다.
#
docker exec -it myk8s-control-plane bash
----------------------------------------
# istioinaction 로 네임스페이스 변경
cat /etc/kubernetes/admin.conf
kubectl config set-context $(kubectl config current-context) --namespace=istioinaction
cat /etc/kubernetes/admin.conf

cd /istiobook/bin/ 
./chaos.sh 500 100 # 모니터링 : kiali, grafana, tracing

./chaos.sh 500 50 # 모니터링 : kiali, grafana, tracing

VirtualService에서 재시도 설정
장애 발생 시에도 안정적인 서비스를 제공하기 위해,
Istio의 재시도 정책을 설정하여 요청 실패 시 자동으로 재시도하도록 구성합니다.

인프라 레벨에서의 간단한 재시도 정책 적용만으로 위의 50% 에러 비율을 93%까지 복원하는것을 확인할 수 있습니다.

# 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

kubectl get vs -n istioinaction
NAME                    GATEWAYS                 HOSTS         AGE
catalog                                          ["catalog"]   12s
webapp-virtualservice   ["outfitters-gateway"]   ["*"]         3h38m

✅ 03. 트래픽 제어 및 릴리즈 전략

서비스 배포 시 한 번에 전체 트래픽을 전환하는 것은 위험할 수 있습니다.

이 단계에서는 Istio의 트래픽 라우팅 기능을 활용해 점진적 릴리즈 전략을 구현하고,
버전별 트래픽 분산 및 특정 사용자 대상 테스트 등을 실습합니다.

Catalog v2 배포 및 라우팅 제어
새 버전의 catalog(v2)를 배포하고, 트래픽 분산 설정을 통해
일부 사용자만 새로운 버전을 테스트할 수 있도록 릴리즈 전략을 구성합니다.

이때 SHOW_IMAGE 환경변수를 통해 v1과 v2의 차이를 시각적으로 구분합니다.

# 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 에러 발생 꺼두기
docker exec -it myk8s-control-plane bash
----------------------------------------
cd /istiobook/bin/
./chaos.sh 500 delete
exit
----------------------------------------

#
kubectl get deploy,pod,svc,ep -n istioinaction
kubectl get gw,vs -n istioinaction

DestinationRule을 이용해 버전 분기

버전이 다른 서비스가 공존할 때, Istio의 DestinationRule과 VirtualService를 조합하여
트래픽을 버전에 따라 분기할 수 있습니다.

이 방식은 점진적 릴리즈나 A/B 테스트에 유용하며,
특정 조건에 맞춰 트래픽을 v1 또는 v2로 유연하게 라우팅하는 전략을 실습합니다.

기본 라우팅 설정
catalog 서비스에 v1, v2 두 버전을 정의하고, DestinationRule을 통해 서브셋으로 명시합니다.

이 설정만으로는 특별한 라우팅 제어 없이 라운드로빈 방식으로 트래픽이 분산됩니다.
# 기본 트래픽 규칙 설정. v1, v2 모두 가능
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

#
kubectl get gw,vs,dr -n istioinaction

# 반복 접속 : v1,v2 분산 접속 확인
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

v1만 접속 설정
VirtualService를 수정해 모든 요청을 version-v1으로만 라우팅하도록 제한합니다.

이를 통해 신규 버전이 아닌 기존 버전만 사용자에게 노출하는 구성을 적용할 수 있습니다.
# v1 라우팅 VS 수정(업데이트)
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
        subset: version-v1
EOF

# 반복 접속 : v1 접속 확인
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

특정 헤더는 v2, 그외에는 v1 접속 설정
HTTP 헤더 값을 기반으로 트래픽을 조건 분기합니다.
예: x-dark-launch: v2 헤더가 있는 요청만 v2로 보내고, 나머지는 v1으로 처리하는 방식입니다.

이를 통해 카나리 배포나 내부 사용자 대상 선행 테스트가 가능합니다.
v1은 1초마다, v2는 0.1초마다 트래픽이 전송되는것을 확인할 수 있습니다.

Kiali에서도 헤더에 따라서 트래픽이 각기다른 버전의 파드로 라우팅 되는것을 확인할 수 있습니다.
# 라우팅 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

#
kubectl get gw,vs,dr -n istioinaction

# 반복 접속 : v1 접속 확인
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

# 반복 접속 : v2 접속 확인
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 0.1; echo; done

📌 Conclusion

Istio는 단순한 서비스 메시 구현체를 넘어, 클라우드 네이티브 환경에서의 복잡한 서비스 간 통신을 제어하고 관찰할 수 있게 해주는 강력한 인프라 레이어입니다.

이번 실습을 통해 서비스 복원력 강화, 트래픽 제어, 관찰 가능성 향상 등 Istio의 핵심 기능을 직접 경험할 수 있었으며, 특히 사이드카 프록시를 통한 코드 수정 없는 네트워크 기능 확장의 가치를 체감할 수 있었습니다.

Istio는 분산 아키텍처를 운영하는 데 있어 필수적인 도구가 되어가고 있으며, 이후 포스팅에서는 실무 환경에서 Istio를 적용하며 얻은 인사이트와 보다 현실적인 운영 전략을 중심으로 다뤄볼 예정입니다.

스터디나 실무에서 Istio를 어떻게 활용하고 계신지, 혹은 궁금한 점이 있다면 댓글로 공유해 주세요!

🔗 Reference

Istio 공식 웹사이트 - https://istio.io/
Istio의 공식 홈페이지로, 서비스 메시의 개념, 아키텍처, 설치 가이드, 트래픽 관리, 보안, 관측성 등 다양한 주제를 다룹니다.
Istio란 무엇인가요? - https://cloud.google.com/learn/what-is-istio?hl=ko
Google Cloud에서 제공하는 Istio의 개요로, 서비스 메시의 개념과 Istio의 주요 기능을 설명합니다.

xgro

안녕하세요! DevOps 엔지니어 이재찬입니다. 블로그에 대한 피드백은 언제나 환영합니다! 기술, 개발, 운영에 관한 다양한 주제로 함께 나누며, 더 나은 협업과 효율적인 개발 환경을 만드는 과정에 대해 인사이트를 나누고 싶습니다. 함께 여행하는 기분으로, 즐겁게 읽어주시면 감사하겠습니다! 🚀

다음 포스트