🚀 서비스 메시
이번엔 쿠버네티스를 다룰 때 자주 나오는 기술인 Istio에 대해 알아보려고 한다! 설치는 나중에 쿠버네티스를 본격적으로 다뤄볼 때 언급하고 오늘은 이게 무엇인지에 대해서만 작성하려고 한다.
🌐 서비스 메시란 무엇인가?
서비스 메시는 마이크로서비스 아키텍처에서 서비스 간 통신을 관리하고 제어하는 인프라 레이어를 의미한다. 현대적인 클라우드 네이티브 애플리케이션이 복잡해지면서 서비스 간 통신 문제를 해결하기 위한 방법으로 등장했다. 서비스 메시는 서비스 간 통신에 대한 네트워킹, 보안, 관측 기능을 애플리케이션 코드와 분리하여 제공한다.
서비스의 수가 증가하면 잠재적 통신 경로의 수도 기하급수적으로 증가한다. 예를 들어 두 서비스에는 오직 두 개의 통신 경로만 있지만, 10개의 서비스에는 90개의 통신 경로가 생긴다. 이러한 복잡한 통신을 효율적으로 관리하기 위해 서비스 메시가 필요하다.
💡 Istio의 정의
Istio는 마이크로서비스 아키텍처의 관리, 보안 및 관찰 가능성을 단순화하는 것을 목표로 하는 오픈 소스 Service Mesh 플랫폼이다. C++로 개발된 고성능 프록시인 Envoy를 기반으로 동작하며, Kubernetes 환경에서 각 애플리케이션들의 네트워크 연결을 쉽게 설정하고 제어할 수 있도록 지원한다.
간단히 말해, Istio는 "내 마음대로 네트워크를 제어하는 가상 네트워크"라고 볼 수 있다. 실제 서비스 코드를 변경하지 않고도 네트워크 레벨에서 다양한 기능을 제공하기 때문이다.
🏗️ Istio의 아키텍처와 구성 요소
Istio는 크게 Control Plane과 Data Plane으로 구성된다. 이 두 계층이 어떻게 구성되고 동작하는지 살펴보자.
📊 데이터 플레인 (Data Plane)
데이터 플레인은 실제 서비스 간 통신이 이루어지는 계층이다. 주로 Envoy 프록시로 구성되며, 다음과 같은 역할을 수행한다.
- 트래픽 라우팅. 서비스 간 요청을 적절히 라우팅한다.
- 로드 밸런싱. 트래픽을 여러 서비스 인스턴스에 균형있게 분배한다.
- 헬스 체크. 서비스의 상태를 주기적으로 확인한다.
- 보안. TLS 암호화, 인증 등의 보안 기능을 제공한다.
- 메트릭 수집. 서비스 간 통신에 대한 다양한 메트릭을 수집한다.
데이터 플레인은 쿠버네티스 관점에서 다음과 같은 형태로 존재한다.
- Ingress Gateway. 클러스터 내부로 들어오는 트래픽을 제어하는 Envoy 프록시다.
- Mesh. 실제 애플리케이션과 함께 사이드카 형태로 배포되는 Envoy 프록시다.
- Egress Gateway. 클러스터 외부로 나가는 트래픽을 제어하는 Envoy 프록시다.
다음은 데이터 플레인의 구조를 텍스트로 표현한 것이다.
[외부 트래픽] --> [Ingress Gateway] --> [Service A + Envoy Sidecar] --> [Service B + Envoy Sidecar] --> [Egress Gateway] --> [외부 서비스]
|
v
[Service C + Envoy Sidecar]🧠 컨트롤 플레인 (Control Plane)
컨트롤 플레인은 Istio의 두뇌 역할을 하며, 서비스 메시의 전반적인 동작을 제어하고 관리한다. 주요 구성 요소는 다음과 같다.
- Pilot. 서비스 디스커버리, 트래픽 관리, 라우팅 규칙 설정 등을 담당한다.
- Citadel. 보안 관련 기능을 제공하며, 인증, 암호화, 접근 제어 등을 처리한다.
- Galley. Istio의 구성 관리를 담당하며, 사용자가 정의한 구성을 검증하고 배포한다.
Istio v1.5 이후부터는 위의 세 컴포넌트가 istiod라는 하나의 컴포넌트로 통합되어 배포된다. istiod는 쿠버네티스 커스텀 리소스의 변경을 감지하여 Envoy 전용 구성으로 변환한 후 사이드카에 전파하는 역할을 한다.
컨트롤 플레인의 구조를 텍스트로 표현하면 다음과 같다.
[istiod]
|
+-------------+-------------+
| | |
[Pilot 기능] [Citadel 기능] [Galley 기능]
| | |
v v v
[서비스 디스커버리] [보안 관리] [구성 검증]🛠️ Istio의 핵심 기능
🔄 트래픽 관리 (Traffic Management)
Istio의 트래픽 관리 기능은 서비스 간 트래픽 흐름을 세밀하게 제어할 수 있게 해준다. 다음과 같은 기능을 제공한다.
- 라우팅 규칙. 요청을 특정 서비스 버전으로 라우팅한다.
- 로드 밸런싱. HTTP, TCP, WebSocket 등 다양한 프로토콜에 대한 로드 밸런싱을 제공한다.
- 서킷 브레이커. 오류가 발생한 서비스로의 트래픽을 차단하여 장애 확산을 방지한다.
- 타임아웃/재시도. 요청에 대한 타임아웃 설정 및 자동 재시도 기능을 제공한다.
- 카나리 배포. 새 버전을 점진적으로 배포하는 전략을 지원한다.
예를 들어, A 서비스와 B 서비스가 있고 B 서비스는 2개 인스턴스로 스케일링되어 있을 때, Istio를 사용하면 A에서 B로 가는 트래픽을 2:8 비율로 로드 밸런싱할 수 있다.
[A 서비스] ---> 20% ---> [B 서비스 v1]
\
\-> 80% ---> [B 서비스 v2]🔒 보안 (Security)
Istio는 서비스 메시 내의 모든 통신에 대해 강력한 보안 기능을 제공한다.
- mTLS (Mutual TLS). 서비스 간 양방향 인증을 통한 암호화 통신을 지원한다.
- 인증/권한 관리. 서비스 간 접근 제어 및 인증 정책을 적용한다.
- 정책 적용. 트래픽에 대한 보안 정책을 적용하고 관리한다.
특히 mTLS는 서비스 간 통신 시 클라이언트와 서버가 각자의 인증서를 교환하고 검증하는 과정을 통해 보다 안전한 통신을 보장한다.
[서비스 A] [서비스 B]
| |
+---------암호화 통신-----------+👁️ 관측 가능성 (Observability)
Istio는 서비스 메시 내의 모든 트래픽에 대한 가시성을 제공한다.
- 메트릭 수집. 서비스 간 통신에 대한 다양한 메트릭을 자동으로 수집한다.
- 로깅. 트래픽에 대한 상세 로그를 제공한다.
- 분산 트레이싱. 여러 서비스를 거치는 요청의 전체 경로를 추적한다.
- 시각화 도구 지원. Grafana, Jaeger/Zipkin, Kiali 등과 통합된다.
트레이싱 엔진은 요청 플로우의 전체 그림을 하나로 완성하여 아키텍처 상에서 오동작할 수 있는 영역을 인식하기 쉽도록 도와준다.
[사용자 요청] --> [서비스 A] --> [서비스 B] --> [서비스 C]
| | |
v v v
[트레이스 ID: abc-123] <-- 분산 트레이싱 --+
| |
+-------------+---------------------+
v
[시각화 도구]🧩 Istio 리소스 및 구성 예제
Istio는 쿠버네티스 커스텀 리소스를 사용하여 다양한 설정을 관리한다. 주요 리소스는 다음과 같다.
🚪 Gateway
Gateway 리소스는 서비스 메시의 경계에서 인바운드 및 아웃바운드 트래픽을 관리한다. 다음은 Nginx를 Istio Gateway로 노출하는 예제이다.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: nginx-gateway
namespace: default
spec:
selector:
istio: gateway # gateway 컨트롤러의 label
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*" # 이 호스트에 대한 트래픽을 제어🌐 VirtualService
VirtualService는 요청이 서비스로 라우팅되는 방법을 정의한다. Gateway와 함께 사용하여 트래픽 규칙을 설정할 수 있다.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: nginx-vs
namespace: default
spec:
hosts:
- "*"
gateways:
- nginx-gateway # 이 VirtualService가 위의 Gateway와 연결
http:
- route:
- destination:
host: nginx.default.svc.cluster.local # 실제 서비스
port:
number: 10080 # 지정한 포트로 라우팅🔐 PeerAuthentication
PeerAuthentication 리소스는 서비스 간 mTLS 설정을 위해 사용된다.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: example-peer-auth
namespace: default
spec:
mtls:
mode: STRICT # 엄격한 mTLS 모드 적용🚦 Istio 데이터 플레인의 모드
Istio의 데이터 플레인은 네트워크 트래픽을 제어하는 핵심 요소다 Kubernetes 클러스터에서 Istio는 Sidecar 모드와 Ambient 모드라는 두 가지 방식을 제공한다 각 모드는 트래픽 처리 방식과 리소스 활용 관점에서 차이를 보인다.
보다 자세한 정보는 공식문서에서 볼 수 있다.
https://istio.io/latest/docs/overview/dataplane-modes/
🚌 Sidecar 모드
🛠️ 동작 원리
- 애플리케이션 Pod에 Envoy 사이드카 프록시가 주입된다
- 모든 인바운드·아웃바운드 트래픽이 사이드카를 통해 처리된다
🔧 특징
- Layer 4와 Layer 7 프로토콜 모두 지원한다
- 세밀한 트래픽 제어와 모니터링이 가능하다
- Pod마다 프록시가 추가되므로 리소스 소비와 운영 복잡도가 증가한다
🌫️ Ambient 모드
🛠️ 동작 원리
- 각 노드에 Ztunnel DaemonSet이 배포된다
- 워크로드 Pod가 네트워크 트래픽을 Ztunnel으로 리다이렉션한다
- Layer 7 기능이 필요할 때는 네임스페이스 단위로 Waypoint Envoy 프록시를 옵션으로 연결한다
🔧 특징
- Pod에 사이드카 주입이 불필요해 리소스 효율성이 높다
- 애플리케이션 설정이나 코드 변경 없이 메시를 적용할 수 있다
- 기본적으로 L4 트래픽만 처리하므로 세밀한 L7 제어는 제한된다
- L7 처리가 필요할 경우 Waypoint로 보완할 수 있다
🔍 Istio의 활용 사례
Istio는 다양한 상황에서 활용될 수 있다.
- 마이크로서비스 통신 관리. 복잡한 마이크로서비스 환경에서 서비스 간 통신을 효율적으로 관리한다.
- 점진적 배포 전략. A/B 테스팅, 카나리 배포 등 다양한 배포 전략을 쉽게 구현한다.
- 멀티 클라우드 환경. 여러 클라우드 환경에 걸쳐 있는 서비스 간 통신을 통합 관리한다.
- 보안 강화. mTLS를 통한 서비스 간 암호화 통신 및 접근 제어를 적용한다.
- 모니터링 및 디버깅. 서비스 메시 전반의 트래픽 상태를 모니터링하고 문제를 진단한다.
- 서킷 브레이커. 목적지 마이크로서비스에 문제가 있을 때 접속을 차단하고 출발지 마이크로서비스에 요청 에러를 반환한다.
'Container & Orchestration > Kubenetes' 카테고리의 다른 글
| Kubernetes - 서비스 카탈로그와 서비스 브로커 (0) | 2025.05.22 |
|---|---|
| Kubernetes - 멀티 테넌시 환경 구축 (0) | 2025.05.21 |
| Kubernetes - Validating, Mutating Admission Controller (0) | 2025.05.16 |
| Kubernetes - Admission Controller (0) | 2025.05.14 |
| [Practice Test] Resource Limits (0) | 2025.05.08 |