Kubernetesネットワーキングの世界で、Cilium(シリウム)はeBPF技術を基盤とした強力な性能と機能で大きな注目を集めています。特にHTTPリクエストパス(GET /api/v1)やgRPCメソッドに基づいてポリシーを設定するLayer 7(アプリケーション層)機能は、Ciliumを「次世代CNI」として印象付ける上で大きな役割を果たしました。
しかし、「CiliumはL7 CNIだ」とだけ知っていると、最も重要な核心を見落としているかもしれません。Ciliumの本当の力はどこから来るのでしょうか?その心臓部を一緒に掘り下げてみましょう。🚀

🏛️ Ciliumのコアデータパス:L3とL4が真の主役
結論から言うと、CiliumのコアデータパスはLinuxカーネルで直接動作し、その主舞台はOSIモデルのLayer 3(ネットワーク層)とLayer 4(トランスポート層)です。
1. Layer 3(ネットワーク層)🌐:すべての通信の基本
- 役割:Podネットワーキングの最も基本となるIPアドレスベースのルーティングを担当します。
- Ciliumの役割:Ciliumは各PodにIPアドレスを割り当て、eBPFを利用してノード間のPod通信経路を非常に効率的に処理します。複雑なiptablesルールやオーバーレイネットワークの性能低下なしに、カーネルレベルで直接パケットを転送します。これがCiliumが高速を誇る最初の秘訣です。
2. Layer 4(トランスポート層)🔌:サービスとポリシーの心臓部
- 役割:TCP/UDPポートに基づいてデータを正確なサービス(プロセス)に転送します。
- Ciliumの役割:Kubernetesの主要機能であるサービス(Service)ロードバランシングとネットワークポリシー(Network Policy)は、まさにこのL4で行われます。
- kube-proxyの代替:CiliumはeBPFを使用してkube-proxyの機能を完全に代替します。サービスのClusterIPとポートに入ってきたリクエストを実際のPodのIPとポートに変換し、分配するプロセスをカーネルで直接処理することで、驚異的な性能向上をもたらします。
- 主要ネットワークポリシー:「A PodはB Podの80番ポートとのみ通信できる」といった基本的なネットワークポリシーはすべてL4レベルで処理されます。
このように、CiliumはeBPFを通じてL3/L4で既に高速かつ効率的なネットワーク基盤を完成させます。ほとんどのトラフィックはこの段階で迅速に処理されます。
✨ では、強力なL7機能の正体は?
「ちょっと待って、Ciliumが誇るL7ポリシーはどうやって動作するんですか?」
非常に良い質問です。CiliumのL7機能が強力なのは事実ですが、これはL3/L4データパスの上に構築された「インテリジェントな拡張機能」です。すべてのトラフィックをL7で検査するのは非効率的だからです。
Ciliumの動作方式を段階的に見ていくと明確になります。
- パケット到着:パケットがノードに到着すると、カーネルのeBPFプログラムが最初に傍受します。
- L3/L4検査 (eBPF):eBPFはこのパケットの送信元/宛先IP(L3)とポート(L4)を確認し、ネットワークポリシーと一致するかどうかを迅速に判断します。
- 分岐点 (Decision Point):
- L7ポリシーがない場合 ✅:もし該当トラフィックに適用されるL7ポリシーがない場合、eBPFはカーネルレベルで直接ALLOWまたはDENY処理を行い、終了します。非常に高速です!
- L7ポリシーがある場合 ➡️:もし「80番ポートに入ってくるトラフィックのうちGET /publicのみ許可」といったL7ポリシーがある場合、eBPFはそのトラフィックをユーザー空間(User Space)で実行中のEnvoyプロキシに送ります。
- L7検査 (Envoy Proxy):Envoyプロキシは受け取ったトラフィックのHTTPヘッダー、パス、メソッドなどを詳細に分析し、ポリシーに基づいて許可/遮断を決定します。
つまり、Ciliumは必要な時にだけ選択的にトラフィックをL7プロキシに送って処理する効率的なハイブリッドモデルを使用します。L3/L4の速度とL7の深さの両方を捉えているのです!
📜 コードで見るL4とL7ポリシーの関係
以下のCiliumNetworkPolicyの例を見ると、この構造が明確に理解できます。
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: api-access-policy
spec:
endpointSelector:
matchLabels:
app: my-api
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
# ⬇️ L4 Policy: まず、80番ポートに入ってくるTCPトラフィックを許可します。
toPorts:
- ports:
- port: "80"
protocol: TCP
# ⬇️ L7 Policy: 上記L4ルールに該当するトラフィックのうち、HTTPルールを追加で適用します。
rules:
http:
- method: "GET"
path: "/public/.*"
- method: "POST"
path: "/data"
ご覧のように、L7ルール(rules.http)はL4ルール(toPorts)の内部に定義されています。これは、L7ポリシーがL4というより大きな枠組みの中で動作する拡張機能であることを示す直感的な証拠です。
❌ 「CiliumはL7 CNIだ」という誤解が危険な理由
もしCiliumを純粋なL7ソリューションとしてのみ理解すると、次のような誤解を招く可能性があります。
- 性能の誤解:すべてのトラフィックがプロキシを通過すると誤解し、性能低下を懸念するかもしれません。しかし実際には、ほとんどのトラフィックはカーネルで迅速に処理されます。
- ポリシー設計の非効率性:L4で簡単に遮断できるトラフィックを、不必要に複雑なL7ポリシーで作成してしまう可能性があります。基本はL4から始めるのが良いでしょう。
- 問題解決の困難さ:通信問題が発生した際、L7プロキシ(Envoy)だけを調べるかもしれません。しかし、問題の原因がL3/L4の基本的なルーティングやポートポリシーにある可能性を見落としがちです。
🎯 結論:全体を見れば真実が見える
Ciliumの本当の強みは、単にL7機能が優れているという点だけではありません。
eBPFを活用した超高速L3/L4データパスを基盤とし、必要に応じてL7の可視性と制御機能をインテリジェントに統合したハイブリッドアーキテクチャ
これこそがCiliumを理解する核心です。強固な基礎(L3/L4)の上に精巧な機能(L7)を積み上げた、よく設計された建物のようなものです。Ciliumを見る際には、その強力な基盤となるL3とL4の役割をぜひ覚えておいてください!✨
コメントを残す