GKE Dataplane V2

このページでは、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 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 を使用します。

カスタム eBPF プログラム

GKE Dataplane V2 は、ルーティング、ロード バランシング、ネットワーク ポリシーの適用など、ネットワーク トラフィックの管理に eBPF プログラムを使用します。これらのプログラムはネットワーク接続に不可欠であるため、GKE Dataplane V2 を使用するノードへのカスタム eBPF プログラムのインストールはサポートされていません。カスタム eBPF プログラムは GKE Dataplane V2 プログラムに干渉し、クラスタ ネットワーキングを中断させる可能性があります。

GKE Dataplane V2 のメリット

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
クラスタあたりのノード数 15,000 500 500
クラスタあたりの Pod 数 400,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 個のエントリを収めることができます。この上限を超えると、クラスタが意図したとおりに動作しない可能性があります。

ノードに関する上限

クラスタあたりのノードの最大数は、GKE Dataplane V2 クラスタのロケーションによって異なります。

  • リージョン クラスタ: クラスタあたり最大 5,000、15,000、65,000 ノード。ノードの増加がすべて自動で行われるわけではありません。ターゲット ノード数によっては、特定のインフラストラクチャ要件があり、Cloud カスタマーケアにお問い合わせいただく必要がある場合があります。 65,000 ノードにスケーリングするには、ネットワーク ポリシーの適用を無効にする Dataplane V2 スケール最適化モードが必要です。詳細については、 クラスタサイズの制限と要件をご覧ください。
  • ゾーンクラスタ: 最大 1,000 ノード。

リージョン クラスタで 5,000 ノードを超えるノード スケーリングの上限を実現するには、環境が次の条件を満たしている必要があります。

  • クラスタで Private Service Connect が有効になっている必要があります。クラスタで Private Service Connect を使用しているかどうかを確認するには、 Private Service Connect を使用したクラスタをご覧ください。
  • CiliumNetworkPolicy CRD を使用するクラスタは、ゾーンクラスタの上限である最大 1,000 ノードに制限されます。代わりに CiliumClusterwideNetworkPolicy CRD を使用して、最大 5,000 ノードまでのスケーリングをサポートします。

Google Distributed Cloud の LoadBalancer Service

Google Distributed Cloud でサポートされている LoadBalancer Service の数は、使用するロードバランサ モードによって異なります。Google Distributed Cloud では、バンドルされたロード バランシング モード（Seesaw）の場合は 500 個の LoadBalancer Service がサポートされます。F5 と統合ロード バランシング モードの場合は 250 個の LoadBalancer Service がサポートされます。詳細については、 スケーラビリティをご覧ください。

Maglev のサポート

バージョン 1.36.0-gke.2882000 以降を実行している GKE クラスタでは、バックエンドの選択に Maglev コンシステント ハッシュ法アルゴリズム を使用するように Service を構成できます。

デフォルトでは、Kubernetes Service は random アルゴリズムを使用してバックエンドを選択します。random アルゴリズムでは、バックエンド Pod のセットが変更されると（スケーリング イベント時など）、正常な接続が再ルーティングされてリセットされる可能性があります。Maglev は、他の Pod が追加または削除された場合でも、接続の割り当てられたバックエンドが正常な状態を維持している限り、トラフィックをそのバックエンドにルーティングし続けることで、この問題を軽減します。

Maglev アルゴリズムを使用するメリット

Maglev アルゴリズムを使用すると、次のメリットがあります。

  • 接続のトラフィックを同じバックエンドに転送することで、接続の安定性を向上させることができます。
  • バックエンド Pod の追加または削除時（Pod の再起動時など）の接続の問題を軽減できます。

Maglev アルゴリズムを使用する場合の制限事項

Maglev アルゴリズムを使用すると、リソースを大量に消費する可能性があります。

  • クラスタごとに anetd のメモリ使用量が増加する可能性があります。詳細については、次のセクション「Maglev のメモリ使用量に関する考慮事項」をご覧ください。
  • バックエンドの変更時に、anetd の CPU 使用率が高くなる可能性があります（最大 3 倍）。

Maglev のメモリ使用量に関する考慮事項

接続とバックエンドを追跡するために、Maglev アルゴリズムはハッシュテーブルを使用します。パケットの 5 タプル（送信元 IP アドレス、宛先 IP アドレス、送信元ポート、宛先ポート、プロトコル）をハッシュします。

ルックアップ テーブルのサイズは 16,381 エントリに構成されています。各エントリのサイズは 4 バイトであるため、Maglev アルゴリズムを使用するように構成された Service では、各ノードの割り当て可能なメモリが 65.5 KB（16,381 × 4 バイト）必要になります。

Maglev が有効になっているサービスの数 追加のメモリ使用量
100 6.5 MB
1,000 65 MB
10,000 650 MB

Maglev アルゴリズムの適用

Maglev アルゴリズムを NodePort または LoadBalancer タイプの Service に適用するには、Service の作成時に Service のメタデータに gke.networking.io/lb-algorithm: "maglev" アノテーションを追加します。

例:

apiVersion: v1
kind: Service
metadata:
  name: maglev-service
  annotations:
    gke.networking.io/lb-algorithm: "maglev"
spec:
  type: LoadBalancer
  selector:
    app: application
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

gke.networking.io/lb-algorithm アノテーションは、Service の作成時に有効になります。既存の Service のアルゴリズムを変更するには、Service を削除して再作成する必要があります。再作成せずにアノテーション値を変更すると、動作が不安定になります。新しいノードの anetd は新しく構成されたアルゴリズムを使用しようとしますが、既存の Pod は引き続き以前のアルゴリズムを使用します。

SCTP を使用してワークロードをデプロイする

GKE Dataplane V2 が有効になっているクラスタに、Stream Control Transmission Protocol（SCTP）を使用するワークロードをデプロイできます。SCTP は、信頼性の高いメッセージ指向の転送を提供するトランスポート層プロトコルです。詳細については、SCTP を使用してワークロードをデプロイするをご覧ください。

制限事項

GKE Dataplane V2 には次の制限があります。

  • GKE Dataplane V2 は、新しいクラスタの作成時にのみ有効にできます。GKE Dataplane V2 を使用するように既存のクラスタをアップグレードすることはできません。
  • NodePort タイプの Service に関連付けられ、手動で作成された内部パススルー ネットワーク ロードバランサはサポートされていません。
  • GKE Dataplane V2 は、kube-proxy ではなく cilium を使用して Kubernetes Service を実装します。kube-proxy は Kubernetes コミュニティによって管理、開発されているため、Service の新機能は、GKE Dataplane V2 の cilium に実装される前に、kube-proxy に実装される可能性が高くなります。
  • 場合によっては、GKE Dataplane V2 エージェント Pod（anetd）が大量の CPU リソース（インスタンスごとに 2 つまたは 3 つの vCPU）を消費する可能性があります。 これは、ノード上で短時間に大量の TCP 接続の開始または終了が行われた場合に発生します。この問題を軽減するため、関連するワークロードの HTTP 呼び出しと接続プーリングのキープアライブを実装することをおすすめします。

  • GKE Dataplane V2 エージェント Pod の報告されるメモリ使用量（anetd）は、ノードで使用可能な合計メモリによって異なります。合計メモリが多いノードでは、anetd Pod のメモリ使用量が多いと報告されます。anetd Pod は実際にはメモリを多く使用しません。この指標には eBPF マップのメモリ予約が含まれているため、報告される使用量が増加します。

    GKE では、最大の eBPF マップのメモリ予約は、ノードメモリの合計の 0.25% です。他の GKE 固有の機能に追加のメモリが予約される場合があります。

  • GKE Dataplane V2 では、クラスタのネットワーク トラフィックの管理に eBPF が使用されます。eBPF が使用されているサードパーティ アプリケーションをインストールすると、GKE Dataplane V2 に干渉する可能性があります。たとえば、Retina を GKE Dataplane V2 とともに使用すると、Pod が Service に接続できなくなる可能性があります。これは、Retina の eBPF プログラムが原因で GKE Dataplane V2 でのトラフィックのルーティング方法に混乱が生じるためです。トラフィックが Service の IP アドレスに直接到達しようとしているため、トラフィックがドロップされたことを示すエラー メッセージが表示される場合は、この問題が発生している可能性があります。この理由は、Pod には Service の IP アドレスへの直接アクセスが許可されておらず、トラフィックは Dataplane V2 のルーティング メカニズムを通過する必要があるためです。詳細については、Retina の非互換性に関する問題をご覧ください。

  • フラグメント化された ICMP パケットはサポートされておらず、GKE Dataplane V2 によってドロップされます。

GKE Dataplane V2 を使用しないネットワーク ポリシーの適用

GKE Dataplane V2 を使用しないクラスタでネットワーク ポリシーの適用を有効にする手順については、ネットワーク ポリシーの適用を使用するをご覧ください。

次のステップ