카테고리 없음

DevOps - istio

게임이 더 좋아 2025. 4. 5. 14:54
반응형
728x170

정의

Istio는 마이크로서비스 아키텍처(MSA)에서
서비스 간 통신을 관리하고,
보안,
관찰 가능성,
트래픽 관리를
지원하는 오픈소스 서비스 메쉬 플랫폼
 
 

왜?

Kubernetes 오브젝트만으로의 한계

트래픽 라우팅 Service, Ingress 버전별 분기, 트래픽 비율 분배 불가능
보안 (mTLS) 없음 (직접 구현 필요) Pod 간 통신 암호화가 기본 미지원
인증/인가 RBAC 위주 서비스 간 세밀한 정책 적용 어려움
트래픽 제어 없음 Retry, Timeout, Circuit Breaker 구현 어려움
모니터링 Metrics 수집 별도 구현 세부 트래픽 분석 어려움
정책 관리 분산된 설정 전역적으로 통제하기 어려움

 

Istio를 사용하면 가능한 기능들

버전별 트래픽 분배 VirtualService, DestinationRule Canary 배포, A/B 테스트 용이 - https://istio.io/latest/docs/ops/best-practices/traffic-management/
자동 mTLS 적용 PeerAuthentication 설정만으로 활성화 보안 강화 - https://istio.io/latest/docs/concepts/security/
세밀한 접근 제어 AuthorizationPolicy 서비스 → 서비스 수준 인증/인가
트래픽 제어 정책 Retry, Timeout, Fault Injection 코드 수정 없이 설정 가능 - https://istio.io/latest/docs/concepts/traffic-management/
서비스 관측 Envoy Proxy + Telemetry Prometheus, Grafana, Kiali 연동 - https://istio.io/latest/docs/concepts/observability/
외부 서비스 통합 제어 ServiceEntry 외부 API 호출도 제어 가능
레이트 리밋, 인증서 회전 확장 기능 가능 WASM, 플러그인 형태 확장성 제공

 

 

 

어떻게?

버전별 트래픽 라우팅

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 75
    - destination:
        host: reviews
        subset: v2
      weight: 25

---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

VirtualService는 Istio에서 트래픽 라우팅 규칙을 정의하는 리소스

hosts: reviews : 이 VirtualService가 적용되는 대상 호스트(서비스 이름)를 지정

http 섹션: HTTP 트래픽에 대한 라우팅 규칙을 정의

reviews 서비스로 들어오는 트래픽을 두 개의 버전(v1v2)으로 분할

 

DestinationRule은 트래픽이 라우팅될 목적지(서비스)의 세부 규칙을 정의

host: reviews: 이 규칙이 적용되는 대상 서비스 이름입니다. 여기서는 reviews 서비스를 지정

subsets 섹션: 목적지를 더 세분화하기 위해 서브셋을 정의

각 서브셋은 서비스의 파드에 붙은 version 레이블을 기준으로 구분함
VirtualService에서 이 서브셋 이름을 참조하여 트래픽을 적절히 분배
 
 

Ingress Gateway 설정

 
외부에서 Bookinfo 앱에 접근하려면 Istio의 Ingress Gateway를 설정
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
  - "*"
  gateways:
  - bookinfo-gateway
  http:
  - match:
    - uri:
        prefix: /productpage
    route:
    - destination:
        host: productpage
        port:
          number: 9080
 
Gateway:
  • 외부에서 80번 포트로 들어오는 모든 HTTP 트래픽을 Istio의 Ingress Gateway가 수신
  • hosts: "*" 설정으로 도메인 제한 없이 모든 요청을 처리

 

VirtualService:
  • Gateway를 통해 들어온 트래픽 중 /productpage로 시작하는 요청을 필터링
  • 해당 요청을 productpage 서비스의 9080번 포트로 라우팅
http://<클러스터-IP>/productpage로 접속

 

서비스 간의 통신을 자동으로 TLS 암호화

PeerAuthentication 리소스를 이용해 네임스페이스 단위로 mTLS를 강제

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-test
spec:
  mtls:
    mode: STRICT
  • istio-test 네임스페이스 내의 모든 서비스 간 통신을 mTLS로 강제
  • 사이드카가 주입되지 않은 서비스는 통신이 차단
  • 네트워크 상에서 평문 통신이 사라지고, 모든 서비스 간 트래픽이 암호화
  • 인증서 기반의 서비스 식별이 가능

Istio가 자동으로 인증서를 발급하려면 Citadel(또는 외부 CA)과 같은 인증서 관리 컴포넌트가  설정되어야 함

 

 

 

A/B 테스트: HTTP 헤더 기반 라우팅

Istio의 VirtualService 리소스를 사용하면, 특정 유저에게만 새로운 서비스 버전을 노출

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
  namespace: istio-test
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: test-user
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

 

  • 일반 사용자는 v1에 접속.
  • test-user는 v2에 접속 → 새 기능 A/B 테스트 가능.

 

  • HTTP 요청에 end-user: test-user 헤더가 포함되어 있으면, 트래픽은 reviews 서비스의 v2 서브셋으로 라우팅
  • 그렇지 않은 모든 트래픽(헤더가 없거나 값이 다름)은 reviews 서비스의 v1 서브셋으로 라우팅
Istio의 Envoy 프록시가 요청 헤더를 검사하고, VirtualService의 규칙에 따라 트래픽을 적절한 목적지로 전달

 

장애 격리: Circuit Breaker (서킷 브레이커)

Circuit Breaker는 장애 상황에서 전체 서비스로 전파되는 걸 막음

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-cb
  namespace: istio-test
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 100

 

  • reviews 서비스가 1개의 요청만 동시에 처리하도록 제한
  • 에러가 많을 경우 해당 인스턴스를 임시 차단(eject) 하여 시스템을 보호

 

trafficPolicy: 트래픽 동작을 제어하는 정책을 설정
  • connectionPool: 연결 풀 설정으로, 서비스 간 연결 수와 요청을 제한
    • tcp.maxConnections: 1: TCP 연결의 최대 수를 1로 제한
    • http:
      • http1MaxPendingRequests: 1: HTTP/1.1 프로토콜에서 대기 중인 요청의 최대 수를 1로 제한
      • maxRequestsPerConnection: 1: 단일 연결당 최대 요청 수를 1로 제한
  • outlierDetection: 이상 감지(서킷 브레이커) 설정으로, 비정상적인 인스턴스를 감지하고 트래픽에서 제외
    • consecutive5xxErrors: 1: 연속으로 5xx 오류(서버 오류)가 1번 발생하면 해당 인스턴스를 이상으로 간주
    • interval: 10s: 이상 여부를 확인하는 주기를 10초로 설정
    • baseEjectionTime: 30s: 이상으로 감지된 인스턴스를 트래픽에서 제외하는 기본 시간은 30초
    • maxEjectionPercent: 100: 최대 100%의 인스턴스를 제외

 

 

 

 

트래픽 미러링 (Traffic Mirroring)

실제 트래픽을 기존 버전에 보내면서, 복제된 트래픽을 새로운 버전에도 전달해 테스트 가능 (결과는 무시됨).

 

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
  mirror:
    host: reviews
    subset: v2
reviews 서비스로 들어오는 모든 HTTP 트래픽은 v1 서브셋으로 라우팅
동일한 요청이 reviews 서비스의 v2 서브셋으로 복제되어 전송
v2의 응답은 기록되거나 모니터링될 수 있지만, 클라이언트에게는 전달 X
 
새 버전 테스트: v2가 새로운 버전이라면, 실제 트래픽을 v1으로 유지하면서 v2의 동작을 미러링으로 관찰 가능
 

 

지연 주입 및 실패 시뮬레이션 (Fault Injection)

  • 특정 서비스 응답에 지연(latency) 또는 에러를 인위적으로 삽입하여 회복 전략을 테스트 가능.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - fault:
      delay:
        fixedDelay: 5s
        percentage:
          value: 100
    route:
    - destination:
        host: reviews
        subset: v1
fault: 트래픽에 고의적인 장애를 주입
  • delay: 요청에 지연을 추가
    • fixedDelay: 5s: 모든 대상 요청에 5초의 고정 지연을 적용
    • percentage.value: 100: 이 지연이 100%의 트래픽에 적용

 

 

회복력 테스트: 애플리케이션이 느린 응답(5초 지연)에 어떻게 반응하는지 확인
재시도 메커니즘 검증: 클라이언트나 서비스가 지연에 대해 재시도를 수행하는지 테스트
카오스 엔지니어링: 프로덕션 환경에서 의도적인 장애를 주입하여 시스템의 안정성을 평가
 
 
 

 

분산 트레이싱 (Distributed Tracing)

  • 서비스 간 호출 흐름을 시각화해서 어디서 병목이 생겼는지 확인 가능
  • Jaeger, Zipkin, Lightstep 등을 연동하여 사용
  • Istio는 x-request-id 같은 헤더를 자동 관리

 

 

AuthorizationPolicy (RBAC)

  • 서비스 간 통신이나 사용자 접근을 세밀하게 역할 기반으로 제한할 수 있음

 

 

 

특정 IP만 접근 허용

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-from-ip
spec:
  selector:
    matchLabels:
      app: productpage
  rules:
  - from:
    - source:
        ipBlocks: ["192.168.1.0/24"]
 
 
 
AuthorizationPolicy 서비스에 대한 접근 제어 정책을 정의하는 Istio 리소스
 
 
metadata:
  • name: allow-from-ip: 이 AuthorizationPolicy의 이름
  • namespace 미지정: 네임스페이스가 명시되지 않았으므로, 배포 컨텍스트에 따라 기본 네임스페이스(예: default)에 적용
 

selector: 이 정책이 적용될 대상 워크로드를 지정

  • matchLabels: { app: productpage }: app: productpage 레이블이 붙은 파드(워크로드)에 이 정책이 적용
    • 즉, productpage라는 애플리케이션에만 영향을 미칩니다.
  • rules: 접근을 허용하거나 거부하는 규칙을 정의
    • from: 요청의 출처를 기준으로 규칙을 설정
      • source.ipBlocks: ["192.168.1.0/24"]: 출처 IP가 192.168.1.0/24 범위(즉, 192.168.1.0 ~ 192.168.1.255)에 속하는 요청만 허용
 
 
 
 
 
 
출처(from), 대상(to), 작업(when) 등을 기준으로 요청을 허용하거나 거부
 
암묵적 거부(deny-by-default) 정책을 따르며, 명시적으로 허용된 요청만 처리
 
 
 
 
  • 내부 네트워크 제한: 특정 사설 IP 범위(예: 내부 네트워크)에서만 접근을 허용하여 외부 요청을 차단
  • 테스트 환경: 테스트 클라이언트(특정 IP 대역)만 서비스에 접근하도록 제한
  • 보안 강화: IP 화이트리스트를 통해 허용된 출처만 접근하도록 제어
 
 
 



 

설치

Istio를 사용하려면 먼저 Kubernetes 클러스터에 설치
istioctl 도구를 사용한 설치를 가정
 
 
설치 확인
 
istio-ingressgateway, istiod 등의 파드 확인
kubectl get pods -n istio-system

 

 

 

Istio가 동작하려면 애플리케이션 파드에 사이드카 프록시(Envoy)를 주입
사이드카 자동 주입 활성화
네임스페이스에 istio-injection=enabled 레이블을 추가하여 Istio 사이드카(Envoy 프록시)가 자동 주입되도록 설정
kubectl create namespace istio-test
kubectl label namespace istio-test istio-injection=enabled

 

 

728x90
반응형
그리드형