Kubernetes Meetup Tokyo #55 (https://k8sjp.connpass.com/event/267620/) での発表 発表動画: https://www.youtube.com/watch?v=wlYHa1gKfBI

1. eBPFは何が嬉しいのか?
Yutaro Hayakawa
Isovalent

2. Self Introduction
● 早川侑太朗 (@YutaroHayakawa)
● Isovalent (2022 ~)
○ Ciliumの開発 (Datapathチーム)
○ マルチクラスタ (ClusterMesh), BGP, SRv6, etc…
● LINE Corporation (2019 ~ 2021)
○ 内製ロードバランサの開発・運用
○ 大規模LBaaSの成長期に体験した二つの問題

4. ユーザが使いたいもの
�
�
��
なぜか話題になるやつ
実装

5. eBPFで作られていることは誰にとってどう重要か？

6. eBPFで作られていることは誰にとってどう重要か？
↓
結局開発者にとってもユーザにとっても重要
*ポジショントーク

7. eBPFとは？
Linuxカーネル拡張を書くためのプログラミングフレームワーク
https://ebpf.io/what-is-ebpf

8. eBPFとは？
Linuxカーネル拡張を書くためのプログラミングフレームワーク
https://ebpf.io/what-is-ebpf

9. eBPFプログラミング
C言語で書く (mainとかはない見慣れないC), ClangにeBPFバイトコードを吐くモードが
ある

10. eBPFプログラミング
ファイルが消えるたびに消されたファイルの名前と消したプロセスのPIDを出力するプロ
グラム

11. eBPFとは？
Linuxカーネル拡張を書くためのプログラミングフレームワーク
https://ebpf.io/what-is-ebpf

12. Load
コンパイラから吐かれた「ELFファイル」をbpfシステムコールに渡せる形にする工程
詳しく知りたい方は => きっと明日から役立つeBPFのしくみ
主要なローダライブラリ => libbpf (C) , cilium/ebpf (Go), libbpf-rs (Rust)

13. eBPFとは？
Linuxカーネル拡張を書くためのプログラミングフレームワーク
https://ebpf.io/what-is-ebpf

14. VerifierとJIT Compiler
bpfシステムコールでロードされたプログラムはVerifierによって「検証」される
=>「安全」でなければ実行できない
検証が通ったらほとんどの場合JITコンパイルされる
=> 実行前に全部ネイティブマシン命令に変換(JSなどの動的JITとはちょっと違う)
検証が共通化できるのがeBPFバイトコードがアーキテクチャ非依存な理由

15. eBPFとは？
Linuxカーネル拡張を書くためのプログラミングフレームワーク
https://ebpf.io/what-is-ebpf

16. Hook / Event
カーネルの中でeBPFを実行できる場所
何かしらのイベントを契機にeBPFが実行される
代表的なフック
- Socket => socketに対するデータの入出力をフィルタする
- Syscall => システムコールの呼び出しをトレース・フィルタ
- kprobe / ftrace => カーネルの関数呼び出しなどをトレース
- TC / XDP => NIC入ったパケットを書き換え・ドロップ
- TCPの輻輳制御, スケジューラ, etc

17. eBPFとは？
Linuxカーネル拡張を書くためのプログラミングフレームワーク
https://ebpf.io/what-is-ebpf

18. eBPF Map
eBPFプログラムとユーザ空間から読み書きできるデータ構造
=> Hash, Array, Trie, Per-CPU Array, etc…
ユーザ空間とeBPFの情報のやりとりに使える (例えるならRedisのようなもの?)

19. eBPFは何が嬉しいのか？
何か新しいことができるようになったから嬉しい？
そもそも誰にとって嬉しい？
ユーザにとってプロダクトがeBPFで作られているのって重要？

20. eBPFによって何か新しいことができるようになった？
技術的にはなっていない
Linuxには元々「カーネルモジュール」がある
カーネルモジュールもeBPFもカーネル空間で動くプログラム
eBPFで実装できる機能は基本的にカーネルモジュールで作れる機能のサブセット
Ciliumをカーネルモジュールベースで作ることは理論的には可能 => でもやらない

21. eBPFはそもそも誰がなんのために作ったのか？
カーネル開発者にとってカーネルの開発があまりにも辛かったから必要だった

22. eBPFのオリジナルの作者
Alexei Starovoitov
現Meta, 元PRUMgridのエンジニア
IOVisorというプロダクトの一部だった
開発秘話的なプレゼン: The untold story of BPF

23. カーネル (モジュール) 開発の4つのつらみ
プログラミングのつらみ
メンテナンスのつらみ
アップストリームのつらみ
デリバリのつらみ

24. カーネル開発のつらみ - プログラミング -
カーネル空間は色んな意味で「安全」ではない
Cプログラミングそのものの辛み (メモリ管理等)
メモリアクセス違反 => マシンそのものが停止
ハング (デッドロック、無限ループ) => マシンそのものが停止
メモリリーク => 誰もリークしたメモリを回収しない
セキュリティホールを作る => 権限Maxな状態で攻撃に晒される

25. カーネル開発のつらみ - メンテナンス -
Linuxカーネルはカーネルモジュールに対して互換性を一切担保しない
あるバージョンで動いていたモジュールは次のバージョンで動く保証がない
Linuxの開発はかなり早い (9 - 10週ごとにリリース)

26. カーネル開発のつらみ - アップストリーム -
パッチをアップストリームすればバージョンアップで壊れるのは防げる
Linuxの開発者との交渉が必要 + レビューは厳しい
あまりにも特定の会社のビジネスに拠った変更は受け入れられないケースもある

27. カーネル開発のつらみ - デリバリ -
Masterに入った変更がディストリビューションカーネルに降りてくるのはいつ？
ディストリビューションによっては3 - 5年かかるケースもある

28. eBPFはカーネル開発のつらみをどう解決したか？
プログラミング: Verifierによる検証でプログラマのミスを未然に防ぐ
メンテナンス: eBPFのプログラムに対しては後方互換性が担保されるようにした*
アップストリーム: 互換性が担保されるということはアップストリームは不要
デリバリ: アップストリームしなくていいということはデリバリも即座にできる

29. カーネル開発のつらみが解消された結果どうなったか？
一般的な現場でもカーネル開発に手を出せるようになった
一般的な現場でもカーネル拡張の保守が現実的なコストでできるようになった
一般的なエンジニアから見て新しいこと（カーネル開発）ができるようになった
=> これが昨今の盛り上がりの一因？

30. eBPFは何が嬉しいのか？
何か新しいことができるようになったから嬉しい？
=> 技術的にはNoだが、一般的なエンジニアでもカーネル開発ができるようになったという
意味ではYes
そもそも誰にとって嬉しい？
=> カーネル開発者にとっては辛いところが解消されて嬉しい
ユーザにとってプロダクトがeBPFで作られているのって重要？

31. eBPFで作られているのはユーザにとって重要か？
重要だと言える
カーネル開発のつらみと結局は関係している
● プログラミングの難易度が高い => バグや脆弱性が紛れ込みやすい
● 互換性が担保されない => カーネルのアップデートがリスク、メンテされなくなれば
短い期間ですぐ使えなくなってしまう
● デリバリが遅い => 欲しい機能がすぐ手に入らない

32. ケーススタディ - Falco -
FalcoはなぜカーネルモジュールからeBPFベースの
実装に移行しているのか？
● Falcoのイベントコレクタはカーネールモジュー
ルベースだった
● ユーザからのフィードバックとして安定性、セ
キュリティ、互換性への懸念が示された
● Sysdig and Falco now powered by eBPF

33. まとめ
eBPFは何が嬉しいのか？
開発者目線
● 安全なカーネル開発ができるようになる
● カーネル拡張の保守が楽になる
● 開発・デリバリのスピードが上がる
エンドユーザ目線
● カーネル拡張の導入がより「安全」になる
● 互換性やプロダクトの持続性に対する懸念が軽減される
● 欲しい機能が素早く手に入る