[Service Mesh] Kubernetes 환경에서 Istio를 사용한 서비스 메시(1) - Istio란?

간만의 포스팅입니다.

한동안 PoC/구축 프로젝트 등으로 정신이 없다가.. 아직 끝나지 않았지만 틈이 나서 포스팅으로 정리를 해 봅니다.

이번에 진행중인 PoC에서 마이크로서비스에 대한 요건이 있어서 대안으로 Istio를 준비하였고 이 내용을 공유할 예정입니다.

Overview

Istio는 마이크로서비스를 서로 연결, 관리, 그리고 보안기능을 제공하는 오픈 플랫폼입니다. Istio는 로드밸런싱, 서비스-서비스 간 인증, 모니터링 등을 어떤 코드의 변경 없이 서비스들 간의 네트워크를 쉽게 만들어 줍니다. Istio는 side-car proxy  방식으로 적용되며 Istio control plane의 기능을 사용하여 마이크로서비스들 간의 네트워크 통신을 중계합니다.

Istio는 현재 Kubernetes 환경을 지원합니다. 또한 개개의 VM 상의 Consul, 또는 Eureka 에 등록된 서비스 역시 지원합니다.

Why Use Istio?

Istio는 "모놀리틱(monolithic - 덩어리)" 애플리케이션을 분산된 마이크로서비스 아키텍처로 변경할 때 개발자와 운영자가 당면하게 되는 수많은 문제를 다룹니다. "서비스 메시(Service Mesh)" 라는 용어는 마이크로서비스의 네트워크를 설명하며 이들을 구성하는 애플리케이션과 그들간의 상호 동작을 말합니다. 서비스 메시는 크기나 복잡도가 증가하고 이는 이해하고 관리하기 점점 더 어려워지고 있습니다. 서비스 메시는 서비스탐색(Discovery), 로드밸런싱Load Balancing), 장애복구(Failure Recovery), 메트릭, 그리고 모니터링과 같은 기능을 필요로 하며, 때로는 A/B Testing, Canary Deployment, Rate Limiting, Access Control, 그리고 End-To-End authentication 과 같은 보다 복잡한 기능을 필요로 합니다.

Istio는 이렇듯 마이크로서비스 아키텍처 구성과 관리에 필요한 전반적인 기능을 제공합니다.

• Traffic Management - 트래픽 흐름과 서비스들 간의 API 호출을 제어하며 보다 신뢰성있는 서비스간 호출을 보장합니다. 또한 불리한 환경에서 네트워크를 보다 견고하게 합니다.
• Service Identity and Security - 서비스들 간 자격 증명을 제공하며 다양한 신뢰도의 네트워크 상에서 서비스 트래픽을 보호하는 기능을 제공합니다.
• Policy Enforcement - 서비스들 간 상호 동작에 대한 조직적 정책을 제공합니다. 애플리케이션 코드 변경 없이 메시를 설정함으로써 정책 변경이 가능합니다.
• Telemetry - 서비스와 그들간의 트래픽 흐름에 따라 서비스 의존성 정보를 수집합니다. 이는 이슈를 빠르게 파악악할 수 있게 합니다.

이러한 기능들 외 추가적으로 다양한 배포 환경에맞춰 확장성을 고려하여 디자인되었습니다.

• Platform Support - Istio는 클라우드, On-Premise, Kubernetes, Mesos 등과 같이 다양한 환경에서 동작할 수 있도록 설계되었습니다. 초기 버전은 Kubernetes환경만을 지원하며 곧 다른 환경도 지원할 예정입니다.
• Integration and Customization - Policy Enforcement 컴포넌트는 다른 솔루션을 위한 ACL, logging, monitoring, quotas, auditing 등 다른 기능들에 확장 및 커스터마이징이 가능합니다.

이러한 기능들은 애플리케이션 코드, 하위 플랫폼, 그리고 정책들 간의 커플링을 줄여줍니다. 이는 서비스를 쉽게 구현할 수 있을 뿐만 아니라 관리자가 서로 다른 환경 또는 다른 정책으로 애플리케이션을 이전하는 것을 보다 간단하게 만들어 줍니다. 결과적으로 애플리케이션은 좀더 Portable 해집니다.

Architecture

Istio 서비스 메시는 논리적으로 data plane 과 control plane으로 분리됩니다.

• Data plane은 프록시(Envoy) 세트로 구성되어 있으며 사이드카 형태로 배포됩니다. 이는 마이크로서비스 간의 모든 네트워크 통신을 중계하고 제어하며 일반적인 목적의 정책과 telemetry hub(Mixer)에 따라 동작합니다.
• Control plane은 프록시(Envoy)가 트래픽을 라우팅할 수 있도록 관리하고 설정하는 역할을 담당합니다. 또한 Mixer가 정책을 할당하고 telmetry를 수집하도록 합니다.

아래 다이어그램은 각 plane이 어떻게 구성되어 있는지를 보여줍니다.

Envoy

Istio는 C++로 개발된 고성능 프록시인 Envoy 프록시 확장 버전을 사용합니다. Envoy는 서비스 메시를 구성하는 모든 서비스의 inbound와 outbound 트래픽을  중계합니다. Istio는 Envoy가 가지고 있는 동적 서비스 탐색(dynamic service discovery), 로드밸런싱, TLS termination, HTTP/2 & gRPC 프록싱, circuit breakers, health check, %-기반 트래픽 분할기능을 가지고 수행하는 staged rollout, fault injection, 그리고 다양한 메트릭 과 같은 다양한 기능을 그대로 사용합니다.

Envoy는 동일한 Kubernetes pod에 관련 서비스로 사이드카 방식으로 배포됩니다. 이는 Istio가 다양한 트래픽 동작에 관련된 신호를 attribute로 추출해 낼 수 있도록 하며 이러한 신호를 가지고 Mixer는 정책 결정에 사용합니다. 그리고 전체 메시의 동작에 관한 정보를 제공하는 모니터링 시스템으로 전달됩니다. 사이드카 프록시 모델은 이미 존재하는 deployment를 새로 코딩하거나 재설계할 필요가 없습니다.

Mixer

Mixer는 플랫폼 독립적인 컴포넌트이며 서비스 메시에 걸쳐 접근 제어와 정책을 적용하고 Envoy 프록시와 다른 서비스들로 부터 telemetry 데이터를 수집하는 기능을 담당합니다. 프록시는 요청 단계의 attribute를 추출하고 이는 평가를 위해 Mixer로 보내집니다. Mixer Configuration 장에서 attribute 추출 및 정책 평가에 대한 내용을 찾을 수 있습니다. Mixer는 유연한 플러그인 모델을 제공하며 이는 다양한 호스트 환경과 백엔드 인프라와 연계할 수 있도록 하며, Envoy 프록시와 Istio가 관리하는 서비스를 보다 추상화합니다.

Pilot

Pilot은 Envoy 사이드카를 위한 서비스 검색(discovery), A/B test, Canary Deployment와 같은 intelligent routing을 위한 트래픽 관리 기능을 제공합니다. 그리고 timeouts, retries, circuit breaker와 같은 resiliency도 함께 제공합니다. 이는 트래픽 관련 행위를 제어하는 고레벨의 라우팅 룰을 Envoy에 특화된 설정으로 변환하고 런타임에 사이드카로 전달합니다. Pilot은 플랫폼에 특화된 서비스 검색 메커니즘을 추상화하고 Envoy data plane API와 일치하는 모든 사이드카가 사용할 수 있는 표준 포맷으로 통합하는 역할을 합니다. 이런 느슨한 결합은 Istio가 multiple 환경(Kubernetes, Consul/Nomad) 에서 동작하도록 합니다. 

Citadel

Citadel은 강력한 서비스-to-서비스, 그리고 end-user 인증을 내장된 자격증명과 크레덴셜 관리를 통해 제공합니다. 이는 서비스 메시에서 암호화되지 않은 트래픽을 업그레이드하는데 사용되며, 운영자가 네트워크 제어 보다는 서비스 자격증명에 기반한 정책을 적용하도록 합니다. 0.5 release  부터, Istio는 role-based access control을 제공하여 서비스에 접근하는 사용자를 제어하도록 합니다.