Skip to main content
RunBook Academy

KubernetesXL · kube-proxy and Service Dataplanekube-proxy

kube-proxy mode comparison — the 1.34 default and the choice matrix

Advanced⏱ ~17 minkubectl

What you'll learn

  • Compare the three kube-proxy modes on performance, scalability, and operational complexity
  • Identify the default mode in Kubernetes 1.34
  • Choose the right mode for the cluster
  • Apply the operational discipline of mode migration

Prerequisites

Verified against Kubernetes 1.34.x · kubeadm 1.34.x · kubectl 1.34.x · etcd 3.6.x · CoreDNS 1.11.x · containerd 1.7.x / 2.x · 2026-08-16

Not yet marked complete on this device.

The three kube-proxy modes are iptables (default in 1.34), IPVS (opt-in), and eBPF (Cilium). Each mode has a different performance characteristic, operational complexity, and dependency. This lesson walks the comparison, the choice matrix, and the operational discipline.

The comparison matrix

The three modes in a comparison matrix:

DimensioniptablesIPVSeBPF
PerformanceO(n) per packetO(1) per packetO(1) per packet
ScalabilityThousands of ServicesHundreds of thousands of ServicesMillions of endpoints
SchedulingRandom onlyMultiple algorithmsRandom, maglev, custom
Observabilityiptables-saveipvsadmHubble
CNI dependencyNoneNoneCilium required
Kernel requirement3.10+4.19+5.4+ (basic), 5.10+ (advanced)
Operational complexityLowMediumHigh
Default in 1.34YesNoNo (Cilium install)

The default in Kubernetes 1.34 is iptables. The cluster operator can opt-in to IPVS by setting the kube-proxy configuration. The eBPF mode requires Cilium as the CNI; the kube-proxy is not used.

The performance characteristics

The three modes have different performance characteristics:

flowchart LR
    A[Packet] --> B{Dataplane}
    B -->|iptables| C[Evaluate ~5000 rules]
    B -->|IPVS| D[Hash table lookup]
    B -->|eBPF| E[eBPF map lookup]
    C --> F[Forward]
    D --> F
    E --> F

The iptables dataplane evaluates every rule on every packet. The IPVS and eBPF dataplanes use a hash table for O(1) lookup.

The choice matrix

The choice of kube-proxy mode is driven by:

  1. Cluster size: small clusters (< 100 Services) use iptables; large clusters (> 1000 Services) use IPVS or eBPF.
  2. CNI choice: Cilium enables the eBPF mode; other CNIs use iptables or IPVS.
  3. Operations team experience: teams without eBPF experience use iptables or IPVS; teams with eBPF experience can use eBPF.
  4. Performance requirements: high-performance clusters use IPVS or eBPF.
  5. Observability requirements: clusters that need Hubble use eBPF.

The production rule is to choose the mode based on the cluster’s needs and the operations team’s experience.

The migration path

The migration from iptables to IPVS is straightforward:

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: ipvs

The change is applied by restarting the kube-proxy. The kube-proxy programs the IPVS rules; the existing iptables rules are cleaned up.

The migration from iptables or IPVS to eBPF is more involved:

  1. Install Cilium CNI.
  2. Enable the kube-proxy replacement.
  3. Drain the nodes and restart the kubelet.
  4. Verify the eBPF dataplane is working.
  5. Remove the kube-proxy DaemonSet.

The migration is a significant change. The cluster operator must plan the maintenance window.

The failure modes

The mode comparison’s failure modes:

  • iptables: rule explosion, slow sync.
  • IPVS: kernel module not loaded, scheduler mismatch.
  • eBPF: kernel version too old, Cilium agent misconfigured.

The failure modes are unique to each mode. The cluster operator must understand the failure modes of the chosen mode.

The operational discipline

The mode comparison’s operational discipline:

  • Document the kube-proxy mode. The cluster operator must understand which mode is used.
  • Choose the mode based on the cluster’s size. Small clusters use iptables; large clusters use IPVS or eBPF.
  • Plan the mode migration. The migration is a significant change.
  • Test the mode in staging. The mode is critical infrastructure.
  • Monitor the mode’s metrics. The metrics are the leading indicator.
  • Document the mode’s design. The mode is the cluster’s Service dataplane; the documentation is the reference.

Quiz

Knowledge check · 4 questions

  1. Q1. What is the default kube-proxy mode in Kubernetes 1.34?

  2. Q2. The IPVS and eBPF modes have O(1) per-packet performance regardless of the number of Services and endpoints.

  3. Q3. A cluster has 5000 Services. The kube-proxy's sync duration is 60 seconds in iptables mode. The cluster operator must reduce the sync duration. What is the choice?

    The cluster has 5000 Services. The kube-proxy's sync duration is 60 seconds in iptables mode. The cluster operator must reduce the sync duration. The cluster uses Cilium CNI.

  4. Q4. Name two factors that drive the choice of kube-proxy mode.

Passing score: 75%. Answers are checked in this browser.

Production discipline

  • The default kube-proxy mode in Kubernetes 1.34 is iptables. The cluster operator can opt-in to IPVS or eBPF.
  • Choose the mode based on the cluster’s size. Small clusters use iptables; large clusters use IPVS or eBPF.
  • Document the kube-proxy mode. The cluster operator must understand which mode is used.
  • Plan the mode migration. The migration is a significant change.
  • Test the mode in staging. The mode is critical infrastructure.
  • Monitor the mode’s metrics. The metrics are the leading indicator.
  • Document the mode’s design. The mode is the cluster’s Service dataplane; the documentation is the reference.
  • Train the operations team on the mode’s diagnostics. The mode is the cluster’s Service networking implementation.
  • Plan the mode’s evolution. The mode is the cluster’s Service networking future; the operator must understand the destination.