서비스 메시가 필요한 순간
마이크로서비스가 10개를 넘어서면 서비스 간 통신 관리가 복잡해집니다. 재시도, 서킷 브레이커, mTLS, 트레이싱을 각 서비스 코드에 구현하는 것은 중복이고 비효율적입니다.
핵심 기능
| 기능 | 설명 |
|---|---|
| mTLS | 서비스 간 자동 암호화 + 인증 |
| 트래픽 관리 | 카나리 배포, A/B 테스트 |
| 관찰성 | 분산 트레이싱, 서비스 의존성 맵 |
| 폴리시 | 서비스 간 접근 제어 |
Istio 설치 및 카나리 배포
istioctl install --set profile=production -y
kubectl label namespace my-app istio-injection=enabledapiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-app
spec:
http:
- route:
- destination:
host: my-app
subset: v1
weight: 90
- destination:
host: my-app
subset: v2
weight: 10mTLS 전체 적용
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: STRICTLinkerd - 경량화
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
kubectl annotate namespace my-app linkerd.io/inject=enabledIstio vs Linkerd 비교
| Istio | Linkerd | |
|---|---|---|
| 컨트롤 플레인 메모리 | ~500MB | ~50MB |
| 사이드카 메모리 | ~50MB/Pod | ~10MB/Pod |
| 레이턴시 추가 | ~1-2ms | <0.5ms |
| 학습 곡선 | 높음 | 낮음 |
Cilium - eBPF 기반 (사이드카 없음)
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
--namespace kube-system \
--set kubeProxyReplacement=true# L7 HTTP 정책
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
spec:
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
rules:
http:
- method: GET
path: "/api/.*"선택 가이드
| 상황 | 추천 |
|---|---|
| 고급 트래픽 관리 | Istio |
| 단순하고 빠른 mTLS | Linkerd |
| CNI와 메시 통합, 최고 성능 | Cilium |
| 소규모 (10개 미만) | 없음 |
서비스 메시는 복잡성을 추가합니다. 필요성을 먼저 검증하고 도입하세요.
규모·요구별 의사결정표
| 상황 | 권장 | 근거 |
|---|---|---|
| 서비스 30개 미만, mTLS·재시도만 필요 | Linkerd | 학습·운영 비용이 가장 낮고 리소스 오버헤드 최소 |
| 트래픽 정책·멀티클러스터·복잡한 라우팅 | Istio | 기능 폭이 가장 넓음 — 대신 전담 운영 역량 필요 |
| 이미 Cilium CNI 사용, L7 관측이 목적 | Cilium Service Mesh | 사이드카 없이 시작 — 단, 메시 기능 성숙도는 문서로 확인 |
| 아직 메시 없이 버틸 수 있는지 고민 | 도입 보류 | 게이트웨이+라이브러리 재시도로 충분한 경우가 많음 |
도입 전 체크리스트
- 목적을 한 문장으로 — "mTLS 의무화"인지 "카나리 배포"인지 "관측"인지 (목적별로 최소 도구가 다름)
- 사이드카 리소스 예산 — 파드당 추가 CPU/메모리 × 파드 수를 미리 계산
- 업그레이드 경로 — 컨트롤플레인 버전 업 시 데이터플레인 재기동 절차 리허설
- 장애 격리 계획 — 메시 컨트롤플레인 장애 시 트래픽 영향 범위 확인 (fail-open 여부)
- 제거 시나리오 — 6개월 후 메시를 걷어낼 수 있는 구성인지
참고: 공식 문서
이 글에서 다루는 동작·설정·에러의 1차 출처는 다음 공식 문서입니다. 버전별 옵션과 정확한 동작은 여기서 확인하세요.
자주 묻는 질문 (FAQ)
Q. Cilium과 Istio는 뭐가 다른가요? A. Istio는 사이드카(Envoy) 기반 L7 서비스 메시로 트래픽 관리·mTLS·관측성이 풍부하지만 사이드카 오버헤드가 있습니다. Cilium은 eBPF 기반으로 커널 레벨에서 네트워킹·보안을 처리해 오버헤드가 낮고, Cilium Service Mesh는 사이드카 없는(sidecarless) 모드를 지원합니다. 성능·저지연이 우선이면 Cilium, 성숙한 L7 트래픽 제어와 생태계가 우선이면 Istio입니다.
Q. Cilium과 Istio를 함께 쓸 수 있나요? A. 가능합니다. CNI는 Cilium(고성능 네트워킹·NetworkPolicy)으로, 서비스 메시 L7 기능은 Istio로 두는 조합이 흔합니다. 단 mTLS·트래픽 관리 기능이 겹치므로 역할을 명확히 분리해야 합니다.
이 글은 AI 에이전트가 자료 조사와 1차 초안 작성을 담당하고, 사람 편집자가 사실관계·출처·톤과 맥락을 검토한 뒤 발행했습니다. 환경(OS·버전)에 따라 결과가 다를 수 있으니 적용 전 공식 문서를 함께 확인하세요. 오류를 발견하시면 이메일로 제보해 주세요 — 확인 후 신속히 정정합니다.
댓글
첫 번째 댓글을 남겨보세요.