Istio가 몇가지 서비스 구성적인 문제나 성능 문제를 가지고는 있지만 CNCF 서비스 메시 항목 중에서 가장 유명하고 가장 잘 쓰이는 서비스 메시가 아닐까 한다(실제 클라우드 플랫폼들도 많이들 기본 지원하고 있기도 하고).
그러나 나름대로 자체 제공되는 항목들이나 Envoy와 연계되어 제공하는 기능들이 많기 때문에 ,
이번 포스팅에서는 먼저 Istio 서비스 메시가 어떤 구성으로 되어 있는지 알아보고자 한다.
Istio를 설치하게되면 기본적으로 Pilot, Citadel, Galley를 Control Plane에 두고 있다. 이 설정들을 반영해 실제 트래픽처리는 Istio proxy 에서 이루어지게 된다.
따라서 중요한 메인 설정들은 Pilot, Citadel, Galley에서 이루어지고, 이 세 컴포넌트가 Istio 동작의 핵심이다. 기타 컴포넌트들(istio ingress-gateway나 mixor, injector 같은 것들)은 설정에 따라 있을 수도 없고 없을 수도 있다.
이 세 컴포넌트들이 배포되는 형태는 버전에 따라 다른데, v1.5 이후 부터는 istiod라는 컴포넌트로 묶여서 배포되고, v1.4이전에는 다 따로따로 배포된다. 사실 세가지 모두 거의 필수적이기 때문에 이쪽이 올바를지도 모르겠다.
위의 아키텍쳐를 참고했을 때, Service 들에는 각각의 proxy가 생성된다. ( injection을 한 경우 ) 주의할 것은 proxy가 생성된다고 가정했을 때 proxy가 없을 때와 비교해서 무조건 hop이 추가된다는 부분이다.
따라서 네트워크 성능이 중요한 경우 proxy injection을 하지않는 것도 고려해볼 필요가 있다.
주요 컴포넌트 별 기능
Pilot: 트래픽 관련 설정을 proxy에 반영하는 역할을 한다. 메인 역할은 envoy 서비스 디스커버리나 트래픽 관련 매니지먼트 처리(예: istio 내 라우팅 관련 설정이나, circuit breaker) 같은 것들이 이다. 예를 들어 Istio Virtual Service 같은 것이 생성되면 Gateway에 머지시킨다. istio 로 생성된 트래픽 관련 오브젝트들이 실제로 매칭되는 역할을 한다고 볼 수 있는 것이다.
Galley: 다른 컴포넌트 (Pilot이나 Mixor)에 쿠버네티스 상의 사용자 설정들을 전달하는 역할들을 한다. 실제로 1.5 이전 버전에서 galley없이 pilot을 배포하려고 시도하면 pilot도 살지 못하고 죽는 것을 확인할 수 있다.
Citadel: 서비스 id 기반으로 서비스-서비스나 엔드유저 인증 처리를 담당한다.
위의 세 가지(1.5버전 이후 부터는 istiod 하나)가 istio를 구성할때 빠질 수 없는 기본 구성이고, 그 외 기타 컴포넌트들은 추가적으로 구성되어 도움을 주는 기능들을 한다.
'Cloud > Kubernetes' 카테고리의 다른 글
Admission Control (0) | 2021.07.27 |
---|---|
Kubernetes NetworkPolicy 란? (0) | 2020.12.26 |
Pod 라우팅과 ExternalTrafficPolicy 옵션 (3) | 2020.11.23 |