eBPF 모니터링이란? 코드 수정 없이 쿠버네티스 옵저버빌리티 구축하기

쿠버네티스 클러스터 하나에 수십 개의 서비스가 올라가면 모든 서비스에 같은 방식으로 모니터링을 적용하기 어렵습니다. 애플리케이션 내부의 처리 과정을 데이터로 남기려면 보통 서비스마다 기록할 에이전트나 라이브러리를 설치해야 하기 때문입니다. 직접 개발한 서비스에는 언어 에이전트나 OpenTelemetry SDK를 붙일 수 있지만, 다른 팀이 운영하거나 벤더가 컨테이너 이미지로 제공한 서비스에는 코드와 배포 권한이 없을 수 있습니다. 데이터를 보고 싶어도 계측을 시작할 방법부터 막히는 것입니다.

이런 사각지대를 줄이는 방법으로 eBPF 기반 무계측 모니터링(eBPF 옵저버빌리티)이 주목받고 있습니다. Grafana Labs가 개발하던 Beyla는 2025년 OpenTelemetry에 기증됐고, OpenTelemetry eBPF Instrumentation(OBI)의 첫 알파 릴리스로 공개됐습니다. 현재는 OpenTelemetry의 무코드 계측(zero-code instrumentation) 구성요소로 관리되고 있습니다.

'무계측'이라는 말은 아무 계측도 하지 않는다는 뜻이 아닙니다. 개발자가 애플리케이션 코드를 수정하지 않는다는 뜻입니다. OBI는 애플리케이션 프로세스 밖에서 eBPF 프로그램을 이용해 실행 파일과 운영체제의 네트워크 계층을 관찰하고, 지원하는 프로토콜의 메트릭과 트레이스를 만듭니다.

그렇다면 코드 안에 들어가지 않고 어디까지 볼 수 있을까요? 그리고 이미 쓰고 있는 언어 에이전트를 대체할 수 있을까요? 답은 '클러스터를 넓게 보는 데는 유리하지만, 애플리케이션 안쪽을 깊게 보는 일까지 모두 대체하지는 못한다'입니다.

‍

eBPF 무계측 모니터링은 어떻게 동작하나

애플리케이션이 네트워크로 데이터를 보내거나 파일을 읽고 프로세스를 실행할 때 운영체제의 커널을 거칩니다. 커널은 애플리케이션과 CPU·메모리·네트워크 같은 시스템 자원 사이에서 요청을 처리하는 핵심 영역입니다. 여러 애플리케이션의 통신과 시스템 동작이 커널을 지나기 때문에 커널에서 이벤트를 관찰하면 개별 애플리케이션의 코드를 열어 보지 않아도 공통된 동작을 확인할 수 있습니다.

eBPF(extended Berkeley Packet Filter)는 리눅스 커널의 특정 이벤트에 작은 프로그램을 연결해 실행하는 기술입니다. 리눅스가 처리하는 주요 지점에 관찰 장치를 덧붙이는 방식입니다. 이름은 패킷 필터링 기술에서 시작했지만, 현재는 네트워크 패킷뿐 아니라 시스템 호출, 프로세스 실행, 커널 함수와 사용자 영역 라이브러리의 동작까지 관찰하는 데 쓰입니다.

커널에서 임의의 프로그램이 실행되면 시스템 전체에 영향을 줄 수 있습니다. 그래서 eBPF 프로그램을 올리기 전에는 검증기(verifier)가 프로그램이 정상적으로 끝나는지, 허용되지 않은 메모리에 접근하지 않는지, 초기화하지 않은 값을 사용하지 않는지 검사합니다. 검증을 통과한 프로그램만 실행됩니다. 검증기를 거치는 구조 덕분에 커널 소스를 수정하거나 별도의 커널 모듈을 설치하지 않고도 관찰 기능을 추가할 수 있습니다. 자세한 원리는 eBPF 공식 소개에서 확인할 수 있습니다.

‍

에이전트는 프로세스 안에서, eBPF는 밖에서

모니터링에서 계측(instrumentation)은 애플리케이션의 동작을 메트릭이나 트레이스로 기록할 수 있도록 관찰 지점을 넣는 작업입니다. 일반적인 언어 에이전트는 애플리케이션 프로세스 안에서 프레임워크와 라이브러리의 동작을 추적하고, SDK 수동 계측은 개발자가 코드에 직접 스팬(요청 처리의 한 구간을 기록한 단위)과 속성을 추가합니다.

eBPF 무계측 모니터링은 관찰 지점을 애플리케이션 코드가 아니라 노드에 설치한 수집기 쪽에 둡니다. 언어 에이전트는 애플리케이션 안에서 메서드와 라이브러리의 동작을 보고, eBPF 수집기는 애플리케이션 밖에서 요청과 응답이 오가는 경계를 봅니다. 관찰 지점이 프로세스 밖에 있으므로 eBPF는 여러 서비스를 넓게 관찰하기 쉽지만, 코드 안에서만 알 수 있는 업무 로직까지 자동으로 알아내지는 못합니다.

계측 위치에 따라 관찰 범위가 달라지는 것을 세 단계로 정리한 표. 프로세스 밖의 eBPF 수집기는 요청과 응답이 오가는 경계에서 요청 수·오류·소요 시간과 서비스 호출 관계, 네트워크 흐름을 얻고, 프로세스 안의 언어 에이전트는 프레임워크와 라이브러리의 동작과 메서드 실행 시간·쿼리를 보며, 코드 안의 SDK 수동 계측은 개발자가 직접 지정한 커스텀 스팬과 테넌트·요금제 같은 업무 속성을 남깁니다. — *관찰 지점에 따라 수집할 수 있는 데이터의 깊이가 달라집니다.*

‍

실제 데이터가 만들어지는 과정

주문 서비스가 결제 서비스를 HTTP로 호출한다고 가정해 보겠습니다. eBPF 수집기는 주문 코드의 함수 이름을 읽는 대신, 주문 서비스에서 결제 서비스로 요청이 나갔고 320ms 뒤에 오류 응답이 돌아왔다는 사실을 관찰합니다. 이를 바탕으로 요청 수, 오류율, 처리 시간과 두 서비스의 호출 관계를 만듭니다.

이 과정을 OBI 기준으로 나누면 다음 순서가 됩니다.

노드에서 실행 중인 프로세스를 찾아 어떤 애플리케이션을 관찰할지 선택합니다.
애플리케이션 실행 파일과 네트워크 계층의 지정 지점에 eBPF 프로브를 연결합니다.
프로브가 요청의 시작과 종료, 오류, 소요 시간, 통신 상대와 프로토콜 정보를 포착합니다.
수집한 이벤트를 HTTP 요청이나 데이터베이스 호출 같은 하나의 트랜잭션으로 구성합니다.
그 결과를 OpenTelemetry 메트릭과 트레이스로 만들어 Collector나 모니터링 백엔드로 보냅니다.

이 과정에서는 애플리케이션 소스 코드에 계측 라이브러리를 넣지 않습니다. 서비스 코드를 다시 빌드하거나 재배포하지 않고도 다음 데이터를 얻을 수 있습니다.

요청 수, 오류 수, 처리 시간으로 구성한 RED 메트릭
지원 프로토콜의 클라이언트·서버 스팬
서비스 사이의 호출 관계와 서비스 그래프
바이트 수, 패킷 수, TCP 왕복 시간과 재전송 같은 네트워크 흐름 정보
쿠버네티스 네임스페이스, 파드, 컨테이너와 같은 리소스 속성

'네트워크 패킷만 보면 HTTPS는 읽을 수 없는 것 아닌가?'라는 의문이 생길 수 있습니다. 관찰 지점을 네트워크가 아니라 그 앞단에 두기 때문에 가능합니다.

애플리케이션이 데이터를 내보낼 때는 암호화 라이브러리 함수를 먼저 거치는데, 그 함수의 입구에는 아직 암호화되지 않은 평문이 인자로 들어옵니다. 받을 때는 반대로 복호화가 끝난 데이터가 나옵니다. eBPF는 커널 함수뿐 아니라 사용자 영역 함수에도 관찰 지점을 걸 수 있고, 이를 uprobe라고 부릅니다. OBI 문제 해결 문서는 OBI가 Go 애플리케이션과 TLS 요청을 계측할 때 uprobe를 사용한다고 밝히고 있습니다. 암호를 푸는 것이 아니라 암호화되기 전과 풀린 뒤를 보기 때문에 키가 필요 없습니다. 그래서 공식 문서가 명시한 지원 범위에서는 TLS·SSL 트랜잭션을 복호화하지 않고 관측할 수 있습니다.

다만 암호화된 요청을 관측하는 것과 여러 서비스를 하나의 분산 트레이스로 끝까지 연결하는 것은 다른 문제입니다. 추적 연결의 제약은 뒤의 '한계 다섯 가지' 3번에서 다룹니다.

‍

eBPF 무계측 모니터링으로 얻는 세 가지

1. 여러 언어의 서비스에 기본 지표를 한 번에 확보한다

OBI 문서는 Java(JDK 8 이상), .NET, Go, Python, Ruby, Node.js, C, C++, Rust를 지원 대상으로 안내합니다. HTTP/S, HTTP/2, gRPC, Kafka, NATS, MQTT를 비롯한 프로토콜과 PostgreSQL, MySQL, MSSQL, Redis 같은 데이터베이스 호출도 수집합니다. 프로토콜과 기능마다 지원 범위가 다르므로, 적용할 서비스가 실제로 지원 대상인지는 OBI 계측 호환성 표에서 미리 확인할 수 있습니다.

OBI가 모든 언어의 내부 동작을 똑같이 해석하지는 않습니다. 대신 서로 다른 언어로 만든 서비스라도 HTTP 요청 수, 오류, 소요 시간처럼 프로토콜 경계에서 공통으로 보이는 데이터를 같은 방식으로 확보할 수 있습니다.

2. 코드와 배포 권한이 없는 서비스도 관찰 범위에 넣는다

언어 에이전트는 보통 서비스별로 시작 옵션이나 환경 변수를 설정하고 프로세스를 다시 시작해야 합니다. SDK로 직접 계측하려면 소스 코드를 수정하고 다시 빌드·배포해야 합니다. 반면 OBI는 노드에 배치한 수집기가 그 노드에서 실행 중인 대상을 찾는 방식입니다. 지원 조건을 충족한다면 벤더 이미지, 오래된 서비스, 담당 팀이 다른 서비스도 애플리케이션을 다시 배포하지 않고 관찰할 수 있습니다.

3. 클러스터의 호출 관계를 먼저 파악한다

장애가 발생했을 때 처음 필요한 정보가 항상 메서드 단위 분석인 것은 아닙니다. 어떤 서비스가 어떤 서비스를 호출하는지, 오류가 어느 구간에서 나왔는지, 지연이 어느 서비스 사이에서 발생했는지부터 확인하는 경우가 있습니다.

eBPF 기반 도구는 이런 관계를 클러스터 단위로 파악하는 데 적합합니다. 같은 기술을 네트워크 관측에 활용하는 Cilium Hubble도 서비스 의존 관계, HTTP 호출, 응답 코드, 서비스 간 지연을 애플리케이션 변경 없이 보여 줍니다. eBPF 수집은 특정 서비스를 깊게 해부하기 전에 전체 호출 구조와 사각지대를 빠르게 드러냅니다.

‍

eBPF 모니터링 도입 전에 확인할 한계 다섯 가지

넓은 관찰 범위를 얻는 대신 운영 환경이 충족해야 할 조건과 데이터 깊이의 한계가 있습니다. 설치 전에 확인할 항목은 다섯 가지입니다.

1. 지원하는 운영체제와 커널 조건이 정해져 있다

리눅스 커널이 일정 버전 이상이어야 하고, 같은 관리형 쿠버네티스라도 노드 이미지에 따라 결과가 달라집니다. OBI 호환성 문서가 요구하는 조건은 다음과 같습니다.

리눅스 amd64 또는 arm64
리눅스 커널 5.8 이상
필요한 eBPF 백포트가 적용된 RHEL 계열은 커널 4.18 이상
커널 타입 정보인 BTF 활성화

기본 수집 조건을 충족하더라도 기능별 요구 사항은 더 높을 수 있습니다. 예를 들어 네트워크 수준에서 들어오는 추적 정보를 처리하는 기능은 분산 추적 문서 기준으로 커널 5.17 이상이 필요합니다.

따라서 '쿠버네티스를 쓰는가'보다 '실제 워커 노드의 운영체제, 커널 버전, BTF 설정이 무엇인가'를 먼저 확인해야 합니다.

2. 호스트를 관찰할 수 있는 높은 권한이 필요하다

프로세스 밖에서 다른 프로세스의 커널 이벤트를 관찰하려면 일반 애플리케이션 파드보다 넓은 접근 권한이 필요합니다. 따라서 기술 검증에 앞서 보안 정책부터 확인해야 합니다. OBI 보안 문서에 따르면 애플리케이션 관측에는 기능 구성에 따라 CAP_BPF, CAP_DAC_READ_SEARCH, CAP_CHECKPOINT_RESTORE, CAP_PERFMON, CAP_NET_RAW, CAP_SYS_PTRACE 등이 필요합니다. 네트워크 수준의 추적 정보 전파를 사용하면 CAP_NET_ADMIN도 필요합니다.

쿠버네티스 설치 문서를 보면, 데몬셋(모든 노드에 파드를 하나씩 띄우는 배포 방식)으로 전체 프로세스를 찾을 때 hostPID: true를 사용합니다. 분산 추적 문서는 네트워크 수준의 추적 전파를 켤 때 hostNetwork: true와 호스트 /sys/fs/cgroup 마운트도 함께 요구합니다. 런타임과 보안 설정에 따라 개별 권한(capability) 대신 privileged: true나 CAP_SYS_ADMIN을 요구할 수 있습니다. 특히 AKS와 EKS는 kernel.perf_event_paranoid 기본값 때문에 CAP_PERFMON만으로 충분하지 않을 수 있습니다. 여기에 더해 OBI 문제 해결 문서는 최근 커널 보안 변경이 여러 구버전 커널에도 백포트되면서 uprobe 자체가 CAP_SYS_ADMIN을 요구하게 됐다고 안내합니다. HTTPS와 Go 애플리케이션 계측은 uprobe에 의존하므로, 이 둘이 필요하면 CAP_SYS_ADMIN을 전제로 검토하는 편이 안전합니다.

특권 컨테이너, 호스트 PID 접근, CAP_SYS_ADMIN을 금지하는 조직이라면 어떤 배포 구성이 허용되는지부터 보안팀과 확인하게 됩니다.

3. 스팬은 수집해도 분산 트레이스가 항상 끝까지 이어지지는 않는다

한 서비스의 요청 스팬을 얻는 것과 여러 서비스의 스팬을 같은 trace ID로 연결하는 것은 다릅니다. trace ID는 요청 하나에 붙는 공통 식별자입니다. 서비스 사이를 지날 때 이 값이 함께 넘어가야 흩어진 스팬이 하나의 요청으로 이어집니다. 분산 트레이스를 만들려면 다음 서비스로 추적 문맥(trace context)을 전달하고, 수신한 서비스가 그 값을 읽어야 합니다. 추적 문맥은 trace ID를 포함해 다음 서비스로 넘기는 값입니다.

OBI 분산 추적 문서에 따르면 일반 HTTP에서는 OpenTelemetry SDK와 호환되는 헤더 전파를 사용할 수 있습니다. 그러나 HTTPS에서는 OBI가 암호화된 HTTP 헤더에 추적 정보를 직접 넣을 수 없어 TCP/IP 수준의 전파를 사용합니다. 이때 추적 정보는 다른 OBI 계측 서비스로만 전달할 수 있고, L7 프록시(HTTP 같은 애플리케이션 계층까지 해석하는 프록시)나 로드 밸런서가 패킷을 종료한 뒤 새 연결을 만들면 전파가 끊깁니다.

비동기 처리 방식도 영향을 줍니다. 요청 처리가 프레임워크 내부 큐, 복잡한 스레드 풀, 이벤트 루프로 넘어가면 들어온 요청과 나가는 호출의 부모·자식 관계를 eBPF 관찰 지점만으로 연결하지 못할 수 있습니다. 중간에 프록시를 두거나 비동기 처리를 많이 쓰는 환경이라면 대표 요청을 실제 경로로 보내 트레이스가 어디까지 이어지는지 확인해야 합니다.

4. 프로세스 안에서만 만들어지는 업무 맥락은 자동으로 알 수 없다

eBPF 수집으로 HTTP 경로, 상태 코드, 데이터베이스 호출 같은 프로토콜 정보는 얻을 수 있습니다. 그러나 다음 정보는 애플리케이션이 직접 알려 주지 않으면 알기 어렵습니다.

어떤 메서드와 내부 로직에서 시간이 걸렸는지
주문 등급, 테넌트, 요금제 같은 업무 속성
개발자가 정의한 커스텀 스팬과 비즈니스 이벤트
프로토콜 경계에 나타나지 않는 큐 대기나 계산 구간

업무 맥락을 얻지 못하는 것은 수집 실패가 아니라 관찰 위치의 차이입니다. 프로세스 밖에서는 통신이 일어난 사실은 볼 수 있지만, 애플리케이션이 그 요청을 어떤 의미로 처리했는지까지 자동으로 복원할 수는 없습니다. OBI 공식 문서는 커스텀 스팬, 애플리케이션 고유 속성, 비즈니스 이벤트가 필요하면 언어 에이전트나 수동 계측을 사용하라고 안내합니다.

5. 아직 안정화 이전 단계다

OBI는 아직 0.x 대에 머물러 있습니다. OBI 저장소는 프로젝트가 v0에 머무는 동안 마이너 릴리스 사이에도 설정, 동작, 지원 환경, 내보내는 관측 데이터가 바뀔 수 있다고 안내합니다. 운영 환경에서 검토한다면 latest 대신 특정 버전을 고정하고, 업그레이드 전에 릴리스 노트를 함께 봅니다. 현재 상태와 최신 버전은 OBI 릴리스 목록에서 확인할 수 있습니다.

OpenTelemetry가 발표한 OBI의 2026년 목표에도 운영 환경 투입을 의미하는 안정 버전 1.0이 포함돼 있습니다. 1.0 목표는 발전 속도가 빠르다는 뜻인 동시에, 현재 버전을 이미 안정된 1.x 구성요소처럼 다루기는 이르다는 뜻입니다.

‍

eBPF, 언어 에이전트, SDK는 무엇이 다른가

'에이전트 계측'과 'SDK 수동 계측'을 같은 것으로 취급하면 선택 기준이 흐려집니다. 언어 에이전트는 소스 코드를 대체로 고치지 않아도 되지만, 보통 서비스의 시작 설정을 바꾸고 재시작해야 합니다. SDK는 원하는 업무 맥락을 가장 정확하게 넣을 수 있지만 코드 수정과 재배포가 필요합니다.

기준	eBPF 무계측 수집	언어 에이전트·자동 계측	SDK 수동 계측
소스 코드 수정	없음	대체로 없음	필요
서비스 재시작·재배포	없음	대체로 필요	필요
적용 단위	노드·클러스터	서비스·런타임	코드 경로
주로 보이는 범위	프로토콜 경계, 서비스 관계, 네트워크 흐름	지원 프레임워크·라이브러리, 쿼리, 일부 메서드	개발자가 정의한 모든 구간
업무 속성 추가	자동 수집에는 한계	지원 범위 안에서 가능	직접 설계 가능
주요 환경 조건	리눅스 커널, BTF, 높은 권한	지원 언어·런타임 버전	지원 SDK와 코드 변경 권한
잘 맞는 목적	전체 관찰 범위와 사각지대 해소	핵심 서비스의 원인 분석	비즈니스 맥락과 커스텀 추적

세 방식은 서로 대체재라기보다 관찰 깊이를 단계적으로 더하는 수단입니다. eBPF로 전체 서비스의 기본 지표와 호출 관계를 확보하고, 장애 영향이 크거나 원인 분석이 필요한 서비스에는 언어 에이전트를 유지하며, 업무 속성이 필요한 구간만 SDK로 보강할 수 있습니다.

‍

상황별 선택 기준

다음 질문에 답하면 어떤 방식부터 적용할지 정하기 쉽습니다.

코드와 배포 권한이 있는가: 벤더 이미지나 다른 팀 서비스처럼 코드와 배포 권한이 없다면 eBPF가 우선 후보입니다. 반대로 핵심 서비스의 코드와 배포 주기를 통제할 수 있다면 언어 에이전트나 SDK를 함께 검토할 수 있습니다.
필요한 답이 '어디가 느린가'인가, '왜 느린가'인가: 어떤 서비스 사이에서 지연과 오류가 생겼는지 찾는 것이 먼저라면 eBPF가 빠릅니다. 특정 요청이 어느 메서드, 프레임워크, SQL에서 시간을 썼는지 알아야 한다면 해당 런타임을 지원하는 언어 에이전트의 상세 추적 설정이 필요합니다. 테넌트나 주문 금액 같은 업무 조건별 원인을 분석하려면 SDK로 속성을 추가해야 합니다.
보안 정책이 호스트 접근을 허용하는가: 조직이 특권 컨테이너, hostPID, CAP_SYS_ADMIN을 허용하지 않는다면 eBPF 도입이 기술적으로 가능해도 운영 승인을 받기 어려울 수 있습니다. 이 경우 서비스별 언어 에이전트가 현실적인 선택입니다.
전체를 한 방식으로 통일해야 하는가: 그럴 필요는 없습니다. 코드 접근이 어려운 서비스와 기본 지표만 필요한 서비스는 eBPF로 수집하고, 핵심 서비스는 기존 에이전트와 커스텀 스팬을 유지하는 것이 한 가지 조합입니다. 다만 같은 구간을 두 방식으로 동시에 계측하면 같은 요청이 두 번 수집될 수 있으므로, 어느 서비스를 어느 방식에 맡길지 범위를 나눠 두는 편이 안전합니다.

‍

도입 전 검증 순서

코드 수정이 없다고 수집 부하까지 없는 것은 아닙니다. eBPF는 수집 작업을 애플리케이션 밖으로 옮기는 방식이므로, 실제 트래픽에서 CPU·메모리 사용량과 데이터 누락 여부를 측정해야 합니다.

확인 항목을 실행 순서로 옮기면 다음 일곱 단계입니다.

노드 확인: 운영체제, CPU 아키텍처, 커널 버전, BTF
권한 목록 작성: 권한(capability), hostPID, hostNetwork, cgroup 마운트
보안 승인: 파드 보안 정책, 관리형 쿠버네티스의 노드 설정
추적 연결 시험: 서비스 메시와 프록시를 지나는 대표 요청 경로
도구 충돌 확인: 기존 Cilium 등 다른 eBPF 도구의 부착 지점 (아래 FAQ 참고)
부하 측정: 수집 누락, CPU·메모리 사용량, 데이터 카디널리티
버전 고정: 운영 환경 배포 버전과 업그레이드 절차

‍

마치며

eBPF 무계측 모니터링으로 코드를 고치지 않고 클러스터의 관찰 범위를 빠르게 넓힐 수 있습니다. 특히 코드 권한이 없는 서비스, 아직 계측하지 못한 서비스, 전체 호출 관계를 먼저 파악해야 하는 환경에서 유용합니다.

대신 리눅스 커널과 높은 권한을 요구하고, 프록시와 비동기 처리 방식에 따라 분산 추적이 끊길 수 있으며, 프로세스 안에서만 알 수 있는 업무 맥락은 자동으로 얻지 못합니다. 따라서 판단할 것은 eBPF와 에이전트 중 하나를 고르는 문제가 아니라, 지금 필요한 답이 프로토콜 경계에 있는지 코드 안쪽에 있는지입니다.

와탭 APM은 서비스 사이의 호출 관계를 애플리케이션 토폴로지로 그리고, 요청 하나가 지난 구간은 히트맵/트레이스 분석으로 기록합니다. 다만 두 화면은 에이전트를 붙인 서비스가 대상입니다. 코드 권한이 없는 구간까지 넓히려면 이 글에서 다룬 무계측 방식이 필요합니다.

‍

자주 묻는 질문

eBPF 수집을 켜면 언어 에이전트를 걷어내도 되나요

서비스 사이의 요청량, 오류, 소요 시간과 호출 관계만 필요하다면 일부 서비스는 eBPF만으로 운영할 수 있습니다. 그러나 트랜잭션 하나를 메서드와 SQL 단위로 나누거나 업무 속성을 붙여야 하는 핵심 서비스에는 언어 에이전트나 SDK가 계속 필요합니다. 먼저 에이전트를 제거하기보다 eBPF로 기존 사각지대를 채운 뒤, 데이터가 중복되는 서비스만 목적에 따라 조정하는 편이 안전합니다.

HTTPS로 암호화된 통신도 볼 수 있나요

보입니다. 지원하는 런타임과 라이브러리 범위에서는 복호화 없이 TLS·SSL 트랜잭션을 관측합니다. 다만 이 관측은 uprobe에 의존합니다. 최근 커널 보안 변경이 적용되거나 백포트된 환경에서는 uprobe 연결에 CAP_SYS_ADMIN이나 특권 실행이 필요할 수 있으므로, 실제 노드에서 연결되는지 확인해야 합니다. '요청이 보인다'와 '분산 트레이스가 끝까지 이어진다'는 다른 문제입니다. 분산 트레이스 연결은 '한계 3번'에서 다룹니다.

우리 클러스터가 eBPF 수집 조건을 만족하는지 어떻게 확인하나요

워커 노드에 접속해 세 가지를 봅니다. 커널 버전은 uname -r, BTF 활성화 여부는 /sys/kernel/btf/vmlinux 파일이 있는지, 권한 제약은 sysctl kernel.perf_event_paranoid 값으로 확인합니다. 기본값은 보통 2이고, 이보다 높게 설정한 배포판(Debian은 3)에서는 값을 2로 낮추거나 CAP_PERFMON 대신 CAP_SYS_ADMIN을 씁니다. AKS와 EKS는 별도로, 기본값이 1보다 커서 OBI에 CAP_SYS_ADMIN이 필요하다고 공식 문서가 명시합니다. 관리형 쿠버네티스는 서비스 이름이 아니라 실제 노드 이미지에 따라 결과가 달라지므로 노드에서 직접 확인해야 합니다. 세 가지를 통과해도 조직의 파드 보안 정책은 별도로 남으므로 보안팀 확인이 함께 필요합니다.

Cilium을 쓰는 클러스터에 OBI를 함께 올려도 되나요

가능하지만 부착 방식을 확인해야 합니다. Cilium과 OBI는 모두 트래픽 제어(TC) 지점에 eBPF 프로그램을 연결합니다. OBI의 Cilium 호환성 문서에 따르면 커널이 TCX(eBPF 프로그램을 트래픽 제어 지점에 붙이는 최신 방식)를 지원하고 두 도구가 TCX를 사용하면 OBI는 체인의 앞쪽에, Cilium은 뒤쪽에 연결돼 서로 간섭하지 않습니다. TCX를 사용할 수 없어 Netlink 방식으로 동작한다면 Cilium의 부착 우선순위를 조정해야 할 수 있습니다.

‍