eBPF로 컨테이너 관찰 — Cilium·Pixie·Parca 실전 비교

핵심 요약

eBPF는 2026년 K8s 관찰성 사실상 표준. 사이드카 없이 커널 레벨에서 네트워크·시스템콜·CPU를 본다. Cilium·Pixie·Parca를 1년 운영하며 알아낸 적합 영역과 함정.

1. 셋 다 eBPF인데 영역이 다르다

2. Cilium Hubble — 네트워크 가시화

# 모든 파드 간 흐름 보기
hubble observe --follow

# HTTP 메서드별 에러율
hubble observe --protocol http --verdict FAILED

K8s NetworkPolicy를 L7까지 확장 (예: "GET /admin은 backend-team만 호출 가능"). 사이드카 없는 mTLS, 사이드카 없는 트래픽 메트릭이 강점.

3. Pixie — "이 요청 안에서 무슨 일이"

HTTP·gRPC·MySQL·Redis 등 L7 프로토콜을 디코딩해 보여줌. 코드 변경 없이 모든 요청 trace.

// PxL 스크립트 — 평균 응답시간 Top 10
df = px.DataFrame('http_events', start_time='-5m')
df = df.groupby('http_req_path').agg(p99=('latency', px.quantiles))
df = df.head(10)
px.display(df)

장점: APM 에이전트 0개. 단점: New Relic/Datadog 수준의 long-term 보관·알람은 별도.

4. Parca — Continuous CPU Profiling

# Helm 설치 후
# 모든 노드의 모든 프로세스를 19Hz로 샘플링
# 결과는 pprof 호환 → Grafana로 시각화

"갑자기 CPU 80%인데 왜?"를 14일 전 데이터까지 거슬러 본다. Flame graph로 함수 단위.

5. 오버헤드 실측 — 워커 노드

3개 모두 켜도 합쳐서 5% 이내. APM 사이드카 1개의 비용에 가깝다.

6. 커널 요구사항

• Cilium: 커널 5.10+ 권장
• Pixie: 4.14+
• Parca: 4.18+ (BPF CO-RE)

2026년 5월 기준 Ubuntu 22.04/24.04, RHEL 9 모두 OK. EKS·GKE·AKS도 기본 충족.

7. 실전 케이스 — 3건

케이스 1: 잡히지 않던 504

API 게이트웨이→백엔드 사이 504. APM 트레이스엔 없음. Hubble로 보니 TCP RST가 백엔드 측 컨테이너 종료 직후 발생. K8s 파드 종료 시 grace period가 짧았던 문제. terminationGracePeriodSeconds 30 → 60으로 해결.

케이스 2: 갑작스런 CPU 폭증

새벽 3시 CPU 80% spike. Parca로 거슬러 보니 cron으로 도는 백업 스크립트의 regex가 catastrophic backtracking. regex 단순화 후 −62%.

케이스 3: Redis 응답 느림

Pixie의 Redis L7 디코더로 보니 특정 키의 LRANGE가 5K 엘리먼트. 키 분할로 −83%.

8. 보안 — eBPF의 양면성

• 장점: 커널에서 모든 시스템콜을 감시 — Falco·Tetragon으로 컨테이너 런타임 보안
• 주의: eBPF 프로그램은 강한 권한. 누가 무엇을 적재하는지 통제 필수

9. 흔한 함정

• 커널 패닉 보고됨: 오래된 5.10 minor 버전에 eBPF 관련 패치 누락. 5.10.158+ 권장
• HTTP/2 디코드: 헤더 압축 때문에 일부 도구 한계. gRPC는 Pixie가 좋음
• TLS 트래픽: 페이로드는 못 봄 (당연). 메타데이터만
• GKE COS / Talos 같은 미니멀 OS: BPF type 정보(BTF) 호환 확인

10. 결정 가이드

참고

• cilium.io/blog/2025/* — Hubble L7 사례
• github.com/pixie-io/pixie
• parca.dev