Tinkerbellから学ぶ、Podで DHCPをリッスンする手法

Kubernetes上でDHCP Serverを扱おうとすると、物理ネットワークセグメントのブロードキャストをどう受けるかといった面倒臭い課題があり、素直に `hostNetwork=true` をするだけでは解決できないこともあります。

このLTでは、TinkerbellのDHCPコンポーネント「Smee」が使っている仕組みを参考に、Pod側にmacvlanインターフェースを渡してDHCPブロードキャストをクリアに受信する経路を用意する方法を紹介します。KubernetesでのPXE Bootやベアメタルのプロビジョニング周りに興味がある方はぜひご覧ください。

Transcript

1. Tinkerbellから学ぶ、Podで 
 DHCPをリッスンする手法 
 近藤 智文（@tomokon_0314）
 
 2025/11/25 Kubernetes Meetup Tokyo #72

2. 自己紹介
 • 近藤 智文（@tomokon_0314）
 • 仕事
 ◦ サイバーエージェント24新卒（2年目）
 ◦ プライベートクラウドのIaaS基盤の開発
 ◦ OpenStack, Kubernetes, ストレージ, 仮想ネットワーク, etc.
 • 趣味
 ◦ 自宅サーバー
 ◦ 最近はベアメタルプロビジョニング/PXEブート周りの構築

3. “Tinkerbell” の紹介 
 
 • CNCF Sandbox Project
 • ベアメタルサーバーの自動プロビジョニングシステム
 • Smee
 ◦ DHCPとPXEブートの応答を担当するコンポーネント
 ◦ ベアメタルホストに対してDHCPを通じてIPアドレスやブート設定を渡す

4. 今日のテーマ： 
 Kubernetes上でDHCPサーバーを動かす際の課題 

5. DHCPサーバーのデプロイパターン 
 L2直結 
 DHCPサーバーとベアメタルホストを 
 同一L2セグメントに配置し、ブロードキャストがその ままDHCPサーバーに到達 
 →Pod上のプロセスがブロードキャスト 
 　をリッスンする必要がある 
 DHCPリレー経由 
 DHCPリレーがブロードキャストをDHCPサーバー 宛のユニキャストに変換して転送 

6. hostNetwork=true でいいのでは？ 
 • PodをNodeのネットワーク名前空間で直接実行
 • 物理インターフェースも見えるため一見良さそう

7. hostNetwork=true の課題 
 ホストのnetnsを全部Podと共有してしまう
 • 意図しないインターフェースで受信する可能性
 • 意図しない送信元IPアドレスでDHCPリプライを送ってしまうかも
 • ポート競合
 
 →いかなる環境でも安定して動かすことが難しい 

8. Tinkerbellでの解決策 
 • init containerでmacvlanインターフェースを作成し てpodのnetnsに渡す
 • Smee（DHCPサーバー）はmacvlanインターフェー スを指定してDHCPをリッスン
 • ホストとnetnsを共有することなくDHCP
 ブロードキャストをmacvlanで受信可能
 

9. まとめ
 • DHCPのようなL2構成まで考慮するワークロードをk8sで動かすには工夫が必要
 • Tinkerbellではmacvlanインターフェースを使うことでホストとnetnsを共有することなく 綺麗なDHCPサーバーへのパスを提供
 
 
 Tinkerbell面白いのでぜひ使ってみてください！ 

10. References 
 • Tinkerbell
 ◦ https://tinkerbell.org/
 • Tinkerbellについて | フューチャー技術ブログ
 ◦ https://future-architect.github.io/articles/20230622a/