【ITニュース解説】Comparing Cilium Networking Setups on a Talos Hybrid Kubernetes Cluster

今回のニュース記事は、Talos Linuxを使ったKubernetesクラスターを、クラウドとオンプレミス環境にまたがる「ハイブリッド環境」で運用する際のネットワーク設定について、特に「Cilium（シリウム）」というネットワークソフトウェアと「KubeSpan（キューブスパン）」というTalos独自のネットワーク技術を組み合わせた際の実証実験とその結果を詳しく説明している。システムエンジニアを目指す上で、このような複雑な分散システムのネットワーク課題を理解することは非常に重要である。

まず、基本的な用語を整理する。Kubernetesとは、コンテナ化されたアプリケーションを効率的に動かすためのシステムで、多数の「ノード」と呼ばれるコンピュータが協力して動作する。これらのノードは役割によって「コントロールプレーンノード」（全体の管理を行う司令塔）と「ワーカーノード」（実際にアプリケーションが動く場所）に分けられる。アプリケーションは「Pod（ポッド）」という最小単位でノード上で実行される。そして、これらのPodやノード間の通信を管理するのが「CNI（Container Network Interface）」と呼ばれるネットワークインターフェース規格で、CiliumはそのCNIの一種である。

ハイブリッド環境では、クラウド上のノードとオンプレミス（自社内）のノードが混在するため、ネットワークの接続が複雑になる。今回の実験では、コントロールプレーンノードがAWS（アマゾンウェブサービス）というクラウド上にあり、ワーカーノードはオンプレミスにあるQEMUという仮想化ソフトウェア上で動いている。このような異なる場所に存在するノード間での通信をいかに安全かつ効率的に行うかが大きな課題となる。

実験1：CiliumのネイティブWireGuardとKubeSpan無効の場合

最初の実験では、Ciliumが持つ「WireGuard（ワイヤーガード）」というVPN（Virtual Private Network）技術を使った通信暗号化機能を使い、KubeSpanを無効にしてみた。WireGuardは、インターネットなどの公共ネットワークを経由しても、安全で暗号化された通信路（トンネル）を確立するための技術である。理論上は、これによりPod間の通信は安全になるはずだった。

しかし、結果は失敗に終わった。その原因は「NAT（Network Address Translation）」という技術にある。オンプレミスのワーカーノードはNATの背後にあった。NATは、企業内などのプライベートネットワークにある複数のコンピュータが、外部（インターネットなど）からは一つのグローバルIPアドレスを使って通信できるようにする技術である。これにより、外部からプライベートネットワーク内のコンピュータの実際のIPアドレスを直接知ることはできない。

CiliumのWireGuard実装は、ノード同士が互いのIPアドレスを直接知っていて、直接通信できることを前提としている。しかし、オンプレミスのワーカーノードがNATの背後にあるため、クラウド上のAWSノードからそのワーカーノードに直接アクセスできず、WireGuardの通信確立（ハンドシェイク）ができなかった。Ciliumは「NATトラバーサル」と呼ばれる、NAT環境下でも通信を確立する技術（例えば、外部からの接続要求を内部に転送する「ポートフォワーディング」や、一時的に通信経路を開ける「ホールパンチング」のような仕組み）を標準ではサポートしていないのだ。

ここで、KubeSpanの重要性が明らかになった。KubeSpanはTalos Linux独自の技術で、WireGuardをベースにしているが、ハイブリッド環境やNATの制約がある環境向けに特別に設計されている。KubeSpanはノード間の境界を越えて自動的にWireGuardトンネルを構築し、NATの背後にあるノードであっても通信を可能にする。この実験から得られた教訓は、NATがあるハイブリッド環境では、KubeSpanなしではCiliumのWireGuardは機能しない、ということである。

実験2：VXLANカプセル化を減らすためのネイティブルート（KubeSpan有効の場合）

次の実験では、ネットワークの効率性を上げる方法を探った。通常のKubernetes環境では、Pod間の通信に「VXLAN（Virtual eXtensible Local Area Network）」という技術がよく使われる。VXLANは、仮想的なネットワークを作り出すための技術で、実際のデータパケットを別のパケットの中に「カプセル化」（包み込む）して送ることで、異なるネットワークセグメント間でも通信を可能にする。これは便利だが、カプセル化の処理にわずかながら「オーバーヘッド」が発生する。特に、ノードをまたがるハイブリッド環境での通信では、このオーバーヘッドが無視できない影響を与える可能性がある。

そこで、このオーバーヘッドを減らすために、Ciliumの「ネイティブルート」という方法を試した。ネイティブルートとは、カプセル化などの追加処理をせずに、IPパケットを直接ルーティングする方式である。これにより、データパスがシンプルになり、通信の遅延（レイテンシ）を減らし、単位時間あたりのデータ処理量（スループット）を向上させることが期待できる。

当初は、ネイティブルートがハイブリッド環境のような複雑なネットワークでは機能しないと考えられていた。しかし、いくつかの工夫（「ワークアラウンド」と呼ばれる回避策）を施すことで、これを可能にできた。具体的には、以下の手順を踏んだ。

まず、各ノードで動作する特別なプログラム（「DaemonSet」というKubernetesのリソースタイプ）をデプロイした。このプログラムは、各ノードの「cilium_host」というネットワークインターフェースのIPアドレスを監視する。次に、監視したIPアドレスに対して、より広い範囲を示す「/24」のような「サブネットマスク」を持つ「セカンダリIPアドレス」を追加で割り当てた。通常のCiliumでは、Podが利用するIPアドレス範囲（Pod CIDR）は「/32」という単一のIPアドレスとして管理されることが多いが、これをより広い範囲として認識させるための変更である。そして、Ciliumの設定で「advertiseKubernetesNetworks」というオプションを有効にし、各ノードが自身のPod CIDR（Podに割り当てるIPアドレスの範囲）をKubernetesクラスター全体に通知・共有するようにした。最後に、KubeSpanの通信相手（ピア）の設定に、これらのPod CIDRを含めるようにした。これにより、KubeSpanが構築するVPNトンネルが、これらのPod CIDR宛ての通信も適切にルーティングするようになる。

このワークアラウンドの結果、CiliumはハイブリッドクラスターでもVXLANのカプセル化をバイパスし、ネイティブルートモードで動作することが可能になった。このことから、KubeSpanと組み合わせ、いくつかのカスタム設定を行うことで、NAT境界を越えてネイティブルートが機能することが確認された。

テスト結果と主要な観察

これらの設定変更による性能への影響を測るため、様々なネットワーク性能テストが実施された。テストでは、PodからPod、ホストからホストといった通信経路で、スループット（単位時間あたりに送れるデータ量）、レイテンシ（通信の遅延時間）、そして「新規接続確立速度」が測定された。通信するノードが同じAWS内にある「コロケートノード」と、AWSとオンプレミスにまたがる「非コロケートノード」の両方で比較が行われた。

その結果、以下の主要な観察結果が得られた。ネイティブルートを適用したハイブリッド環境（非コロケートノード）では、VXLANを使用した場合と比較して、ノード間通信のレイテンシが約7〜20ミリ秒（ms）削減された。これは、特に応答速度が求められるアプリケーションにとっては重要な改善となる。スループットの向上は控えめではあったが、特にUDP通信（リアルタイム通信などで使われる、多少のパケット損失が許容される高速なプロトコル）のシナリオで、改善がより顕著に見られた。具体的な数値としては、VXLAN設定でのクロスノードスループットが105〜430Mb/sだったのに対し、ネイティブルートでは117〜583Mb/sとわずかながら増加した。VXLANのカプセル化が不要になったことで、データがネットワーク内を流れる経路（データパス）がより透過的でシンプルになった。これにより、トラブルシューティングが容易になるなどの副次的なメリットも考えられる。同じノード内のPod間、ホスト間の通信性能は、ネイティブルートとVXLANのどちらのセットアップでも非常に高く、同程度の性能を発揮した。これは、ノード内の通信においては、VXLANのカプセル化によるオーバーヘッドがボトルネックになりにくいことを示唆している。

結論と今後の展望

結論として、Ciliumのネイティブルートは、ハイブリッドKubernetes環境において、レイテンシの低減、スループットのわずかな向上、そしてよりクリーンなデータパスといった測定可能な改善をもたらすことが示された。

しかし、これらの改善は「劇的」というよりは「段階的」なものだった。また、ネイティブルートを機能させるために必要だったワークアラウンド（DaemonSetを使ったIPアドレスの追加割り当てなど）は複雑であり、現時点では本番環境で安心して使えるレベルとは言えない。複雑な手動設定は、運用ミスのリスクを高めるからである。

ただし、良いニュースもある。KubeSpanを開発しているSideroコミュニティが、KubeSpanの機能を積極的に強化しており、将来のリリースではネイティブルートをそのまま（特別なハックなしで）サポートする可能性が示唆されている。もしそれが実現すれば、KubeSpanが提供するセキュリティとNATトラバーサルの能力を、ネイティブルートの性能メリットと組み合わせることが、より簡単になり、システムエンジニアがハイブリッド環境を構築・運用する上での大きな助けとなるだろう。このような進化は、クラウドとオンプレミスの連携がますます重要になるこれからのシステム開発において、非常に期待される。