Ciliumはどうテストされているのか

eBPF Japan Meetup #4 2025/05/30

Transcript

1. Ciliumはどうテストされているのか？ Isovalent at Cisco 早川侑太朗 (@YutaroHayakawa) @eBPF Japan Meetup 2025/05/30 1
2. 発表の主旨 • Ciliumを例にeBPFを使った (ネットワーク系の) プロダクトのテストの考え方, 苦労話, ノウハウを共有する • eBPF固有のテストの難しさに焦点を当てていきたい 2
3. Ciliumとは？ 3 • Kubernetesのネットワークプラグイン (CNI) • Pod間通信, LB (Service), FW (NetworkPolicy) • Data Plane部分の実装にeBPFを使っている
4. Ciliumがやっていること 4 Node (Linux) Agent Node (Linux) Agent Node (Linux) Agent Data Plane (Linux/eBPF) Data Plane (Linux/eBPF) Data Plane (Linux/eBPF) 1. K8s APIにある設定をとってくる 2. APIの設定に応じたData Planeの設定をする 3. パケットが通る 4. 1. に戻る
5. どうテストする？ • K8s API -> Agentのテスト ◦ AgentはGoで書かれているので一般的なGoのテスト ◦ K8s APIのモック等の問題はあるが概ねテストの方法論が 確立された分野 ◦ 今回はスコープ外 5 Node (Linux) Agent Data Plane (Linux/eBPF)
6. どうテストする？ • Agent -> Linux Kernelの部分のテスト ◦ 依然としてGoだが、Linuxカーネルとのやりとりあり ◦ 特権テストのためのツール整備 ◦ テスト環境の分離 (e.g. netns) 6 Node (Linux) Agent Data Plane (Linux/eBPF)
7. どうテストする？ • Data Planeのテストの難しいところ ◦ eBPF (CGroup, TC, XDP), Linuxカーネルスタック, ユーザスペースの透過プロキシの組み合わせで作られている ◦ これらが一気通貫で動いて初めて 「正しい」 • これに対して単体テストをあまり書かずにE2Eに頼ってきた ◦ K8sクラスタを立てて実際にトラフィックを流す ◦ ユーザの動きに近いので安心感がある ◦ なるべく数を減らす努力をしているがなかなか無くせない 7 Node (Linux) Agent Data Plane (Linux/eBPF)
8. E2Eテストの問題点: Flakyなテストができがち • テストがFlakyになりがち ◦ E2Eテストは動いているものが多いので様々な要因で失敗する ▪ CI環境の問題 ▪ 確率的に発現するバグ ◦ 失敗の原因を突き止めるのが非常に難しい ▪ Ciliumは非常にたくさんのgoroutine (手元では381あった) が並行・並列に動く ▪ 動きは全く決定的ではないのでRace Conditionなどは起きやすいし見逃しやすい 8
9. なぜE2Eテストのケースが減らせないのか • Ciliumは多機能な上にサポートしている動作環境が多い ◦ 機能の組み合わせ * 動作環境 • Linuxカーネルのバージョン ◦ ディストリビューション固有カーネル (RHELカーネルなど), LTSカーネル数バージョン • Kubernetesのバージョン ◦ アップストリームのバージョン3つ ◦ クラウドの固有環境 (GKE, EKS, AKS, etc...) • Cilium自身のバージョン ◦ Upgrade/Downgradeテスト • 最新のUpgrade/DowngradeテストはMatrixの数が33 • 時間的にも経済的にも (CloudやGHAの使用料) コストが高い 9
10. Linuxカーネルバージョンごとのテストはなぜ必要なのか？ • 基本的にLinuxは互換性を壊さない(?)のになぜテストするのか？ ◦ 新しいカーネルのバージョンにしかない機能を使う場合は新旧カーネルでテストしたいこともある • Linuxのリグレッションは普通に起こる ◦ Verifierへの変更等によってLoadできていたプログラムができなくなることがたまにある ◦ Network Stack側のリグレッションもありえる ▪ 過去にはデバイスドライバやNetfilterのリグレッションもあった • カーネルコミュニティに対してフィードバックをすることも大事 ◦ カーネルがリリースされる前に問題を発見するためにbpf-nextツリーのカーネルもテストしている ◦ 発見した問題はカーネルチームが直接修正するかフィードバックする ◦ 場合によってはディストリビューションカーネルにバックポートを依頼することも 10
11. テスト改善の取り組み: Unit Testの拡充 • 一般的なテストの原則に忠実に ◦ Unit Testなどの小規模で早いテストを充実させてそこでバグを拾えるようにする ◦ 開発者がテストを積極的に書きやすくするような工夫も必要 11
12. BPF_PROG_TEST_RUN • bpf(2)の機能でLoadしたeBPFのプログラム をAttachせずに実行できる (ref) ◦ まさにeBPFの単体テストのために作られた機能 • そのままでも使えるが, ちょっとテスト走らせるま での手続きが面倒くさい ◦ Goでパケット作ったりパースしたり ◦ eBPFプログラムをロードしたり ◦ もう少しテストを書くのに専念したい 12 eBPF Program Test Runner In Pkt Out Pkt bpf(BPF_PROG_TEST_RUN) User Kernel
13. eBPF Unit Test Framework • eBPFの単体テストを書くための自作フレームワーク (ref) • BPF_PROG_TEST_RUNを使うが、eBPFのコードのみで テストを書き切ることができる • PKGENのコードの中でパケット (skb) を作る • SETUPで実際のコードにskbを通す • CHECKで出力が意図通りか確認する ◦ ちゃんとNATされたか, 返り値 (PASS, DROP, REDIRECT) が意図通りか等 13 PKTGEN Program Test Runner Empty InPkt SETUP Program InPkt OutPkt CHECK Program OutPkt Result bpf(BPF_PROG_TEST_RUN) 開発者が書くところ
14. テスト改善の取り組み: Ciliumのモジュール化 • Ciliumの必要なSubsetだけを切り出してテストしたりできるようにする ◦ モジュール間の依存関係をなるべく減らす ◦ モックのしやすさなども含めたコードの改善 14
15. Hive/Cell Dependency Injection Framework • DIフレームワーク (cilium/hive) ◦ Go向けのいわゆるConstructor Injection ◦ Hive == DIコンテナ, Cell == Constructor (蜂の巣) ◦ Cilium AgentはHiveを中心にしたモジュラーモノリス構造 • モジュール間の依存解決や初期化をDI任せにできる ◦ テストに必要なCiliumのSubsetだけを集めてテストすることが比較的 容易にできる ◦ K８s APIやLinux Kernelのモックなども容易に 15 https://en.wikipedia.org/wiki/Beehive
16. テスト改善の取り組み: E2Eテストの改善 • E2Eテストを完全になくすのは難しいので数を減らしつつ改善にも取り組む ◦ なるべく実行を速くするための工夫をする ◦ Flakyなテストを放置せずなるべく迅速に直せるような組織的な取り組み 16
17. Little VM Helper (LVH) • 起動が非常に早い最小構成のVMを動かすQEMUラッパー (ref) ◦ OCIフォーマットのイメージに入ったQCoWイメージを動かせる ◦ コンテナレジストリにVMイメージをPushして配布できる ◦ Dockerのような使用感でVMが動く • カーネルを自動ビルドしてレジストリにPushするパイプラインが常に動いている (ref) ◦ 気軽に任意のカーネルバージョンでテストを走らせることができる 17
18. Flakyテストに対する取り組み • CI Health Manager ◦ Flakyなテストを直すローテーションワーク (ref) ◦ テスト実行の統計情報を見て失敗率の高いテストを直す ◦ 現状はIsovalentの人がやっている ▪ (コミュニティの中でやる人がいてもいいなと個人的には思う) 18
19. Q&A 19