KubeCon EU、欠点から逆算するKubernetesのネットワークに関するセッションを紹介

KubeCon EUからKubernetesのネットワークの構造的な弱点を紹介し、eBPF（Extended Berkeley Packet Filter）を使ったネットワークスタックであるCiliumの利点を解説するセッションを紹介する。このセッションはオープンソースのネットワークスタックであるCiliumの開発元であるIsovalentのCTOであるThomas Graf氏が行ったもので、Kubernetesのネットワークの構造に由来する盲点を指摘しながら、それを解消するためのテクノロジーであるCiliumを推奨するものだ。特徴的なのは、Cilium自体についてはほとんど解説されていないという部分だろう。

セッションの動画：How to Break your Kubernetes Cluster with Networking - Thomas Graf, Isovalent

タイトルは「How to Break your Kubernetes Cluster with Networking」というもので、Kubernetesのネットワークの構造やカスタマイズの方法に由来する欠点を指摘しながら、デモを交えて解説を行った。

IsovalentのCTO、Graf氏のセッション

最初にKubernetesのネットワークに関して、CNCFが用意したKubeCon EUの公式タイトルスライドにKubernetesのネットワークの状況が現れているとして解説を始めた。

iptables、kube-proxy、CoreDNSなどが協調して働いているのがKubernetesのネットワーク

ここでは、eBPFの比較対象として常に挙げられるiptablesがkube-proxyやCoreDNS、アプリケーションと連携して稼働していること、しかしプラットフォームチームがKubernetesのネットワークにおける弱点を無視して運用しているということを皮肉として解説した。このセッションでは主にKubernetesの弱点を解説しながら、それを防ぐためにはなにが必要か？ については深い説明をせずに、最後にCiliumの名前だけを紹介している。

Ciliumについて知る

実際にCiliumを理解するためには、2020年に行われたKubeCon EU 2020のセッションを参照すると良いだろう。ここからはKubeCon EU 2020の「Hubble - eBPF Based Observability for Kubernetes」と題されたセッションをかいつまんで紹介する。担当したのはIsovalentのSebastian Wicki氏だ。

セッションの動画：Hubble - eBPF Based Observability for Kubernetes - Sebastian Wicki, Isovalent

このセッションはCiliumではなくCiliumに連動するオブザーバービリティのためのツールであるHubbleの紹介を行っているが、コアとなっているeBPFそしてCiliumとの関連についても良くわかる内容になっている。

eBPFの解説

まずCiliumのコアであるeBPFについては「Linuxのカーネルの機能に小さなプログラムを動的に追加し、セキュアに実行する機能」であると紹介。ここでは通信機能に使われるだけではなく、ブロックデバイスなどのストレージにも応用が可能であることが解説されている。iptablesが通信に特化しているのに対して、eBPFはカーネルモードで動的にプログラムを実行させるという発想になっていることがわかる。

そして次のスライドからCiliumが暗号化やロードバランシングも可能なネットワークモジュールであり、それに対してHubbleはCiliumと連動してメトリクスを採取するモジュールであることがわかる。Thomas Graf氏のセッションでも、デモの中でHubbleのCLIを使ったモニタリングが行われている。CiliumとHubbleはセットで使うのが、Ciliumコミュニティの想定ということだろう。

CiliumとHubbleの概略

ここまでの経緯を紹介したスライドでは、CiliumとHubbleが文字通りセットとして開発されてきたことがわかる。

CiliumとHubbleの開発の歴史を紹介

ここでの注目は202年2月のCilium 1.7の時点でHubbleがオープンソースになったという記述だろう。ここからHubbleは元々プロプライエタリーな商用ソフトとして開発され、途中でCiliumと連携するようになり、完全なオープンソースに移行したことがわかる。またRelayというクラスター間をまたがるCiliumのメトリクスを採取する機能によって、マルチクラスターにおいても統合的なメトリクス監視が可能になっていることにも注目だろう。

CiliumとHubbleが同じエージェントに共存していることが分かるアーキテクチャー図

またサービス間の通信をiptablesと比較して、Ciliumがどのようにショートカットしているのかを表したスライドがあるのでそれも紹介したい。

iptablesによるPod間通信の概略

CiliumによるPod間通信の概略

これはKubeCon EU 2021の「eBPF on the Rise - Getting Started Quentin Monnet, Isovalent」というセッションのものだ。これを見れば、iptablesによる通信と比べてCiliumが効率的に通信を行っていることがわかるだろう。

動画：eBPF on the Rise - Getting Started - Quentin Monnet, Isovalent

Kubernetesネットワークの課題

ここまででカーネルモードで実行されるプログラムを動的にインジェクトするeBPFと、それを使ったネットワークスタックであるCilium、そしてモニタリングのためのモジュールであるHubbleの概略を紹介した。ここからKubeCon EU 2021のThomas Graf氏のセッションに戻って、Kubernetesのネットワークの問題点を紹介していく。

Kubernetesのネットワーク機能のダークサイドを紹介

ここで紹介されているダークサイドの主要な配役はDNSであるというのがポイントだ。

Ciliumのユーザーが実際に体験したトラブルから引用

ここからは、Ciliumユーザーが実際に体験したKubernetesのネットワークにおける問題点を解説していく。最初にKubernetesのネットワークの基礎を解説。

Kubernetesのネットワークの基礎

すべてのPodにIPアドレスが割り当てられ、何の設定もしなければPod間の通信はすべて許可され、ロードバランシングのサービスがデフォルトで実装され、CoreDNSによってサービスディスカバリーが実現されていることなどをトピックとして紹介した。

KubernetesのDNSを紹介

ダークサイドの主要な配役として名指しされたDNSだが、ここからクラスター内の名前解決の仕組みを解説し、デモを交えてndotsによる名前解決の動作の遅延、DNSによるレートリミットを超えたことによるエラーが発生する事象などを紹介して、DNSに起因するトラブルが多いことを解説した。

DNSのエラーとしてレートリミットに引っかかる例を紹介

またネットワークポリシーの設定におけるよくあるミスも紹介した。

Kubernetesのネットワークポリシーを紹介

ここではフロントエンドとバックエンドのPodが通信を行うという設定において、DNSへの通信を許可しないことでサービスディスカバリーが行えなくなる問題を紹介。

EgressのポリシーにDNSが含まれていない問題

ここでCiliumプロジェクトが開発しているNetwork Policy Editorを使ってダイヤグラムを操作することで、必要なYAMLファイルが生成されることを紹介。

Network Policy Editorの紹介

またネットワークサービスとロードバランシング、さらにKubernetesをカスタマイズするCRDについても具体的なトラブル例に沿って紹介した。

トラフィックの増大に従って性能が劣化するKube-Proxyと劣化しないeBPF

このスライドはKubeCon NA 2019のセッションからの引用だが、サービスへの通信が増加するとiptablesを使った場合に明らかに劣化がみられることを紹介した。このグラフの黄色のバー（レイテンシーなので短いほど良い）が急激に遅くなっていることを示している。

また脆弱性としてKubernetesにおいて発生するMan in the Middle攻撃についてもデモを交えて紹介し、Kubernetesのネットワークにはまだ課題が多いことを解説した。

CVE-2020-8554の紹介を、デモを交えて行った

またKubernetesをカスタマイズする仕組みであるCRD（Custom Resource Definition）についても、起動時に大量のブートストームが発生することを紹介。API Serverへの大量のアクセスによって性能が劣化することを紹介した。

CRDへのアクセスが集中することでAPI Serverの性能が劣化する

さらにKubernetesのネットワークモジュールの規格であるCNIにおいても、プラグインとして実装されるモジュールと設定ファイルの合致しない問題や、設定ファイルだけが残される問題、CNIプラグイン起動時の競合問題など、実際に発生した多くの事例をベースに解説し、Kubernetesのネットワークには設計上の問題はなくとも運用上の問題がまだ残されていることを紹介した。

CNIとCRDがマッチしないことで問題が発生していると解説

そして結論として「Shiny Objects are Cool but keep it simple」として「Kubernetesはカッコイイソフトウェアだが、シンプルに実装して運用することが大事」であることを強調した。

Keep it Simpleが大事と強調

またKubernetesのネットワークにおいては、単に接続ができることだけではなく可視化することが重要だと強調してセッションを終えた。この部分の可視化はCiliumにおけるHubbleを指していると思われる。Kubernetesについて「ネットワークがわかりにくい」と言われるのは、複雑というよりも何が起きているのか見えづらいということに由来しているとすれば、HubbleのようにGUIでもコマンドラインでもメトリクスを取って可視化できる機能が役に立つだろう。

Graf氏がデモとして使ったNetwork Policy Editorについては以下のサイトを参照されたい。

Network Policy Editor

Ciliumの公式GitHubページは以下から参照されたい。

Cilium：https://github.com/cilium/cilium

Isovalentが主催しているeCHOというオンラインセミナーでもCiliumとHubbleが紹介されているので、こちらも参考にすると良いだろう。

eCHO episode 1: Introduction to Cilium

eCHO episode 2: Introduction to Hubble

CiliumとHubbleの公式ドキュメント：Introduction to Cilium＆Hubble