📌 [Deployment 심화편 #10] Deployment와 서비스 메시 (Istio, Linkerd)를 활용한 배포 제어

1️⃣ 개요

 

쿠버네티스에서 애플리케이션을 배포할 때 트래픽을 세밀하게 제어하고, 안전하게 업데이트하는 방법이 필요합니다.

특히, Canary Deployment, Blue-Green Deployment, Shadow Deployment 같은 배포 전략을 효과적으로 적용하려면 트래픽을 제어할 수 있는 기술이 필수적입니다.

 

이를 위해 서비스 메시(Service Mesh) 를 활용하면,

✅ 배포 중 트래픽을 Canary 버전과 Stable 버전으로 분배

✅ 배포 실패 시 자동 롤백 가능

✅ A/B 테스트 및 Shadow Deployment 지원

✅ Zero-Trust 네트워크 보안 강화

 

이번 글에서는 서비스 메시의 개념과, Istio 및 Linkerd를 활용한 배포 제어 방법을 설명하겠습니다. 🚀

 

---

2️⃣ 서비스 메시(Service Mesh)란?

 

✅ 1. 서비스 메시의 개념

• 애플리케이션 간의 네트워크 트래픽을 제어하는 인프라 계층

• 각 서비스(Pod)마다 사이드카 프록시(Proxy)를 추가하여 트래픽을 라우팅 및 모니터링

• 트래픽 제어, 서비스 간 인증, 가시성(Observability), 네트워크 보안 제공

 

📌 서비스 메시의 주요 기능

기능	설명
트래픽 라우팅	Canary 배포, Blue-Green 배포, A/B 테스트 지원
보안 강화	TLS 암호화, 서비스 간 인증, RBAC 적용 가능
모니터링	Prometheus, Grafana, Jaeger와 연동하여 트래픽 분석 가능
자동화된 롤백	에러율이 증가하면 자동으로 이전 버전으로 복귀

✅ 서비스 메시를 활용하면 배포 중에도 트래픽을 세밀하게 제어할 수 있습니다.

 

---

3️⃣ 서비스 메시를 활용한 배포 전략

 

서비스 메시는 트래픽을 특정 버전의 Deployment로 조절할 수 있도록 지원합니다.

이를 활용하여 Canary, Blue-Green, Shadow Deployment 등의 전략을 구현할 수 있습니다.

 

---

✅ 1. Istio를 활용한 Canary Deployment

 

Istio의 VirtualService 를 활용하면, 기존 버전과 새로운 버전 간의 트래픽 비율을 조정할 수 있습니다.

 

📌 Canary 배포를 위한 Istio 설정

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
    - my-app.example.com
  http:
    - route:
        - destination:
            host: my-app
            subset: stable
          weight: 80  # 기존 버전(Stable)에 80% 트래픽 전송
        - destination:
            host: my-app
            subset: canary
          weight: 20  # 새로운 버전(Canary)에 20% 트래픽 전송

 

📌 Canary 배포 적용

kubectl apply -f canary-virtualservice.yaml

✅ 이제 Canary 버전으로 20%의 트래픽만 전송되며, 점진적으로 비율을 조정할 수 있습니다.

 

---

✅ 2. Istio를 활용한 Blue-Green Deployment

 

Blue-Green 배포에서는 Stable과 Green 두 개의 Deployment를 운영하면서, Istio를 활용해 트래픽을 한 번에 전환합니다.

 

📌 Blue-Green 배포를 위한 Istio 설정

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
    - my-app.example.com
  http:
    - route:
        - destination:
            host: my-app
            subset: green  # 새로운 버전(Green)으로 전체 트래픽 전환

 

📌 트래픽 전환 적용

kubectl apply -f blue-green-virtualservice.yaml

✅ 기존 버전(Blue)에서 새로운 버전(Green)으로 트래픽이 한 번에 이동됩니다.

 

---

✅ 3. Istio를 활용한 Shadow Deployment (트래픽 미러링)

 

Shadow Deployment에서는 사용자 요청을 기존 버전과 새로운 버전에 동시에 전송하여, 새로운 버전의 동작을 실제 트래픽으로 검증할 수 있습니다.

 

📌 Shadow Deployment를 위한 Istio 설정

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
    - my-app.example.com
  http:
    - route:
        - destination:
            host: my-app
            subset: stable  # 기존 버전(Stable)에만 응답
      mirror:
        host: my-app
        subset: shadow  # Shadow 버전에도 동일한 요청을 복제 (응답 X)
      mirrorPercentage: 100.0

 

📌 Shadow Deployment 적용

kubectl apply -f shadow-virtualservice.yaml

✅ Shadow 버전은 응답을 반환하지 않고, 오직 트래픽 분석 목적으로만 동작합니다.

 

---

4️⃣ 서비스 메시 운영 시 고려해야 할 점

 

✅ 1. 서비스 메시 오버헤드 관리

• 모든 Pod에 사이드카(Proxy)가 추가되므로 리소스 사용량 증가 가능

• Istio의 Sidecar Injection 기능을 활용하여 필요한 서비스에만 적용하도록 설정

 

📌 네임스페이스 단위로 사이드카 자동 주입 활성화

kubectl label namespace my-namespace istio-injection=enabled

✅ 서비스 메시 적용 범위를 최소화하면 성능 최적화가 가능합니다.

 

---

✅ 2. 실시간 모니터링 및 장애 감지

• 서비스 메시가 적용된 환경에서는 트래픽 흐름을 모니터링하는 것이 필수적

• Prometheus, Grafana, Kiali, Jaeger를 활용하여 실시간으로 분석 가능

 

📌 Istio의 Kiali 대시보드 실행 (서비스 간 트래픽 분석)

istioctl dashboard kiali

 

📌 서비스 메시에서 발생하는 트래픽 로그 확인

kubectl logs -l istio=proxy

✅ 실시간 모니터링을 통해 트래픽 이상 징후를 감지할 수 있습니다.

 

---

🔥 5️⃣ 결론

 

✔ 서비스 메시(Istio, Linkerd)를 활용하면 트래픽을 세밀하게 제어하여 안정적인 배포 가능

✔ Canary, Blue-Green, Shadow Deployment 같은 배포 전략을 효과적으로 구현할 수 있음

✔ 트래픽 비율을 조정하여 배포 중에도 문제 발생 시 즉시 롤백 가능

✔ 사이드카 프록시를 활용하므로, 네트워크 오버헤드와 리소스 사용량을 고려해야 함

✔ Prometheus, Grafana, Kiali를 활용하여 실시간으로 트래픽 모니터링이 필요함