[Istio] Overview

Service Mesh

k8s 는 지금까지 나온 분산 아키텍처를 구축하기 위한 프레임워크 중 가장 많이 사용된다고 볼 수 있다. k8s 를 통해 MSA를 구축하는데는 문제가 없다. k8s의 약점은 pod 간의 상호연결을 관리하고 그것들에 대한 가시성을 제공하는 부분이다.

 

서비스 메시를 사용하게 되면, 컨테이너간 모든 호출이 서비스 메시를 경유하게 된다. 서비스 메시가 타킷 컨테이너로 호출을 인도하게 된다. 따라서 서비스 메시는 개별 네트워크 요청에 대한 지표 수집이 가능하다. (클러스터 전반적인 health를 관리하기 위한 prometheus나 grafana와는 다르다.)

 

서비스 메시는 요청을 받을 때마다 작은 메시를 만든다. 

요청을 받은 시각을 기록하고, 타깃 컨테이너로 전달하고, 응답을 받으면 걸린 시간, 응답 코드를 기록한다.

 

Istio는 서비스 메시의 구현체 중 하나이다. 이스티오가 실제로 서비스 메시를 구현한 방식은 pod에 proxy container를 두는 것이다.

모든 네트워크는 proxy container를 통한다

 

Istio의 동작은 istio-system 네임스페이스 내 istiod (Istio Daemon) 로 관리된다. istiod 및 Kiali UI (네트워킹 시각화) 등 istio 시스템을 Control Plane이라고하고, Istio가 추가한 proxy set은 Data Plane 에 해당한다.

---

Istio sidecar 주입 (Istio proxy)

특정 namespace에 label을 지정하여 해당 namespace의 모든 pod에 istio proxy를 주입할 수 있다. (해당 동작은 istiod가 수행하며, 이전에는 istio-sidecar-injector가 수행했다.)

$ kubectl label namespace {namespace} istio-injection=enabled

 

label 지정 후 해당 namespace에 pod을 생성하면, 해당 pod에 istio 초기화를 위한 init container가 추가되며, istio-proxy container가 추가된다.

만약 namespace label을 지정하지 않고 pod을 실행하였다면, namespace label 지정 후 pod을 모두 재실행해야 적용된다.

---

Kiali

Istio의 Control Plane 컴포넌트 중 kiali는 Istio의 서비스 메쉬를 시각화한다. 

$ kubectl -n istio-system port-forward service/kiali 8088:20001

kiali

서비스 메시를 통과하는 데이터를 통해 kiali는 graph를 생성한다.

microservice 간 서비스 통신에 문제가 생기면, 위와 같이 빨간 선으로 나타난다.

fleetman-staff-service ->  fleetman-driver-monitoring 간 traffic이 대부분 500으로 실패하였다.

 

위 그래프를 통해 staff-service 가 driver-monitoring을 호출할 때 문제가 생겨 staff-service의 기능이 저하되었음을 알 수 있다.

driver-monitoring은 k8s 내부 서비스가 아닌 istio crd 이다.

driver-monitoring 노드는 다른 서비스들처럼 △가 아닌 다른 모양이다. △는 k8s object인 Service를 의미하고, driver-monitoring는 Istio의 object인 ServiceEntry 이다. 외부로 나가는 네트워크임을 알 수 있다.

#
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: fleetman-driver-monitoring
spec:
  hosts:
  - 2oujlno5e4.execute-api.us-east-1.amazonaws.com
  location: MESH_EXTERNAL
  ports:
  - number: 80
    name: http-port
    protocol: HTTP
  - number: 443
    name: https-port-for-tls-origination
    protocol: HTTPS
  resolution: DNS
---
# this is a legacy service that we're integrating with
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: fleetman-driver-monitoring
spec:
  hosts:
  - 2oujlno5e4.execute-api.us-east-1.amazonaws.com
  http:
  - match:
    - port: 80
    timeout: 1s
    route:
    - destination:
        host: 2oujlno5e4.execute-api.us-east-1.amazonaws.com
        port:
          number: 443

 

driver-monitoring 의 VirtualService에 timeout 을 추가하여, 1초 내 정상 응답을 못받을시 504 error를 낼 수 있다. 해당 microservice가 필수적이지않고 당장 대응할 수 없는 비상시에 위와 같이 처리할 수도 있다.

---

Envoy & Istio

클러스터 기반 응용 프로그램을 위한 프록시로, Istio의 proxy는 envoy 기반으로 만들어졌다. envoy를 직접 이용해서 스스로 서비스 메시를 구축할 수도 있다. 다만 envoy 프록시들이 트래픽 관리나 원격 측정 같이 서비스 메시에서 바라는 기능을 만족한다면, istio의 역할은 뭘까?

 

envoy는 다양한 유형의 클러스터에 배포할 수 있다. k8s와는 관계가 없는 그냥 프록시일 뿐이다. 우리가 envoy를 통해 k8s 클러스터에서 서비스 메시를 구현하려면, 어떤 식으로든 envoy의 모든 개념을 k8s 클러스터와 매핑해야할 것이다.

 

istio는 k8s에서 envoy를 우리에게 익숙한 객체로 이용할 수 있도록 한다. k8s yaml은 자동으로 envoy 구성으로 변환될 것이다.

 

---

참고: https://github.com/DickChesterwood/istio-fleetman/tree/master/_course_files