
Prerequisites
- kind (Kubernetes in Docker) — https://kind.sigs.k8s.io/
- kubectl — https://kubernetes.io/docs/tasks/tools/
- Helm — https://helm.sh/
- Basic familiarity with CNI/Cilium and kube-proxy concepts
Create a kind cluster
Save the following askind.config and create a cluster named my-cluster. This configuration disables the default CNI so we can install Cilium:
NotReady until a CNI is installed):
Install Cilium (run alongside kube-proxy)
Install Cilium via the official Helm chart. By default, Cilium’s Helm chart sets kubeProxyReplacement to “false”, which means Cilium runs alongside kube-proxy and does not change service handling. Snippet example fromvalues.yaml:
Switching Cilium to replace kube-proxy
Cilium’s kube-proxy replacement (kubeProxyReplacement: “true”) hands over Kubernetes service handling from kube-proxy (iptables/ipvs) to Cilium’s eBPF-based datapath. High-level steps:- Remove kube-proxy components (daemonset and configmap).
- Clean up kube-proxy-created iptables chains (environment-dependent).
- Update Cilium configuration to enable kube-proxy replacement and configure direct API server connectivity (k8sServiceHost/k8sServicePort).
- Upgrade the Cilium Helm release with new values.
- Verify replacement is active and confirm service connectivity.
Deleting kube-proxy and flushing iptables can disrupt cluster networking. Ensure you have console access to nodes and a recovery plan before making these changes on production clusters.
- On kind clusters (Docker-in-Docker), iptables changes from inside containers may not affect the host. Proceed with caution and skip iptables cleanup on kind unless you understand the host context.
- Ensure Cilium agents can reach the API server directly when kube-proxy is removed (set k8sServiceHost and k8sServicePort appropriately).
Remove kube-proxy daemonset and configmap
Delete the kube-proxy daemonset:iptables cleanup (environment-dependent)
kube-proxy typically creates Kubernetes-specific iptables chains. In production you would remove those so that Cilium’s eBPF datapath becomes authoritative for services. Do not run these commands on kind unless you know the correct host context. Example inspection and (cautious) commands:On kind clusters running inside Docker containers, modifying host iptables from the container may not have the intended effect. Skip iptables cleanup on kind unless you know the correct host context.
Enable kube-proxy replacement in values.yaml
Edit yourvalues.yaml to enable kube-proxy replacement and add API server connectivity settings. Example modifications:
- k8sServiceHost should be a hostname or IP reachable from worker nodes.
- k8sServicePort is typically 6443 (API server port).
Reference: Cilium kube-proxy replacement docs
Push updated configuration with Helm
Upgrade the Cilium release with the modified values:Test service connectivity (NodePort example)
Create a simple nginx deployment and a NodePort service to verify service handling through Cilium’s replacement. deployment.yaml:Summary
- By default Cilium runs alongside kube-proxy (kubeProxyReplacement: “false”).
- To let Cilium replace kube-proxy:
- Remove kube-proxy components.
- Clean iptables chains where required (environment-dependent).
- Set kubeProxyReplacement: “true” and configure k8sServiceHost/k8sServicePort.
- Upgrade the Cilium Helm release and verify with
cilium-dbg status. - Validate service traffic with a test Deployment + Service.
- Always test carefully and have recovery access when changing core networking components.
- Cilium Documentation — kube-proxy replacement
- kind — Kubernetes in Docker
- Helm
- Kubernetes Documentation