Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Cilium’s Kubernetes datapath is the packet-processing layer on each Linux node that decides what happens to traffic from a Pod. For every packet it chooses one of three branches: deliver it to a local endpoint, hand it to the node’s Linux routing, or translate it first when it is addressed to a Kubernetes Service. Knowing which branch a packet takes is the fastest way to reason about connectivity, policy and failures in a Cilium cluster.
What the datapath is made of
Every Pod that Cilium manages has a corresponding endpoint on its node. Cilium attaches eBPF programs to the node’s networking path and uses eBPF maps, kernel-resident key-value tables, to hold the state those programs read for each packet, such as endpoint information and service mappings. Cilium’s eBPF Datapath documentation describes this arrangement as the packet-handling machinery for endpoint traffic and its supporting maps.
The exact hooks a packet passes through depend on the Cilium configuration, the kernel version and whether the destination is local, routed or a Service address. Read the rest of this article as a model of the decision points, not as a fixed list of hooks.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Follow a packet through the node
Cilium’s datapath documentation organizes the packet path into three flows: endpoint-to-endpoint traffic, egress from an endpoint and ingress to an endpoint. The same three flows make a practical troubleshooting map.
#1 Best Overall
Endpoint to endpoint on the same node
- Pod A sends a packet addressed to the IP of Pod B.
- The Cilium programs on the node path look up the destination and find that it is a local endpoint.
- The packet is delivered to Pod B directly. It never leaves the node, so underlay routing plays no part.
Egress from an endpoint
Egress is where most of the decisions happen, because the destination can be local, a Service address or something outside the node.
- The packet leaves Pod A’s network namespace and reaches the node-side datapath.
- If the destination is a local endpoint, the packet is delivered locally, as in the previous flow.
- If the destination is a Kubernetes Service address, service translation applies. With Cilium’s kube-proxy replacement, Cilium performs that translation in eBPF. Without it, kube-proxy’s rules handle the Service.
- If the destination is neither local nor a Service that Cilium translates, native routing mode passes the packet to Linux routing. The node’s routing table then selects the next hop.
Ingress to an endpoint
Ingress is the mirror image. A packet arriving at the node from the network is checked for a local destination. If the destination is a local endpoint, the packet is delivered to that endpoint after Cilium’s policy checks. If it is not local, the node must forward it onward, which again depends on the routing mode described below.
Cross-node traffic: who provides reachability
For traffic between nodes, separate two roles. Cilium processes the packet on each node. The underlay network carries the packet between nodes. Cilium does not automatically create underlay reachability in every environment, so the choice of routing mode determines what you must provide.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchIn native routing mode, Cilium delegates packets that are not destined for a local endpoint to Linux routing. Remote Pod IPs are reachable only if the node or the surrounding network has routes to them. Those routes can come from cloud network integration, direct node routes on a shared Layer 2 network or a routing component that distributes routes.
Rank #3
The table below compares native routing with tunnel (overlay) mode on the axes that matter when you design a cluster. Where the sources reviewed do not give a value, the cell says so.
| Question | Native routing | Tunnel (overlay) mode |
|---|---|---|
| Who provides reachability to remote Pod IPs | The underlay, through cloud network integration, direct node routes on a shared L2 network, or a route-distribution component | Cilium’s overlay carries Pod traffic between nodes; the underlay only needs node-to-node IP connectivity |
| Encapsulation of cross-node packets | Not added by Cilium for non-local packets, which are passed to Linux routing | Cross-node packets are encapsulated, which adds per-packet overhead |
| How Pod routes are distributed | Through routes the node or network already has or receives | Through the overlay’s own mapping of Pod address ranges to nodes |
| Underlay requirements | Routes to every Pod address range must exist before traffic flows | Ports and MTU requirements are release-specific; not stated in the sources reviewed, so check the Routing documentation for your version |
Before you choose native routing, confirm the following:
- Each node can reach every other node’s Pod address range through a route your network or cloud provides.
- Those routes are present on the nodes and on any gateway between them, not just on one host.
- Your cloud or network integration can distribute new Pod ranges when nodes are added.
Services: kube-proxy or Cilium replacement
By default, kube-proxy translates Service addresses such as ClusterIP, NodePort and LoadBalancer addresses into backend Pod addresses. Cilium’s kube-proxy replacement moves that service translation and load balancing into Cilium’s eBPF datapath. The change affects who implements the translation, how source IPs are preserved and how traffic policies apply, so treat it as a configuration decision rather than a switch to flip.
| Axis | kube-proxy retained | Cilium kube-proxy replacement |
|---|---|---|
| Who implements Service translation | kube-proxy on each node | Cilium’s eBPF datapath |
| Compatibility with surrounding proxies and storage | Behavior that existing tools already expect | Must be checked for each proxy or storage path in use |
| Source IP preservation | Governed by kube-proxy behavior | Configurable; the Kubernetes Without kube-proxy documentation describes the modes and their requirements |
| Service traffic policies | Governed by kube-proxy behavior | Configurable, with behavior described in the same documentation |
| Kernel feature support | Not affected by Cilium’s kernel requirements | Depends on the kernel features the chosen options need |
Limits to check before you switch
- SCTP support is limited to a few basic cases in Cilium’s Kubernetes Without kube-proxy documentation.
- Socket-level load balancing has kernel-related concerns for NFS or SMB mounts that go through a Service IP. Test those mounts on the kernel you run.
- Source IP preservation and traffic policy behavior depend on the mode you select. Confirm them against the release you deploy.
Service meshes
Cilium’s Istio integration documentation recommends keeping kube-proxy for minimal disruption in the common Istio modes. Full kube-proxy replacement requires additional settings in those setups. If you run Istio, plan the replacement as a separate project.
Best Value
When the datapath still uses iptables
Cilium does not bypass iptables or the regular Linux stack for every packet. Its iptables usage documentation describes legacy iptables as the fallback when the kernel lacks a capability that a function requires. Host routing and other optimizations can also change which hooks or tables see a given packet. The iptables guidance comes from Cilium’s latest development documentation, so confirm the fallback behavior in the documentation for the stable release you run before you rely on it.
Kernel and datapath mode are design inputs
Kernel version and datapath mode determine which features you can use, so decide them before you deploy. The Cilium Tuning Guide states the following for netkit:
- netkit requires kernel 6.8 or newer.
- netkit requires eBPF host routing.
- netkit cannot be enabled in place on existing veth-based Pods. A migration must account for newly created or restarted Pods, or for replacing nodes.
These requirements apply to netkit only. Other Cilium features have their own kernel and mode requirements, so do not apply the 6.8 minimum to them without checking the documentation for your release.
Troubleshooting: identify the branch first
Most datapath failures become easier once you know which branch the packet should take. Work through these checks in order.
Quick Recap
- Confirm the kernel on the affected node with
uname -r. If you use netkit, the result must be 6.8 or newer. - Confirm the datapath mode with
cilium statusrun from the Cilium agent. The output reports the routing mode and the kube-proxy replacement state. Compare both with the values in your installation configuration. - For a cross-node failure, run
ip route getfollowed by a remote Pod IP on the source node. If the command finds no usable route, native routing cannot deliver the packet. Fix the underlay routes first. - For a Service failure, confirm whether kube-proxy or Cilium performs the translation. If the failing traffic is SCTP or an NFS or SMB mount through a Service IP, compare it with the limits listed above.
- If an iptables rule appears to handle traffic you expected Cilium to handle, check whether the fallback applies to your kernel and selected features in the stable documentation for your release.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
