[Learning eBPF] Cilium 오픈소스 분석(2015.12 - 초기 코드)

가장 초기 Cilium Datapath PoC 코드부터 살펴보기이번 eBPF 스터디를 통해서 Cilium 자체도 이해하고 싶었다.Cilium을 통해서 Kubernetes Networking에서 eBPF가 실제 Packet 처리에 어떻게 사용되는지도 확인해보고 싶었다.하지만 현재 Cilium 코드는 너무 크고, 기능이 많이 한번에 모든 Cilium 코드와 기능을 분석하는게 어려웠다.그래서 최신 코드부터 시작하지 않고 가장 초기의 PoC 수준 코드부터 시작해서 점차 현재 Cilium 구조로 올라가 보기로 했다.이번에 분석한 오픈소스 코드는 2015년 12월의 다음 Commit이다.https://github.com/cilium/cilium/commit/a1eab8fa7bdc1132a197deab70a11599..

  • format_list_bulleted 카테고리 없음
  • · 2026. 9. 5.

[EKS] 학습

학습 주제내용자료EKS Architecture / Control PlaneEKS가 관리하는 영역 vs 사용자 영역, Control Plane VPC와 사용자 VPC, EKS ENI, API Server Public/Private Endpoint, Control Plane HA 구조 이해. kubectl → EKS API Endpoint → Control Plane → Node 흐름을 직접 설명할 수 있어야 함. (AWS 문서)AWS EKS Architecture API Endpoint 설정 re:Invent 2025 - EKS Under the Hood re:Invent EKS Under the Hood PDFEKS Cluster Access / IAM / RBACIAM 인증과 Kubernetes RBA..

  • format_list_bulleted 카테고리 없음
  • · 2026. 8. 29.

[Learning eBPF] Ch7. eBPF Program과 Attachment Type 이해하기

Chapter 7은 세부 Program Type을 하나씩 나열하기보다, 어디에 붙는가 → 어떤 정보를 받는가 → 무엇을 할 수 있는가 흐름으로 묶고 그림 중심으로 설명하는 게 좋다.eBPF Program은 Linux Kernel 내부의 아무 위치에서 실행되는 것이 아니다. 특정 Event가 발생하는 Hook Point에 Attach되어 실행된다.예를 들어 Process 실행을 추적하려면 kprobe, fentry, tracepoint 등을 사용할 수 있고, Network Packet을 처리하려면 XDP, TC 같은 Hook을 사용한다. Chapter 7은 이러한 Program Type과 Attachment Point의 관계를 설명한다. 1. Program Type과 Attachment TypeeBPF..

  • format_list_bulleted eBPF
  • · 2026. 8. 29.

AWS EC2 Nitro 아키텍처 딥다이브(Deep Dive)

2013년 Xen의 한계점 : Trap & Emulate 구조로 인한 Dom0 과부하 및 자원 낭비 가상 머신(게스트 OS)이 네트워크나 디스크 I/O를 요청할 때마다 특권 명령어(Privileged Instruction)가 발생.Xen에서는 CPU → 하이퍼바이저 → dom0(관리용 OS) → 디바이스 모델이라는 복잡한 소프트웨어 단계를 거쳐야 했음.> 이 과정에서 CPU가 계속 대기 상태(Trap)에 빠짐> 관리용 OS(dom0)가 메인 CPU와 RAM 자원을 과도하게 사용함 → 고객에게 할당할 자원이 줄어드는 문제 발생 Xen → Nitro System으로: 하드웨어 오프로딩 단계별 흐름 시각화 Nitro System 사진 Nitro System Network

  • format_list_bulleted AWS - knowledge base/EC2
  • · 2026. 8. 23.

[Learning eBPF] Chapter 6. eBPF Verifier 이해하기

eBPF 프로그램은 일반적인 애플리케이션과 달리 Linux Kernel 내부에서 실행될 수 있기 때문에, 잘못된 프로그램이 실행되면 시스템 전체에 영향을 줄 수 있다.그래서 Linux Kernel은 eBPF 프로그램을 바로 실행하지 않고, 먼저 Verifier를 통해 안전성을 검증한 뒤 통과한 프로그램만 실행한다.Chapter 6의 핵심은 이 Verifier가 어떤 방식으로 프로그램의 안전성을 판단하는가를 이해하는 것이다. Verifier는 모든 가능한 실행 경로와 각 Instruction의 안전성을 확인하며, 우리가 작성한 C 코드가 아니라 컴파일된 eBPF Bytecode를 대상으로 분석한다.1. Verifier는 프로그램을 어떻게 검사할까?Verifier는 프로그램을 실제로 실행해서 문제가 있는지 ..

  • format_list_bulleted eBPF
  • · 2026. 8. 21.

[Learning eBPF] ch5. CO-RE, BTF, and Libbpf

1. 이 챕터의 핵심CO-RE(Compile Once – Run Everywhere)는 eBPF 프로그램을 한 번 빌드한 뒤, 서로 다른 Linux 커널 버전에서도 실행할 수 있도록 만드는 메커니즘이다.즉, CO-RE는 커널 구조체의 메모리 배치가 달라져도 로딩 시점에 eBPF 프로그램을 보정하는 방식이다. 2. 커널 구조체의 메모리 배치가 달라진다?2-1. include/linux/sched.h (v4.14)https://github.com/torvalds/linux/blob/bebc6082da0a9f5d47a1ea2edc099bf671058bd4/include/linux/sched.h#L519 더보기struct task_struct {#ifdef CONFIG_THREAD_INFO_IN_TASK ..

  • format_list_bulleted eBPF
  • · 2026. 8. 15.