- Istio는 오픈소스 서비스 메쉬로, 분리된 어플리케이션을 투명하게 계층화할 수 있다.
- 현재 쿠버네티스의 네트워크 구성에 가장 많이 사용되고 있는 오픈소스기도 하다.
- Istio는 쿠버네티스 네트워크의 복잡성을 줄이고, 분산 네트워크 환경에서 여러 어플리케이션들의 연결을 쉽게 설정할 수 있게 지원한다.
- Sidecar 패턴(Pod 내에 Envoy proxy sidecar로 존재)을 이용하여 application 코드의 변경없이 작업자가 VirtualService, DestinationRule이라는 Custom Resource로 손쉽게 원하는 서비스로 트래픽 전송이 가능
- k8s로 Canary 배포를 하기 위해선 직접 replica 개수를 조정해야 했으나, Istio VirtualService의 Weight와 subset을 통해 이 과정이 Envoy로 Header와 Path의 L7 라우팅이 매우 간단해짐
- log, metric, trace를 Istio를 통해 모두 수집 가능 - Envoy를 통해 Observability 구현
- MSA 구조로 인한 Man in middle 공격과 manifest 노출의 리스크를 mTLS로 통신 레이어 보안 향상시킴
- Policy를 활용하여 서비스간의 통신의 권한을 코드화시켜 관리가 가능
- 어플리케이션 코드의 변경없이도 클러스터의 보안을 강화시킴
- 따라서 Istio를 사용하면 서비스의 코드를 변경하지 않고 로드밸런싱과 service to service 인증 및 모니터링을 할 수 있다.
- TLS 암호화와 함께 서비스간 통신의 보안과 인증
- HTTP, gRPC, Websocket, TCP의 로드밸런싱
- 다양한 라우팅 룰과 재시도, 결함 제거 및 장애 극복과 같은 트래픽 동작을 세부적으로 제어
- 플러그형 정책 계층과 액세스 제어와 속도 제한 등을 지원하는 API
- ingress, egress를 포함한 클러스터 내의 자동 메트릭, 로그, 추적 기능
- control plane은 kubernetes namespace 'istio-system'에 속한 파드들을 의미한다.
- Data Plane은 서비스간의 통신으로 실제 트래픽을 받아 처리한다.
- 서비스의 사이드카 형태로 구성된 프록시들을 말하며 Envoy가 사이드카 프록시로 활용된다.
- Data plane은 Control plane에 의해서 컨트롤된다.
- Control Plane
- Data Plane을 관리하는 컨트롤타워다.
- kubernetes cluster에서 istio-system 네임스페이스로 구성된다.
- Envoy
- lstio 외에도 Consule, App mesh, Kong Mesh 등의 서비스메쉬가 Envoy로 구현되어 있다.
- Envoy는 경량화된 L7 Proxy로 HTTP, TCP, gRPC 등의 프로토콜을 지원한다.
- Retry, Circuit Breaker, Timeout 등 다양한 기능을 수행할 수 있다.
- Service A와 Service B는 컨테이너에서 동작하는 마이크로서비스고 Envoy Proxy로 통신하는 것을 볼 수 있다.
- lstio는 Envoy가 배포되면 Envoy proxy를 Pod에 주입한다.
- Ingress 트래픽은 Ingress 리소스를 통해서 서비스 매시에 도착한다.
- Ingress는 Pilot에 의해서 구성된 하나 이상의 Envoy 프록시의 은행이다.
- Pilot은 쿠버네티스 서비스 엔드포인트를 사용해서 Ingress proxy를 구성하면 이 Ingress 프록시는 백엔드를 인식하게 된다.
- Ingress는 패킷을 수신하면 패킷을 보낼 위치를 인식한다.
- health check와 로드밸런싱을 수행하고 패킷과 할당량 및 트래픽 밸런싱과 같은 메트릭을 기반하여 메시지를 보내는 결정을 내린다.
- Service A: Ingress가 첫 파드에 라우트하면 컨테이너를 대신해서 Service A의 프록시에 도달한다.
- 사이드카가 같은 파드에 존재하기 떄문에 같은 네트워크 네임스페이스를 공유하고 같은 노드에 위치한다.
- 두 컨테이너는 같은 IP 주소와 같은 IP table rule을 공유하게되어, 프록시는 완전한 파드 컨트롤이 가능해진다. 여기서 파드에 전송되는 모든 트래픽을 처리하게 된다.
- Envoy 프록시는 Citadel과 상호작용하여 만약 어떤 정책이 강화되는지를 이해한다. 트래픽을 암호화 해야하는지, 백엔드 파드와 TLS를 맺어야하는지 확인한다.
- Service B: Service A가 암호화된 패킷을 Service B에 보내면, 패킷의 발신자의 신원증명과 함께 TLS 핸드쉐이크를 수행한다. 신뢰관계가 맺어지면 패킷을 수신하고 Service B 컨테이너로 향한다. 이후 Egress로 이어진다.
- Egress: 모든 트래픽은 메시를 통해서 나오며, Egress리소스를 사용한다.
- Egress 레이어는 어떤 트래픽이 메시를 통해 나오는지를 정의하고 Pliot을 사용하며, Ingress 레이어의 구성과 비슷하다.
- Egress 리소스를 사용함으로써 제한된 아웃바운드 트래픽의 정책을 쓸 수 있고, 요구된 서비스만이 패킷을 매쉬 밖으로 보내는 것이 가능해진다.