istio 개념 정리 (1) - Service Mesh와 istio

Istio

 
Istio : Service Mesh의 한 종류.
 

Service Mesh

• cluster-based MicroService 프로젝트가 많아지면서, k8s와 같은 Orchestration tool만으로는 기능 요구사항을 맞추기 어려워지며 대두된 서비스.
• 일종의 Extra Layer of Software that you deploy alongside k8s.
• Multiple Software Components가 서로 통신하고 연결되어 있는 Distributed Architecture라면 사용할 수 있음. 반드시 K8s 환경에서만 쓰이는 게 아님.

 

예시를 위한 도식.

• 각 Microservice에는 pod가 있고, 보통 하나의 pod에는 하나의 Container가 있다.
• 각각의 microservice는 Service discovery (by k8s) 기능을 통해 서로 통신할 수 있다.
  • k8s에서 제공하지 않는 기능 중 하나가 pod와 다른 pod간 interconnection 정보.
  • 예컨대 한쪽 pod에서 장애가 발생할 경우, 해당 pod로 넘어간 request는 어떤 상태가 되는지?
    • 심지어 pod 개수가 많으면, 어디서 장애가 났고 어디가 영향을 받는지 파악하기가 어려워진다.
• 즉 K8s만으로는 Visibility / Control over the connections btwn the containers

 

따라서

• 모든 microservice의 pod에는 underneath layer인 Service mesh가 존재하고
• pod간 통신은 전부 이 service mesh를 통해 이루어진다.
  • 원래는 k8s Object인 service가 pod 간 통신 역할을 담당해서, pod과 pod의 일대일 통신이 가능함.
  • service mesh로 요청을 보낼 때, mesh 내부에서 routing 로직을 추가할 수 있음. (before the call / after the call)
• 대표 사용예시로는 Telemetry (gathering Metrics) 가 있음.
  • k8s에서 prometheus 등으로 cpu, memory 등의 리소스 확인이 가능한 것과 비슷하지만
  • service mesh로는 개별 network request에 관련된 metrics를 수집할 수 있음
• container 간 여러 request의 tracing 기능도 수행할 수 있음. request chain 이력을 추적할 수 있기 때문.
• Traffic Management 가능.

 

Service Mesh가 위와 같은 동작을 수행하는 방법 (SW layer의 Implementation) 은 여러 가지가 있음.
 
Istio의 경우 pod 내부에 proxy Container를 추가한다.

• pod 내의 container는 요청을 proxy로 전달한다. (re-routed)
  • proxy 내부에 ip table이 있음. container는 다른 pod에 직접 연결했다고 생각하지만, 실제로는 proxy로 전달됨
  • proxy 내부에서 service mesh에 관련된 로직이 동작한다.
• proxy는 실제로 연결해야 하는 다른 pod의 proxy로 요청을 전달한다.
• target pod의 proxy의 service mesh 로직을 통과한 뒤, target Container로 요청이 전달된다.

즉 개념적으로는 Service mesh라는 별도의 SW layer가 있지만, istio에서는 pod 내부에 proxy container를 추가하는 식으로 구현되어 있음.
 

istio의 proxy에는 Service mesh에서 동작해야 하는 logic을 추가할 수 있다. 이 로직이 proxy에서 전부 실행되는 건 아니고, istio-system Namespace에 있는 pod에서 처리된다.

• 예전에는 pilot / Citadel / Galley 라는 이름으로 된 pods가 각각 담당하는 로직이 있었음 (1.5 이전)
• 1.5 이후 버전은 istiod (istio Daemon) 라는 single pod에서 처리함.
  • 대표적인 기능: Telemetry (Gathering Statistics)
    • proxy에서 request를 전송하기 전에 timestamp를 추가한다던가 (record the request)
    • target container에서 보낸 응답을 리턴하기 전에 timestamp를 추가한다던가 (record the response)
    • 이렇게 저장된 records를 기록해두고, 조건을 걸고 데이터 조회할 수 있음

 

• istio Docs에서 자주 등장하는 Data Plane -> Pod에 추가되어 있는 Proxy들을 의미함.
• Control Plance -> istio-system Namespace에서 동작하는 istioD pod 외 몇 가지 Component를 포함한다.
  • Kiali UI - for Visualization

istio를 사용하기 위해 원래의 Container 설정을 변경할 필요는 없다. 비단 istio뿐만 아니라 모든 Service Mesh의 공통점임.

• Service Mesh를 사용하는 건 일종의 Switch On / Off 개념. 원래의 container functionality에 변경사항 없음
• 단, istio에서 tracing 기능을 사용하려면 requirement가 있음. tracing 설명할 때 자세히 다룸.

Envoy in istio

 

istio에서 Service mesh를 구현하는 방법: Pod 내부에 proxy Component를 추가한다.

• proxy Component는 k8s의 SideCar Container 로 구현되어 있음.
• 즉 istio proxy == sidecar 라고 생각해도 됨

 
sidecar container를 istio가 직접 구현한 건 아니고, 보통 3rd party component를 사용함.

• istio는 Envoy라는 오픈소스를 사용한다.
• Envoy : Proxy for cluster-based application. (https://envoyproxy.io)
  • Envoy에서 제공하는 기능 자체가 istio에서도 거의 핵심
  • 'istio manages envoy' 라고 생각하자.

따라서 Envoy / SideCar / Proxy 전부 istio 내에서는 같은 의미라고 보면 된다. 어떤 단어를 쓰건 지칭하는 건 똑같음
 

'그럼 istio 대신 envoy만 써도 되는 거 아님?' 싶을 수도 있는데, 불가능한 건 아님. 하지만..

• envoy 자체는 상대적으로 더 low-level tool이라서 configuration이 더 복잡함.
• envoy는 k8s뿐만 아니라 다른 종류의 cluster tool에서도 적용 가능한 SW.
  • 따라서 Cluster-based-solution과는 Independenct Terminology가 대부분임. k8s에 익숙한 사람들에게는 생소한 용어와 개념이 많음.
  • 직접 configuration 하려면 러닝커브가 꽤 있다는 뜻.

공식문서에서 제공하는 minimal bootstrap file 을 확인해보면 됨.

• nginx나 apache configuration을 자주 다뤄보지 않았다면 생소함.
• 특히 k8s 관련 용어는 없다시피하다. k8s Engineer가 envoy 설정을 직접 '제대로' 해내기는 쉽지 않음

 

따라서 Envoy Configuration을 K8s-based CRDs 로 사용할 수 있게 만드는 것이 Istio. 조금 거칠게 비유하면 Abstraction Layer of Envoy 인 셈.