Develop/DevOps

[Istio] 공부한거 이것저것 정리 (WIP)

재융 2025. 6. 21. 21:52
반응형

Installation

몰랐는데 설치방식이 두가지가 존재한다.

  • 첫번째는 우리가 흔히 알고있는 sidecar mode인데. 해당 방식은 모든 pod에 Envoy Proxy가 sidecar형태로 자동 주입되는 모드이다.
    • 장점으로는
      • 모든 트래픽을 Envoy가 가로채서 정책을 적용하고 보안을 적용하여 보안성이 뛰어나고
      • L7(http) 레벨 제어 기능이 풍부함
      • 기존 설치방식이라 자료가 풍부함
    • 단점으로는
      • 설치방식에서 언급한대로 pod마다 Envoy sidecar가 붙으니 리소스가 낭비되고 관리가 복잡함
      • 업데이트/보한 패치등도 모든 sidecar에 적용해야함
  • 두번째는 istio 1.18+부터 Preview상태로 도입된 아키텍처인데 Ambient Mode이다.
    • 장점으로는
      • Sidecar Mode와 다르게 Pod에 Envoy Proxy sidecar가 생성되지않는다. 따라서 Sidecar Mode보다 리소스가 절약된다. 대신에 노드 레벨의 ztunnel 이라는 요소가 트래픽을 암호화(mTLS) 및 L4수준 라우팅 처리를 해준다.
      • 필요할때만 Waypoint Proxy (Envoy)를 붙여서 L7 기능 활성화를 한다.
    • 단점으로는
      • Sidecar Mode에 비해 자료가 적고 아직 안정화 단계중인것으로 보여진다. 일부 기능이 지원이 안될수있다.

Upgrade (WIP)

전해듣기론 istio 업그레이드 과정이 까다롭다고한다.

https://istio.io/latest/docs/setup/upgrade/helm/

 

Upgrade with Helm

Instructions to upgrade Istio using Helm.

istio.io

 

istioctl 로 먼저 upgrade전 호환성을 체크한다.

istioctl x precheck
#Error [IST0142] (Cluster) The Kubernetes Version "v1.28.10" is lower than the minimum version: 1.29
#Error: Issues found when checking the cluster. Istio may not be safe to install or upgrade.
#See https://istio.io/v1.26/docs/reference/config/analysis for more information about causes and resolutions.

 

DestinationRule

https://istio.io/latest/docs/reference/config/networking/destination-rule/

 

Destination Rule

Configuration affecting load balancing, outlier detection, etc.

istio.io

호스트에 맵핑된 트래픽이 Gateway통해서 들어오고 VirtualService를 통해서 특정 서비스로 가게되고 만일에 해당 서비스와 연결된 pod들이 여러개 존재한다고할때 특정 pod에 가게끔 하려면 어떻게 해야할까?

이럴때 사용하는것이 DestinationRule이다. 외부에서 트래픽이 들어오면 다음과같은 과정을 거친다고 생각하면된다.

 

   Incoming Request
          |
          v
     [ Gateway ]  
          |        - Gateway는 메쉬 외부로부터 들어오는 트래픽을 제어
          v
[ Virtual Service ] 
          |        - Virtual Service는 Gateway로부터 받은 트래픽을 어느 서비스로 라우팅할지 결정
          v
[ Destination Rule ] 
          |        - Destination Rule은 특정 'destination' 서비스에 대한 트래픽 행동을 세부적으로 정의합니다.
          v
     [ Service ]

 

DestinationRule은 아래와같은 yaml예시로 선언 할 수 있다.

  • 위에서 설정한 trafficPolicy는 하위 subsets에서 별도 설정이 없다면 사용 할 정책(default값)
  • 아래에서 설정한 trafficPolicy는 해당 subsets에서 설정한 트래픽 정책
  • VirtualService는 어떤 subset으로 트래픽을 보낼지 결정(weight등)
  • DestinationRule은 어떤 subset에 어떤 로드 밸런싱 전략을 쓸지 설정
  • subsets.name에 지정한건 VirtualService에서 destination으로 지정한 이름이다.
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local # VirtualService와 연결된 호스트 명
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
  subsets:
  - name: testversion
    labels:
      version: v3 # 해당 라벨은 서비스와 연결된 pod label과 연결된다.
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN

 

HTTPMatchRequest

https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPMatchRequest

 

Virtual Service

Configuration affecting label/content routing, sni routing, etc.

istio.io

VirtualService에서 특정 subURI & query문에 대한 트래픽 route 해주는 기능

# HOST/v2/notify에 대한 트래픽을 notify로 보내고 해당 트래픽은 v2 subset으로 전송 예시
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
 name: notification
spec:
 hosts:
 - notification-service
 http:
 - match:
   - uri:
      prefix: "/v2/notify"
   rewrite:
      uri: "/notify"
   route:
   - destination:
      host: notification-service
      subset: v2
 - route:
   - destination:
       host: notification-service
 
---
# 특정 쿼리문이 포함된 uri의 트래픽을 특정 destination으로 route해주는 예시
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
 name: notification
spec:
 hosts:
 - notification-service
 http:
 - match:
   - queryParams:
      testing:
       exact: "true"
   route:
   - destination:
      host: notification-service
      subset: v2
 - route:
   - destination:
       host: notification-service
       subset: v1
반응형