このページでは、GKE Dataplane V2 の機能と仕組みの概要を説明します。
このページを読む前に、GKE クラスタ内のネットワーキングについて理解しておく必要があります。
GKE Dataplane V2 の概要
GKE Dataplane V2 は、Kubernetes ネットワーキング用に最適化されたデータプレーンです。GKE Dataplane V2 の特徴は次のとおりです。
- ネットワーキングで一貫したユーザー エクスペリエンスを提供。
- ネットワーク アクティビティをリアルタイムで可視化。
- よりシンプルなアーキテクチャにより、クラスタの管理とトラブルシューティングが容易に。
GKE Dataplane V2 は、新しいすべての Autopilot クラスタでデフォルトで有効になります。
GKE Dataplane V2 の仕組み
GKE Dataplane V2 は eBPF を使用して実装されています。パケットが GKE ノードに到着すると、カーネルにインストールされている eBPF プログラムによってパケットのルーティング方法と処理方法が決定されます。iptables を使用したパケット処理とは異なり、eBPF プログラムはパケット内で Kubernetes 固有のメタデータを使用できます。これにより、GKE Dataplane V2 はカーネル内のネットワーク パケットをより効率的に処理し、アノテーション付きのアクションをユーザー スペースに報告してログに記録できます。
次の図は、GKE Dataplane V2 を使用しているノードを通過するパケットの経路を示しています。
GKE は、GKE Dataplane V2 コントローラを anetd という名前の DaemonSet としてクラスタ内の各ノードにデプロイします。anetd は、Kubernetes オブジェクトを解釈し、eBPF でネットワーク トポロジをプログラムします。anetd Pod は kube-system Namespace で実行されます。
GKE Dataplane V2 と NetworkPolicy
GKE Dataplane V2 は Cilium を使用して実装されています。GKE のレガシー データプレーンは Calico を使用して実装されています。
どちらのテクノロジーも Kubernetes の NetworkPolicy を管理します。Cilium は eBPF を使用し、Calico Container Network Interface（CNI）は Linux カーネルの iptables を使用します。
GKE Dataplane V2 のメリット
スケーラビリティ
GKE Dataplane V2 のスケーラビリティ特性は、従来のデータプレーンとは異なります。
GKE Dataplane V2 が kube-proxy を使用せず、サービス ルーティングで iptables に依存しない GKE バージョンの場合、Service 数などボトルネックに関する一部の iptables が削除されます。
GKE Dataplane V2 は eBPF マップに依存しています。Service 全体で 260,000 エンドポイントに制限されています。
セキュリティ
GKE Dataplane V2 のあるクラスタでは、Kubernetes NetworkPolicy が常に有効になっています。ネットワーク ポリシーを適用するために、Calico などのサードパーティ ソフトウェア アドオンをインストールして管理する必要はありません。
運用
GKE Dataplane V2 を使用してクラスタを作成すると、ネットワーク ポリシー ロギングが組み込まれます。クラスタでロギング CRD を構成すると、Pod によっていつ接続が許可または拒否されたかを確認できます。
整合性
GKE Dataplane V2 は一貫したネットワーキング エクスペリエンスを提供します。
詳細については、GKE Dataplane V2 の可用性をご覧ください。
GKE Dataplane V2 の技術仕様
GKE Dataplane V2 は、次の仕様のクラスタをサポートしています。
| 仕様 | GKE | Google Distributed Cloud Edge | Google Distributed Cloud Hosted |
|---|---|---|---|
| クラスタあたりのノード数 | 7,500 | 500 | 500 |
| クラスタあたりの Pod 数 | 200,000 | 15,000 | 27,500 |
| 1 つの Service の背後にある Pod の数 | 10,000 | 1,000 | 1,000 |
| クラスタ IP サービスの数 | 10,000 | 1,000 | 1,000 |
| クラスタあたりの LoadBalancer Service の数 | 750 | 500 | 1,000 |
GKE Dataplane V2 は、どの Service がバックエンドとしてどの Pod を参照するかを追跡するための Service マップを維持します。各サービスの Pod バックエンドがすべて、この Service マップに収められている必要があります。このマップには最大で 260,000 個のエントリを収めることができます。この上限を超えると、クラスタが意図したとおりに動作しない可能性があります。
バージョン 1.31 のノードの上限を 7,500 に引き上げ
Kubernetes バージョン 1.31 以降では、GKE Dataplane V2 クラスタあたり 5,000 ノードという上限が 7,500 に引き上げられています。クラスタに以前に適用されていた条件（5,000 ノード上限）は引き続き適用されます。
バージョン 1.23 のノードの上限を 5,000 に引き上げ
Kubernetes バージョン 1.23 以降では、GKE Dataplane V2 クラスタあたり 500 ノードという上限が 5,000 に引き上げられています。また、クラスタに次の追加条件が適用されます。
- Private Service Connect を使用するクラスタ。クラスタで Private Service Connect を使用しているかどうかを確認するには、Private Service Connect を使用するクラスタをご覧ください。
- リージョン クラスタのみ
- GKE バージョン 1.23 以降で作成されたクラスタでのみ、上限が 5,000 ノードに引き上げられています。以前のバージョンの GKE で作成されたクラスタの場合、クラスタサイズの割り当ての引き上げが必要になる可能性があります。詳しくは、サポートまでお問い合わせください。
- Cilium CRD（CiliumNetworkPolicy と CiliumClusterwideNetworkPolicy）を使用するクラスタは、5,000 ノードまでスケーリングできません。
Google Distributed Cloud の LoadBalancer Service
Google Distributed Cloud でサポートされている LoadBalancer Service の数は、使用するロードバランサ モードによって異なります。Google Distributed Cloud では、バンドルされたロード バランシング モード（Seesaw）の場合は 500 個の LoadBalancer Service がサポートされます。F5 と統合ロード バランシング モードの場合は 250 個の LoadBalancer Service がサポートされます。詳細については、スケーラビリティをご覧ください。
制限事項
GKE Dataplane V2 には次の制限があります。
- GKE Dataplane V2 は、新しいクラスタの作成時にのみ有効にできます。GKE Dataplane V2 を使用するように既存のクラスタをアップグレードすることはできません。
- 1.20.12-gke.500 より前の GKE バージョンでは、NodeLocal DNSCache を使用して GKE Dataplane V2 を有効にした場合、
dnsPolicy: ClusterFirstWithHostNetを使用して Pod を構成することはできません。Pod で DNS 解決エラーが発生します。 - GKE バージョン 1.21.5-gke.1300 以降、GKE Dataplane V2 は CiliumNetworkPolicy API または CiliumClusterwideNetworkPolicy CRD API をサポートしていません。GKE バージョン 1.28.6-gke.1095000 以降と 1.29.1-gke.1016000 以降では、新規または既存のクラスタで CiliumClusterwideNetworkPolicy を有効にできます。
- NodePort タイプの Service に関連付けられ、手動で作成された内部パススルー ネットワーク ロードバランサはサポートされていません。
- GKE Dataplane V2 は eBPF を使用して eBPF カーネル パケット処理を最適化するため、Pod のチャーンが高いワークロードがある場合、Pod のパフォーマンスに影響する可能性があります。GKE Dataplane V2 は、最適な eBPF の実現に重点を置いています。
- GKE Dataplane V2 に、複数の（TCP / UDP）ポートを持つマルチクラスタ Service について既知の問題があります。詳細については、複数のポートを持つ MCS Service をご覧ください。
- GKE Dataplane V2 は、
kube-proxyではなくciliumを使用して Kubernetes Service を実装します。kube-proxyは Kubernetes コミュニティによって管理、開発されているため、Service の新機能は、GKE Dataplane V2 のciliumに実装される前に、kube-proxyに実装される可能性が高くなります。kube-proxyで先に実装されたサービス機能としては、KEP-1669: Proxy Terminating Endpoints があります。 - デフォルトの SNAT 範囲と PUPI 範囲を使用してバージョン 1.25 以前を実行している NodePort Service の場合は、
ip-masq-agentConfigMap のnonMasqueradeCIDRsに Pod の PUPI 範囲を追加する必要があります。これにより、接続の問題を回避できます。 - 場合によっては、GKE Dataplane V2 エージェント Pod（
anetd）が大量の CPU リソース（インスタンスごとに 2 つまたは 3 つの vCPU）を消費する可能性があります。これは、ノード上で短時間に大量の TCP 接続の開始または終了が行われた場合に発生します。この問題を軽減するため、関連するワークロードの HTTP 呼び出しと接続プーリングのキープアライブを実装することをおすすめします。 - バージョン 1.27 以前のコントロール プレーンを実行している GKE Dataplane V2 クラスタは、Service の
.spec.internalTrafficPolicyフィールドをサポートしていません。サービスに有効な内部トラフィック ポリシーはClusterです。任意のノードのバックエンドが Service の解決候補になります。フィールドの詳細については、サービス内部トラフィック ポリシーをご覧ください。 - GKE Dataplane V2 は eBPF を使用してクラスタのネットワーク トラフィックを管理します。eBPF も使用するサードパーティ アプリケーションをインストールすると、GKE Dataplane V2 と競合する可能性があります。たとえば、GKE Dataplane V2 で Retina を使用すると、Pod が Service に接続できなくなる可能性があります。これは、Retina の eBPF プログラムが GKE Dataplane V2 のトラフィックのルーティングを中断する可能性があるためです。サービスに直接アクセスしようとしているためにトラフィックがドロップされていることを示すエラー メッセージが表示される場合は、この問題が発生している可能性があります。これは、Pod が Service の IP アドレスに直接アクセスできないため、トラフィックが Dataplane V2 のルーティング メカニズムを経由する必要があるためです。詳細については、Retina の非互換性に関する問題をご覧ください。
GKE Dataplane V2 と kube-proxy
GKE バージョン 1.25 の Windows Server ノードプールを除き、GKE Dataplane V2 は kube-proxy を使用しません。
GKE Dataplane V2 を使用しないネットワーク ポリシーの適用
GKE Dataplane V2 を使用しないクラスタでネットワーク ポリシーの適用を有効にする手順については、ネットワーク ポリシーの適用を使用するをご覧ください。
次のステップ
- GKE Dataplane V2 の使用を読む。
- GKE Dataplane V2 のオブザーバビリティについて学習する。
- ネットワーク ポリシー ロギングを使用する方法を学習する。