Service Mesh란

Service Mesh란

 

• MSA에서 서비스 간 통신을 제어하는 application에 내장된 적용 인프라 계층(infrastructure layer).
• X2BEE처럼 MSA (MicroService Architecture) 구조를 적용하기 위한 클러스터의 내부 통신이, 위와 같은 Mesh 네트워크 구조라는 데 출발해 Service Mesh라는 이름이 지어졌다.
• 추상화를 통해 복잡한 내부 네트워크를 제어하고, 추적하고 탄력성도 확보한다.
• sidecar라고 불리는 proxy를 이용하여 abstracts that logic into a parallel layer of infrastructure.
• Service Mesh는 Layer 7 네트워크이고 서비스간 secure TLS (mTLS)를 관리해주는데 좋고, 구현체인 경량화 proxy를 통해 다양한 routing rule 제공
• Sidecar proxy는 Service Mesh의 Data plane을 구성한다.

Service Mesh의 장점

Monolithic architecture에서 process나 thread 간 메모리 공유 등은 instance 내부에서 처리하였지만, MSA는 서비스 간 통신을 통해 처리된다.
동적으로 수많은 pod가 만들어지고 없어지고 하면서 서비스 간 통신이 유발하는 이런 복잡한 상황에서 내부 네트워크를 안정적으로 다루기 위해서는 새로운 요구사항과 기능이 필요하다.
분명 MSA는 Monolithic의 단점을 극복하기 위해서 나온 것이고,
Service Mesh는 이렇게 Monolithic architecture보다 MSA구조를 cloud 환경에서 시스템을 운영할 때 MSA의 장점을 극대화하기 위해 사용된다. 이를 통해 많은 문제를 해결하였지만 다른 문제점도 있다. 그것은 system runtime의 복잡성이다.

단점

• 각 pod에 sidecar proxy 추가로 latency가 추가될 수 있고, CPU와 메모리 사용이 증가할 수 있다.
• 서비스 간 통신에 네트워크 layer가 추가되어 운영상 overhead 추가 및 복잡성 증가

Service Mesh의 기능

• Service Discovery
• Load Balancing
• Dynamic Request Routing
• Circuit Breaking
• Retry and Timeout
• TLS
• Distributed Tracing
• metrics collection

Service Mesh 구현

 

위와 같이 경량화 proxy를 sidecar pattern으로 배치하여 서비스간 통신을 제어하는 방법이다.
이 proxy에 routing rules, retry, timeout 등을 설정하고 logic을 작성하여 공통 기능을 기본 application에서 분리시킬 수 있다.

Sidecar의 장점

• 기본 app의 logic을 수정하지 않고도 추가 기능 수행 가능
• sidecar app은 기본 app과 resource 공유 가능, 이를 통해 monitoring에 필요한 metrics 수집 가능

Service Mesh

Service Mesh - MSA간 proxy를 사용하여 통신을 위한 infra 계층
장점 - 통신에 대한 관찰 가능성 제공, 보안 연결 제공, 실패 요청의 재시도 등.
Service Mesh 아키텍쳐는 Istio, Linkerd, AWS App Mesh, Open Service Mesh등의 S/W가 있음
Service Mesh는 Data Plane에서 Envoy Proxy를 사용

K8s native의 경우 (왼쪽) Worker Node 내에서는 서로 통신 가능, 그러나 서로 다른 Worker Node끼리는 CNI를 통해 kube-proxy로 통신함. 이를 위해 K8s API server에 연결 요청.
그러나 Service Mesh의 경우 proxy to proxy간의 연결을 통해서 통신함. → 더 복잡하지만 control plane에 있는 컴포넌트로 관리가 자동화 됨.

Istio

Istio

Google, IBM, Lyft가 함께 기여하고 있는 open source. K8s를 기본으로 지원. Control plane - Data plane 구조로 동작.
Envoy라는 open source 서비스를 사용한다.
Envoy란 inbound와 outbound 서비스 트래픽을 중재 proxy를 기본으로 사용하지만 nginx나 linkerd 로도 대체 가능.
Jaeger라는 간단한 UI를 가진 모니터링 도구를 MSA 디버깅으로 사용한다.

Linkerd

Buoyant에서 기여하고 있는 open source Service Mesh. Sidecar로 배포하는 것이 리소스를 많이 잡아먹어 linkerd는 worker node당 하나의 linkerd를 배포해서 동작함

Conduit

Buoyant에서 기여하는 또 하나의 open source. Control plane, Data plane 구조로 동작.

Istio 추가

• 기존 분산 application에 투명하게 계층화되는 open source Service Mesh tool.
• 서비스 코드 변경없이 Load Balancing, 서비스 간 인증 및 모니터링 경로에 대한 설정을 적용 가능.
• Istio Control Plane은 K8s에서 실행되고, 해당 cluster에 배포된 application을 Service Mesh에 추가하거나 다른 cluster로 확장 가능하여 multi-cluster도 구현 가능
• 홈페이지: https://istio.io

Istio 특징 4가지

• Service Mesh 운영
  • MSA 관련 코드를 추가할 필요없음
  • 모니터링 로그분석 추적 기능 관련 데이터 수집
• 보안 강화
  • mTLS(mutual(쌍방향) Transport Layer Security)는 MSA 간의 통신에 암호화를 추가 (기존은 https)
• Routing 용이
  • 사용자의 요청에 따라 다른 버전으로 전달 가능
• 복원력 향상
  • 요청에 타임아웃을 추가하고, 요청으르 재시도 할 수 있음
  • MSA 과부하 보호를 위해 circuit breaker 사용 가능

Istio 동작 원리

공식홈페이지 이미지

inbound traffice이 들어오면 service가 받는 것이 아니고 Envoy proxy가 받는다.
Envoy proxy에서 Service Mesh에 들어오고 나가는 inbound, outbound traffic을 결정하기 때문에 sidecar 개념이 들어간다.
K8s에 서로 다른 container를 추가해서 pod를 나열하면 2/2로 표시됨.
1개 container는 MSA를 포함
1개 container는 Service Mesh에 통합할 수 있게하는 sidecar를 포함
Istio는 자동으로 각 pod에 container를 주입

출처: https://istio.io/latest/docs/ops/deployment/architecture/

위처럼 Envoy proxy가 Sidecar로 배포되어 서비스A와 서비스B사이에 communication과 service container에 들어가는 것을 관리.

Istio Architecture

• Istio는 모든 송수진 traffice을 proxy를 통해 routing
• Istio에서는 Envoy Proxy(https://www.envoyproxy.io)를 확장해 적용
• 모든 네트워크 traffic은 proxy를 통과
• Proxy는 모든 traffic을 수정하고 측정
• Proxy는 Service Mesh를 투명하게하고 서비스의 Service Mesh 기능을 활성화
• Istio Proxy는 모든 TCP 기반 프로토콜을 처리 (Layer 4)
• Layer7은 HTTP1.1, HTTP2, gRPC를 지원
• HTTP 상태코드 평가를 통해 실행 성공 여부를 결정

Istio component

Envoy

• Envoy는 원래 C++로 개발된 open-source인데 Istio는 이 Envoy Proxy의 고성능 확장 버전을 사용함
• Envoy Proxy는 Data Plane traffic과 상호작용하는 유일한 Istio component
• Sidecar 배포를 통해 Istio는 정책 결정을 시행하고, 모니터링 시스템으로 보내 전체 Service Mesh의 동작에 대한 정보를 제공할 수 있는 풍부한 telemetry 정보를 추출 가능
• Sidecar Proxy 모델을 사용하면 코드를 재설계하거나 다시 작성할 필요없이 기존 배포에 Istio 기능을 추가할 수 있음Envoy 기능
• Traffic 제어 기능
  • %기반 Traffic 분할이 있는 단계적 배포 → Canary라고 부름
  • HTTP, gRPC, WebSocket 및 TCP Traffic에 대한 풍부한 Routing 규칙으로 세분화된 Traffic 제어를 실행
• Network 복원 기능
  • HTTP/2 및 gRPC Proxy, Circuit Breaker, 결함 주입
• 보안 및 인증 기능
  • TLS 종료
  • 상태 확인
  • 풍부한 metrics

Istiod

• 서비스 검색, 구성 및 인증서 관리를 제공
• Traffic을 제어하는 고급 routing 규칙을 envoy별 구성으로 변환하고 런타임 시 sidecar에 전파

VirtualService

• Routing하는 방법을 구성할 수 있음
  예시:

  http:
  - match:
    - headers:
      end-user:
        exact: json
    route:
    - destination:
      host: reviews
      subset: v2

end-user에 명시된 해당사용자만 routing을 통해 해당 요청을 v2로 보낼 수 있다.

DestinationRule

• VirtualService Routing 규칙이 적용된 후에 적용되므로 Traffic의 '실제' 대상에 적용됨
• 특히 DestinationRule을 사용하여 지정된 서비스의 모든 인스턴스를 버전별로 그룹화하는 것과 같이 명명된 서비스 Subset을 지정
• DestinationRule을 사용하면 전체 대상 서비스 또는 선호하는 Load Balancing 모델, TLS 보안 모드 또는 Circuit Breaker 설정과 같은 특정 서비스 Subset을 호출할 때 Envoy의 Traffic 정책을 custom 가능

Gateway

• Service Mesh에 대한 Inbound 및 Outbound traffic을 관리하여 Service Mesh에 들어오거나 나갈 Traffic을 지정할 수 있음
• Gateway 구성은 Service Workload와 함께 실행되는 sidecar envoy proxy가 아니라 Service Mesh Edge에서 독립 실행형 envoy proxy(Ingress Gateway라는 이름의 pod)에 적용
• K8s Ingress API와 같이 시스템에 들어오는 Traffic을 제어하는 다른 메커니즘과 달리 Istio Gateway를 사용하면 Istio Traffic Routing의 모든 기능과 유연성을 사용할 수 있음
• Istio의 Gateway resource를 사용하면 노출할 port, TLS 설정 등과 같은 layer 4~6 Load Balancing 속성을 구성할 수 있음
• 동일한 API resource application 계층 traffic routing(L7)을 추가하는 대신 일반 Istio VirtualService를 Gateway에 binding
• 기본적으로 Istio Service Mesh의 다른 Data Plane Traffic과 마찬가지로 Gateway Traffic을 관리할 수 있음.

 

 Sidecar proxy injection용 Label을 namespace에 적용

kubectl label ns [Namespace이름] istio-injection=enabled

 

 

(이거 내 Notion 마크다운 파일 긁어붙이기하는데 UI가 마음에 안 드넹....)

 

참고문헌 :

https://www.dynatrace.com/news/blog/what-is-a-service-mesh/
https://www.techtarget.com/searchitoperations/definition/service-mesh
https://jimmysong.io/en/blog/service-mesh-the-microservices-in-post-kubernetes-era/#kubernetes-vs-service-mesh
https://istio.io/latest/about/service-mesh/

https://www.linkedin.com/pulse/istio%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B4%EA%B3%A0-%EC%99%9C-%EC%A4%91%EC%9A%94%ED%95%A0%EA%B9%8C-sean-lee/