Istio 서비스메시에 대해서 알아보자!

Istio?

Istio는 오픈소스 서비스 메쉬로, 분리된 어플리케이션을 투명하게 계층화할 수 있다. 현재 쿠버네티스의 네트워크 구성에 가장 많이 사용되고 있는 오픈소스기도 하다. Istio는 쿠버네티스 네트워크의 복잡성을 줄이고, 분산 네트워크 환경에서 여러 어플리케이션들의 연결을 쉽게 설정할 수 있게 지원한다. Istio를 대표하는 3가지의 컨셉은 다음과 같다.

Traffic management

• Sidecar 패턴(Pod 내에 Envoy proxy가 sidecar로 존재)을 이용하여 application 코드의 변경없이 작업자가 VirtualService, DestinationRule이라는 Custom Resource로 손쉽게 원하는 서비스로 트래픽 전송이 가능
• k8s로 Canary 배포를 하기 위해선 직접 replica 개수를 조정해야 했으나, Istio VirtualService의 Weight와 subset을 통해 이 과정이 단순해짐
• Envoy로 Header와 Path의 L7 라우팅이 매우 간단해짐

Observability

• log, metric, trace를 Istio를 통해 모두 수집 가능 → Observability
• Envoy를 통해 Observability 구현

Security capabilities

• MSA 구조로 인한 Man in middle 공격과 manifest 노출의 리스크를 mTLS로 통신 레이어 보안 향상시킴
• Policy를 활용하여 서비스간의 통신의 권한을 코드화시켜 관리가 가능
• 어플리케이션 코드의 변경없이도 클러스터의 보안을 강화시킴

Istio를 사용하면 서비스의 코드를 변경하지않고 로드밸런싱과 service to service 인증 및 모니터링을 할 수 있다. 여기서 Istio의 컨트롤타워인 control plane은 아래와 같은 기능들을 가진다.

• TLS 암호화와 함께 서비스간 통신의 보안과 인증
• HTTP, gRPC, Websocket, TCP의 로드밸런싱
• 다양한 라우팅 룰과 재시도, 결함 제거 및 장애 극복과 같은 트래픽 동작을 세부적으로 제어
• 플러그형 정책 계층과 액세스 제어와 속도 제한 등 을 지원하는 API
• ingress, egress를 포함한 클러스터 내의 자동 메트릭, 로그, 추적 기능

control plane은 kubernetes 상에서 작동되고, 다른 클러스터로의 확장을 위해 여러 어플리케이션을 추가할 수 있다. control plane은 kubernetes namespace 'istio-system'에 속한 파드들을 의미하기도 한다.

---

Data plane, Control plane, Envoy

Data Plane

Data Plane은 서비스간의 통신으로 실제 트래픽을 받아 처리한다. 서비스의 사이드카 형태로 구성된 프록시들을 말하며 Envoy가 사이드카 프록시로 활용된다. Data plane은 Control plane에 의해서 컨트롤된다.

Control Plane

Data Plane을 관리하는 컨트롤타워다. kubernetes cluster에서 istio-system 네임스페이스로 구성된다.

Envoy

Istio 외에도 Consule, App mesh, Kong Mesh 등의 서비스메쉬가 Envoy로 구현되어 있다. Envoy는 경량화된 L7 Proxy로 HTTP, TCP, gRPC 등의 프로토콜을 지원한다. Retry, Circuit Breaker, Timeout 등 다양한 기능을 수행할 수 있다.

---

How Components Interact With Each Other

 

위 이미지에서 왼편에 APIs Content를 시작으로 Ingress를 거쳐 두 개의 마이크로 서비스가 있고 오른편에 Egress로 이어진다. Service A와 Service B는 컨테이너에서 동작하는 마이크로서비스고 그들은 Envoy Proxy로 통신하는 것을 볼 수 있다.(Service A는 서비스의 프론트엔드고 Service B는 백엔드)

Istio는 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 리소스를 사용함으로써 제한된 아웃바운드 트래픽의 정책을 쓸 수 있고, 요구된 서비스만이 패킷을 매쉬 밖으로 보내는 것이 가능해진다.