前編のeBPF解説はいかがでしたか。後編では、Kubernetes向けの代表的なeBPFソリューションであるCiliumを取り上げ、Dataplane V2との関係を掘り下げていきます。
Cilium 🐝 はeBPFを基盤とする、いま注目の技術です。eBPFといえばまず名前が挙がる存在で、特にKubernetes界隈ではその傾向が顕著です。Ciliumは、Kubernetes向けのCNIプラグインとして動作するオープンソースソフトウェアで、クラウドおよびオンプレミスでKubernetesを運用するプラットフォームチームに、eBPFベースのネットワーキング・可観測性・セキュリティを優れたスケーラビリティとパフォーマンスで提供します。
Extended Berkeley Packet Filter(eBPF)を活用するCiliumは、Kubernetesに数多くの興味深い機能をもたらします。さっそく見ていきましょう。
ネットワークポリシー 🕸
Kubernetes Pod間の通信には、最小権限(Least Privilege)の原則を適用するのがベストプラクティスです。標準のKubernetes Network Policies(L3/L4で動作)も十分に機能しますが、Cilium Network Policies(L3〜L7で動作)を併用することでさらに強化できます。
これはKubernetesやマイクロサービスの世界で非常に有用です。というのも、IPやポートといったメタデータでトラフィックを検査・制御してもさほど意味がないからです。サービスの起動・停止に伴ってIPやポートは絶えず変化します。Ciliumを使えば、Pod・HTTP・gRPC・Kafka・DNSなどのメタデータでもトラフィックを制御できます。
たとえば、特定のAPIコールをパス・ヘッダー・リクエストメソッド単位で、特定のPodからのみ許可するHTTPルールを定義できます。あるいはFQDNベースのDNSルールを定義し、特定ドメインへのクエリのみを許可することも可能です。これにより、現実のユースケースで真に役立つセキュリティポリシーを定義できます。
マルチクラスタ接続 🔗
Ciliumはクラスタメッシュを用いて、Kubernetes Podがクラスタをまたいで相互に通信・検出できるようにします。ユースケースとしては、高可用性やマルチクラウド(複数のクラウドプロバイダーをまたぐKubernetesクラスタ接続)などが挙げられます。
ロードバランシング ⚖️
Ciliumはkube-proxyをBPFベースで置き換えます。kube-proxyが利用しているiptablesは、BPFへの置き換えが進んでいます。これによりパフォーマンスが大幅に向上します。
その他の機能
- Pod間の透過的暗号化。IPsec/Wireguardに対応
- ネットワークパフォーマンスの向上
- 高いインフラスケーラビリティ
- IPやポートだけでなくL7プロトコルレベルでのトラフィックフロー可視化の強化。興味深いDNSデバッグの事例はこちらの記事をご覧ください
- マイクロサービス間のネットワークエラーに対するモニタリングと可視性向上。CiliumはPrometheus互換のメトリクスを提供します
代替手段にも触れておきましょう。市場には他にも有力なCNIプラグインがあります。 こちらの比較 (主観が含まれる可能性あり)も参考になります。Calicoも最近、eBPFデータプレーンを 導入しました 。
Dataplane V2 ✈
Google Cloud Platformは、独自の仕組みであるDataplane V2にCiliumを取り入れることで、GKE(Google Kubernetes Engine)を最新動向に追従させています。では、Dataplane V2は本当にGKE向けのGoogleマネージドCiliumなのでしょうか。マネージドサービスは魅力的ですよね。ここはじっくり検証してみる価値がありそうです。
GoogleのDataplane V2のコンセプトに関するドキュメントを確認しても、Ciliumプロジェクトへの言及は見当たりません(本記事執筆時点)。ただし、公式ブログ記事や一部のドキュメントには、わずかながら言及があります。
Dataplane V2のコントロールプレーンは、anetdというKubernetes DaemonSetとしてデプロイされます。kubectl describe daemonsets.apps -n kube-system anetdを実行してみると、gke.gcr.io/cilium/cilium:v1.9.4-gke.17というイメージが使われていることがわかります。
では、これは本当にCiliumなのでしょうか。kubectl exec -n kube-system -ti ds/anetd — cilium versionを実行してみましょう。出力は次のとおりです。
Client: 1.9.4 609a63dfb 2021-04-12T15:01:54-07:00 go version go1.15.7 linux/amd64
確かにCilium 1.9.4です。ただし、公式のCilium v1.9.4イメージと比較すると、結果が微妙に異なります。
Client: 1.9.4 07b62884c 2021-02-03T11:45:44-08:00 go version go1.15.7 linux/amd64
続いて、gke.gcr.io/cilium/cilium:v1.9.4-gke.17とquay.io/cilium/cilium:v1.9.4のDockerイメージをDiveのようなツールで比較してみます。レイヤーにはいくつか変更があるようですが、Ciliumの提供機能の観点で大きなロジック変更があるかどうかを判断するのは難しいところです。
付け加えると、 このブログ記事 では、Googleが自ら関与し、Ciliumプロジェクトに有意義な機能を数多く貢献したと述べられています。これは一定のコミットメントの表れと言えるでしょう。
結局、Dataplane V2 = マネージドCiliumなのか?
現時点では、Dataplane V2がGKE向けのマネージドCiliumかどうかを断定することはできません。公式の見解がない以上、少なくともプロダクトとしては Dataplane V2 ≠ Cilium と言うほかありません。内部的にはCiliumが使われているように見えますが、Googleのドキュメントはそれに言及せず、Ciliumのドキュメントへ誘導することもありません。完全に別物の提供形態として位置付けられているのです。
筆者が試した範囲では、Dataplane V2上でも一部のCilium機能は動作するようでした。しかし、Googleの公式サポート対象ではありません。言うまでもなく、Dataplane V2における「未確認」のCilium機能は、いま動いていてもいつ突然動かなくなるかわかりません。未踏の領域には踏み込まず、安全のために公式ドキュメントに従うのが賢明です。
バニラCilium、それともDataplane V2? 🤔
機能を比較してみましょう。
現時点でCiliumとDataplane V2に共通する機能は次のとおりです。
- Kubernetes Network Policies(CiliumNetworkPolicyは対象外。ただしDataplane V2は現時点で拒否はしないようです)
- eBPFによる
kube-proxyの置き換え - ネットワークポリシーロギング。厳密にはCiliumの機能ではありませんが、Ciliumをベースとしており、ネットワークポリシーのヒット結果をモニタリングできます。
筆者の見解 💭
筆者は常に、できるだけシンプルなソリューションを選ぶようにしています。マネージドであればなおのこと、関係者全員にとって貴重な時間を節約できます。Kubernetes Network Policies、性能・スケール向上のためのkube-proxyのeBPF置き換え、そして使いやすいネットワークポリシーロギングだけが必要なのであれば、Dataplane V2の方がシンプルで導入も容易なマネージドソリューションだと言えるでしょう。
ただし、その制限事項には必ず目を通してください。Hubble、Cilium L7 Network Policies、Cluster MeshといったCilium独自機能が必要な場合や、セルフホスト・別のクラウドプロバイダーでの利用を想定する場合は、バニラCiliumを選ぶ方がよいでしょう。
Dataplane V2のメリット 👍
- 第一に、導入が簡単です。
gcloud container clusters createで新しいGKEクラスタを作成する際に—enable-dataplane-v2フラグを付けるだけで有効化できます。 - オープンソースのCiliumプロジェクトをベースにしています。
- Dataplane V2は、GKEのネットワークポリシーロギングの基盤としても機能します。これは、ネットワークポリシーによって接続が許可・拒否された際にログを生成できる便利な機能です。
- Dataplane V2の構成要素である
antedプラグイン(Ciliumベース)はGoogleが管理しており、現在GA(General Availability)です。つまり、本番環境のworkloadsに利用可能で、継続的な更新とサポートが提供されます。 - 今後、GoogleがGKEネイティブ機能、さらにはCiliumネイティブ機能との統合を増やしていくと考えるのは自然でしょう。長期的視点で見ると、選択肢としての魅力はさらに高まります。
Dataplane V2のデメリット 👎
- 現時点では、Dataplane V2でHubbleを利用する方法は見つかりませんでした。HubbleはCiliumによる優れた可観測性ツールで、Cilium eBPFを活用して重要な可視性を提供します。進捗はこちらで追跡できます。
- 公式には、Dataplane V2はマネージドCiliumソリューションではありません。つまり、現在Dataplane V2で動作している一部のCilium機能を当てにすることはできず、今後突然動作しなくなる可能性があります。
- 新規作成のGKEクラスタでのみ有効化でき、既存のGKEクラスタには適用できません。
- このほかにも、把握しておくべき制限事項がいくつかあります。
はじめかた 🏃🏽♀️
KubernetesでCiliumを使い始めるにはこちら。
GKEでDataplane V2を使い始めるにはこちら。
ワンポイント:Kubernetes/Cilium Network Policyのマニフェストを作成・設計する際は、 Cilium Editor を使うと楽しく安全に作業できます。
eBPFの未来
これは画期的な技術であり、eBPFを活用したソリューションや興味深い発展は今後も続々と登場するはずです。
影響が及ぶと見込まれる領域の一つがサービスメッシュです。既存のサービスメッシュソリューション(IstioやLinkerdなど)の多くは、Podに付随させるサイドカープロキシに依存しており、これがパフォーマンス低下や複雑化、新たな障害点の追加につながっています。eBPFはサイドカープロキシをeBPFロジックで置き換えることでサービスメッシュ機能を実現できる可能性を秘めており、より幅広いユースケースでサービスメッシュを利用しやすくしてくれるかもしれません。
続報にご期待ください。
お読みいただきありがとうございました。最新情報は DoiT Engineering Blog 、 DoiT LinkedInチャンネル 、 DoiT Twitterチャンネル でフォローしてご覧ください。採用情報は https://careers.doit-intl.com からご確認いただけます。