このページでは、GKE Dataplane V2 の機能と仕組みの概要について説明します。
このページを読む前に、GKE クラスタ内のネットワーキングについて理解しておく必要があります。
GKE Dataplane V2 の概要
GKE Dataplane V2 は、Kubernetes ネットワーキング用に最適化されたデータプレーンです。GKE Dataplane V2 の特徴は次のとおりです。
- ネットワーキングで一貫したユーザー エクスペリエンスを提供。
- ネットワーク アクティビティをリアルタイムで可視化。
- よりシンプルなアーキテクチャにより、クラスタの管理とトラブルシューティングが容易に。
GKE Dataplane V2 は、新しい Autopilot クラスタのバージョン 1.22.7-gke.1500 以降、バージョン 1.23.4-gke.1500 以降、および 1.24 以降のすべてのバージョンで有効になっています。
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 全体で 64,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 | GKE on VMware | Bare Metal 向け Google Distributed Cloud Virtual |
|---|---|---|---|
| クラスタあたりのノード数 | 5,000 | 500 | 500 |
| クラスタあたりの Pod 数 | 50,000 | 15,000 | 27,500 |
| クラスタあたりの LoadBalancer Service の数 | 750 | 500 | 1,000 |
GKE Dataplane V2 は、どの Service がバックエンドとしてどの Pod を参照するかを追跡するための Service マップを維持します。各サービスの Pod バックエンドがすべて、この Service マップに収められている必要があります。このマップには最大で 64,000 個のエントリを収めることができます。この上限を超えると、クラスタが意図したとおりに動作しない可能性があります。
バージョン 1.23 でのノード上限の引き上げ
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 ノードまでスケーリングできません。
GKE on VMware の LoadBalancer Service
GKE on VMware でサポートされている LoadBalancer Service の数は、使用するロードバランサ モードによって異なります。GKE on VMware では、バンドル型ロード バランシング モード（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 をサポートしていません。
- 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 と kube-proxy
GKE バージョン 1.25 の Windows Server ノードプールを除き、GKE Dataplane V2 は kube-proxy を使用しません。
GKE Dataplane V2 を使用しないネットワーク ポリシーの適用
GKE Dataplane V2 を使用しないクラスタでネットワーク ポリシーの適用を有効にする手順については、ネットワーク ポリシーの適用を使用するをご覧ください。
次のステップ
- GKE Dataplane V2 の使用を読む。
- ネットワーク ポリシー ロギングを使用する方法を学習する。