8편. CO-RE와 Parca – 커널 의존성 문제는 어떻게 해결되는가

아래는 8편 전체 본문 확장판 초안입니다.
이번 편은 Parca가 “운영 환경에서도 안전하게 eBPF를 쓰는 이유”를 설명하는 핵심 이론 편입니다.

• 왜 eBPF가 커널 버전에 취약했는지
• CO-RE가 무엇을 해결했는지
• Parca / parca-agent가 이를 어떻게 활용하는지
• 실무자가 반드시 알아야 할 한계까지 포함

---

CO-RE와 Parca

커널 의존성 문제는 어떻게 해결되는가

eBPF를 공부하다 보면
반드시 한 번은 이런 말을 듣게 된다.

“eBPF는 좋은데,
커널 버전 맞추는 게 너무 힘들다.”

이 말은 과거에는 사실이었다.
그리고 CO-RE(Compile Once – Run Everywhere)는
이 문제를 정면으로 해결하기 위해 등장했다.

Parca는 바로 이 CO-RE 위에 설계된
운영 환경 친화적 eBPF 프로파일러다.

---

1️⃣ eBPF의 오래된 문제: 커널 의존성

초기의 eBPF 프로그램은 다음 문제를 안고 있었다.

• 커널 버전마다 struct 레이아웃이 다름
• 배포판마다 config 옵션 상이
• minor version 차이에도 offset 변경
• 커널 업데이트 시 프로그램 재빌드 필요

즉,

“이 서버에서는 잘 되는데,
저 서버에서는 verifier에서 터진다.”

운영 환경에서는 거의 재앙에 가까운 문제였다.

---

2️⃣ 전통적인 해결책의 한계

CO-RE 이전에는 보통 이런 방법을 썼다.

① 커널 버전별 빌드

• kernel 5.4용
• kernel 5.10용
• kernel 5.15용 …

→ 현실적으로 관리 불가

---

② 런타임 offset 추정

• kprobe로 주소 추적
• fragile한 휴리스틱
• 커널 패치 하나에 무너짐

→ 유지보수 지옥

---

3️⃣ CO-RE란 무엇인가

CO-RE는 이름 그대로다.

Compile Once, Run Everywhere

핵심 아이디어는 단순하다.

“컴파일 시점이 아니라,
로드 시점에 커널 구조체에 맞춘다.”

이를 가능하게 하는 핵심 기술이 BTF다.

---

4️⃣ BTF (BPF Type Format)

BTF는 다음을 제공한다.

• 커널 내부 struct 정의
• 필드 이름
• 타입 정보
• 오프셋 정보

이 정보는:

• 커널 빌드 시 생성
• /sys/kernel/btf/vmlinux에 포함

즉,

“커널이 스스로 자기 타입 정보를 제공한다.”

---

5️⃣ CO-RE의 동작 원리

CO-RE eBPF 프로그램은 다음과 같이 동작한다.

1. eBPF object는 논리적 필드 접근으로 작성
2. 로드 시:
   • 커널의 BTF 정보 로드
   • 실제 struct layout 확인
3. 필드 접근을 실제 offset으로 재배치(relocation)

---

CO-RE 스타일 코드 예시

 

struct task_struct *task = (struct task_struct *)bpf_get_current_task();

/* CO-RE field access */
u32 pid = BPF_CORE_READ(task, pid);

이 코드는:

• kernel 5.4
• kernel 5.10
• kernel 6.x

모두에서 같은 바이너리로 동작한다.

---

CO-RE 이전 코드 (위험)

 

u32 pid = task->pid;  /* offset 고정 가정 */

→ 커널이 바뀌면 바로 깨진다.

---

6️⃣ Parca에서 CO-RE가 중요한 이유

Parca는 다음 특성을 가진다.

• 노드 수 많음
• 커널 버전 제각각
• Kubernetes 환경
• 빈번한 커널 업데이트

이 상황에서:

“노드마다 agent를 다시 빌드한다”
→ 사실상 불가능

---

Parca의 선택

• parca-agent는 CO-RE 기반 eBPF
• 하나의 바이너리로:
  • Ubuntu
  • RHEL
  • Amazon Linux
  • GKE / EKS / AKS

에서 동작

이게 바로 운영 가능성의 핵심이다.

---

7️⃣ CO-RE가 해결하는 것 vs 해결하지 못하는 것

해결하는 것

• struct layout 변경
• 필드 offset 차이
• 커널 minor version 차이
• 배포판 간 config 차이 일부

---

해결하지 못하는 것

• BTF가 없는 커널
• 너무 오래된 커널 (4.x 초반)
• eBPF helper 자체가 없는 경우
• verifier 정책 차이

즉,

CO-RE는 “만능”이 아니라
“운영 가능성의 기준선”이다.

---

8️⃣ Parca 운영 시 CO-RE 관련 체크 포인트

반드시 확인할 것

• /sys/kernel/btf/vmlinux 존재 여부
• 커널이 CONFIG_DEBUG_INFO_BTF 활성화
• parca-agent 로그에 CO-RE fallback 여부

---

실패 시 나타나는 증상

• agent 기동 실패
• verifier reject
• “failed to load BPF program” 로그

이 경우:

• 커널 업그레이드
• BTF-enabled 커널 사용

외에는 답이 없다.

---

9️⃣ 왜 CO-RE가 “게임 체인저”인가

CO-RE 이전:

• eBPF는 전문가의 장난감
• 운영 투입 부담 큼

CO-RE 이후:

• eBPF는 인프라 도구
• Parca 같은 제품 가능

CO-RE는 eBPF를
“데모 기술”에서
“운영 기술”로 끌어올렸다.

---

10️⃣ 이 편의 핵심 요약

• eBPF의 최대 약점은 커널 의존성
• CO-RE + BTF가 이를 해결
• Parca는 CO-RE 없이는 성립 불가
• 운영 환경에서 Parca가 안정적인 이유

---

다음 편 예고

다음 편에서는
Parca 도입 시 현실적인 고민들을 다룬다.

• 오버헤드
• 보안
• 언제 켜야 하고, 언제 끄는가
• 도입하면 안 되는 경우

---

다음 편

9편. Parca 도입 시 현실적인 고려사항 – 운영, 보안, 성능 관점