ISTIO, traffic management API

Jeonghak Cho·2025년 2월 16일

Istio Service mesh destination rule virtual service

Istio

목록 보기

3/6

Istio Traffic Management API 리소스 개요

Istio의 트래픽 관리(Traffic Management) API는 서비스 간 트래픽 흐름을 세밀하게 제어할 수 있도록 설계되었다. 이 API를 활용하면 트래픽 라우팅, 로드 밸런싱, 재시도, 페일오버, 트래픽 미러링 등 다양한 정책을 설정할 수 있다.
Istio에서 트래픽을 제어하는 주요 API 리소스는 다음과 같다.

리소스	주요 기능
VirtualService	트래픽 라우팅 (A/B 테스트, Canary 배포, 재시도, 페일오버 등)
DestinationRule	서비스 대상 설정 (로드 밸런싱, 서킷 브레이커, mTLS 등)
ServiceEntry	외부 서비스(API, DB 등)를 Istio 네트워크에 포함
Gateway	외부 트래픽 관리 (Ingress, Egress)
Sidecar	특정 서비스의 트래픽 필터링 및 네트워크 최적화

이 후부터 트래픽 관리(Traffic Management) API에 대한 상세 설명이다.

VirtualService

VirtualService는 Istio에서 트래픽을 제어하는 리소스로, 서비스 메시 내에서 트래픽 라우팅 규칙을 정의하는 역할을 한다. 이를 통해 요청을 특정 버전의 서비스로 라우팅하거나, A/B 테스트, Canary 배포 등을 손쉽게 구현할 수 있다.

VirtualService의 주요 역할

트래픽 라우팅

서비스 메시 내에서 요청을 원하는 워크로드(Pod)로 전달 가능
특정 요청을 특정 버전의 서비스로 라우팅 가능
예: v1과 v2 서비스 간에 트래픽을 80%:20% 비율로 분배

호스트 기반 트래픽 제어

특정 도메인(예: api.example.com)으로 들어오는 요청을 적절한 서비스로 라우팅 가능
Kubernetes의 Service 리소스뿐만 아니라 외부 서비스도 포함 가능

Canary 배포 및 A/B 테스트

새로운 서비스 버전을 점진적으로 배포하며 트래픽을 조절할 수 있음
다양한 트래픽 분배 전략을 통해 안전한 롤아웃 지원

Fault Injection (장애 주입 테스트)

일부 요청에 대해 인위적으로 지연(latency) 또는 오류(failure)를 발생시켜 회복력 테스트 수행

Retries, Timeout, Circuit Breaker 지원

요청이 실패할 경우 재시도(Retry) 정책 적용 가능
응답 시간이 너무 길 경우 Timeout 설정 가능
Circuit Breaker를 적용하여 장애 확산 방지

VirtualService의 속성

필드	설명
hosts	트래픽을 수신할 서비스의 호스트 (예: `reviews.default.svc.cluster.local`)
gateways	외부 트래픽을 허용할 Istio Gateway (예: `my-gateway`)
http / tcp / tls	HTTP, TCP, TLS 기반 트래픽을 라우팅하는 규칙
match	특정 요청 조건 (예: `headers`, `URI`, `method`)
route	트래픽을 전달할 대상 서비스와 비율 설정
timeout	요청의 최대 응답 대기 시간
retries	실패한 요청의 재시도 정책
fault	장애 주입 (latency 추가, 오류 반환)
mirror	요청을 복사하여 다른 서비스로 전달 (미러링)

VirtualService 사용법

트래픽을 80:20 비율로 분배

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: reviews.default.svc.cluster.local
        subset: v1
      weight: 70
    - destination:
        host: reviews.default.svc.cluster.local
        subset: v2
      weight: 30

이 설정은 reviews 서비스의 v1 버전에 80%의 트래픽을, v2 버전에 20%의 트래픽을 보내도록 한다.

Canary 배포 예제

아래 예제는 새로운 v2 버전을 Canary 방식으로 배포하는 설정이다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: canary-deployment
spec:
  hosts:
  - my-service.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v1
      weight: 90
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v2
      weight: 10

이 설정에서는 v1 버전에 90%, v2 버전에 10%의 트래픽을 보냄으로써 Canary 배포를 수행한다.

특정 요청 헤더 기반 라우팅

아래 예제는 user-group이라는 요청 헤더 값을 기반으로 트래픽을 v2 버전으로 라우팅하는 설정이다.

yaml

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: header-routing
spec:
  hosts:
  - my-app.default.svc.cluster.local
  http:
  - match:
    - headers:
        user-group:
          exact: "test-users"
    route:
    - destination:
        host: my-app.default.svc.cluster.local
        subset: v2
  - route:
    - destination:
        host: my-app.default.svc.cluster.local
        subset: v1

이 설정에서는 user-group: test-users 헤더를 포함한 요청은 v2로 보내고, 나머지는 v1으로 보낸다.

Kiali에서 VirtualService 시각화

Kiali에서는 VirtualService 설정을 기반으로 서비스 간 트래픽 흐름을 그래프로 시각화할 수 있다.
특정 VirtualService가 적용된 트래픽 패턴을 확인하고, A/B 테스트, Canary 배포 등 라우팅 전략을 쉽게 분석할 수 있다.
Kiali UI를 통해 VirtualService의 트래픽 비율, 재시도 설정, 장애 주입 상태 등을 직관적으로 확인 가능하다.

DestinationRule

DestinationRule은 Istio에서 서비스 간 트래픽을 세분화하고, 부하 분산, 연결 정책, 보안 설정을 관리하는 리소스다. VirtualService와 함께 사용되며, 트래픽이 특정 서비스로 도착한 후 어떤 방식으로 처리될지 결정하는 역할을 한다.

DestinationRule의 주요 역할

서비스 서브셋(Subset) 정의

특정 서비스의 버전(v1, v2 등) 을 서브셋으로 정의하여 트래픽을 나누는 데 사용
VirtualService와 결합하여 Canary 배포, A/B 테스트, 블루-그린 배포 가능

부하 분산(Load Balancing) 정책 설정

기본적으로 Istio는 Round Robin 방식으로 부하를 분산하지만, Least Request, Random, Consistent Hash 등의 다양한 부하 분산 정책을 적용 가능

연결 정책(Connection Pool, Outlier Detection) 설정

Connection Pool: 연결을 재사용하여 효율적으로 관리
Outlier Detection: 오류가 많은 인스턴스를 자동으로 제외하여 서비스 안정성 향상

TLS 보안 정책 설정

mTLS (Mutual TLS) 설정을 통해 서비스 간 통신을 암호화
특정 서비스에 대해서만 TLS를 활성화하거나 필요에 따라 조정 가능

DestinationRule 속성

필드	설명
host	트래픽을 적용할 대상 서비스 (예: `reviews.default.svc.cluster.local`)
subsets	특정 버전(예: v1, v2) 또는 특정 레이블을 가진 서비스 그룹
trafficPolicy	부하 분산, 연결 풀, TLS, 장애 감지 등의 정책 설정
loadBalancer	부하 분산 방식 (Round Robin, Least Request, Random 등)
connectionPool	최대 연결 수, 동시 요청 수 등의 연결 제한 설정
outlierDetection	장애 발생 시 문제가 있는 인스턴스를 자동으로 제외하는 기능
tls	서비스 간 TLS 통신 설정 (DISABLE, SIMPLE, MUTUAL, ISTIO_MUTUAL)

DestinationRule 사용법

기본적인 DestinationRule (Subset 정의)

아래 예제는 reviews 서비스에 대해 v1과 v2 버전을 정의하는 설정이다.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews.default.svc.cluster.local
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

이 설정을 사용하면 VirtualService에서 v1, v2 서브셋을 기준으로 트래픽을 분배할 수 있다.

부하 분산 정책 적용

아래 예제는 reviews 서비스에 대해 Least Request 방식의 부하 분산 정책을 적용하는 설정이다.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-loadbalancer
spec:
  host: reviews.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST

Least Request: 가장 적은 요청을 처리 중인 인스턴스에 트래픽을 분배하는 방식.

Outlier Detection (장애 감지) 설정

아래 예제는 오류가 많은 인스턴스를 자동으로 제거하는 Outlier Detection을 설정하는 방법이다.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-outlier
spec:
  host: reviews.default.svc.cluster.local
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 10s
      baseEjectionTime: 30s

위 설정은 10초 동안 3번 이상의 5xx 오류가 발생하는 인스턴스를 30초 동안 제외한다.

TLS 보안 정책 설정

아래 예제는 reviews 서비스 간 mTLS (Mutual TLS) 암호화를 활성화하는 설정이다.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-tls
spec:
  host: reviews.default.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

ISTIO_MUTUAL은 Istio에서 자동으로 TLS 인증서를 관리하도록 설정하는 방식이다.

DestinationRule과 VirtualService의 관계

VirtualService는 트래픽이 어떤 서비스로 전송될지 결정
DestinationRule은 트래픽이 서비스에 도착한 후 어떻게 처리될지 결정

VirtualService + DestinationRule 조합 예제

VirtualService

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: reviews.default.svc.cluster.local
        subset: v1
      weight: 80
    - destination:
        host: reviews.default.svc.cluster.local
        subset: v2
      weight: 20

DestinationRule

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews.default.svc.cluster.local
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

VirtualService는 80% 트래픽을 v1, 20% 트래픽을 v2로 보낸다. DestinationRule은 v1, v2 서브셋을 정의하여 VirtualService에서 이를 참조 가능하도록 한다.

Kiali에서 DestinationRule 모니터링

Kiali에서는 DestinationRule을 기반으로 트래픽 분배 및 부하 분산 정책을 시각적으로 분석 가능
특정 서브셋으로 얼마나 많은 트래픽이 흘러가는지 실시간으로 확인 가능
Outlier Detection 및 Circuit Breaker 상태도 확인하여 장애 발생 시 빠르게 대처 가능

Gateways API 개요

Gateways API는 Kubernetes 환경에서 네트워크 트래픽을 제어하고 관리하는 새로운 표준 API이다. 기존 Istio Gateway 또는 Ingress 리소스를 대체하거나 확장하는 역할을 하며, 더 유연한 트래픽 라우팅과 멀티 클러스터 지원을 제공한다.

Gateways API 기능

Kubernetes 네트워크 게이트웨이 표준

기존 Ingress API의 단순한 동작을 넘어 더 강력한 트래픽 제어 기능을 제공
서비스 메시, API Gateway, 클라우드 네트워크 정책을 통합 관리 가능

Istio, Envoy, NGINX 등 다양한 컨트롤러 지원

특정 Ingress Controller(NGINX, Istio 등)에 종속되지 않고, 여러 컨트롤러에서 일관된 네트워크 정책을 유지 가능
Istio의 Gateway 리소스를 대체할 수도 있음

Layer 4(L4) + Layer 7(L7) 트래픽 제어

TCP, UDP, TLS와 같은 L4 트래픽과 HTTP, gRPC와 같은 L7 트래픽을 함께 지원
보다 정교한 트래픽 제어 정책을 적용 가능

Gateways API 리소스 종류

Gateways API는 여러 개의 CRD (Custom Resource Definition) 로 구성되어 있다.

리소스	역할
GatewayClass	Gateway의 동작 방식 및 컨트롤러를 정의
Gateway	클러스터 외부에서 내부 서비스로 트래픽을 유입시키는 역할
HTTPRoute	HTTP 요청을 특정 서비스로 라우팅 (호스트 기반, 경로 기반 등)
TCPRoute	TCP 트래픽을 특정 백엔드 서비스로 라우팅
TLSRoute	TLS 트래픽을 특정 백엔드 서비스로 전달
GRPCRoute	gRPC 요청을 특정 백엔드 서비스로 라우팅
ReferenceGrant	다른 네임스페이스의 리소스를 참조할 수 있도록 허용

기존 Ingress API는 HTTP 기반 요청만 처리할 수 있지만, Gateways API는 TCP, UDP, gRPC까지 지원하여 더욱 유연한 트래픽 제어가 가능하다.

Gateways API 구성 요소

GatewayClass

Gateway 리소스의 기본 동작을 정의하는 역할
Istio, NGINX, Envoy 등의 특정 네트워크 컨트롤러에 따라 다르게 설정 가능

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: istio-gateway
spec:
  controllerName: istio.io/gateway-controller

Gateway

특정 네트워크 트래픽을 클러스터 내부 서비스로 전달하는 리소스
클러스터 외부와 내부를 연결하는 네트워크 진입점 역할

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: istio-gateway
  listeners:
    - protocol: HTTP
      port: 80
      name: http
      allowedRoutes:
        namespaces:
          from: All

gatewayClassName: 사용할 GatewayClass 지정 (예: istio-gateway)
listeners: 특정 프로토콜(HTTP, TCP, TLS 등)에 대한 설정

HTTPRoute

HTTP 요청을 특정 서비스로 라우팅하는 역할
호스트 기반, 경로 기반, 헤더 기반 라우팅 지원

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
    - name: my-gateway
  hostnames:
    - "example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: "/api"
      backendRefs:
        - name: my-service
          port: 8080

parentRefs: 어느 Gateway와 연결할지 지정
hostnames: 특정 도메인(예: example.com)에서만 요청을 허용
rules: /api 경로로 들어오는 요청을 my-service:8080으로 전달

TCPRoute

TCP 기반 서비스(MySQL, Redis, Kafka 등)를 위한 트래픽 제어 설정

apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: my-tcp-route
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - backendRefs:
        - name: my-tcp-service
          port: 3306

TLSRoute

TLS 트래픽을 특정 백엔드 서비스로 라우팅

apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
  name: my-tls-route
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - backendRefs:
        - name: my-tls-service
          port: 443

Gateways API vs 기존 Ingress vs Istio Gateway

기능	Kubernetes Ingress	Istio Gateway	Gateway API
L4 (TCP) 트래픽 제어	❌ 불가능	✅ 가능	✅ 가능
L7 (HTTP) 트래픽 제어	✅ 가능	✅ 가능	✅ 가능
mTLS 지원	❌ 불가능	✅ 가능	✅ 가능
다양한 리스너 지원	❌ 제한적 (HTTP/HTTPS)	✅ 가능 (TCP, HTTP, HTTPS, gRPC)	✅ 가능 (더 유연함)
VirtualService 연동 가능	❌ 불가능	✅ 가능	✅ 가능
멀티클러스터 지원	❌ 불가능	✅ 가능	✅ 가능
표준화된 API	❌ Kubernetes 전용	❌ Istio 전용	✅ Kubernetes 공식 API

Ingress는 HTTP 기반 트래픽만 처리 가능
Istio Gateway는 Istio에 종속적
Gateways API는 L4 + L7 트래픽을 모두 지원하며, 다양한 컨트롤러에서 동작 가능

Kiali에서의 Gateways API 모니터링

Istio에서 Gateways API를 사용하면, Kiali를 통해 게이트웨이 트래픽 흐름을 시각적으로 확인 가능
특정 Gateway가 어떤 HTTPRoute, TCPRoute와 연결되어 있는지 한눈에 파악 가능
mTLS 상태, 라우팅 정책, 부하 분산 전략을 쉽게 분석할 수 있음

Sidecars

Sidecars API는 Istio에서 특정 네임스페이스 또는 서비스의 프록시(Sidecar Envoy)를 커스터마이징하는 리소스다.
기본적으로 Istio는 모든 Pod에 동일한 Sidecar 프록시 설정을 적용하지만, Sidecar 리소스를 사용하면 특정 서비스에 맞는 네트워크 정책을 개별적으로 설정할 수 있다.

Sidecars 기능

서비스별 맞춤 Sidecar 구성 가능

기본적으로 Istio는 클러스터 내 모든 Pod에 동일한 Sidecar Envoy를 삽입
Sidecar 리소스를 사용하면 특정 네임스페이스, 특정 워크로드, 특정 트래픽에 대한 Sidecar 동작을 커스터마이징 가능

네트워크 정책 최적화

특정 서비스에서 외부 트래픽을 제한하거나, 불필요한 트래픽을 차단하여 성능을 최적화 가능
필요 없는 서비스로 트래픽이 전달되지 않도록 Outbound(출력) 정책을 제한

메모리 및 CPU 사용량 절감

기본적으로 Sidecar Envoy는 모든 네임스페이스의 트래픽을 감시하지만, 필요한 서비스만 감시하도록 구성하면 불필요한 리소스 사용을 줄일 수 있음

Sidecar API 리소스 속성

필드	설명
workloadSelector	특정 Pod(워크로드)에만 Sidecar 설정을 적용 (예: `app: my-app`)
ingress	다른 서비스가 이 Sidecar를 통해 접근할 수 있는 트래픽 규칙 설정
egress	이 Sidecar에서 외부로 나가는 트래픽을 제한 또는 허용
outboundTrafficPolicy	외부 트래픽(클러스터 외부 접속) 정책 (`ALLOW_ANY`, `REGISTRY_ONLY`)
listeners	Envoy Proxy가 트래픽을 수신하는 리스너 설정

Sidecar 리소스 사용법

특정 네임스페이스에만 Sidecar 적용

기본적으로 Istio는 모든 네임스페이스에서 트래픽을 감시하지만, 아래 설정을 적용하면 특정 네임스페이스(my-namespace)에만 Sidecar를 삽입할 수 있다.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: custom-sidecar
  namespace: my-namespace
spec:
  egress:
  - hosts:
      - "./*"  # 같은 네임스페이스의 서비스만 허용
      - "istio-system/*"  # Istio 컨트롤 플레인과의 통신 허용

./* → 같은 네임스페이스(my-namespace)의 트래픽만 허용
istio-system/* → Istio 컨트롤 플레인과의 통신만 허용
그 외의 모든 네임스페이스 트래픽은 차단됨

특정 애플리케이션(Pod)에만 Sidecar 적용

아래 설정을 적용하면 특정 라벨이 있는 Pod (app: my-app)에만 Sidecar 설정을 적용할 수 있다.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: app-specific-sidecar
  namespace: my-namespace
spec:
  workloadSelector:
    labels:
      app: my-app  # 이 라벨이 붙은 Pod에만 Sidecar 적용
  egress:
  - hosts:
      - "./*"  # 같은 네임스페이스 내 트래픽 허용
      - "external-namespace/*"  # 특정 네임스페이스의 서비스만 허용

workloadSelector.labels.app: my-app → my-app이 있는 Pod에만 Sidecar 적용
external-namespace/* → 특정 네임스페이스 서비스로 나가는 트래픽만 허용

외부 트래픽 차단 (Outbound Traffic 정책)

기본적으로 Istio는 모든 외부 트래픽을 허용(ALLOW_ANY)하지만, 아래 설정을 적용하면 클러스터 내부 서비스만 통신 가능하도록 제한할 수 있다.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: restricted-egress
  namespace: my-namespace
spec:
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY  # 외부 트래픽 차단 (클러스터 내부 서비스만 허용)

REGISTRY_ONLY → Istio에 등록된 서비스만 통신 가능, 외부 인터넷 차단
이를 통해 보안 강화 및 불필요한 외부 요청 방지 가능

Sidecar API vs 기본 Istio 설정

기능	기본 Istio Sidecar	Sidecar API 사용 시
모든 네임스페이스 감시	✅ 예	❌ 아니요 (제한 가능)
특정 네임스페이스만 감시	❌ 불가능	✅ 가능
특정 서비스 트래픽만 허용	❌ 불가능	✅ 가능
외부 트래픽 제한	❌ 기본적으로 허용됨	✅ 차단 가능 (`REGISTRY_ONLY`)
리소스 절감	❌ 불필요한 트래픽 감시	✅ 최소한의 트래픽 감시 가능

💡 핵심 차이점:

기본 Istio는 모든 Pod의 네트워크 트래픽을 감시하지만, Sidecar API를 사용하면 필요한 서비스만 감시하여 리소스 절감 가능
외부 트래픽을 자동으로 차단할 수도 있고, 특정 서비스에 대해서만 허용 가능

Kiali에서 Sidecar 모니터링

Kiali에서는 Sidecar를 통해 어떤 서비스가 어떤 트래픽을 허용하는지 시각적으로 확인 가능
특정 네임스페이스나 Pod의 Sidecar 적용 여부를 확인하고, 트래픽 흐름을 시각적으로 분석 가능
외부 트래픽 제한 설정(REGISTRY_ONLY)이 적용되었는지 쉽게 확인 가능

ServiceEntry API

ServiceEntry API는 Istio에서 클러스터 외부의 서비스(외부 API, DB, SaaS 등)를 서비스 메시에 등록하는 역할을 한다.
기본적으로 Kubernetes 내부 서비스만 Istio의 트래픽 관리 대상이지만, ServiceEntry 리소스를 사용하면 외부 서비스를 마치 클러스터 내부 서비스처럼 통합 관리할 수 있다.

ServiceEntry 기능

클러스터 외부 서비스 등록

AWS RDS, Google Cloud API, 외부 REST API 등을 Istio 네트워크에 추가 가능
내부 서비스와 동일한 방식으로 외부 서비스에 대한 트래픽 관리, 정책 적용, 모니터링 가능

mTLS 및 보안 정책 적용

외부 서비스와의 통신에도 TLS 암호화 적용 가능
외부 트래픽을 제한하거나 인증 요구 조건을 설정 가능

Destination Rule 및 Virtual Service와 연동 가능

ServiceEntry를 정의한 후 DestinationRule을 설정하면 로드 밸런싱, 연결 제한, 타임아웃 등을 적용 가능
VirtualService를 사용하면 외부 서비스로 트래픽을 라우팅하는 고급 정책 설정 가능

ServiceEntry API 리소스 속성

필드	설명
hosts	외부 서비스의 호스트 이름 (예: `api.example.com`)
addresses	IP 기반으로 서비스 접근을 제어할 경우 사용
ports	통신할 프로토콜과 포트 정의 (예: HTTP 80, HTTPS 443)
location	`MESH_EXTERNAL` (외부 서비스), `MESH_INTERNAL` (내부 서비스)
resolution	DNS를 통한 서비스 검색 여부 (`DNS`, `STATIC`, `NONE`)
workloadSelector	특정 워크로드에만 적용할 경우 사용

ServiceEntry 리소스 사용법

외부 REST API (HTTP) 추가

아래 설정을 적용하면 api.example.com을 클러스터 내부 서비스처럼 등록할 수 있다.

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: external-api
spec:
  hosts:
    - api.example.com
  location: MESH_EXTERNAL
  ports:
    - number: 80
      name: http
      protocol: HTTP
  resolution: DNS

hosts: api.example.com을 외부 서비스로 등록
location: MESH_EXTERNAL: 클러스터 외부 서비스임을 명시
ports: HTTP(80) 포트 사용
resolution: DNS: DNS를 통해 서비스 검색

외부 DB (TCP) 추가

아래 설정을 적용하면 MySQL 데이터베이스(mysql.external.com:3306)를 서비스 메시에 등록할 수 있다.

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: external-db
spec:
  hosts:
    - mysql.external.com  # 외부 DB 호스트
  location: MESH_EXTERNAL
  ports:
    - number: 3306
      name: mysql
      protocol: TCP
  resolution: DNS

protocol: TCP → MySQL과 같은 TCP 기반 서비스에 적용 가능
클러스터 내부 서비스처럼 MySQL DB에 연결 가능

특정 서비스에서만 외부 API 접근 허용

아래 설정을 적용하면 라벨이 app: web인 Pod만 외부 API(api.external.com)에 접근 가능하도록 제한할 수 있다.

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: restricted-api
spec:
  hosts:
    - api.external.com
  location: MESH_EXTERNAL
  ports:
    - number: 443
      name: https
      protocol: HTTPS
  resolution: DNS
  workloadSelector:
    labels:
      app: web  # 웹 애플리케이션만 접근 가능

workloadSelector.labels.app: web → app=web 라벨이 있는 Pod에서만 외부 API 호출 가능
특정 서비스에서만 외부 API를 사용할 수 있도록 보안 강화 가능

VirtualService와 결합하여 트래픽 라우팅

ServiceEntry를 VirtualService와 결합하면 트래픽 라우팅, 재시도, 타임아웃 등 고급 정책 적용 가능
아래 예제는 api.example.com의 트래픽을 우선적으로 내부 캐시 서버로 보내고, 실패하면 외부 API 호출하도록 설정한다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-routing
spec:
  hosts:
    - api.example.com
  gateways:
    - mesh
  http:
    - route:
        - destination:
            host: cache-service  # 내부 캐시 서버
            port:
              number: 8080
        - destination:
            host: api.example.com  # 외부 API
            port:
              number: 80
      retries:
        attempts: 3  # 3번 재시도
        perTryTimeout: 2s  # 재시도 간격 2초

우선 cache-service:8080으로 요청
내부 캐시 서버가 응답하지 않으면 api.example.com으로 트래픽 전달
요청 실패 시 3번 재시도 (2초 간격)

ServiceEntry vs 기존 Kubernetes Service

기능	Kubernetes Service	Istio ServiceEntry
외부 서비스 등록 가능 여부	❌ 불가능	✅ 가능
mTLS 적용 가능 여부	❌ 불가능	✅ 가능
트래픽 제어 (VirtualService 연동)	❌ 불가능	✅ 가능
로드 밸런싱 적용 가능 여부	❌ 불가능	✅ 가능 (`DestinationRule` 필요)

Kubernetes의 Service는 클러스터 내부 서비스만 관리 가능, 하지만 ServiceEntry는 외부 서비스도 Istio 네트워크에 추가 가능
외부 서비스에 mTLS, 트래픽 제한, 로드 밸런싱 등을 적용할 수 있음

Kiali에서 ServiceEntry 모니터링

외부 서비스와의 연결을 시각적으로 분석 가능
특정 서비스가 어떤 외부 API를 호출하고 있는지 한눈에 확인 가능
트래픽 흐름과 응답 시간 분석을 통해 성능 최적화 가능

Jeonghak Cho

khagor

이전 포스트

ISTIO, Kiali

다음 포스트

ISTIO, traffic management API

Istio

Istio Traffic Management API 리소스 개요

VirtualService

VirtualService의 주요 역할

트래픽 라우팅

호스트 기반 트래픽 제어

Canary 배포 및 A/B 테스트

Fault Injection (장애 주입 테스트)

Retries, Timeout, Circuit Breaker 지원

VirtualService의 속성

VirtualService 사용법

트래픽을 80:20 비율로 분배

Canary 배포 예제

특정 요청 헤더 기반 라우팅

Kiali에서 VirtualService 시각화

DestinationRule

DestinationRule의 주요 역할

서비스 서브셋(Subset) 정의

부하 분산(Load Balancing) 정책 설정

연결 정책(Connection Pool, Outlier Detection) 설정

TLS 보안 정책 설정

DestinationRule 속성

DestinationRule 사용법

기본적인 DestinationRule (Subset 정의)

부하 분산 정책 적용

Outlier Detection (장애 감지) 설정

TLS 보안 정책 설정

DestinationRule과 VirtualService의 관계

VirtualService + DestinationRule 조합 예제

VirtualService

DestinationRule

Kiali에서 DestinationRule 모니터링

Gateways API 개요

Gateways API 기능

Kubernetes 네트워크 게이트웨이 표준

Istio, Envoy, NGINX 등 다양한 컨트롤러 지원

Layer 4(L4) + Layer 7(L7) 트래픽 제어

Gateways API 리소스 종류

Gateways API 구성 요소

GatewayClass

Gateway

HTTPRoute

TCPRoute

TLSRoute

Gateways API vs 기존 Ingress vs Istio Gateway

Kiali에서의 Gateways API 모니터링

Sidecars

Sidecars 기능

서비스별 맞춤 Sidecar 구성 가능

네트워크 정책 최적화

메모리 및 CPU 사용량 절감

Sidecar API 리소스 속성

Sidecar 리소스 사용법

특정 네임스페이스에만 Sidecar 적용

특정 애플리케이션(Pod)에만 Sidecar 적용

외부 트래픽 차단 (Outbound Traffic 정책)

Kiali에서 Sidecar 모니터링

ServiceEntry API

ServiceEntry 기능

클러스터 외부 서비스 등록

mTLS 및 보안 정책 적용

Destination Rule 및 Virtual Service와 연동 가능

ServiceEntry API 리소스 속성

ServiceEntry 리소스 사용법

외부 REST API (HTTP) 추가

외부 DB (TCP) 추가

특정 서비스에서만 외부 API 접근 허용

VirtualService와 결합하여 트래픽 라우팅

ServiceEntry vs 기존 Kubernetes Service

Kiali에서 ServiceEntry 모니터링

ISTIO, Kiali

ISTIO, Istio Gateway

0개의 댓글