Service Mesh (1) - Introduction

☁️ 클클 5기 시즌 1 스터디 : 90DaysOfDevOps 레포지토리를 바탕으로 공부합니다!

 

🧩 77 > Let's break down a Service Mesh

🧩 79 > Comparing Different Service Meshes

90DaysOfDevOps/2023/day77.md at main · MichaelCade/90DaysOfDevOps

Day 77. Let's break down a Service Mesh

📍 서비스 메시 탄생 배경

: 서비스 메시는 MSA가 굴린 스노우볼.. ❄️

• 분산 환경 → 점점 컨테이너 내부에서 실행되는 작은 코드 덩어리의 애플리케이션..
  • 근데 서로 통신할 수 있어야 해!!
    • 근데 또 암호화되면서 승인된 방식이어야해!!!!!
      • 아니 근데 또 누가 하나 장애 나버리면 어떻게 해결하지? → 너무 복잡해!!!!
• 네트워크의 예측 불가능성 → 너무 의존해서는 안 되는데, 그렇다고 계속 코드를 수정하기엔 또….

서비스 메시
= 세분화된 트래픽 제어, AuthN, AuthZ 및 observability를 위한 계층을 제공하여 서비스 간 통신을 처리하는 애플리케이션 네트워크 계층

 

---

📍 서비스 메시가 해결하려는 문제

1. 마이크로 서비스 확장하며 적응해야 하는 불안정하고 바뀌는 복잡한 네트워크
2. RBAC, AuthZ, AuthN이 중요한 환경에서 (거의) zero-trust 보장
3. 암호화, 트래픽 필터링 기술 → 데이터 손실 방지 접근 보장
4. 애플리케이션 상태와 요청 처리하는 특성 결정 및 시각화
5. 서비스의 가용성과 안정성 보장

---

📍 서비스 메시의 주요 기능

• 서비스의 로드 밸런싱
• 여러 환경 사이에서 서비스 찾기
• HTTP와 gRPC 요청의 균일한 트래픽 제어와 라우팅
• 요청 재시도 자동화
• 복원력 위한 실패 주입 (Fault injection for resiliency)
• 로깅, 모니터링, 메트릭
• Peer AuthN, AuthZ
• mTLS 사용한 서비스↔ 서비스 암호화

---

📍 서비스 메시 구성 요소

• Control plane : 구성 배포 (configuration deploy)
• Data Plane : 사이드카(sidecar)와 게이트웨이(gateway) 둘 다에 구현되어 있다
• k8s cluster에서 위치하고 있다.

 

• 동작 방식
  • Operator → 트래픽 라우팅/보안 정책 적용
  • Control Plane → 게이트웨이나 사이드카 프록시에 구성/정책 push
  • Gateway/Sidecar → 트래픽 규칙 적용
• 위 사진 예시
  • 맨 처음 Ingress 게이트웨이가 외부 인바운드 요청을 받는다.
  • 요청 경로의 첫 번째 서비스인 Service A로 전달
  • Service A는 이 요청 처리할 사이드카가 있고, Control Plane에 원격 측정(telemetry) 데이터를 전송

---

📍 K8S과 관계

서비스 메시가 해 주는 책임들…

• 인증서 rotation 및 관리
• 서비스 간 암호화
• Ingress와 서비스↔서비스 라우팅으로 세분화된 트래픽 라우팅
• 애플리케이션 상태의 가시성/메트릭

---

📍 서비스 메시 제품

• Istio : Google, IBM, Lyft가 만들어서 Solo.io에서 유지중 ✅

Istio

---

• AppMesh : ECS, EKS, EC2 같은 AWS 서비스에 적용

애플리케이션 네트워킹 서비스 - AWS App Mesh - Amazon Web Services

애플리케이션 네트워킹 서비스 - AWS App Mesh - Amazon Web Services

AWS App Mesh란? - AWS App Mesh

AWS App Mesh란? - AWS App Mesh

---

• Consul : Hashicorp에서 만든 것

Consul by HashiCorp

Consul by HashiCorp

Consul Documentation | Consul | HashiCorp Developer

Consul Documentation | Consul | HashiCorp Developer

---

• Linkerd : Istio의 가벼운 버전 ✅

Overview

Overview

The world's most advanced service mesh.

The world's most advanced service mesh.

---

• Cilium : eBPF를 활용하여 Linux 커널을 사용하여 패킷 처리를 최적화하는 컨테이너 네트워킹 인터페이스

Cilium - Cloud Native, eBPF-based Networking, Observability, and Security

Cilium - Cloud Native, eBPF-based Networking, Observability, and Security

Cilium Service Mesh

Cilium Service Mesh

---

Day 79. Comparing Different Service Meshes

📍 서비스 메시 종류가 너무 많아요

Service Mesh	Open Source or Proprietary	Notes
Istio	Open Source	Widely adopted and abstracted
Linkerd	Open Source	Built by Buoyant
Consul	Open Source	Owned by Hashcorp, Cloud offering available
Kuma	Open Source	Maintained by Kong
Traefik Mesh	Open Source	Specialized Proxy
Open Service Mesh	Open Source	By Microsoft
Gloo Mesh	Proprietary	Built by http://solo.io/ ontop of Istio
AWS App Mesh	Proprietary	AWS specific services
OpenShift Service Mesh	Proprietary	Built by Redhad, based on Istio
Tanzu Service Mesh	Proprietary	SaaS based on Istio, built by VMware
Anthos Service Mesh	Proprietary	SaaS based on Istio, built by Google
Bouyant Cloud	Proprietary	SaaS based on Linkerd
Cilium Service Mesh	Open Source	Originally a CNI

---

📍 Istio vs Linkerd vs AppMesh vs Consul vs Cilium

Feature	Istio	Linkerd	AppMesh	Consul	Cilium
Project Creators	Google, Lyft, IBM, Solo	Buoyant	AWS	Hashicorp	Isovalent
Service Proxy	Envoy, Rust-Proxy (experimental)	Linkerd2-proxy	Envoy	Interchangeable, Envoy default	Per-node Envoy
Ingress Capabilities	Yes via the Istio Ingress-Gateway	No; BYO	Yes via AWS	Envoy	Cilium-Based Ingress
Traffic Management (Load Balancing, Traffic Split)	Yes	Yes	Yes	Yes	Yes, but manual Envoy config required for traffic splits
Resiliency Capabilities (Circuit Breaking, Retries/Timeouts, Faults, Delays)	Yes	Yes, no Circuit Breaking or Delays	Yes, No Fault or Delays	Yes, No Fault or Delays	Circuit Breaking, Retries and Timeouts require manual Envoy configuration, no other resiliency capabilities
Monitoring	Access Logs, Kiali, Jaegar/Zikin, Grafana, Prometheus, LETS, OTEL	LETS, Prometheus, Grafana, OTEL	AWS X-RAY, and Cloud Watch provides these	Datadog, Jaegar, Zipkin, OpenTracing, OTEL, Honeycomb	Hubble, OTEL, Prometheus, Grafana
Security Capabilities (mTLS, External CA)	Yes	Yes	Yes	Yes	Yes, with Wireguard
Getting Started	Yes	Yes	Yes	Yes	Yes
Production Ready	Yes	Yes	Yes	Yes	Yes
Key Features	Sidecar and Sidecar-less, Wasm Extensibility, VM support, Multi-cloud Support, Data Plane extensions	Simplistic and non-invasive	Highly focused and tight integration into AWS Ecosystem	Tight integration into Nomad and Hashicorp Ecosystem	Usage of eBPF for enhanced packet processing, Cilium Control Plane used to manage Service Mesh, No sidecars
Limitations	Complex, learning curve	Strictly K8s, additional config for BYO Ingress	Limited to just AWS services	Storage tied to Consul and not K8s	Not a complete Service Mesh, requires manual configuration
Protocol Support (TCP, HTTP 1.1 & 2, gRPC)	Yes	Yes	Yes	Yes	Yes
Sidecar Modes	Sidecar and Sidecar-less	Sidecar	Sidecar	Sidecar	No sidecar
CNI Redirection	Istio CNI Plugin	linkerd-cni	ProxyConfiguration Required	Consul CNI	eBPF Kernel processing
Platform Support	K8s and VMs	K8s	EC2, EKS, ECS, Fargate, K8s on EC2	K8s, Nomad, ECS, Lambda, VMs	K8s, VMs, Nomad
Multi-cluster Mesh	Yes	Yes	Yes, only AWS	Yes	Yes
Governance and Oversight	Istio Community	Linkered Community	AWS	Hashicorp	Cilium Community

---

📍 결론

• Istio : 플랫폼 지원, 사용자 정의 가능성, 확장성, 대부분의 프로덕션 지원 → 최고다~
  • Linkerd : 더 가벼운 버전
• AppMesh : 기능이 많지만 AWS 생태계에만 적용
• Consul : 낫밷
• Cilium CNI : eBPF 사용하고 네트워킹 스택 확장… 벋 아직 갈 길 멀었다