쿠버네티스 · 네트워킹

Envoy — 쿠버네티스의 유니버설 데이터 플레인

기술인프라kubernetesenvoy

네 갈래로 살펴봐요

1Envoy가 무엇이고 왜 쓰는지

2어떤 구조로 요청을 처리하는지

3xDS로 설정을 어떻게 동적으로 바꾸는지

4쿠버네티스에서 어떻게 쓰이는지

01

Envoy는 앱 옆에 붙는 프록시예요

네트워킹을 앱에서 떼어내 프록시로 모으는 게 핵심 아이디어예요.

무엇인가

고성능 L7 프록시이자 메시의 데이터 플레인이에요

⚙️

C++ L7/L4 프록시

Lyft가 대규모 마이크로서비스를 위해 만들었어요.

🎓

CNCF Graduated

2018년 졸업 — k8s·Prometheus에 이은 3번째.

🔌

out-of-process

앱과 별도 프로세스로 실행돼 언어와 무관하게 동작해요.

스스로 "universal data plane"이라 부르며, 서비스 메시의 데이터 플레인 표준이 됐어요.

L7/L4: L7=애플리케이션(HTTP 등), L4=전송(TCP) 계층 · 데이터 플레인: 실제 트래픽을 나르고 정책을 집행하는 층 · 마이크로서비스: 작은 서비스 여러 개로 쪼갠 아키텍처 · CNCF: 클라우드 네이티브 재단

왜 쓰나

네트워킹을 앱마다 짜지 않고 프록시로 통일해요

Envoy 없이

LB·retry·타임아웃·TLS·관측을 앱마다 각자 구현
언어·팀마다 품질이 제각각
비즈니스 로직에 네트워킹이 섞여요

Envoy로

그 관심사를 프록시 한 곳으로 이동
언어와 무관하게 동일한 신뢰성·관측성
앱은 비즈니스 로직에만 집중

retry: 실패한 요청 재시도 · 서킷 브레이킹(circuit breaking): 장애 대상 호출을 잠시 끊어 연쇄 실패를 막는 것 · 관측성(observability): 메트릭·로그·트레이스로 내부 상태를 들여다보는 능력

02

요청은 정해진 부품을 거쳐 흘러요

listener·filter·route·cluster·endpoint를 먼저 익혀요.

핵심 용어

이 다섯 부품이 요청을 나눠 처리해요

부품	뜻
Listener	downstream이 접속하는 명명된 네트워크 위치(IP:port)
Filter (chain)	요청이 통과하는 처리 단계 — listener·network·HTTP 필터로 이어져요
Route	virtual host·경로·헤더로 매칭해 어느 cluster로 보낼지 결정
Cluster	Envoy가 로드밸런싱하는 upstream 묶음
Endpoint	cluster를 이루는 개별 upstream 인스턴스(실제 IP:port)

downstream: Envoy에 접속해 요청을 보내는 쪽(클라이언트 방향) · upstream: Envoy가 요청을 전달하는 쪽(백엔드 방향) · virtual host: 도메인별로 라우팅 규칙을 묶는 단위

요청 경로 · 개요

downstream에서 endpoint까지 이렇게 이어져요

Downstream

→

Listener

→

HCM
필터 체인

→

Router

→

Route → Cluster

→

Endpoint
upstream

HCM(HTTP Connection Manager): L7 HTTP 처리를 담당하는 대표 network filter · Router: HTTP 필터 체인의 마지막 필터로, 매칭된 cluster로 요청을 보냄

요청 경로 · 심화

부품마다 이 일을 해요

1

Listener가 IP:port에 바인딩해 downstream 연결을 수락해요.

2

연결 조건(SNI 등)으로 filter chain을 고르고, network filter인 HCM이 L7으로 해석해요.

3

HTTP 필터들을 차례로 지나 마지막 router filter에 닿아요.

4

route match: virtual host + 경로/헤더로 목적지 cluster를 정해요.

5

cluster의 load balancer가 endpoint 하나를 골라 upstream으로 보내요.

SNI(Server Name Indication): TLS 핸드셰이크에서 접속하려는 도메인을 알리는 값 · load balancer: 여러 endpoint에 요청을 분배하는 방식(라운드로빈 등)

설정 멘탈 모델

설정도 그 부품 순서 그대로예요

listeners: - address: { 0.0.0.0:10000 } # Listener (bind) filter_chains: - filters: - name: http_connection_manager # HCM (network filter) http_filters: [ router ] # 마지막 = router route_config: # Route routes: - match: { prefix: "/" } route: { cluster: backend } # → Cluster 지정 clusters: - name: backend # Cluster endpoints: [ backend.svc:443 ] # Endpoint (upstream)

부팅 시 고정(static). 동적으로 하려면 각 블록을 LDS·RDS·CDS·EDS로 대체해요.

간략화한 예시예요 — 실제 Envoy YAML은 더 자세해요

03

설정은 재시작 없이 바뀌어요

control plane이 xDS로 Envoy에 설정을 실시간으로 밀어넣어요.

두 개의 평면

Envoy는 손발, control plane은 두뇌예요

Data plane = Envoy

실제 트래픽을 나르고 정책을 집행
혼자서는 static 설정만 처리

Control plane

xDS로 설정을 push하는 두뇌
예: Istiod · Contour · Envoy Gateway
이 분리가 동적 메시·인그레스의 핵심

control plane: 데이터 플레인에게 "어떻게 동작할지" 설정을 내려주는 제어 두뇌 · push: 서버가 먼저 변경을 보내주는 방식(폴링 반대)

xDS API

부품별로 발견 채널이 나뉘어 있어요

xDS	발견하는 것
LDS	Listener 집합
RDS	Route 규칙
CDS	Cluster 집합
EDS	Cluster 안의 Endpoint(실제 인스턴스)
ADS	위 전부를 단일 gRPC 스트림으로 다중화 → 순서 보장

xDS: x Discovery Service — 설정을 동적으로 발견·전달하는 API 묶음 · gRPC: HTTP/2 기반 고성능 RPC 프로토콜 · 다중화: 여러 스트림을 하나로 합치는 것

동적 반영

설정이 바뀌면 곧바로 반영돼요

1

클러스터 상태가 변해요(파드 추가·라우팅 변경 등).

2

control plane이 새 설정을 계산해 gRPC로 push해요.

3

각 Envoy가 xDS로 받아 재시작 없이 반영해요.

4

수천 개 프록시를 API로 실시간·중앙에서 조율할 수 있어요.

재시작 없이(hot reload): 프로세스를 내리지 않고 설정만 갈아끼우는 것 · Envoy가 static 리로드형 프록시와 갈리는 지점이에요

04

쿠버네티스에선 크게 두 자리에 놓여요

파드 옆 사이드카(메시)와, 클러스터 입구 인그레스예요.

패턴 ① 사이드카 (메시)

파드마다 Envoy를 넣어 트래픽을 가로채요

1

각 Pod에 Envoy 컨테이너를 주입해요(Istio).

2

iptables로 Pod의 인바운드·아웃바운드를 전부 Envoy로 돌려요.

3

Istiod가 control plane으로 각 Envoy에 설정을 내려요.

4

앱 수정 없이 서비스 간 mTLS·카나리·retry·telemetry를 얻어요.

사이드카(sidecar): 앱 컨테이너 옆에 함께 뜨는 보조 컨테이너 · 서비스 메시: 서비스 간 통신을 프록시로 관리하는 인프라 계층 · mTLS: 서버·클라이언트가 서로 인증서로 검증하는 상호 인증 · 카나리: 트래픽 일부만 새 버전에 흘려 검증

사이드카 트래픽

두 앱 사이 통신이 Envoy를 양쪽에서 거쳐요

App A

→

Envoy A
사이드카

→

mTLS
암호화

→

Envoy B
사이드카

→

App B

앱은 평범하게 상대를 호출할 뿐, 암호화·재시도·계측은 Envoy 두 개가 알아서 처리해요.

인바운드/아웃바운드: 파드로 들어오는/나가는 트래픽 · telemetry(계측): 트래픽에서 메트릭·로그·트레이스를 뽑아내는 것

최신 흐름 · 앰비언트

사이드카 없이 L4·L7을 나누기도 해요

ztunnel (L4)

노드당 DaemonSet으로 한 개
zero-trust 터널 — mTLS·L4 라우팅
파드마다 프록시를 안 넣어요

waypoint (L7)

필요할 때만 배치하는 L7 Envoy
HTTP 라우팅·L7 인가 등 담당
네임스페이스/서비스 단위

Istio의 ambient 모드 — 사이드카 방식도 여전히 지원돼요.

앰비언트(ambient): 파드별 사이드카 없이 메시를 제공하는 Istio의 새 모드 · DaemonSet: 모든 노드에 하나씩 뜨는 워크로드 · zero-trust: 내부라도 무조건 믿지 않고 검증하는 보안 모델

패턴 ② 인그레스 (엣지)

클러스터 입구에서도 Envoy가 관문이 돼요

🚪

Contour

CNCF, Envoy 기반 인그레스 컨트롤러.

🧭

Emissary / Ambassador

Envoy 기반 쿠버네티스 API 게이트웨이.

🌐

Envoy Gateway

Gateway API의 표준 Envoy 구현. fleet을 동적 provision.

인그레스(ingress): 클러스터 바깥→안 트래픽의 입구 · 엣지(edge) 프록시: 시스템 최전방 관문 · Gateway API: 구식 Ingress를 대체하는 쿠버네티스 표준 라우팅 API · provision: 필요한 자원을 자동으로 만들어 배치

차이점

Traefik·nginx와는 설계가 달라요

Traefik · nginx 인그레스

스스로 설정을 읽어 동작하는 통합형
data·control이 한 몸
단독으로 바로 인그레스가 돼요

Envoy

순수 data plane — control plane이 필수
xDS로 대규모 fleet을 중앙 제어
메시의 사실상 표준 data plane

통합형: 데이터·제어 기능을 한 프로세스가 함께 갖는 형태 · fleet: 함께 운영되는 다수의 프록시 인스턴스 무리

핵심 기능

신뢰성·관측성을 폭넓게 챙겨줘요

⚖️

고급 L7 LB

least-request·ring hash·Maglev 등 다양한 방식.

🛡️

복원력

헬스체크·outlier detection·서킷 브레이킹·retry/timeout.

📈

관측성·보안

1000+ 메트릭·분산 트레이싱·access log, TLS/mTLS.

HTTP/1.1·HTTP/2(gRPC)·HTTP/3(1.19.0+) 지원, 프로토콜 간 변환도 가능해요.

outlier detection: 비정상 endpoint를 자동 감지해 잠시 빼는 것 · ring hash·Maglev: 같은 키를 같은 서버로 보내는 일관 해싱 LB · 분산 트레이싱: 요청이 여러 서비스를 거친 경로를 추적

자주 하는 오해

이 세 가지를 헷갈리기 쉬워요

❌ Envoy = 서비스 메시

Envoy는 data plane. 메시 = control plane(Istiod) + Envoy 무리.

❌ 단독으로 동적 동작

동적 설정엔 control plane 필수. 혼자면 static만.

❌ Endpoint는 그냥 서버

cluster 하위 개념 — 보통 EDS가 관리하는 실제 IP:port.

용어 사전

여기 나온 용어를 한눈에 정리했어요

데이터 플레인: 실제 트래픽을 나르고 정책을 집행하는 층

control plane: 데이터 플레인에 설정을 내려주는 두뇌

Listener: downstream이 접속하는 IP:port

Filter (chain): 요청이 통과하는 처리 단계 묶음

HCM: L7 HTTP를 처리하는 대표 network filter

Route: 경로·헤더로 목적지 cluster를 정함

Cluster: 로드밸런싱하는 upstream 묶음

Endpoint: cluster 안 개별 upstream(IP:port)

downstream/upstream: 요청 보내는 쪽 / 받는 쪽

xDS: 설정을 동적으로 전달하는 API(LDS/RDS/CDS/EDS/ADS)

사이드카: 앱 옆에 함께 뜨는 보조 컨테이너

서비스 메시: 서비스 통신을 프록시로 관리하는 계층

Istiod: Istio의 control plane

앰비언트: 사이드카 없는 Istio 모드(ztunnel+waypoint)

mTLS: 서로 인증서로 검증하는 상호 인증

Gateway API: 인그레스를 대체하는 k8s 표준 라우팅 API

Envoy는 data plane,
지휘하는 control plane과 함께 완성돼요

기술 · 인프라 · kubernetes · envoy