26Y06n2
네, 결론부터 말씀드리면 1,000개 노드급 대규모 프로덕션 환경에서 Cilium을 운영할 때 자원 및 메모리 누수(Leak) 가능성은 명확히 존재하며, SRE 관점에서 주기적으로 추적해야 하는 핵심 대상입니다.
Cilium은 일반적인 CNI와 달리 커널 레벨의 eBPF(Extended Berkeley Packet Filter) 맵(Maps)과 유저스페이스의 Go 기반 에이전트(cilium-agent), 그리고 L7 프록시인 Envoy가 유기적으로 결합된 구조이기 때문에, 누수가 발생할 수 있는 레이어가 다차원적입니다. 특히 앞서 질문하신 호스트의 숨겨진 메모리 Used 상승 현상과도 밀접한 연관이 있습니다.
Cilium 환경에서 발생할 수 있는 주요 누수 유형과 아키텍처적 원인, 그리고 진단 방법을 정리해 드립니다.
1. Cilium에서 발생 가능한 4대 누수(Leak) 유형
① 커널 레벨: eBPF Map의 Stale Entries (잔여 가비지 데이터 누수) — 가장 빈번
Cilium은 커널 내부에서 패킷을 라우팅하고 정책을 검사하기 위해 고정된 크기의 eBPF 맵을 사용합니다. 대표적으로 연결 상태를 추적하는 Conntrack 맵(cilium_ct_any4)과 IP-Identity 매핑을 들고 있는 IP 캐시 맵(cilium_ipcache)이 있습니다.
- 누수 메커니즘: 파드가 엄청난 속도로 생성/소멸(High Pod Churn)하거나 네트워크 커넥션이 정상적으로 close되지 않고 유실(Ghost Connection)되면,
cilium-agent가 커널 맵에서 해당 엔트리를 지우지 못하는 Stale Entry 누수가 발생합니다. - 여파: 이는 물리 메모리를 직접적으로 대량 고갈시키지는 않지만, eBPF 맵의 용량 제한(
map-full)을 유발하여 신규 파드가 네트워크 통신이 불가능해지는 치명적인 장애로 이어집니다.
② 시스템 레벨: BPF 가상 가비지 및 파일 디스크립터(FD) 누수
v1.14~v1.16+ 등 최신 Cilium 버전으로 오면서 eBPF 프로그램 장착 방식이 개선되었으나, 과거 버전이나 특정 Linux 커널 커스텀 빌드 환경에서는 bpf_link나 소켓 옵션(sockops) 런타임 분리 시 릭이 보고되곤 했습니다.
- 누수 메커니즘: 파드가 제거될 때 해당 파드의 소켓 가속을 위해 커널에 훅을 걸어둔 bpf 프로그램이나 파일 디스크립터가 온전히 반환되지 않고 커널 커널 메모리(
vmalloc영역)에 좀비 형태로 남는 현상입니다. 직전에 분석하신free -h수식에서 프로세스 RSS에 잡히지 않던 Used 영역의 주범 중 하나가 될 수 있습니다.
③ 유저스페이스 계층: cilium-agent Go 힙(Heap) 및 Goroutine 누수
노드마다 데몬셋으로 뜨는 cilium-agent는 쿠버네티스 API 서버의 대량 이벤트(Pod, Endpoint, NetworkPolicy 등)를 감시(Watch)하는 Go 어플리케이션입니다.
- 누수 메커니즘: 1,000노드급 클러스터에서 네트워크 정책(CiliumNetworkPolicy)이 빈번하게 변경되거나 멀티 클러스터(Clustermesh) 간 동기화 지연이 발생하면, 에어갭 내부의 특정 에러 핸들링 로직 오작동으로 인해 이벤트 큐를 처리하던 Goroutine이 종료되지 않고 백그라운드에 무한 누적될 수 있습니다.
- 여파:
cilium-agent파드의 RSS 메모리가 매일 조금씩 우상향하는 전형적인 메모리 릭 형태로 나타납니다.
④ 네트워크 계층: Cilium Security Identity 누수
Cilium은 IP 기반이 아닌 락이 없는 정수형 ID(Security Identity) 기반으로 정책을 통제합니다.
- 누수 메커니즘: 파드가 죽으면 해당 파드가 쓰던 Identity 자원도 CRD 및 아키텍처 상의 Key-Value 스토어(etcd 등)에서 해제되어야 합니다. 그러나 에어갭 사내망의 일시적인 네트워크 찰나의 순단으로 인해 동기화가 깨지면, 주인 잃은 구세대 Identity들이 전사 클러스터 노드들의
cilium_ipcache맵에 동기화된 채 유령 자산으로 잔존하게 됩니다.
2. SRE 관점의 Cilium 누수 진단 및 무결성 검증 가이드 (Playbook)
Cilium에 의한 커널 및 시스템 누수가 의심될 때, 노드 배스천 및 에이전트 내부에서 즉시 실행해 보아야 하는 실무 명령 세트입니다.
🛠️ 진단 Step 1. eBPF 맵의 가비지 적체량 확인 (Stale Entry 추적)
특정 노드의 cilium-agent 팟 내부로 진입하여 글로벌 커넥션 추적(Conntrack) 맵의 현재 사용량과 유효 기간을 검사합니다.
# Cilium 에이전트 팟 내부에서 BPF Conntrack 맵 상태 요약 출력
cilium bpf ct list global | head -n 20
# 만약 죽은 파드의 IP가 여전히 ipcache에 수 분 이상 남아있는지 대조 검증
cilium bpf ipcache list | grep <소멸된_파드_IP>
- 만약 수 시간이 지난 연결 기록이나 이미 삭제된 파드의 IP 정보가 수천 개 이상 출력된다면, Cilium 내부의 Garbage Collector(GC) 커널 타이머 로직이 병목을 겪고 있는 상태입니다.
🛠️ 진단 Step 2. 커널 단의 BPF 메모리 실제 점유율 추적
Linux 커널 5.11+ 이상부터는 bpftool을 이용해 eBPF 프로그램과 맵이 소비하는 순수 물리 메모리 용량을 바이트 단위로 정확히 진수해 낼 수 있습니다.
# 커널에 로드된 모든 bpf 맵의 메모리 점유율(memlock)을 확인하고 내림차순 정렬
bpftool map show | grep -E "name|memlock" | awk '{print $0}'
- 이 합산 수치가 수십 GB를 넘어간다면, 앞서 확인하신 호스트의
Used메모리 중 상당수가 eBPF 인프라 레이어에 고정 결착되어 누수되고 있음을 물리적으로 증명하는 근거가 됩니다.
🛠️ 진단 Step 3. 유저스페이스 릭 추적 (Go pprof 및 Metrics)
cilium-agent 파드 자체의 메모리가 새고 있는지 프로파일링 메트릭을 조사합니다.
# 에이전트가 노출하는 프로메테우스 메트릭 중 BPF 맵 메모리 가드레일 추적
curl -s http://localhost:9090/metrics | grep -E "cilium_bpf_maps_virtual_memory|cilium_goroutines"
cilium_goroutines: 이 지표가 하루 주기로 계속 우상향한다면 100% 고루틴 누수 상태입니다.
3. 대규모 온프레미스 환경을 위한 최적화 및 방어 전략
- Conntrack GC 주기 보수적 튜닝 (
configmap보정)
- 대량의 분산 쿼리와 쇼트 커넥션이 쏟아지는 환경에서는 Cilium의 기본 가비지 컬렉션 주기(
conntrack-gc-interval)가 2분~5분 단위로 너무 길면 순간적으로 맵이 터질 수 있습니다. 이를 30초~1분 단위로 촘촘하게 좁혀주어 커널 맵의 순환 속도를 강제로 가속화하십시오.
cilium-agent자동 자가 치유(OOM Guard) 가드레일 설정
- Go 런타임 계층의 미세한 누수로 인해 에이전트가 노드의 RAM을 잠식하는 것을 막기 위해, Cilium 데몬셋 매니페스트에 보수적인
resources.limits.memory(예: 4Gi~8Gi)를 강제 설정하십시오. 에이전트가 혹여 릭으로 인해 한계치에 다다르면 쿠버네티스가 에이전트를 사살 후 재기동(Restart)시키면서, 커널 맵은 유지하되 유저스페이스의 좀비 고루틴과 힙 가비지를 순간적으로 깨끗하게 청소해 주는 안전장치가 됩니다.
