- eBPF의 시작은 2014년 Plumgrid에서 ebpf를 처음 리눅스 커널에 도입함. 왼쪽 사진은 차례로 Pere Monclus, Brenden Blanco, Alexei Starovoitov, 그들이 처음으로 ebpf를 리눅스 커널에 도입했다. 오른쪽 사진은 Daniel Borkmann 포함해 토의하는 사진
잠깐 Plumgrid에 대해 살펴보면 당시 Openstack 환경을 위한 SDN 을 위해 IO Visor 제품을 개발했었다. 아직 홈페이지가 남아있어 제품 설명을 일부 볼 수 있다. https://www.iovisor.org/
남은 자료들에서 일부 내용을 정리해봤다.
- IO Visor: Revolutionizing Kernel I/O & Networking 이 프로젝트는 개발자가 동적 IO 및 네트워킹 기능을 갖춘 개방형 프로그래밍 가능 데이터 플레인을 구축, 혁신 및 공유할 수 있도록 지원. - What are the Challenges? 유저 레벨에서 개발된 다양한 제품이 많았으나 이는 높은 성능을 달성할 수 없고, 여러 기능을 수행하기 위해서는 hairpinnin 트래픽으로 병목이 생긴다 > 성능 부족 개발자의 경우 IO 모듈을 생성하고 적용하려면 소프트웨어를 수정/컴파일 혹은 재부팅까지 필요 > 유연성 부족 - What is eBPF? What is eBPF는 커널내 가상머신을 제공하여 네트워킹/비네트워킹 기능에 대해 활용 범위를 확장. 이러한 가상머신 구조를 통해 eBPF는 인프라개발자가 커널 내 IO 모듈을 생성하고, 재부팅이나 컴파일 없이 런타임에 로드/언로드 할 수 있도록 지원함.
당시 자료의 eBPF에는 아래처럼 설명이 되어있다. C로 BPF를 개발 > LLVM(Low Level VM)을 통해 eBPF 명령어로 변환 > 커널 로드 및 실행 > 리눅스 네트워크 스택의 다양한 레벨에 연결됨(Hooked)
그리고 이러한 방식을 통해 가상/물리적 장비(appliance)없이 모든 데이터플레인 구성 요소가 커널 내에서 동적으로 삽입된다고 한다.
아래는 IO Visor에서 얘기하는 에코시스템인데, 당시의 SDN/NFV에 대해 관심이 있던 사람이라면 아래 그림을 보면 익숙한 프로젝트들이 보인다.
- 페이스북이 eBPF 초기 시절에 크게 관여했다. 지금의 eBPF는 재단의 일부이고 다양한 그룹에서 논의 되고 있다.
- 리눅스 커널 eBPF그룹을 보면 네트워크 트랙의 일부이고, David Miller를 볼 수 있다.
- 왼쪽. 리눅스 25주년 파티에서 실리움 창립팀 Thomas Graf, Daniel Borkmann, Mandhu Challa, Andre Martins . 오른쪽. Iovisor summit에서 초기 실리움 프리젠테이션
- 첫 실리움 디자인 서밋에서 스위스의 눈많은 산속으로 갔다. 안개도 끼고 가시성이 거의 제로였었는데, 관찰 가능성이 중요하다는 걸 깨닳았다.
- 첫번째 컨퍼런스 참여는 토론토 Linuxcon이었다. 아주 미래지향적이었고, 차세대 네트워크 레이어를 만들고 싶었어서 IPv6만 지원했고, 컨테이너용, Identity 기반 보안 등... 이었으나 IPv6는 좀 극단적이라는 걸 배우고, IPv4 지원을 추가했다.
- Isovalent 가 시작된 역사. 타임라인. 공동창업자는 Thomas Graf 와 Dan Wendlandt이다. Thomas는 레드햇에서 Dan은 Nicira라는 회사에서 Open vSwitch 를 작업하다가 만났다. eBPF가 탄생하고 시스코에 들어가서 Cilium 작업을 시작했고, Cilium을 만들고 나서 Andreessen Horowitz(16z, 벤처 캐피탈)의 첫 라운드 투자와 함께 창업.
- Liz Rice가 조인한건 대단한 순간이었고, CNCF 프로젝트가 되었다. 그 뒤로 다양한 거물들이 합류하면서 성장했다.
- 처음 cilium 을 시작할 때 쿠버네티스 layer3,4의 네트워킹 문제나 온프렘, 클라우드 등의 핵심에 집중했고, DockerCon 2017 에서 스타워즈 데모를 진행함 (https://www.youtube.com/watch?v=ilKlmTDdFgk). k8s가 성장하던 시기기도 했고, cilium의 첫 번째 큰 순간 중 하나였다.
- 네트워킹에 대해서만 집중하는걸 넘어서야 겠다는 걸 느끼고, 네트워크 정책이나 세그먼테이션, 암호화 등을 추가했다.
- 첫 로고
flow logs, metrics and troubleshooting capabilities 를 제공하는 허블도 공개
- 허블은 단순히 UI 뿐만 아니라 네트워크 정책 에디터로 정책을 관리하고 시각화 하며 실제 사용할 수 있음.
- 그 뒤 쭉 성장했고, Kubecon 에서 cilium 이 2000 스타를 넘었으나 축하하지 않음. 엔지니어기 때문에 2048(2K)에서 축하함.
- 2018년 Kubecon 에서 조금 일렀지만 Cluster mesh 를 추가하고 소개함 (https://www.youtube.com/watch?v=U34lQ8KbQow) 클러스터 자체를 연합(federating)하지 않고도 독립성을 유지하면서 클러스터들을 연결할 수 있게 하고 Cilium은 이러한 클러스터들 아래에 데이터 플레인을 생성하여 모든 파드(pod)들이 서로 통신할 수 있도록 지원. 로드밸런서도 추가함
- Tetragon 을 소개함. 모든 노드에서 eBPF기반으로 실행되어, 네트워크 뿐만이 아니라 런타임에 대해서도 보안적으로 관찰 가능성을 제공하고 런타임 정책을 적용할 수 있음.
- 실리움에 벤더들이 붙기 시작함. AKS에 cilium 을 사용함.
- Grafana도 파트너쉽을 맺음. 커널 엔지니어들이라 시각화에서 어려움을 겪고 있었는데, 시각화 하는데 매우 도움이 됐다.
- 작년(2022) 서비스 메시를 소개함. 커뮤니티에서 service mesh 요구가 많았는데, 이미 시장에 service mesh 가 많은데 왜 또 하나가 필요하냐는 의문이었고, 사람들의 피드백은 사이드카 프록시를 없애달라는 것이었다. 그래서 투명한 인프라의 일부로 서비스 메시를 출시했다.
- 서비스 메시가 그림을 완성시켰다. L7 LB, tracing, mTLS, API gateway,...
- 실제 영상 영상을 보면 스위스에서 일화 등을 소개하면서 분위기를 잘 풀어가고 드립도 치는데, 아래 그림도 개가 들어간다...
- what is next for cilium? (만우절)
- 실제 로드맵. 네트워크 정책에 대한 mTLS 지원, SPIFEE 기반 mTLS의 원활한 배포. yaml 두줄로 다 처리되도록 통합. day 2 운영 개선
- cilium 의 big picture. 쿠버네티스 네트워킹에서 시작되어서...
- cilium mesh 를 통해서 transit gateway 처럼 동작해서 모든 인프라 네트워크를 통합 할 수 있도록 계획. CNI를 cilium을 사용하는게 아니라 cni 위에 chaining mode로 cilium을 실행해서 기존 cni를 유지한 채로 통합.
- Q&A
Q. cilium mesh에서 gcp 는 의도적으로 빠진거냐
A. 자리가 없었음.
Q. 다른 CNI를 쓰고 있는데, Cilium 으로 마이그레이션 하는 방법이 좀.. 설명이 부족한데, 뭔가 계획이 있냐?
Thomas Graf는 "eBPF 와 커널을 프로그래밍 가능하게 하는 것은 매우 흥미롭고, 우리가 하는 일을 바꿀 뿔 만이 아니라 업계 전체를 바꿀 것이다" 라고 말한다. 2011년 커널쪽에서 일하는 사람들은 리눅스의 큰 성장을 체감했고, 대부분 디바이스에 리눅스가 쓰였다.
eBPF에 참여한 사람은 SDN(Software Defined Networking)쪽 일을 했다. 당시 SDN은 핫한 주제였고, 하드웨어로 작업하던 케이블을 소프트웨어로 워크로드를 연결하는 것들에 집중했다.
이때 네트워킹은 하드웨어 기반 사업이었는데, 소프트웨어 기반 사업으로 변화했고, 당시 SDN은 많은 기능이 나왔지만 프로그래밍 유연성이 높지 않않다. 당시 리눅스 커널에서 사용한 기술은 브릿지나 이더넷 스위칭 정도에 초점되어 있었고, 이는 SDN에 맞지 않았음. next level을 위한 무언가 필요했다. 당시 리눅스에 대한 시각 자체도 지루함과 안정성을 요구하다보니 혁신이 어려웠다.
Chris Wright는 당시 레드헷 아키텍트 리드였는고, 다양한 회사와 협업을 했는데, 그 중 PLUMgrid가 있었다.
PLUM grid는 Parse, Lookup, Update, Modify 임. 이것들을 모아서(Plumlets) 그리드에 연결하고 네트워크 기능을 수행.
언어와 컴파일러를 통해 커널 프로그램의 안정성을 보장(Rust와 유사)하려 했지만 호스트와 충돌하는 버그로 유저 스페이스 공간 자체를 신뢰하면 안된다는 걸 깨닳았다. 그래서 검증기(verifier)를 개발하고 커널은 무엇이 로드되는지 알야야한다는 결론에 도달했다. 그래서 명령어 세트를 개발하기 시작했고, PLUMgrid는 CEO 와 CTO는 이 기술이 성공하려면오픈소스와 업스트림(커널에 통합하는걸 의미하는 듯)의 필요성을 강조했다.
패킷을 캡쳐하고 패킷에 따라 무엇을 할지 결정하는 probe point를 커널에다가 바로 삽입하는 아이디어는 단순한 네트워킹 뿐만이 아니라 커널 자체를 확장 가능하게 했다. 이 혁신을 커널 커뮤니티가 받아들일 수 있으려면 혁명으로 보이지 않아야 하고, 이를 위해 원래 있던 것과 유사해야 함을 강조했다.
그래서 BPF를 확장하기로 하고, BPF와 비슷하게 디자인하고 명령어 세트를 재 설계하고, eBPF라고 이름을 붙였다.
David miller(레드헷 엔지니어) 는 일을 하다가 기존 BPF 메커니즘을 강화할 이 패치를 마주쳤는데, 사용자 커널에서 원하는 기능을 가능하게 해주는 판도라의 상자 같은 것이었지만 이는 골치아플 수 있다고 한다 (커널에 넣어서 실행하다보니, 소프트웨어를 판매한 회사는 support가 골치아파짐) . eBPF는 돌 하나로 천마리의 새를 잡으려 했다고 설명한다.
Daniel Borkmann은 당시 BPF(classic BPF)를 작업하는 중에 이 패치 제안을 봤고, LLVM 백엔드 까지 포함한 패치 폭탄이었다.커널에 이를 병합하는 건 미친짓이라고 생각했지만, 이 아이디어에 빠졌고, 그 잠재력음 보았다고 한다.
그 뒤 Daniel은 Thomas 의 사무실로 와서 같이 할 수 있냐고 하고 조인했다.
eBPF의 아이디어는 엄청난 것이지만 알렉세이를 만나 커널에 병합하기 위해 논의를 했으나, 이를 커널에 병합하려면 쉽지 않았고, 당시 네트워크 커널 관리자였던 david miller를 설득 해야했다.
그래서 구식 BPF tcpdump 인터프리터를 교체하고, 성능을 향상시키는걸로 다시 시작했지만, 당시 이는 david miller와 네트워크 커뮤니티의 강력한 반발이 있었다. 네트워크 문제를 해결하려고 접근했으나 이미 Open vSwitch 가 모든 네트워크 문제를 해결하고 있기 때문에 두번째 솔루션이 필요하지 않다고 생각했다.
그래서 두번째 사용자(대상)을 찾아야했고, Brendan Gregg를 만나게 됐다.
2014년 넷플릭스에서 Brendan Gregg은 당시의 트레이서들은 모두 완벽하지 않아서 그가 필요한 모든것을 할 수 있는 트레이서는 하나도 없었다. 내부에서 이 패치를 보고 알렉세이를 초청했고, Kprobes 지원을 해준다면, 이를 사용할 프론트엔드 도구를 작성할 것이라고 합의했다.
Thomas는 이때부터 모든 것을 추적으로 피벗했고, 전체 패치를 재배치하고, 업스트림에 접근하는 방법과 네트워킹을 잊고, 트레이싱에만 전념했다.
Daniel 은 네트워킹 측면에 집중했고, 두 사람의 협력으로 merge될 가능성이 높아졌다.
첫 제출물은 BPF를 좀 더 빠르고 더 좋게 만들 것이 었기 때문에, David miller는 이를 병합했고, PLUMgrid에서는 엄청나게 기뻤다고 한다.
Brendan Gregg는 이건 커널에 자바스크립트를 넣는 것 처럼 미친 생각이라고 하면서 알렉세이가 제품 전체를 한번에 커널에 넣기보다, 레고 블록 하나 하나를 넣어서 쌓아올렸던 게 현명했다고 한다.
Liz Rice는 이 초기 패치와 사람들이 eBPF에 대해 알기 시작한 시점은 2~3년 차이가 날 것이라고 한다.
쿠버네티스에서 파드는 독립적으로 실행되지만, 이를 공통 로깅 추적, 보안 등 기능을 넣으려고 하면 쉽지 않았는데, eBPF는 어플리케이션에서 개별적으로 처리하지 않고, eBPF가 커널에서 동작하기 때문에 공통 플랫폼을 가질 수 있게 해주면서 이는 클라우드 네이티브 환경과 인프라 소프트웨어에 대한 변화를 가져왔다.
2011-2012에는 엔터프라이즈 리눅스가 표준이 되고 있었는데, 커널 변경이 유저에게 수년이 걸렸었는데, eBPF는 이걸 다시 근본적으로 변화시키면서 런타임에 프로그램을 로드할 수 있어 아이디어를 빠르게 구현하고 바로 사용자에 전달 가능해졌다.
페이스북은 수백만 대의 서버 규모에서 eBPF를 도입했다. 페이스북의 로드밸런서(Katran)은 BPF 및 XDP 기술을 기반으로 개발되었고, BPF와 XDP를 통해 기존 솔루션에 비해 10배 성능 차이를 보여줬다. 페이스북으로 가는 모든 패킷은 XDP 계층에서 eBPF를 거치게 되고, 여기서 eBPF의 네트워킹이 시작된 곳이라고 한다.
eBPF 프로그램은 강력했지만, 하이퍼스케일 회사들이야 자체 커널 팀을 가지고 있어서 이들에게는 훌륭했지만 최종 사용자에게는 너무 어려워서 접근하기 어려웠다.
이를 하이퍼스케일이 아니라 전 세계에 가져가기 위해 cilium을 작업하기 시작했다. cilium을 만든 동기 중 하나는 eBPF의 기능을 최종 사용자에게 제공하는 것이라고 한다.
실리움의 첫 버전은 안전하고 컨테이너의 확장성 요구 사항과 성능 요구 사항을 충족하는 완전히 새로운 네트워킹 계층을 구현하고 개발자와 플랫폼 팀이 인프라를 이해하지 않아도 되는 새로운 쿠버네티스 개념을 도입하려고 했고, 이 때 Isovalent 를 시작하기로 하고 창업 했다.
다양한 기능들을 eBPF에 넣기 시작했고, 커널에서 할 수 없었던 것들을 하도록 노력했다. Isovalent는 초기에 사용자에게 집중했고, 사람들의 요구사항이 개발의 방향을 결정하면서 성장해 나갔다. 2017년에는 사람들이 BPF 프로그램을 실행할 수 있는 커널을 업스트림하기 시작했다.
2017 도커콘 이후 eBPF 커뮤니티가 폭발적으로 성장했다. 게다가 Thomas, brendan, Liz가 모두 이곳에서 발표했다.
도커콘 이후 성장하면서 실제 사용자도 늘어나고 있었고, 프로젝트 규모도 점점 커지고 주요 회사들이 이를 채택하기 시작했다.
구글이 cilium에 관심있어 했던 시점이 큰 이정표 중 하나였다.
구글은 Anthos와 GDC를 통해 온프렘 환경까지 제품 제공을 확장하려고 했고, 고객들은 가시성,네트워크 보안, 감사, 정책 등을 원했었다. eBPF를 통해 더 많은 것을 할수 있게 되었고, 더 많은 프로그램 가능성을 가지게 됐다. eBPF 기반 네트워킹 스택을 채택하는 것이 합리적이었고, 지금은 GKE, Anthos, GDC, Autopilot, Dataplane V2까지 사용된다.
eBPF는 초능력과 같은 도구이다. 성능 문제를 빠르게 찾을 수 있기에 제품 개발속도가 빨라지고, 경쟁력 있는 제품이 선택받고 이는 산업 전체를 발전 시킨다.
지금 eBPF는 어디에나 있다. andorid에도 있고, ... 대부분 새로운 보안 제품은 eBPF를 사용한다.
10년이 지났지만 아직 시작에 불과하고, 그동안의 혁신이 사용자 공간으로 나아가는 모습을 보았지만, 이제는 커널로 다시 이동하고 있다.
Thomas Graff는 자신의 열정은 효과적으로 혁신하고, 다른사람들이 혁신할 수 있도록 하는것이다. BPF는 이를 충족시켜준다고 말한다. 과거에는 커널 프로그래머가 수백명에 불과했지만, 이제는 BPF를 통해 전 세계적으로 10만명의 사람들이 커널을 프로그래밍 할 수 있다고 강조한다.
