Istio는 서비스 간 통신을 제어하고 보호하며 관측하기 위한 서비스 메시다. 애플리케이션마다 통신 정책 코드를 반복 작성하기보다 공통 데이터 플레인과 제어면에서 정책을 적용한다. Kubernetes와 함께 사용되는 경우가 많지만 단순한 외부 웹 진입 프록시보다 넓은 역할을 갖는다. 공식 개요는 주요 기능과 배치 방식을 소개한다.
제어면과 데이터 플레인
제어면 istiod는 서비스 발견과 정책·인증서 등 데이터 플레인에 필요한 정보를 제공한다. 데이터 플레인은 실제 서비스 트래픽을 처리한다. Sidecar 모드는 Pod 옆의 프록시를, Ambient 모드는 노드의 ztunnel과 선택적인 waypoint를 활용한다. 모드마다 기능과 적용 경로가 다르므로 같은 선언이 모든 환경에서 같게 작동한다고 가정하지 않는다.
상호 TLS는 서비스 간 연결의 신원 확인과 암호화에 쓰이고, 인가 정책은 어떤 요청을 허용할지 정한다. 트래픽 정책으로 목적지 선택·시간 제한·재시도 등을 다룰 수 있다. 암호화된 연결이라는 사실만으로 사용자의 업무 권한까지 검증되는 것은 아니므로 애플리케이션 인증과 함께 설계한다.
장점과 한계
여러 언어로 작성된 서비스에도 공통 통신 정책을 적용하고, 애플리케이션 코드를 크게 바꾸지 않으면서 관측 정보를 모으기 좋다. 점진적인 트래픽 전환과 연결 정책을 중앙에서 검토할 수 있다. 반면 추가 프록시와 제어면의 자원 비용, 정책 복잡도, 장애 조사 계층이 늘어난다.
재시도를 켜면 항상 안정성이 좋아지는 것은 아니다. 느린 백엔드에 요청을 더 보내 부하를 키우거나, 중복 처리에 안전하지 않은 요청을 반복할 수 있다. 시간 제한·재시도·회로 차단을 각 계층에 중복 설정할 때 전체 요청 시간과 시도 횟수를 계산해야 한다. 트래픽 관리 문서가 관련 자원과 동작을 설명한다.
도서 검색 요청 시간 제한
다음은 Sidecar 기반 Istio가 구성된 library-lab에서 catalog Service로 가는 메시 내부 HTTP 요청에 시간 제한을 두는 예시다. Service와 프록시 등록은 이미 준비되어 있어야 하며, 외부 Gateway 구성이나 모든 Ambient 경로에 대한 적용 예시는 아니다.
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: catalog-timeout
namespace: library-lab
spec:
hosts:
- catalog.library-lab.svc.cluster.local
http:
- timeout: 2s
route:
- destination:
host: catalog.library-lab.svc.cluster.local
port:
number: 8080이 규칙은 해당 요청에 2초의 제한을 표현한다. 2초 안에 정상 응답하는 성능을 만들어 주는 설정은 아니며, 실제 요청이 해당 프록시·규칙을 통과하는지 확인해야 한다. 오류율과 지연을 함께 보고 제한이 너무 짧아 정상 작업까지 끊지 않는지 검토한다.
자주 생기는 오해
메시를 설치한 것만으로 모든 트래픽이 보호된다고 단정하지 않는다. 등록되지 않은 워크로드와 외부 시스템 경로를 따로 확인한다. 연결 문제를 해결하기 위해 인증서 검증이나 인가를 일괄 끄기보다, 서비스 이름·정책 선택 범위·프록시 상태를 단계별로 점검한다.