KubernetesXL · kube-proxy and Service Dataplanekube-proxy
kube-proxy mode comparison — the 1.34 default and the choice matrix
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
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:
| Dimension | iptables | IPVS | eBPF |
|---|---|---|---|
| Performance | O(n) per packet | O(1) per packet | O(1) per packet |
| Scalability | Thousands of Services | Hundreds of thousands of Services | Millions of endpoints |
| Scheduling | Random only | Multiple algorithms | Random, maglev, custom |
| Observability | iptables-save | ipvsadm | Hubble |
| CNI dependency | None | None | Cilium required |
| Kernel requirement | 3.10+ | 4.19+ | 5.4+ (basic), 5.10+ (advanced) |
| Operational complexity | Low | Medium | High |
| Default in 1.34 | Yes | No | No (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:
- Cluster size: small clusters (< 100 Services) use iptables; large clusters (> 1000 Services) use IPVS or eBPF.
- CNI choice: Cilium enables the eBPF mode; other CNIs use iptables or IPVS.
- Operations team experience: teams without eBPF experience use iptables or IPVS; teams with eBPF experience can use eBPF.
- Performance requirements: high-performance clusters use IPVS or eBPF.
- 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:
- Install Cilium CNI.
- Enable the kube-proxy replacement.
- Drain the nodes and restart the kubelet.
- Verify the eBPF dataplane is working.
- 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
Q1. What is the default kube-proxy mode in Kubernetes 1.34?
Q2. The IPVS and eBPF modes have O(1) per-packet performance regardless of the number of Services and endpoints.
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.
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.