TechLeague

    Google Cloud

    GKE Dataplane V2: 2026年にCiliumベースのネットワーキングへ移行すべき理由

    TechLeague Editorial··14 分で読了

    業界はようやく、従来のKube-proxy/IPtablesネットワークモデルが、現代の2026年運用環境には場違いなレガシーなボトルネックであるという事実に目を向け始めています。Google Kubernetes Engine (GKE) Dataplane V2は単なる「選択肢」ではありません。これは、IPtablesの線形チェーン処理という古来のオーバーヘッドを、eBPFとCiliumの外科手術的な効率性で置き換え、数十ノードを超える規模のエンタープライズにとって必須の基盤となります。

    IPtablesの終焉とGKEにおけるeBPFの台頭

    10年間、KubernetesのネットワーキングはIPtablesモードのkube-proxyに依存していました。機能的ではあったものの、IPtablesはコンテナ化された環境の高速な変化のために設計されたものではありませんでした。大規模なクラスターでは、数千にも及ぶルールの逐次評価がO(n)のパフォーマンス低下を引き起こします。ノードに入ってくるすべてのパケットは、膨大なルールリストをトラバースする必要があり、レイテンシーとCPUジッターを増加させていました。

    オープンソースのCiliumプロジェクトとeBPF (extended Berkeley Packet Filter)を基盤とするGKE Dataplane V2は、これをハッシュテーブルルックアップ（O(1)の複雑性）に置き換えます。JITコンパイルされたバイトコードを介してネットワーキングロジックをカーネルに移動することで、GKEはパケット処理のためにカーネルがユーザー空間とカーネル空間を行き来する必要性を排除します。レガシースタックでGKEを実行している場合、内部トラフィックのルーティングのためだけに、実質的にCPUサイクルの15%～20%という「税金」を支払っていることになります。

    Dataplane V2の技術アーキテクチャ

    Dataplane V2では、従来のkube-proxy DaemonSetはなくなりました。代わりに、anetd Podがすべてのノードで実行されます。このエージェントは、eBPFプログラムをコンパイルし、カーネルにロードする役割を担います。これらのプログラムは、PodにアタッチされたVirtual Ethernet (veth)ペアのtc（トラフィック制御）イングレス/イグレスフックにフックします。

    # クラスターでDataplane V2がアクティブかどうかを確認する
gcloud container clusters describe [CLUSTER_NAME] \
    --zone [ZONE] --format="value(networkConfig.datapathProvider)"
# 期待される出力: ADVANCED_DATAPATH

    ネットワーキングスタックは統合されました。従来のモデルでは、Calicoをネットワークポリシーに、IPtablesをサービスルーティングに、といったようにアーキテクチャを混在させる必要があったため、デュアルパスのオーバーヘッドが発生していました。Dataplane V2は、Ciliumベースの単一かつ高度に最適化されたエンジンで両方を処理します。この統合により、従来のクラスターと比較して接続セットアップ率（1秒あたりの接続数）が2～3倍向上しています。

    ネットワークポリシーの進化：「Calico Lite」はもはや存在しない

    2026年、GKEにおけるCalicoとCiliumをめぐる議論は終了します。GoogleはCiliumをDataplane V2のバックボーンとして完全にコミットしました。Calicoは優れた製品ですが、GKEとの統合は常に「後付け」のように感じられました。Dataplane V2では、ネットワークポリシーがeBPFを介して厳密に適用されます。これは、パケットライフサイクルの可能な限り早い段階で適用が行われることを意味します。

    重要な利点の1つは、可視性です。eBPFはデータパスに存在するため、従来のPCAPやパケットミラーリングツールのような massiveなパフォーマンスペナルティなしに、詳細なフローログをCloud LoggingとCloud Monitoringにエクスポートできます。L3/L4の可視性、および「ポリシーによる拒否」イベントをGCPコンソール内でネイティブに取得できます。

    高度なネットワークポリシー機能

    • FQDNベースのEgress: 静的IPではなくドメイン名（例: *.googleapis.com）に基づいてポリシーを記述する機能。これはDataplane V2アーキテクチャ内のローカルDNSプロキシによって処理されます。
    • L7ポリシー適用: GKE Dataplane V2はL3/L4に重点を置いていますが、基盤となるCiliumアーキテクチャはL7 (HTTP/gRPC)フィルタリングをサポートしています。ただし、GoogleはService MeshまたはGateway API統合を通じてこの機能を慎重に公開しています。

    「FQDN Egress」というゲームチェンジャー

    歴史的に、KubernetesにおけるEgressのセキュリティ確保は悪夢でした。MicroserviceがStripeやTwilioのような外部SaaSと通信する必要がある場合、それらのIPレンジのリストを維持するか（これはアウトテージのレシピです）、扱いにくいNAT Gatewayプロキシを使用する必要がありました。Dataplane V2は、FQDNベースのネットワークポリシーを介してこれを処理します。

    anetdエージェントは、Podに戻ってくるDNS応答を監視し、解決するIPを承認されたドメイン名にマッピングします。その後、eBPFマップを動的に更新し、それらの特定のIPへのトラフィックをTTL制限付きの期間だけ許可します。これは、CDNがエッジアドレスを変更しても破綻しない high-fidelityなセキュリティです。

    # Dataplane V2におけるDNSベースポリシーの例（簡略化された表現）
apiVersion: networking.gke.io/v1
kind: NetworkPolicy
spec:
  egress:
  - toFQDNs:
    - matchName: "api.stripe.com"
  podSelector:
    matchLabels:
      app: payment-processor

    パフォーマンスベンチマーク: Calico vs. Dataplane V2

    C3およびN4マシンタイプでの内部ベンチマークでは、Dataplane V2がパケットテールレイテンシー（P99）を大幅に削減することが示されています。500以上のサービスを持つクラスターでは、IPtablesのルールセットは10,000行以上に膨れ上がることがあります。IPtablesベースのPodは、サービスに対する正しいNATエントリーを見つけるためだけに2〜5msのレイテンシー上昇を経験します。Dataplane V2は同じルックアップをナノ秒単位で実行します。

    さらに、Dataplane V2は多くの内部操作でconntrackテーブルをバイパスするため、高トラフィッククラスターを悩ませる「conntrack table full」エラーを軽減します。ワークロードが高頻度のgRPC呼び出しや数千の同時TCP接続を伴う場合、従来のDatapathは時限爆弾です。

    Googleのクラウドネイティブネットワーキングの基盤についての詳細な情報は、GCP Cloud Interconnect Architectureに関するガイドを参照して、クラスタートラフィックがオンプレミスインフラストラクチャとどのように連携するかを理解してください。

    マルチクラスターネットワーキングとGKE Enterprise

    GKE Enterprise（旧Anthos）のリリースにより、Dataplane V2はさらに重要になります。Multi-cluster Services (MCS)やMulti-cluster Gatewayのような機能は、eBPFデータプレーンによって提供される一貫したネットワークIDに依存しています。マルチクラスター設定では、Dataplane V2はローカルVPCを超えた「ID認識型」ネットワーキングを可能にします。リージョン間で重複する可能性のあるPod IPに基づいてルーティングする代わりに、コントロールプレーンはCiliumによってパケットメタデータに注入されたSPIFFEベースのIDを使用します。

    これにより、「Global Network Policies」を実装できます。たとえば、us-east1のフロントエンドPodがeurope-west4のバックエンドPodとしか通信できない、といったことが、中間ルーティングホップやIP変換に関係なく可能になります。このレベルの粒度は、標準のIPtablesでは不可能です。

    技術的なトレードオフと制約

    メリットは圧倒的ですが、Dataplane V2も何もかも解決する「魔法のボタン」ではありません。移行には、ノードが少なくともGKE 1.20.6+を実行している必要がありますが、2026年の設計では、ステートフルな接続追跡の改善の恩恵を受けるために1.30+を義務付けています。

    • アップグレード可能性: 既存のレガシークラスターをDataplane V2に切り替えることはできません。これはクラスター作成時のフラグです。移行にはBlue/Greenクラスターロールアウトが必要です。
    • リソースオーバーヘッド: anetd Podは、eBPFマップとDNSプロキシを維持する必要があるため、従来のkube-proxyよりもわずかに多くのメモリ（Pod密度に応じて約300MB～600MB）を消費します。
    • トラブルシューティング: iptables -Lのような標準ツールはここでは役に立ちません。データプレーンの状態を検査するには、cilium-dbgを学習するか、GKEのネイティブなNetwork Analyzerツールを使用する必要があります。

    2026年における最高のパフォーマンス設定

    Tier-1のプロダクションワークロードを実行している場合、GKE Dataplane V2をデプロイする際にデフォルト設定を使用しないでください。Node-Local DNS Cacheを有効にする必要があります。Dataplane V2では、データプレーン内のDNSプロキシがローカルキャッシュPodと連携してFQDN egressポリシーをノードから離れることなく解決します。これにより、Kube-DNS (CoreDNS) Podへの負荷が大幅に軽減されます。

    さらに、VPCがPrivate Google Accessで構成されており、Intra-node visibilityを使用していることを確認してください。これにより、Dataplane V2は同一ノード上の2つのPod間のトラフィックをキャプチャしログに記録できます。これは、以前のKubernetesネットワーキングの実装における悪名高い死角でした。

    結論: GKEにおけるCiliumの評価

    GKE Dataplane V2は、GCPにおけるネットワーキングにおいて唯一の正当な選択肢です。Ciliumの高性能機能を効果的に商品化し、管理オーバーヘッドをGoogleのSREチームに完全に委ねています。新しいクラスターを構築する場合、レガシーパスはあなたが抱えることになる技術的負債です。O(1)ルックアップによるパフォーマンス向上、FQDN egressによるセキュリティ、およびeBPFによって提供される純粋な可視性は、GKEプラットフォームの歴史上最も重要なアップグレードの1つとなっています。

    TechLeagueでは、組織がこれらの複雑なアーキテクチャ移行を進めるのを支援しています。EKSからGKEへの移行であろうと、レガシーIPtables構成からのアップグレードであろうと、当社のエンジニアリングチームはコストとパフォーマンスのためにパケットフローを最適化できます。techleague.ioで私たちの専門コンサルティングパッケージをご覧ください。

    よくある質問

    既存のGKEクラスターを再作成せずにDataplane V2に移行できますか？+

    できません。レガシーデータパスで一度作成されたクラスターは、Dataplane V2に切り替えることはできません。新しいクラスターをプロビジョニングし、Blue/GreenまたはDNSカットオーバー戦略を使用してワークロードを移行する必要があります。

    Dataplane V2はIPtablesと比較してどのようにパフォーマンスを向上させますか？+

    Dataplane V2はeBPFマップを介してO(1)ハッシュテーブルルックアップを使用しますが、従来のIPtablesはO(n)線形チェーン処理を使用します。つまり、サービスを追加してもDataplane V2は高速を維持しますが、IPtablesは徐々に遅くなります。

    anetd Podのリソースオーバーヘッドはどれくらいですか？+

    anetd Pod（Ciliumエージェント）は、通常300MB～600MBのRAMと、CPUコアのわずかな割合を必要とします。kube-proxyよりも高いですが、全体のクラスターCPUの純粋な節約（効率的なルーティングによる）が通常このコストを相殺します。

    Dataplane V2はFQDNベースのネットワークポリシーをサポートしていますか？+

    はい。GKEでは、ネットワークポリシーでFQDNベースのegressルールを定義できます。CiliumはDNSトラフィックをインターセプトしてIPを許可されたホスト名に動的にマッピングすることでこれを処理します。

    GKE Dataplane V2はスタンドアロンのCiliumとどう異なりますか？+

    Ciliumはオープンソースエンジンであり、Dataplane V2はGoogleによるそのマネージド実装です。スタンドアロンのCiliumで利用可能な一部の「knobs」（カスタムCNIチェイニングなど）は失われますが、完全にマネージドされたGoogleサポートのコントロールプレーンが得られます。

    2026年の高性能ネットワーキングに推奨される設定は何ですか？+

    Node-Local DNS Cacheを有効にし、Tier-1ネットワーキングを使用し（C3インスタンスの場合）、eBPFベースのログ記録と監視の効果を最大限に引き出すためにIntra-node visibilityを有効にします。