주요 요구가 L3/L4 라우팅, 정책이고 파드별 프록시 비용이 크다면 대안을 검토할 수 있지만, 복잡한 L7 처리는 노드 단위 Envoy 같은 하이브리드가 여전히 필요합니다.
Istio 사이드카를 없애도 될까: eBPF 서비스 메시와 L7 하이브리드 조건
먼저 사이드카가 제공하는 기능을 분해한다
Istio나 Linkerd의 사이드카는 단순한 네트워크 홉이 아닙니다. 트래픽 가로채기, mTLS, 서비스 인증, 재시도, 타임아웃, HTTP 라우팅과 관측을 애플리케이션 밖에서 제공합니다. “Envoy를 제거한다”는 목표부터 세우면 이 기능 중 무엇이 사라지는지 놓칩니다.
반면 파드마다 프록시를 실행하면 파드 수에 따라 CPU, 메모리가 늘고, 시작 순서와 업그레이드, 사용자 공간 왕복을 관리해야 합니다. 실제 sidecar request, limit, 평균과 p99 지연, 재시도 횟수, 프록시 OOM과 장애 비율을 모아야 비용이 문제인지 알 수 있습니다. 작은 클러스터에서 이 값이 미미하다면 구조 변경의 위험이 절감액보다 클 수 있습니다.
eBPF로 옮길 기능과 남길 기능을 나눈다
BPF Map과 소켓 훅은 IP, 포트 기반 정책, 서비스 조회, 일부 로드밸런싱과 네트워크 관측을 노드 커널 경로로 옮길 수 있습니다. 사용자 공간 컨트롤 플레인이 정책을 Map에 넣고 커널 프로그램이 트래픽에 적용하는 구조입니다. 같은 노드의 일부 연결은 소켓 경로에서 더 짧게 처리할 여지도 있습니다.
그러나 HTTP body와 헤더, 복잡한 카나리 규칙, gRPC 재시도, 인증서 교환처럼 L7 문맥이 필요한 기능은 커널 프로그램에 무리하게 넣기 어렵습니다. 이때 노드당 Envoy를 두거나 특정 트래픽만 프록시에 보내는 하이브리드 구성이 가능합니다. 파드당 프록시 수를 줄이는 것과 프록시 기능을 완전히 없애는 것은 다른 결과입니다.
원문에 포함된 하드코딩 IP의 XDP_DROP C 코드는 초기 패킷 필터를 설명하는 스냅샷일 뿐 서비스 메시 구현이 아닙니다. include와 helper, 라이선스, 빌드, attach, Map이 빠졌고 Ethernet 다음을 곧바로 IPv4로 가정해 VLAN, IPv6를 다루지 않습니다. 이 예제의 빠른 드롭을 mTLS나 L7 라우팅 성능으로 확장해서 해석하면 안 됩니다.
sidecarless가 아니라 기능 배치표로 결정한다
현재 정책을 다음처럼 분류하면 전환 범위가 보입니다.
| 요구 | 가능한 위치 | 확인할 한계 |
|---|---|---|
| IP, 포트 정책 | eBPF 데이터 경로 | Map 동기화와 커널 호환성 |
| 서비스 로드밸런싱 | eBPF | 세션, 프로토콜별 의미 |
| TCP 흐름 관측 | eBPF, Hubble 계열 | 암호화와 보존 범위 |
| HTTP 헤더 라우팅 | L7 프록시 | 노드 프록시 경유 비용 |
| 재시도, 타임아웃 | 프록시 또는 앱 | 중복 요청과 예산 |
| mTLS | 메시 구성요소 | 인증서 수명주기와 신원 경계 |
이 표에서 L7 항목이 대부분이라면 “sidecarless”라는 이름만 보고 이동할 이유가 약합니다. L3/L4가 대부분이고 파드별 프록시 비용이 측정됐다면 노드 수준 구성의 이점이 커집니다.
운영 역량도 메시 기능의 일부다
eBPF의 최신 기능은 커널과 배포판 조합에 의존합니다. 원문의 Linux 4.19 이상, 5.x 권장이라는 표현은 대략적인 방향이며 실제 Cilium 기능과 노드 이미지의 요구 조건을 확인해야 합니다. BPF 프로그램이나 Map 문제로 패킷이 드롭될 때 애플리케이션 로그에는 단서가 없을 수 있으므로 Hubble 같은 전용 관측과 커널 네트워킹 지식이 필요합니다.
기존 Envoy 로그와 대시보드를 없애기 전에 새 경로에서 정책 결정, 드롭, 연결 실패를 추적할 수 있는지 검증해야 합니다. 데이터 플레인 업그레이드가 노드 전체에 미치는 범위, 잘못된 정책 배포를 되돌리는 시간, 공급자 지원과 벤더 종속성도 운영 비용에 포함됩니다.
파일럿의 종료 조건을 숫자로 정한다
작은 서비스 하나에서 다음 순서로 비교합니다.
- 현재 sidecar의 CPU, 메모리, p99와 사용하는 L7 기능을 기록합니다.
- 같은 정책을 eBPF와 필요한 노드 프록시로 재현합니다.
- 정상 부하뿐 아니라 재시도, 인증서 갱신, 프록시, 노드 장애를 시험합니다.
- 리소스 절감과 함께 정책 누락, 진단 시간, 롤백 시간을 측정합니다.
- 목표 절감률과 기능 회귀 0건을 모두 만족할 때만 노드 풀을 넓힙니다.
작고 안정적인 클러스터라면 기존 사이드카를 유지하는 것이 합리적일 수 있습니다. 대규모 환경에서 파드별 프록시 비용과 지연이 확인됐다면 eBPF와 L7 하이브리드를 검토할 근거가 생깁니다. Istio를 없앨지의 답은 기술 유행이 아니라, 남겨야 할 L7 기능과 실제로 줄일 수 있는 파드당 비용의 교차점에 있습니다.
서비스 신원과 mTLS 경계는 별도로 그린다
암호화 여부만 확인하면 서비스 메시가 제공하던 신원 의미를 놓칠 수 있습니다. workload identity를 누가 발급하고, 인증서를 어느 주기로 회전하며, 파드, 노드, 서비스 중 무엇에 묶는지 그려야 합니다. 노드 단위 프록시에서 TLS를 종료하면 파드까지의 남은 구간과 한 노드 안에서 다른 workload를 구분하는 방법도 설명돼야 합니다.
인증서 갱신 실패와 clock skew, 제어 plane 단절을 시험합니다. 만료 직전 인증서가 갱신되지 않을 때 연결을 거부할지 기존 세션을 유지할지, 폐기된 신원이 Map과 프록시 cache에서 언제 사라지는지 확인해야 합니다. 평상시 연결 성공만 보면 수명주기 문제는 드러나지 않습니다.
정책과 감사 로그에는 요청을 보낸 service identity, 결정한 계층과 정책 버전이 남아야 합니다. eBPF가 L3, L4를 허용하고 노드 프록시가 L7을 거부했다면 두 사건을 같은 요청으로 연결할 수 있어야 합니다. 그렇지 않으면 운영자가 커널과 프록시 로그 사이에서 원인을 추측하게 됩니다.
재시도와 timeout은 위치가 바뀌면 의미도 달라진다
사이드카가 수행하던 재시도를 애플리케이션이나 노드 프록시로 옮길 때 총 retry budget을 다시 계산해야 합니다. 앱과 프록시가 각각 세 번 재시도하면 장애 시 요청 수가 곱으로 늘 수 있습니다. 어느 계층이 어떤 오류에 몇 번 재시도하는지 한 표로 만들고, idempotent하지 않은 쓰기는 기본적으로 자동 재시도 대상에서 제외합니다.
timeout도 connect, response header, 전체 업무 마감 시간으로 나눕니다. 상위 요청보다 하위 재시도의 timeout이 길면 취소된 요청이 백그라운드에서 계속 자원을 사용할 수 있습니다. 취소 신호가 노드 프록시와 애플리케이션까지 전달되는지 부하 테스트에서 확인합니다.
카나리 라우팅과 circuit breaker가 기존 Envoy 설정에 있었다면 새 위치에서 같은 조건을 재현하거나 기능을 의도적으로 제거했다는 결정을 기록합니다. L3, L4 로드밸런싱만으로 HTTP 헤더 기반 실험과 오류율 기반 차단이 자동으로 대체되지는 않습니다.
전환은 관측 모드와 정책 모드를 분리한다
가능하다면 새 데이터 경로를 먼저 관측만 하는 모드로 배치해 기존 정책 결정과 비교합니다. 새 경로가 허용, 거부했을 결과를 실제 차단 없이 기록하면 identity mapping과 정책 변환 오류를 찾을 수 있습니다. 오차가 충분히 낮아진 뒤 한 namespace 또는 노드 풀에서 enforcement를 시작합니다.
이중 관측 기간에는 기존 sidecar와 새 노드 구성의 flow ID, 서비스 이름과 시간축을 맞춥니다. 단순 이벤트 수가 다르다는 사실보다 어떤 요청에서 결정이 달라졌는지 조사할 수 있어야 합니다. 암호화나 sampling 때문에 비교할 수 없는 구간은 성공률에서 제외하지 말고 미확인으로 따로 기록합니다.
파드별 사이드카 제거는 rollout 순서도 중요합니다. init container, readiness, iptables redirect와 종료 drain에 의존하던 배포 스크립트가 있는지 확인합니다. 노드 프록시가 업데이트될 때 연결을 어떻게 배출하는지, 노드 장애가 여러 서비스에 동시에 미치는지도 시험합니다.
운영 런북은 데이터 경로별 질문으로 만든다
장애 때 먼저 알아야 할 것은 이 연결이 어느 경로를 탔는지입니다. source, destination workload, 노드, 적용된 L3, L4 정책, L7 프록시 경유 여부와 인증서 신원을 한 조회 흐름으로 연결합니다. 정상 경로의 기준 trace를 보관하면 변경 뒤 단계가 하나 늘거나 사라졌는지 비교할 수 있습니다.
허용 트래픽이 막혔을 때는 BPF 프로그램 적재, Map 정책 버전, identity 동기화, 노드 프록시와 애플리케이션 순서로 좁힐 수 있어야 합니다. 반대로 차단돼야 할 트래픽이 통과하면 fallback이 fail-open인지, unsupported protocol이 상위 계층으로 넘어갔는지 확인합니다.
새 구성을 운영할 팀이 이 질문에 정해진 시간 안에 답하지 못하면 자원 절감만으로 확대하기 어렵습니다. 파일럿 성공 조건에 평균 진단 시간과 롤백 시간을 넣는 이유입니다.
함께 읽으면 이해가 이어지는 글
- 사이드카를 없애도 될까: eBPF 서비스 메시의 경계와 선택 기준 — eBPF, Cilium이 파드별 프록시의 L3/L4 역할을 어디까지 줄일 수 있는지 살펴보고, mTLS, L7 라우팅, 관측 요구에 따라 사이드카 유지 여부를 판단합니다.
- eBPF는 사이드카를 어디까지 대체할까: XDP, Sockmap과 운영 비용의 경계 — 사이드카의 사용자 공간 경로를 eBPF의 XDP, Sockmap, BPF Map으로 옮길 때 줄어드는 비용과 그대로 남는 L7 기능, 커널, 검증기, 운영 역량의 교환을 설명합니다.
- Cilium으로 사이드카를 줄여도 될까: L4, L7 경계와 마이그레이션 — Cilium이 eBPF로 쿠버네티스 네트워크와 정책을 처리하는 구조를 살펴보고, 사이드카 없는 L4 경로와 L7 프록시가 남는 지점을 구분해 이관 기준을 정리합니다.
자주 묻는 질문
sidecarless 서비스 메시에는 프록시가 전혀 없나요?
반드시 그렇지는 않습니다. 파드별 프록시를 줄이면서 L7 처리가 필요한 트래픽만 노드 단위 프록시로 보내는 하이브리드 구성이 가능합니다.
eBPF만으로 mTLS 인증서 수명주기를 처리할 수 있나요?
데이터 경로 일부를 커널에서 처리할 수 있어도 신원 발급, 인증서 회전, 폐기, 감사 정책은 별도의 제어 계층과 검증이 필요합니다.
Istio 사이드카 제거 전에 무엇을 가장 먼저 확인해야 하나요?
현재 실제로 사용하는 메시 기능과 트래픽별 정책을 목록화하고 새 위치에서 동일 동작과 장애 복구를 재현할 수 있는지부터 확인해야 합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.