Overview
오늘은 대표적인 오픈소스 Service Mesh 플랫폼인 Istio에 대해 학습해보았다.
Istio는 마이크로서비스 간의 트래픽 제어, 보안, 관측 가능성을 강화해주는 솔루션으로, 특히 Kubernetes 기반의 환경에서 널리 활용되고 있다.
Istio의 주요 기능(트래픽 관리, mTLS 보안, 모니터링, 확장성)은 물론,
Data Plane(Envoy)과 Control Plane(istiod)의 역할과 구성 요소들(Pilot, Citadel, Galley 등)을 상세히 정리하였다.
또한 최신 Istio의 변화(istiod 단일화, Ambient Mesh, Gateway API 통합), 실무에서 자주 활용되는 CRD 리소스(VirtualService, DestinationRule 등)와 실무 꿀팁까지 함께 정리하며
Istio가 실질적으로 어떻게 활용될 수 있는지에 대한 큰 그림을 이해할 수 있었다.
📅 관련 글
Service Mesh에 대한 내용은 아래의 포스팅에 정리되어 있다.
2023.03.08 - [IaC/Service Mesh] - Service Mesh vs Api Gateway
2024.02.02 - [IaC/Service Mesh] - Istio 설치 및 실습
lstio란?
Istio는 마이크로서비스 아키텍처의 관리, 보안 및 관찰 가능성을 단순화하는 것을 목표로 하는 오픈 소스 Service Mesh 플랫폼이다. C++로 개발된 고성능 프록시 사이드카이다.
2017년에 처음 출시된 Istio는 특히 Kubernetes와 같은 컨테이너화된 환경에서 마이크로 서비스를 배포, 확장 및 유지 관리할 때 발생하는 복잡성을 해결하기 위한 방법으로 Google, IBM 및 Lyft에서 개발하였다.
Istio의 주요 기능
트래픽 관리(Traffic Management)
- Istio는 마이크로서비스의 트래픽 라우팅, 로드 밸런싱 및 복원력에 대한 세밀한 제어를 제공한다. A/B 테스트, 카나리아 배포, 오류 주입과 같은 기능을 사용하여 애플리케이션의 복원력을 테스트할 수 있다.
보안(Security)
- Istio는 서비스 간 통신 암호화를 위한 상호 TLS(mTLS)를 포함하여 마이크로서비스를 위한 강력한 보안 기능을 제공한다. 또한 서비스에 대한 인증, 권한 부여 및 보안 ID 관리를 관리한다.
관측 가능성(Observability)
- Istio는 내장된 원격 측정, 로깅 및 모니터링 기능을 제공하여 마이크로서비스의 관측 가능성을 향상시킨다. 서비스에서 메트릭과 추적을 수집하여 개발자와 운영자가 애플리케이션의 성능, 안정성 및 효율성에 대한 통찰력을 얻을 수 있도록 한다.
확장성(Extensibility)
- Istio는 다양한 플러그인과 어댑터를 사용하여 확장 및 사용자 정의할 수 있으므로 조직에서 기존 도구 및 인프라와 통합할 수 있다.
Istio 구성 요소
Istio에서 Data Plane과 Control Plane은 서비스 메시의 통신, 구성 및 기능을 관리하기 위해 함께 작동하는 두 가지 필수 구성 요소이다.
Data Plane(데이터 플레인)
Data Plane은 서비스 메시의 각 마이크로서비스와 함께 배포되는 지능형 프록시 세트(Istio에서는 Envoy 프록시임)로 구성된다.이러한 프록시는 마이크로 서비스 간에 들어오고 나가는 모든 네트워크 트래픽을 가로채고 Control Plane에서 제공하는 구성을 기반으로 서비스 메시 내에서 라우팅, 로드 밸런싱 및 통신을 관리한다.
Data Plane은 또한 원격 측정 데이터를 수집하고 Control Plane에서 받은 정책을 적용한다.
- Control Plane은 운영자 또는 개발자로부터 높은 수준의 구성 및 정책을 받아 처리한다.
- 이러한 높은 수준의 구성은 Pilot, Mixer 및 Citadel과 같은 구성 요소에 의해 특정 프록시 구성으로 변환된다.
- Data Plane의 Envoy 프록시는 이러한 구성을 수신하여 마이크로서비스 간의 트래픽 흐름에 적용한다.
- 또한 Envoy 프록시는 제어 평면 구성 요소의 지시에 따라 원격 측정 데이터를 수집하고 정책을 시행한다
Envoy
- 마이크로서비스 간에 들어오고 나가는 모든 트래픽을 가로채는 고성능 경량 프록시이다. 서비스 메시 내에서 로드 밸런싱, 라우팅 및 통신을 관리한다.
Control Plane(컨트롤 플레인)
Control Plane은 서비스 메시의 전반적인 동작을 관리하고 구성하는 역할을 한다. 높은 수준의 정책, 트래픽 관리 규칙 및 보안 구성을 처리하고 이를 Data Plane의 프록시에 필요한 특정 구성으로 변환한다. Istio에서 컨트롤 플레인은 다음 구성 요소로 구성된다.
Pilot
- 서비스 메시의 동작을 관리하고 구성하는 구성 요소이다. 고급 라우팅 규칙을 Envoy별 구성으로 변환하고 이를 프록시에 전파한다. Pilot이 Mixer 기능까지 함께 수행한다.
- 트래픽 관리 규칙 및 서비스 검색 정보를 포함하여 서비스 메쉬의 구성을 관리한다.
- Service Discovery(서비스 검색)
- Traffic Management(트래픽 관리)
- Load Balancing(로드 밸런싱)
- Resilience(복원력)
- Traffic Splitting(트래픽 분할)
- Configuring TLS setting(TLS 셋팅)
- Cross-Platform Support(교차 플랫폼 지원)
Mixer(Removed) - Mixer has been removed from the Istio architecture since the release of Istio 1.5
- 정책 시행 및 원격 측정 수집 구성 요소이다. 액세스 제어, 속도 제한 및 할당량 관리 정책을 적용하고 프록시에서 원격 측정 데이터를 수집한다.
Citadel
- 서비스 간 통신을 위한 인증서 관리를 제공하여 상호 TLS 인증을 가능하게 하는 보안 구성 요소이다.
Galley
- Istio의 구성 데이터를 관리하고 서비스 메시 전체에서 일관성을 유지하는 구성 유효성 검사 및 배포 구성 요소이다.
- Istio configuration을 체크하고 yaml 파일을 Istio가 읽을 수 있게 변환시켜준다.
Istio의 장점과 단점 정리
장점 | 단점 |
강력한 트래픽 제어 | 학습 곡선이 가파름 |
서비스 간 mTLS 자동 구성 | 구성 복잡도 증가 |
뛰어난 관측 가능성 | 리소스 오버헤드 존재 |
다양한 정책 제어 가능 | 사이드카로 인한 네트워크 지연 가능성 |
Istio vs Linkerd vs Consul 비교
Istio | Linkerd | Consul | |
언어 | C++, Go | Rust | Go |
아키텍처 | 풀기능 서비스메쉬 | 경량 서비스메쉬 | 서비스 디스커버리+메쉬 |
보안 | mTLS, RBAC | mTLS | mTLS, ACL |
트래픽관리 | VirtualService 등 강력 | 기본적인 라우팅 | 기본적인 라우팅 |
관측가능성 | Prometheus + Grafana | 자체 메트릭 | Consul UI 제공 |
복잡도 | 높음 | 낮음 | 중간 |
Istio의 추가 기능
1️⃣ Gateway 및 Ingress/Egress 컨트롤
Istio는 서비스 메시 내부뿐만 아니라 외부 트래픽을 제어할 수 있는 기능도 제공한다.
- Ingress Gateway: 외부에서 들어오는 요청을 처리하고 내부 서비스로 라우팅한다.
- Egress Gateway: 내부 서비스에서 외부 서비스(AWS, Google API 등)로 나가는 트래픽을 제어한다.
이를 통해 보안 정책 적용, 트래픽 모니터링, TLS 암호화 등을 수행할 수 있다.
예제
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-ingress-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "example.com"
2️⃣ Istio Ambient Mesh (사이드카리스 모드)
기존 Istio는 사이드카(sidecar) 방식으로 동작하지만, Istio Ambient Mesh는 사이드카 없이도 작동할 수 있는 새로운 방식이다.
- 사이드카가 없으므로 리소스 사용량 감소
- 애플리케이션 변경 없이 적용 가능
- 점진적 도입 가능 (기존 Istio 환경에서도 함께 사용 가능)
공식 문서: https://istio.io/latest/docs/ambient/
3️⃣ Istio와 Kubernetes Gateway API의 통합
최근 Kubernetes Gateway API와 Istio가 통합되어, Istio를 Kubernetes 네이티브 환경에서 더욱 쉽게 사용할 수 있다.
- 기존 VirtualService, DestinationRule이 아닌 Kubernetes Gateway API를 활용 가능
- Istio의 네트워크 정책을 보다 직관적으로 정의 가능
4️⃣ Istio의 보안 기능 강화
Istio는 기본적으로 mTLS를 제공하지만, 최근에는 OIDC, JWT 인증, OPA(Open Policy Agent)와의 연동 등 보안 기능이 더욱 강화되고 있다.
- 클라이언트-서버 간 mTLS 통신을 자동으로 설정
- JWT(JSON Web Token)를 활용한 인증
- OPA(Open Policy Agent)와 연동하여 정책 기반의 RBAC(Role-Based Access Control) 적용
예제: JWT 인증을 위한 Istio Policy
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
name: jwt-auth
namespace: istio-system
spec:
selector:
matchLabels:
app: my-app
jwtRules:
- issuer: "https://my-auth-provider.com/"
jwksUri: "https://my-auth-provider.com/.well-known/jwks.json"
🔒 mTLS란?
mTLS는 Mutual TLS의 약자다. 보통 TLS는 "한쪽만 인증"하는 방식이다.
- 클라이언트 → 서버로 접속할 때 서버 인증서만 검증 (https 접속할 때 브라우저가 서버 인증서 확인하는 것처럼)
mTLS는 이걸 한 단계 더 나아가서,
- 클라이언트는 서버의 인증서를 검증하고
- 서버도 클라이언트의 인증서를 검증하는 방식이다.
한 마디로
서로 신뢰할 수 있는지 양방향으로 확인하는 보안 프로토콜
왜 필요한데?
마이크로서비스 환경에서는 서비스끼리 서로 요청을 주고받잖아? 이때 서비스 간 통신도 안전하게 보장해야 해.
그냥 TLS만 쓰면 서버만 인증하지만, mTLS를 쓰면 양쪽 서비스가 서로 인증하니까 더 안전해지는 거야.
🔗 흐름 예시
- 서비스A → 서비스B로 요청
- 서비스B가 인증서 보내고 서비스A가 검증
- 서비스A도 자기 인증서 보내고 서비스B가 검증
- 둘 다 성공하면 데이터 전송 시작
추가 내용 - 최신 동향 및 실무 활용 팁
Istio 최신 아키텍처 변화
- Istio는 지속적인 발전을 거쳐, 1.5 버전 이후 아키텍처가 크게 변경되었다.
- 기존의 Mixer 컴포넌트는 제거되었고, Telemetry 및 Policy 관리 기능은 Envoy와 Pilot으로 흡수되었다.
- Pilot, Citadel, Galley 또한 istiod라는 단일 컨트롤러로 통합되어, 관리가 훨씬 단순해졌다.
- 이로 인해 Control Plane 구성요소가 대폭 단순화되고, 성능 및 관리 측면에서 개선되었다.
Istiod 구성
현재 Istio에서 가장 중요한 Control Plane 컴포넌트는 istiod 하나로 단일화되어 있다. istiod는 아래의 역할을 모두 수행한다.
역할 | 설명 |
서비스 디스커버리 | Kubernetes Service 정보를 수집해 Envoy로 전달 |
컨피그 전달 | VirtualService, DestinationRule 등을 Envoy로 전달 |
보안 관리 | mTLS 인증서 관리 및 배포 |
텔레메트리 수집 | Envoy에서 메트릭/로그 수집 |
Istio의 실제 현업 활용 시 꿀팁
상황 | 팁 |
트래픽 점진 배포 | VirtualService로 Canary 배포 구성 가능 |
트래픽 라우팅 | 특정 요청을 특정 서비스로 라우팅하는 기능 활용 |
보안 강화 | 서비스 간 mTLS 강제 적용으로 통신 암호화 |
장애주입 테스트 | Fault Injection 기능으로 장애 상황 테스트 |
성능 모니터링 | Prometheus + Grafana와 연동하여 서비스 메쉬 전체 모니터링 |
Istio Ingress Gateway
- Istio는 자체적으로 Ingress Gateway를 제공하며, 외부 트래픽을 서비스 메쉬로 라우팅하는 역할을 수행한다.
- Kubernetes Ingress와 비슷하지만, Istio의 강력한 트래픽 관리 기능(VirtualService, DestinationRule 등)을 그대로 활용할 수 있다.
- 여기에 mTLS 및 인증서 자동 갱신까지 지원해 보안 측면에서도 유리하다.
실무에서 자주 사용하는 CRD 예시
리소스 | 역할 | 예시 |
Gateway | Ingress Gateway 설정 | 외부 트래픽 수용 |
VirtualService | 트래픽 라우팅 정책 | A/B 테스트, Canary 배포 |
DestinationRule | 백엔드 서비스 정책 | 서킷브레이커, 타임아웃 설정 |
ServiceEntry | 외부 서비스 등록 | 외부 DB 접속 허용 |
Istio + Prometheus + Grafana 연동 구성도
마무리
- 이번 포스팅에서는 Istio의 기본 개념부터 주요 구성 요소, 그리고 실무에서 유용한 활용 팁까지 폭넓게 정리해봤다.
- Istio는 단순한 서비스메쉬 도구를 넘어서 마이크로서비스 운영 표준으로 자리 잡고 있으며, 특히 트래픽 제어, 보안 강화, 장애 주입 테스트, 메트릭 수집까지 한 번에 해결할 수 있는 강력한 툴이다.
- 하지만 그만큼 학습 난이도와 구성 복잡도도 높기 때문에, 작은 규모의 서비스라면 Linkerd처럼 더 가벼운 솔루션도 고려할 수 있다.
- 특히, Istio는 꾸준한 버전 업데이트로 기능이 추가되고 아키텍처가 개선되고 있으니, 공식 문서 및 Release Note를 항상 참고하는 습관을 들이면 좋다.
Reference
istio 아키텍처
istio란? IBM
istio 정리 참고 블로그
istio 공식문서
- Istio 공식 문서: https://istio.io/latest/docs/
- Istio Ambient Mesh: https://istio.io/latest/blog/2022/introducing-ambient-mesh/
- Kubernetes Gateway API + Istio 통합: https://istio.io/latest/blog/2022/gateway-api-beta/
- Istio OPA 연동 보안: https://www.openpolicyagent.org/docs/latest/istio/
'IaC > Service Mesh' 카테고리의 다른 글
Istio 설치 및 실습 (0) | 2024.02.13 |
---|---|
Service Mesh vs Api Gateway (0) | 2023.03.08 |