[Service Mesh] 3. Istio?

Service Mesh 알아보기

1. [Service Mesh] 1. Service Mesh란?
2. [Service Mehs] 2. Envoy Proxy
3. [Service Mesh] 3. Istio?
4. [Service Mesh] 4. Istio Traffic Management (1) - Virtual Service & Destination Rule
5. [Service Mesh] 5. Istio Traffic Managerment (2) - Gateway & Service Entry
6. [Service Mesh] 6. Service Monitoring in Istio
7. [Service Mesh] 7. Logging

---

이번 글에서는 Istio에 대해서 알아보도록 하겠습니다.

Istio?

Istio는 마이크로 서비스 애플리케이션의 다양한 요구 사항을 충족시킬 수 있는 서비스 메시 플랫폼으로 서비스 메시에 대한 행동 통찰력과 운영 제어를 제공합니다. Istio는 로드 밸런싱, 보안, 관찰성과 같은 부분들을 애플리케이션 코드의 변경없이 인프라 레이어에서 수행할 수 있게 됩니다. 

Istio는 다음과 같은 기능을 제공합니다.

• Traffic Management
  Istio는 간단한 설정을 통해 서비스 간 발생하는 트래픽을 제어할 수 있습니다. 그리고 Circuit Breaker, Timeout과 같은 설정을 할 수 있으며, A/B Test 및 카나리 배포와 같은 배포 전략을 달성할 수 있습니다.
• Security
  Istio를 사용하면 인프라 레이어에서 보안 정책을 일관되게 적용할 수 있습니다.
• Observability
  네트워크 간에 발생하는 호출을 추적하거나 모니터링, 로깅을 통해 Service Mesh 네트워크에 대한 상태를 파악할 수 있습니다.

 

Istio Architecture

Istio Architecture

출처 : Istio Document - Architecture

Istio는 논리적으로 Data Plane과 Control Plane으로 나누어집니다.

• Data Plane
  Data Plane은 Sidecar로 배포된 Proxy들로 구성되어 있습니다. 이 Proxy는 서비스 간의 모든 네트워크 통신을 담당하게 되며 Istio에서는 Envoy Proxy를 사용합니다.
• Control Plane
  Control Plane은 Proxy의 트래픽을 라우팅 하기 위한 설정들을 관리합니다. Proxy는 연결을 위한 다른 Proxy에 대해 알지 못하고 Control Plane을 통해 어디로 보내질지 결정됩니다.

Control Plane은 1.5 버전 이전까지는 Mixer, Pilot, Citadel, Galley이라는 모듈로 구성되어 있었지만, 1.5 버전 이후에는 Istiod라는 모듈로 통합되어 제공됩니다. 먼저 1.5 버전 이전까지 존재했던 모듈에 대해 알아보겠습니다.

• Mixer
  Mixer는 서비스의 Telemetry를 수집하는 메커니즘을 제공하며 권한 부여 정책을 시행합니다. 
• Pilot
  Proxy에 대해 라우팅을 수행하고 Service Discovery,Timeout, Circuit Breaker 등의 기능을 제공합니다. 
• Citadel
  Istio 내에 요청을 암호화하며, 서비스에 관한 RBAC를 제공합니다.
• Galley
  사용자로부터 Istio에 대한 설정을 저장 및 검증하는 역할을 담당합니다.

---

Mixer

물론 1.5 버전 이후에 Mixer가 Deprecated 되었지만, Istio에서 Mixer를 통해 Telemetry와 같은 기능을 제공할 때 어떻게 인프라 백엔드에 종속적이지 않게 되는지에 대해 알아보는 것이 도움이 될 것 같아 이 부분을 좀 더 살펴보도록 하겠습니다.

서비스가 파일 시스템에 로그를 쓰게 되는 상황을 예시로 들어보겠습니다. 컨테이너는 임시적이므로 컨테이너가 종료됨에 따라 파일시스템에 기록한 로그가 손실 될 수 있습니다. 이를 위해 외부 볼륨을 마운트 하거나, 클라우드 로깅 시스템에 로그를 보냄으로 이러한 문제를 해결할 수 있습니다. 후자의 경우, 만약 새로운 로그 수집기를 도입하려고 한다면 서비스 레이어에서 로그 전송을 위한 부분을 추가해야 합니다. 이는 서비스의 핵심 비즈니스 로직이 아닌 로깅을 위한 부분이므로 서비스 입장에서는 불필요한 관심사가 생기게 됩니다.

이런 부분을 Istio를 통해 인프라 레이어에서 처리하고, 인프라 백엔드와 상호작용을 통해 서비스가 비즈니스 로직에 집중할 수 있도록 만들 수 있습니다. 이 때, Istio와 인프라 백엔드와의 통신을 위해 추상화 된 부분이 Mixer입니다.

Adapter

하지만, Mixer가 특정 인프라 백엔드에 종속적이게 된다면 확장성 측면에서 올바르지 않은 구성이 됩니다. 인프라 백엔드가 변경될 때마다 istio도 영향을 받게 된다면 유지 보수 및 확장에 용이하지 않은 구조가 되어버립니다. 이를 해결하기 위해 Mixer는 Adapter라는 플러그인을 제공합니다.

Adapter는 Mixer가 인프라 백엔드와 상호작용하며 인프라 제공자로부터 추상화된 상태를 유지할 수 있도록 해줍니다. Adapter를 사용하면 Mixer는 사용 중인 인프라 백엔드와 상관없이 일관된 API를 노출할 수 있게됩니다. Adpater를 통해 추상화 된 Mixer의 구조는 다음과 같습니다.

Mixer & Adapter API

Attribute

Mixer는 다양한 인프라 백엔드를 선택하거나 보낼 데이터를 결정할 때 Attribute을 사용합니다. 

Attribute는 요청의 특성을 정의하는 데이터로 요청 경로, IP 주로, 응답 코드와 같은 데이터가 포함되어 있습니다. Mixer는 이런 Attribute를 수신하고 인프라 백엔드를 호출하게 됩니다. 하지만 여기서 궁금한 점은 어떤 인프라 백엔드가 활성화 되어 있고, 수신한 속성을 Adapter 속성에 매핑하는 방법과 같은 부분들에 대한 처리가 어떻게 동작하는지 입니다. 이런 부분들은 Mixer의 Configuration Model에 의해 처리됩니다.

Configuration Model

Configuration Model에서는 다음과 같은 3가지 종류에 대한 구성을 정의합니다.

• Instance
  Mixer가 수신한 Attribute를 어떻게 처리할 것인지에 대한 정의를 의미합니다. 이 데이터 템플릿을 Handler에게 넘겨주게 됩니다.
• Handler
  Instance의 데이터를 Adapter 입력에 어떻게 매핑할 것인지를 정의하는 부분입니다. 예를 들면 CloudWatch Adapter에 보내기 위해 Json Payload를 정의하는 부분이 됩니다.
• Rule
  Instance와 Handler를 매핑해 Adapter에 실제로 데이터를 전송하며, 매핑하기 원하는 조건(ex. TCP인 경우)을 정의할 수 있습니다.

Istio 1.5 버전 이상부터는 통합된 Control Plane인 Istiod를 통해 Pilot, Galley, Citadel의 역할을 수행하게 됩니다. 하지만 Mixer가 수행했던 역할은 성능상의 이슈로 Istiod가 아닌 Envoy Proxy 쪽에 WebAssembly Extension을 사용해서 제공됩니다. 자세한 내용은 Istio 문서에서 확인하실 수 있습니다. (Istio 1.7까지는 Mixer를 사용할 수는 있었지만, 1.8 부터는 완전히 삭제되었습니다.)

---

Install

Istio 공식 문서를 참고해 Istio와 함께 동작하는 Sample Application을 배포해보겠습니다. 아래의 모든 과정은 Minikube Cluster를 사용해서 배포를 진행하였습니다.

먼저 kubectl과 같이 Istio의 작업을 수행하기 위한 자체 CLI인 istioctl을 설치하도록 하겠습니다.

▶ curl -L https://istio.io/downloadIstio | sh -
▶ cd istio-1.8.1 && export PATH=$PWD/bin:$PATH

 

설치한 istioctl을 통해 Istio 컴포넌트를 설치하겠습니다. Istio의 설치 Profile은 이 글에서 확인할 수 있으며 저는 모든 컴포넌트를 설치하는 demo Profile을 사용하였습니다. 추가로 이후 배포할 Sample Application은 default namespace에 배포되며, 배포 시 자동으로 Envoy Proxy를 Sidecar로 배포하기 위해 namespace에 label을 추가해줬습니다.

▶ istioctl install --set profile=demo -y
Detected that your cluster does not support third party JWT authentication. Falling back to less secure first party JWT. See https://istio.io/v1.8/docs/ops/best-practices/security/#configure-third-party-service-account-tokens for details.
✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Egress gateways installed
✔ Installation complete

▶ kcl label namespace default istio-injection=enabled
namespace/default labeled

 

Sample Application을 설치하기 이전에 위의 명령어로 설치된 Istio CRD를 간단하게 살펴보겠습니다. 

Istio CustomResoureDefinition

• Virtual Service
  서비스가 다른 호스트를 호출할 때 사용되는 트래픽 규칙에 대한 정의를 의미합니다. 
• Destination Rule
  Load Balancing, Connection Pool Size와 같은 구성을 다루며, 라우팅이 끝났을 때 적용됩니다.
• Service Entry
  Istio의 Service Registry 수동으로 서비스에 대한 정의를 추가할 때 사용됩니다. 서비스의 주소, 프로토콜, 포트번호와 같은 구성이 포함됩니다.
• Gateway
  Service Mesh 입구에서 특정 포트로 외부 연결을 수신하고 내부에 트래픽을 라우팅하는 역할을 담당합니다.
• Envoy FIlter
  Envoy Proxy 관련 필터를 정의하여 사용할 수 있습니다.
• Policy
  보안, 요청 등과 같은 서비스에 관한 규칙을 정의하는 부분입니다.

다음으로 Sample Application을 설치합니다.

▶ kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml 
service/details created 
serviceaccount/bookinfo-details created 
deployment.apps/details-v1 created 
service/ratings created 
serviceaccount/bookinfo-ratings created 
deployment.apps/ratings-v1 created 
service/reviews created 
serviceaccount/bookinfo-reviews created 
deployment.apps/reviews-v1 created 
deployment.apps/reviews-v2 created 
deployment.apps/reviews-v3 created 
service/productpage created 
serviceaccount/bookinfo-productpage created 
deployment.apps/productpage-v1 created

 

설치가 완료되면 Cluster 외부에서 Sample Application에 접근하기 위해 Istio Ingress Gateway를 생성해야합니다. 

▶ kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml 
gateway.networking.istio.io/bookinfo-gateway created 
virtualservice.networking.istio.io/bookinfo created

 

Ingress Gateway가 설치되면 외부 접속을 위한 주소를 환경변수로 생성하여 접근할 수 있습니다.

▶ export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')

▶ export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')

▶ export INGRESS_HOST=$(minikube ip)

▶ export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT

 

Minikube Cluster에 외부에서 접근하기 위해서 다음 명령어를 실행해줍니다. (이 때 새로운 터미널에서 실행시켜야 합니다.)

▶ minikube tunnel

 

Istio 기본 컴포넌트 이외에도 몇가지의 telemetry 솔루션을 사용해 애플리케이션의 상태를 확인할 수 있습니다. Prometheus, Grafana, Kiali 등의 컴포넌트가 포함되어 있는 addon을 설치해보겠습니다.

▶ kubectl apply -f samples/addons
serviceaccount/grafana created
configmap/grafana created
service/grafana created
deployment.apps/grafana created
configmap/istio-grafana-dashboards created
configmap/istio-services-grafana-dashboards created
deployment.apps/jaeger created
service/tracing created
service/zipkin created
service/jaeger-collector created
customresourcedefinition.apiextensions.k8s.io/monitoringdashboards.monitoring.kiali.io created
serviceaccount/kiali created
configmap/kiali created
clusterrole.rbac.authorization.k8s.io/kiali-viewer created
clusterrole.rbac.authorization.k8s.io/kiali created
clusterrolebinding.rbac.authorization.k8s.io/kiali created
service/kiali created
deployment.apps/kiali created
serviceaccount/prometheus created
configmap/prometheus created
clusterrole.rbac.authorization.k8s.io/prometheus created
clusterrolebinding.rbac.authorization.k8s.io/prometheus created
service/prometheus created
deployment.apps/prometheus created

 

설치가 완료되면 istioctl을 통해 addon 컴포넌트의 대시보드에 접근할 수 있습니다.

▶ istioctl dashboard prometheus
http://localhost:9090

▶ istioctl dashboard grafana
http://localhost:3000

▶ istioctl dashboard kiali
http://localhost:20001/kiali

 

이번 글에서는 Istio에 대한 구성과 공식 문서를 참고하여 Istio 위에서 실행되는 Sample Application에 대해 실행해보았습니다. 다음 글에서는 Istio CRD인 Virtual Service에 대해 좀 더 자세히 알아보도록 하겠습니다.

참고자료

1. Istio로 시작하는 서비스 메시 - 에이콘 출판사
2. Istio Document