ゴールデンウィークを挟んで途切れてしまった。5月後半からは落ち着いたので再開する。 低レイヤでのトレーシングに関連して、eBPFを利用したコンテナオーバーレイネットワークに関する論文を紹介。

vNetTracer: Efficient and Programmable Packet Tracing in Virtualized Networks

K. Suo, Y. Zhao, W. Chen and J. Rao, “vNetTracer: Efficient and Programmable Packet Tracing in Virtualized Networks,” 2018 IEEE 38th International Conference on Distributed Computing Systems (ICDCS), Vienna, Austria, 2018, pp. 165-175, doi: 10.1109/ICDCS.2018.00026.

概要
  • 境界を超えたパケット伝達・仮想化ネットワークのトレースをeBPFで動的・非侵入的に実現する提案
  • コンテナオーバーレイネットワークや仮想化ネットワークを中心に研究してるグループ
感想
  • システム全体でPacketIDの伝播はしておらず、sender, receiver間の紐付けのみに利用しているっぽいが、それならPacketIDなくてもできるのでは？
    • TCP, UDPヘッダの情報のみで個々のパケットを識別って本当にできないんかな
    • 解析はどうせオフラインでやっているっぽいので、その時にヘッダも解析すれば通信のオーバーヘッドはなさそう
  • オーバーヘッド削減のためにカーネルモジュールをロードしてるがどれくらい削減できるのか？
    • ログ保存時に発生するディスク操作を削減することは重要だが、そもそもディスク操作がどれくらい起こるものなのか
    • カーネルモジュールなくても一応動作自体はするのであれば、カーネルモジュールをロードする手間と削減できるオーバーヘッドのトレードオフを考えたい
  • eBPFを使ったトレーシングって今だといくつかあるけど、本当に当時(2018)はなかったんかな？

Efficient Network Monitoring Applications in the Kernel with eBPF and XDP

M. Abranches, O. Michel, E. Keller and S. Schmid, “Efficient Network Monitoring Applications in the Kernel with eBPF and XDP,” 2021 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN), Heraklion, Greece, 2021, pp. 28-34, doi: 10.1109/NFV-SDN53031.2021.9665095.

概要
  • 全てのネットワーク分析アプリケーションから共通するパケット処理タスクを統合し、eBPFやXDPを用いてカーネル空間で実行・必要な場合のみアプリケーションを起動することでリソースやオーバーヘッドを削減するネットワーク監視フレームワークの提案
  • 著者はSDNやNFVの研究している人が多い
感想
  • 複数のネットワーク監視アプリから共通の処理を切り出してアプリをオーケストレーションするというところに新規性がありそうだが、その共通の処理にeBPF, XDPを使用したという点は新しいんだろうか？個々の監視アプリも今までeBPF, XDPを使用していたというわけではない？
  • SDN, NFVあたりの知識をもっとつけてから読みたい

Bypass Container Overlay Networks with Transparent BPF-driven Socket Replacement

S. Choochotkaew, T. Chiba, S. Trent and M. Amaral, “Bypass Container Overlay Networks with Transparent BPF-driven Socket Replacement,” 2022 IEEE 15th International Conference on Cloud Computing (CLOUD), Barcelona, Spain, 2022, pp. 134-143, doi: 10.1109/CLOUD55607.2022.00033.

概要
  • Podのnetwork namespaceの通信をHost(default)のnetwork namespaceの通信へと置き換えることでコンテナオーバーレイネットワークをバイパスしてオーバーヘッドを減らす処理を、Host側のエージェントがeBPFとptraceを用いて実行する提案
  • ユーザープロセスを変更しないためユーザビリティが高い・ユーザープロセスの権限昇格が必要ないのでコンテナエスケープ攻撃を防げて安全
  • 東京のIBM研究所のグループ。筆頭著者はコンテナとかKubernetes, BPF関連の研究がいくつか
感想
  • コネクション確立時にミラーリングしたソケットに置き換えて以降の通信をバイパスしているようだが、コネクションレス通信ではどうするんだろうか
    • 諦めて通常通りPodのnetwork namespaceを通ってそう
  • コネクション確立時にClient/ServerのO2H(proposed)デーモン同士が毎回通信しているとオーバーヘッドが大きそうだがそうでもないんかな
    • ソケットの置き換えはコネクションが確立されて通信が開始された後にされるらしいので、デーモン同士の通信はその間にやってるのかな
  • 通信途中にソケットを置き換えることによるパケットロスは起こり得ないんだろうか？
  • Slimの論文を読んでから思ったけど、Slimとの差分は何なのだろうか？
    • Hostのnetwork namespaceでコネクションを確立するまではPodのnetwork namespaceで通信することで、コネクション確立のオーバーヘッドを減らしているというのはありそう
    • eBPFを使っているというのは実装面での違いでしかないし

Slim: OS Kernel Support for a Low-Overhead Container Overlay Network

D. Zhuo, K. Zhang, Y. Zhu, H. H. Liu, M. Rockett, A. Krishnamurthy, and T. Anderson, “Slim: OS kernel support for a Low-Overhead container overlay network,” in 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19). Boston, MA: USENIX Association, Feb. 2019, pp. 331–344. [Online]. Available: https://www.usenix.org/conference/nsdi19/presentation/zhuo

概要
  • コネクション確立時にContainer NamespaceのソケットをHost Namespaceのソケットに置き換えるContainer Overlay NetworkであるSlimを提案
  • パケットがOSカーネルのネットワークスタックを一度だけ通るようになるのでContainer Overlay Netwokのオーバーヘッドが低減される
感想
  • コネクション確立のたびにSlimSocketからSlimRouterに通信するのは相当オーバーヘッドが大きそう
    • コネクション確立のオーバーヘッドの問題点は論文中でも述べられていて、従来のContainer Overlay Networkを経由するよりは総合的には速いっぽい
    • 短いコネクションだとかなり遅そうなのでコネクションの再利用が重要になってくるのか
  • LD_PRELOADなるものを使っているのか。eBPF使ってもできそうだがどう違う？
    • 少なくともeBPFよりセキュアではなさそう
    • 静的リンクを必要とするシステム(Goで書かれたアプリなど)ではバイナリにパッチが必要だと書いてあるのが気になった(よく分かっていない)
      • サラッと書いてあるが結構なデメリットでは？
      • eBPFで同じことができるならこのデメリットはなくなりそうだがどうなんだろう
  • 実装レポジトリが公開されていたので読んでみたい( https://github.com/danyangz/slim )

XMasq: Low-Overhead Container Overlay Network Based on eBPF

S. Lin, P. Cao, T. Huang, S. Zhao, Q. Tian, Q. Wu, D. Han, X. Wang, and C. Zhou, “Xmasq: Low-overhead container overlay network based on ebpf,” 2023. [Online]. Available: https://doi.org/10.48550/arXiv.2305.05455

概要
  • eBPFを用いて、最初のラウンドトリップのパケットでコンテナペアごとに情報をキャッシュしておき、その後のパケットヘッダを書き換えることでコンテナオーバーレイネットワークをbypassする提案
  • キャッシュする情報は主にSrc/DstそれぞれでHost/ContainerのMac/IPアドレスとContainerのNIC index、コンテナペアをホストペア内で一意に識別するKey
感想
  • すごく革新的で面白そうな提案だと思った
    • 今月初めにarXivに投稿されたばかりなので動向が気になる
  • Restore KeyをID, DSCP, Optionのいずれかに書き込むことによる副作用はないのかな
  • コンテナの配置ホストを移動する際にキャッシュを削除することでContainer Live Migrationを実現しているのならば、キャッシュのrefresh時間を設定してrefreshする意味はあるんだろうか？
  • 各ホストごとに関係するコンテナペアの情報をキャッシュする必要があるが、コンテナが増えるとキャッシュサイズがかなり大きくならないか？
    • あるコンテナが通信するコンテナは限られているから問題ない？
  • ラウンドトリップを利用して送信元と送信先コンテナの情報を互いのホストで埋めているので、UDPで一方的にパケットを送り続ける(レスポンスがない)通信の場合は適用きないな
    • そんな通信なかなかなさそうではある
  • Masq Mapにアクセス制御ルールの照合結果をキャッシュしておけば毎回Rule Mapを見る必要は無くなりそう
  • コンテナ内からtracerouteするとアンダーレイネットワーク情報が分かってしまうとのことなので、テナントが信用できない場合は利用が難しいかも？
    • Slimはここら辺結構気をつけてた
  • GitHubレポジトリのURL載ってたけど404だった
    • 実装見たかったので残念だが、いずれ公開されるのだろうか