Kubernetes platform에서 일부 서비스가 외부 네트워크로 노출 되어야 할 때 어떤 방법을 사용하는게 좋을까?
Kubernetes에서는 CluterIp, NodePort, LoadBalencer, Ingress, Istio gateway 등 다양한 수단을 제공한다. 이 때 service mesh에 적합한 수단은 무엇인지 알아보고자 한다.
그 전에 고민의 배경인 service mesh에 대해 알아보자.
Service Mesh 란?
•
MSA 도입 시 발생하는 문제점
◦
모놀리틱 아키텍처에 비해 서비스가 분산되어 있기 때문에 서비스 간 통신에 복잡성이 증가한다.
◦
데이터에 대한 트랜잭션을 유지하기 어렵다.
◦
장애 추적 및 모니터링에 대한 어려움이 있다.
이러한 문제를 해결하기 위해 Service Mesh가 등장하게 되었다.
Service Mesh는 Application Layer에서 이런 부분을 처리하는 것이 아닌 Infrastructure Layer에서 처리하는 방법이다.
따라서 MSA의 각 서비스는 핵심 비즈니스 로직에만 집중할 수 있고 MSA를 도입함으로써 발생하는 문제점 (내결함성, 보안, 모니터링 ..)을 Infrastructure Layer에서 처리하여 해결한다.
Service Mesh는 일반적으로 Sidecar Pattern으로 구성된다.
Sidecar Pattern 이란?
애플리케이션의 비즈니스 로직 이외에 별도로 필요한 로직을 수행하는 프로세스를 함께 배포하는 방식을 뜻한다.
쿠버네티스에서는 애플리케이션 컨테이너 + 사이드카 컨테이너를 하나의 Pod로 묶어 배포하는 방식을 사용하게 된다.
Service Mesh에서 사이드카는 서비스 간 모든 트래픽을 프록시하며 Service Discovery, Health Check, Routing, Load Balancing, Security, Observability 기능을 수행한다.
Service Mesh 구성을 돕기 위한 도구들은 여러가지가 있지만 이번에는 Istio와 Linkerd에 대해서 다루고자 한다.
Istio란?
마이크로 서비스 애플리케이션의 다양한 요구 사항을 충족시킬 수 있는 서비스 메시 플랫폼으로 서비스 메시에 대한 행동 통찰력과 운영 제어를 제공한다.
로드 밸런싱, 보안, 관찰성과 같은 부분들을 애플리케이션 코드의 변경 없이 Infrastructure Layer에서 수행할 수 있다.
Istio Architecture
•
Data Plane
◦
Sidecar로 배포된 Proxy들로 구성되어 있다.
◦
이 Proxy는 서비스 간의 모든 네트워크 통신을 담당하게 되며 Istio에서는 Envoy Proxy를 사용한다.
•
Control Plane
◦
Control Plane은 Proxy 간의 네트워크를 구성/변경/관리/보안/모니터링 등의 관리 기능을 담당한다.
◦
Proxy는 연결을 위한 다른 Proxy에 대해 알지 못하고 Control Plane을 통해 어디로 보내질지 결정된다.
istiod
Istio는 다음과 같은 기능을 제공한다.
Traffic Management
•
파일럿과 사이드카 프록시인 Envoy를 통해 서비스 간 발생하는 트래픽을 제어하고 관리한다.
•
믹서는 파일럿을 이용하여 서비스 버전별 트래픽 양을 분산하거나 요청 콘텐츠에 따라 특정 버전별로 트래픽을 분할하여 전송할 수 있다.
•
파일럿을 통해 서비스를 디스커버리하고 로드밸런싱한다.
•
서비스 상태를 주기적으로 체크하여 비정상적인 인스턴스는 자동으로 제거한다.
•
서비스 간 호출 안전성을 위해 호출 재시도 횟수를 통제하거나 응답 시간에 따른 에러 처리 등 통신 상태도 관리할 수 있다.
•
Circuit Breaker, Timeout과 같은 설정을 할 수 있으며, A/B Test 및 카나리 배포와 같은 배포 전략을 달성할 수 있다.
Security
•
이스티오는 모든 서비스의 트래픽이 Envoy를 통해 이뤄지며 TLS(Transport Layer Security)를 이용하여 서비스 간 통신이 암호화된다.
•
서비스 간 인증, 서비스와 엔드 유저(클라이언트) 간 인증이 가능하고 역할 기반 접근 제어(RBAC, Role Based Authentication Control) 기능으로 서비스 접근 권한을 통제한다.
•
인프라 레이어에서 보안 정책을 일관되게 적용할 수 있다.
Observability
•
믹서를 통해 서비스 간 호출 관계, 서비스 응답시간, 처리량 등의 네트워크 트래픽 지표를 수집하고 모니터링한다.
•
모든 서비스는 호출될 때 앞단의 Envoy를 거치기 때문에 각 서비스의 호출 시 또는 주기적으로 믹서에 정보를 전달하고 이를 로깅한다.
•
믹서는 쿠버네티스에서 많이 사용하는 Heapster, Prometheus, StackDriver, Datadog 등의 모니터링 도구들과 연계하여 시각화할 수 있으며 Grafana를 통해 각 서비스의 응답시간, 처리량 등을 확인할 수 있다. 또한 Jaeger를 이용하면 분산 트랜잭션 구간별로 응답 시간을 모니터링할 수도 있다.
•
네트워크 간에 발생하는 호출을 추적하거나 모니터링, 로깅을 통해 Service Mesh 네트워크에 대한 상태를 파악할 수 있다.
Envoy란?
Out of Process Architecture
Envoy는 L7 프록시로 어플리케이션 서버와 함께 실행되도록 설계된 self-container 프로세스이다.
각 Envoy는 투명한 네트워크를 형성하고 각 애플리케이션은 Localhost과 메세지를 주고받는다. (이 때 어플리케이션은 네트워크 토폴로지에 대해 알지 못한 상태)
Out of Process 아키텍처는 다음과 같은 장점을 가진다.
•
애플리케이션에 사용된 언어에 상관없이 동작한다.
•
빠르게 배포되고 업그레이드 될 수 있다.
Layer Architecture
작동 방식
•
Downstream
◦
Envoy에게 요청을 보내는 호스트
•
Listener
◦
Downstream에게 요청을 받는 부분.
◦
IP/Port 바인딩을 담당하고 새로운 TCP/UDP 연결을 수락한다.
◦
Envoy는 하나 이상의 Listener을 노출하여 Downstream과 연결된다.
•
Filter
◦
수신된 메시지에 대해 라우팅, 프로토콜 변환, 통계 생성과 같은 다양한 작업을 수행하는 부분.
◦
요청을 처리하기 위한 일련의 파이프 라인이다.
•
Upstream
◦
Envoy가 요청을 보내는 호스트
•
Cluster
◦
Upstream 호스트의 그룹.
◦
Envoy가 요청을 리다이렉트 해줄 백 단의 서비스 엔드포인트 집합
Kiali
•
웹 대시보드 형태로 Istio 정책을 제어하고 Istio 동작을 확인할 수 있는 기능을 지원한다.
Linkerd란?
다른 서비스 메시와 마찬가지로 분산 애플리케이션에서 코드를 변경할 필요 없이 런타임 디버깅, 모니터링, 안정성 및 보안을 제공한다.
Linkerd Architecture
•
CLI : 클러스터 외부(예: 로컬 시스템)에서 실행되며 Linkerd와 상호 작용하는 데 사용된다.
•
Control Plane
◦
destination
▪
서비스 검색 정보를 가져오는 데 사용된다.(즉, 특정 요청을 보낼 위치와 다른 쪽 끝에서 예상되는 TLS ID).
▪
어떤 유형의 요청이 허용되는지에 대한 정책 정보를 가져온다.
▪
경로별 메트릭, 재시도 및 시간 초과를 알리는 데 사용되는 서비스 프로필 정보를 가져온다.
◦
identity
▪
◦
proxy-injector
▪
Pod가 생성될 때마다 웹훅 요청을 수신하는 Kubernetes 승인 컨트롤러
▪
어노테이션을 찾고 linkerd.io/inject: enabled포드 사양을 변경하여 initContainer프록시 자체를 포함하는 사이드카와 사이드카를 모두 추가하는 승인 컨트롤러
•
Data Plane
특징 | 이스티오 | 링커드 |
설치 용이성 | Istio는 최근 이 영역에서 개선되어 더 쉽게 시도할 수 있습니다. | 즉시 사용 가능한 구성으로 인해 비교적 쉽게 적응할 수 있음 |
플랫폼 | 쿠버네티스, VM | 쿠버네티스 |
지원되는 프로토콜 | gRPC, HTTP/2, HTTP/1.x, Websockets 및 모든 TCP 트래픽 | gRPC, HTTP/2, HTTP/1.x, Websockets 및 모든 TCP 트래픽 |
인그레스 컨트롤러 | Envoy, Istio 게이트웨이 자체 | 모두 – Linkerd는 자체적으로 수신 기능을 제공하지 않습니다. |
멀티 클러스터 메시 및 확장 지원 | 다양한 구성 옵션과 Kubernetes 클러스터 외부의 메시 확장으로 안정적인 릴리스의 멀티 클러스터 배포 지원 | 다중 클러스터 배포가 안정적입니다. |
서비스 메시 인터페이스(SMI) 호환성 | 타사 CRD를 통해 | 트래픽 액세스 제어가 아닌 트래픽 분할 및 메트릭에 대한 기본 |
모니터링 기능 | 풍부한 기능 | 풍부한 기능 |
추적 지원 | 예거, 집킨 | OpenCensus를 지원하는 모든 백엔드 |
라우팅 기능 | 다양한 로드 밸런싱 알고리즘(Round-Robin, Random Least Connection), 백분율 기반 트래픽 분할 지원, 헤더 및 경로 기반 트래픽 분할 지원 | EWMA(지수 가중 이동 평균) 로드 밸런싱 알고리즘 지원, SNI를 통한 백분율 기반 트래픽 분할 지원 |
회복력 | 회로 차단, 재시도 및 시간 초과, 결함 주입, 지연 주입 | 재시도 및 시간 초과, 오류 주입, 지연 주입 불가능, 회로 차단 지원은 아직 v2에 없습니다. 문제 #2846 참조 |
보안 | 모든 프로토콜에 대한 mTLS 지원, 외부 CA 인증서/키 가능, 권한 부여 규칙 지원. | |
성능 | 최근 릴리스를 통해 Istio는 리소스 풋프린트와 대기 시간이 개선되어 개선되고 있습니다. | |
기업 지원 | AspenMesh, solo.io 및 Tetrate와 같은 다양한 공급업체에서 사용 가능 | Linkerd의 OSS 버전을 개발한 Buoyant가 제공하는 완전한 엔터프라이즈급 엔지니어링, 지원 및 교육 |
