> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Kube Proxy less
> Explains replacing kube-proxy with Cilium to implement service routing and load balancing via eBPF, covering benefits, configuration steps, verification, and operational caveats
In this lesson you'll learn how to replace kube-proxy with Cilium so that service routing and load balancing run via eBPF. Cilium can be deployed in two main modes:
* Coexist with kube-proxy: Cilium provides CNI, ingress (e.g., Gateway API) and observability, while kube-proxy continues to perform service routing/load balancing using iptables or ipvs.
* Replace kube-proxy: Cilium implements service routing and load balancing directly with eBPF, removing the need for kube-proxy.
Replacing kube-proxy with an eBPF-based data plane (Cilium) yields measurable performance and scalability benefits compared to the traditional iptables approach. The fundamental difference is how packet lookup is performed.
With kube-proxy in iptables mode, each packet is evaluated against a sequential list of rules. As the number of services and endpoints grows, packet processing may require scanning many rules, and kube-proxy frequently rebuilds iptables rules on service or endpoint changes. This sequential scanning and frequent rebuilding does not scale well in highly dynamic Kubernetes clusters.
Cilium replaces sequential rule scanning with eBPF maps and per-CPU hash tables. Hash lookups are O(1) on average, so increasing the number of services and endpoints does not proportionally increase packet-processing latency as with iptables. This architecture delivers lower latency, improved scalability, more efficient load balancing, and richer observability and debugging.
Key benefits of replacing kube-proxy with Cilium (eBPF)
* Lower packet-processing latency
* Better scalability for clusters with many services and endpoints
* More efficient and flexible load balancing (including session affinity and L4/L7 options)
* Enhanced observability, tracing, and debugging via Cilium tooling
Summary comparison
| Aspect | kube-proxy (iptables/ipvs) | Cilium (eBPF, kube-proxy replacement) |
| ------------------- | ------------------------------------- | ------------------------------------- |
| Packet lookup model | Sequential rule matching (iptables) | Hash-based eBPF maps (per-CPU) |
| Scalability | Degrades with many services/endpoints | Scales well due to O(1) lookups |
| Rule rebuilds | Frequent, on service/endpoint change | Minimal, maps updated efficiently |
| Observability | Limited | Rich telemetry integrated in Cilium |
| Load balancing | iptables/ipvs | eBPF-based, more efficient |
Default Cilium behavior
By default Cilium does not replace kube-proxy; it coexists and delegates service routing to kube-proxy:
```yaml theme={null}
kubeProxyReplacement: "false"
```
You can confirm the current kube-proxy replacement setting from a Cilium agent:
```bash theme={null}
kubectl -n kube-system exec ds/cilium -- cilium-dbg status | grep KubeProxyReplacement
```
If the output shows `KubeProxyReplacement: false`, kube-proxy remains active and continues handling service routing.
When to replace kube-proxy
Consider replacing kube-proxy with Cilium when you need:
* Lower L4 packet latency for high-throughput workloads
* A more scalable service datapath for large clusters
* Integrated observability and easier troubleshooting
* Reduced operational complexity from iptables/ipvs rule churn
Before you proceed, validate control-plane connectivity and cluster-specific networking requirements.
Step-by-step: Replacing kube-proxy with Cilium
1. Remove kube-proxy artifacts
First, delete the kube-proxy DaemonSet and the associated ConfigMap. Removing the ConfigMap prevents kubeadm from automatically re-installing kube-proxy during control-plane upgrades on supported versions:
```bash theme={null}
kubectl -n kube-system delete ds kube-proxy
# Delete the ConfigMap as well to avoid kube-proxy being reinstalled during a kubeadm upgrade
kubectl -n kube-system delete cm kube-proxy
```
Also ensure you clean up any leftover iptables or ipvs rules created by kube-proxy to avoid conflicts with Cilium.
Before removing kube-proxy, ensure you understand how control-plane and API-server access will be handled. Removing kube-proxy without configuring Cilium to communicate with the API server can lead to control-plane connectivity issues.
2. Configure Cilium to replace kube-proxy
When Cilium replaces kube-proxy, it must be able to contact the Kubernetes API server directly (since the kube-proxy Service IP may no longer exist). Provide explicit API server host and port in Cilium's configuration and enable kubeProxyReplacement:
```yaml theme={null}
kubeProxyReplacement: "true"
k8sServiceHost: "host-ip-control-plane"
k8sServicePort: "6443"
```
Setting k8sServiceHost and k8sServicePort avoids a bootstrap problem: with kube-proxy removed, Cilium needs explicit connectivity information to the API server to initialize service discovery and control-plane interactions.
Apply the Cilium manifest or Helm chart with these settings and ensure Cilium DaemonSet/Pods restart with the new configuration.
3. Verify kube-proxy replacement is active
After deploying Cilium with kubeProxyReplacement enabled, validate the agent status:
```bash theme={null}
kubectl -n kube-system exec ds/cilium -- cilium-dbg status | grep KubeProxyReplacement
```
For more verbose diagnostics:
```bash theme={null}
kubectl -n kube-system exec ds/cilium -- cilium-dbg status --verbose | grep KubeProxyReplacement
```
A successful replacement shows `KubeProxyReplacement: true`, indicating Cilium is handling service routing/load balancing via eBPF.
Operational notes and caveats
* Remove all kube-proxy artifacts (DaemonSet, ConfigMap) and clear iptables/ipvs rules to avoid conflicts.
* Ensure k8sServiceHost and k8sServicePort are correct so Cilium can reach the API server.
* Test pod-to-pod, pod-to-service, and control-plane connectivity after enabling replacement.
* Monitor Cilium logs and use Cilium diagnostics (cilium-dbg, Hubble) to validate traffic flows and troubleshoot.
Helpful links and references
* Cilium Documentation: [https://cilium.io/](https://cilium.io/)
* Kubernetes Service Networking: [https://kubernetes.io/docs/concepts/services-networking/](https://kubernetes.io/docs/concepts/services-networking/)
* eBPF Overview: [https://ebpf.io/](https://ebpf.io/)
For more on configuring Cilium via Helm or manifests, see the official Cilium docs and Helm chart examples.