K8s Istio Service Mesh – 테오의 저장소

K8s Service Mesh란?

Service Mesh는 마이크로서비스 간 통신을 인프라 레벨에서 제어하는 전용 계층이다. 애플리케이션 코드 수정 없이 트래픽 라우팅, mTLS 암호화, 관측성(Observability)을 제공한다. 그 중 Istio는 가장 널리 사용되는 Service Mesh로, Envoy 사이드카 프록시를 기반으로 동작한다.

1. Istio 아키텍처

Istio는 Data Plane(Envoy 사이드카)과 Control Plane(istiod)으로 구성된다.

# Istio 설치 (istioctl)
istioctl install --set profile=demo -y

# 네임스페이스에 사이드카 자동 주입 활성화
kubectl label namespace default istio-injection=enabled

# 확인
kubectl get pods -n istio-system

사이드카 주입이 활성화된 네임스페이스에 Pod를 배포하면 자동으로 Envoy 컨테이너가 추가된다. 모든 인바운드/아웃바운드 트래픽이 Envoy를 통과하므로 애플리케이션은 메시의 존재를 모른다.

구성 요소	역할
`istiod`	설정 배포, 인증서 관리, 서비스 디스커버리
`Envoy Proxy`	사이드카로 트래픽 가로채기, 라우팅, TLS
`Istio Gateway`	메시 진입점 (Ingress 대체)

2. VirtualService 트래픽 라우팅

VirtualService는 Istio의 핵심 리소스로, 요청을 어느 서비스 버전으로 보낼지 세밀하게 제어한다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-routing
spec:
  hosts:
    - api-service
  http:
    # 헤더 기반 라우팅
    - match:
        - headers:
            x-version:
              exact: "v2"
      route:
        - destination:
            host: api-service
            subset: v2

    # 가중치 기반 카나리
    - route:
        - destination:
            host: api-service
            subset: v1
          weight: 90
        - destination:
            host: api-service
            subset: v2
          weight: 10

    # 타임아웃·재시도
      timeout: 5s
      retries:
        attempts: 3
        perTryTimeout: 2s
        retryOn: 5xx,reset,connect-failure

K8s Ingress의 카나리 배포와 비교하면, Istio는 헤더·쿠키·URI·가중치 등 훨씬 세밀한 라우팅 조건을 지원한다. Ingress 기반 카나리는 Ingress NGINX 심화 글을 참고하자.

3. DestinationRule: 서비스 버전 정의

DestinationRule은 서비스의 서브셋(버전)과 로드밸런싱 정책을 정의한다.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: api-service-dr
spec:
  host: api-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: DEFAULT
        http1MaxPendingRequests: 100
        http2MaxRequests: 1000
    loadBalancer:
      simple: LEAST_REQUEST
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

설정	역할
`connectionPool`	커넥션 풀 크기 제한 (서킷 브레이커)
`outlierDetection`	비정상 Pod 자동 제외 (이상치 탐지)
`loadBalancer`	ROUND_ROBIN, LEAST_REQUEST, RANDOM
`subsets`	라벨 기반 서비스 버전 그룹

4. mTLS 자동 암호화

Istio는 서비스 간 통신에 상호 TLS(mTLS)를 자동 적용한다.

# STRICT 모드: mTLS 강제
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT  # STRICT | PERMISSIVE | DISABLE

---
# 특정 서비스만 예외 (레거시 연동)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: legacy-exception
  namespace: default
spec:
  selector:
    matchLabels:
      app: legacy-service
  mtls:
    mode: PERMISSIVE

STRICT 모드에서는 사이드카가 없는 서비스와의 통신이 차단된다. 마이그레이션 중에는 PERMISSIVE로 시작해서 점진적으로 STRICT로 전환한다. K8s 네트워크 보안은 NetworkPolicy 제로 트러스트 글도 참고하자.

5. AuthorizationPolicy 접근 제어

# JWT 인증 설정
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-auth
spec:
  jwtRules:
    - issuer: "https://auth.example.com"
      jwksUri: "https://auth.example.com/.well-known/jwks.json"
      forwardOriginalToken: true

---
# 역할 기반 접근 제어
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: api-authz
spec:
  selector:
    matchLabels:
      app: api-service
  rules:
    # admin만 DELETE 허용
    - from:
        - source:
            requestPrincipals: ["*"]
      to:
        - operation:
            methods: ["DELETE"]
      when:
        - key: request.auth.claims[role]
          values: ["admin"]
    # 인증된 사용자는 GET/POST 허용
    - from:
        - source:
            requestPrincipals: ["*"]
      to:
        - operation:
            methods: ["GET", "POST"]

6. 관측성: Kiali·Jaeger·Prometheus

Istio는 사이드카가 수집하는 메트릭으로 자동 관측성을 제공한다.

# 관측성 애드온 설치
kubectl apply -f samples/addons/prometheus.yaml
kubectl apply -f samples/addons/grafana.yaml
kubectl apply -f samples/addons/jaeger.yaml
kubectl apply -f samples/addons/kiali.yaml

# Kiali 대시보드 열기
istioctl dashboard kiali

코드 한 줄 없이 서비스 토폴로지, 요청 성공률, 지연 시간, 분산 트레이싱을 확인할 수 있다. Envoy가 자동으로 istio_requests_total, istio_request_duration_milliseconds 같은 Prometheus 메트릭을 노출한다.

7. Fault Injection 카오스 테스트

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: chaos-test
spec:
  hosts:
    - payment-service
  http:
    - fault:
        delay:
          percentage:
            value: 10
          fixedDelay: 3s
        abort:
          percentage:
            value: 5
          httpStatus: 503
      route:
        - destination:
            host: payment-service

트래픽의 10%에 3초 지연, 5%에 503 에러를 주입한다. 프로덕션 환경에서 장애 복원력을 검증하는 카오스 엔지니어링을 코드 수정 없이 구현할 수 있다.

마무리

Istio Service Mesh는 마이크로서비스 운영의 복잡성을 인프라 레벨에서 흡수한다. 트래픽 라우팅, mTLS, 서킷 브레이커, 관측성, 카오스 테스트까지 애플리케이션 코드 변경 없이 구현할 수 있다. 다만 사이드카로 인한 리소스 오버헤드와 복잡성이 증가하므로, 서비스 수가 충분히 많고 통신 제어가 필요한 환경에서 도입을 검토하자.