eBPF가 바꾸는 것과 바꾸지 않는 것

eBPF는 커널 기능을 확장하는 프로그램을 지원하지만 커널 모듈 전체를 대체하지는 않습니다. 프로그램은 특정 유형의 훅과 커널이 허용하는 helper·기능 범위에 묶입니다. 로드 과정에서 verifier는 레지스터와 스택의 초기화 여부, 포인터 유형과 접근 범위, 컨텍스트별 허용 접근, helper 인자 같은 제약을 검사합니다. 통과는 이 제약을 만족한다는 뜻이지 정책이 올바르거나 모든 런타임 오류가 불가능하다는 보증은 아닙니다. 프로그램 유형, 권한, 커널 버전과 설정에 따라 지원 범위와 로드 결과가 다릅니다.

현대 커널은 조건이 맞는 제한된 반복을 지원할 수 있지만, 모든 커널에서 모든 반복문이 허용된다는 뜻은 아닙니다. verifier의 복잡도 한계나 상태 추적으로 로드가 거절될 수도 있습니다. 배포 대상과 같은 커널에서 실제 로드하고 verifier 로그를 확인해야 합니다. JIT는 활성화·아키텍처·정책에 따라 바이트코드를 네이티브 명령으로 변환할 수 있으며, 변환 자체가 성능 목표 달성을 보장하지 않습니다.

훅 위치가 관측 결과를 바꾼다

추적 프로그램은 tracepoint, kprobe, uprobe 등 목적별 부착 지점과 프로그램 유형을 고릅니다. 해당 지점이 모든 커널에 존재하거나 같은 의미를 갖는다고 가정하지 말고, 대상 커널의 BTF·프로그램 유형·helper 지원 및 권한을 확인하세요. BPF map도 모두 “락 없이 교환되는 테이블”은 아닙니다. 유형에 따라 접근·동시성 의미가 달라지므로 공유 카운터의 갱신 방식, 사용자 공간 소비 속도와 이벤트 유실을 따로 살펴야 합니다.

네트워크의 XDP에는 세 모드가 있습니다. native XDP는 지원 드라이버의 이른 수신 경로, generic XDP는 네트워크 스택에 더 들어간 뒤, offload는 지원 NIC 하드웨어에서 실행됩니다. Cilium의 XDP 가속도 설정과 장치 지원에 좌우됩니다. XDP에서 처리된 패킷은 더 뒤쪽 지점의 tcpdump에 나타나지 않을 수 있으므로, 캡처가 없다는 사실만으로 패킷이 처리되지 않았다고 결론내리지 마세요.

가상 장애조사: 이벤트가 보이지 않을 때

다음은 절차를 설명하기 위한 가상 사례이며 측정 결과가 아닙니다. 운영자가 Cilium 노드에서 기대한 NodePort 패킷을 tcpdump로 찾지 못했다고 가정합니다.

확인 순서관측할 증거해석과 다음 확인
1. 실제 부착 지점ip link의 XDP 상태, cilium status의 XDP 가속 상태, 인터페이스 드라이버native/generic/offload 여부와 기대한 장치에 붙었는지 확인합니다. 상태가 다르면 우선 설정·드라이버 지원 문제를 조사합니다.
2. 캡처 위치패킷 처리 경로에서 tcpdump가 붙은 지점과 XDP 통계native XDP에서 먼저 처리되면 뒤쪽 캡처 지점에 패킷이 없을 수 있습니다. XDP 전후에 맞는 카운터·관측 지점을 선택합니다.
3. 프로그램 로드프로그램 유형, verifier 로그, 커널 버전과 권한로드 거절은 메모리/타입 검증이나 미지원 기능일 수 있습니다. 로그의 첫 거절 지점과 대상 커널 기능을 대조합니다.
4. 부하와 유실처리량·CPU, map 갱신 경합, ring buffer 유실/소비 지연이벤트가 누락되면 버퍼 크기만 키우기 전에 생산률, 소비율, 이벤트 크기와 수집 비용을 함께 봅니다.

먼저 관측 질문 하나와 최소한의 훅을 정하고, 격리된 대상 커널에서 로드·카운터·유실을 확인하세요. 이후 대표 부하에서 기준선과 eBPF 활성 상태의 CPU 및 지연을 비교합니다. 이 문서에는 실제 커널 로드, Cilium 배포 또는 성능 벤치마크를 수행했다는 주장이 없습니다.

자료: Linux eBPF verifier, Linux BPF design Q&A, Cilium XDP program types, Cilium XDP acceleration