概要
「Kubernetesのネットワークが何もわからないから、Kubernetes基盤を運用するプラットフォームエンジニアとどう関わればいいかわからない…」
そんな悩みを抱えたことはありませんか？
近年のクラウド基盤の発展に伴い、オンプレミス環境においてもKubernetesなどクラウドネイティブな基盤の導入が進む中、CNI(Container Network Interface)がコンテナ間通信を支える中核コンポーネントとして注目されています。
CNIはどんなネットワーク技術でもフラットにコンテナへ接続できるようにする柔軟な仕組みであり、NWとプラットフォームの窓口として設計されています。
しかし、CNIは境界領域ゆえ、ネットワークエンジニアとプラットフォームエンジニアの双方にとってブラックボックス化し、フラットな対話を阻む壁となることがあります。
本発表は、このCNIを思想と実装の両面からフラットな目線で紐解きます。
そもそも「CNI」という言葉は、CNIの仕様(本体)、基盤(Kubernetesなど)が求める要件、それらの実装であるCNIプラグインの3つをまとめて指すことが多い用語です。
まずCNIの仕様が示す「どんなネットワーク技術もフラットに受け入れる」という柔軟な設計思想を紐解き、Kubernetesなどの基盤がどのような要件を定義しているか整理します。
その上で、Flannel・Calico・Ciliumといった主要CNIプラグインの実装に踏み込み、それらがどのようにオーバーレイ(VXLANやVPN)、L3ルーティング(BGP)、eBPFといった異なる手法でネットワークを構築しているか比較します。
現場では、プラットフォームチームが主要CNIを選定し、ネットワークチームがノータッチになってしまうケースも少なくありません。
しかし主要CNIはどこでも動く汎用性の代償として、見えないオーバーヘッドや設計上の制約を抱えています。
SR-IOVのようなシンプルな構成で済む環境でもVXLANオーバーレイを無条件に採用するような例も多く、対話の欠如が非効率を生んでいるのです。
CNIをブラックボックスから共通言語へ。
さらに効率の良いKubernetesネットワークのために、CNIを通してネットワークとプラットフォームが「フラッと」に対話できる未来を、ここから一緒に考えてみましょう。
議論ポイント
- CNI選定の基準は何か？
- プラットフォーム視点とネットワーク視点で、どのように選定基準が異なるか
- ネットワークエンジニアはどのようにプラットフォームに助言できるのか
- ネットワークとプラットフォームの責任分界点
- CNIを誰がどこまで理解し、管理するべきか？
- CNIを「どちらも触らない」ではなく「どちらも触る」にするために、双方は何ができるか
- どんな環境でも動く汎用設計と現場最適化のバランス
- メジャーなプラグインが提供する汎用実装のオーバーヘッドは、どこまで許容できるか
- Google CloudやAWS、Azureがやっているような自社のアンダーレイネットワークへの最適化は、我々にとって現実的な選択肢になり得るか
- CNIプラグイン自作・改変は現実的な選択肢か。現場で取り得る「最適化レベル」はどこか
- 次世代のCNIやコンテナネットワークの未来は？
- eBPFベースの高速化、SRv6統合、クラウド横断ネットワークなど、次世代の方向性はどうなるか
- DraNetなどのAIワークロードに対する最適化は、この先どのように進めるべきか
場所
本会議場3 グラングリーン大阪北館5F 5-1
日時
Day2 2026年2月12日(木) 15:00～16:00 (1時間)
発表者
公開資料
各種情報
| ストリーミング配信 | 実施する |
| アーカイブ配信 | 実施する |
| SNSやSlackでの議論 | 制限しない |
| プログラム種別 | 登壇者から応募のあったプログラムです |
アーカイブ配信
本会議終了後、順次配信予定です
