Loading today’s stories
Build1 distinct publisher3 min readUpdated
A tutorial walkthrough of kube-proxy is a useful reminder that a ClusterIP is not an interface. The iptables-to-IPVS-to-eBPF sequence is an answer to per-node rule accounting, not taste.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A Kubernetes Service ClusterIP is usually not a real, physical network interface attached to any Pod [1]. That is the premise of the eighth instalment of dev.to's Kubernetes networking series, which opens up what it calls the Service dataplane [2], and it is also the reason Service networking gets expensive in a place most teams do not instrument: on every node, on the packet path.
The worked example is deliberately small. A frontend Pod at 10.244.1.5 runs curl against the name `backend`, DNS resolves that to 10.96.120.50, and the packet leaves with source 10.244.1.5 and destination 10.96.120.50:80 [3]. The Service is backed by three Pods, at 10.244.1.10:80, 10.244.2.10:80 and 10.244.3.10:80 [4]. Something has to rewrite the destination to one of those, and the article's answer is destination NAT: 10.96.120.50:80 becomes 10.244.2.10:80 [5].
Who does the rewriting is where the naming misleads. kube-proxy is not a traditional HTTP proxy, a point the article flags as an interview trap [6]. It watches Services and EndpointSlices and programs the node's networking rules to match what it sees [7]. Historically it did that by programming iptables rules [8]. It typically runs as a DaemonSet, so every node has its own instance, because each node needs to handle Service traffic that arrives locally [9]. It does not create Pods; Deployments create Pods, Services define a stable endpoint, and the dataplane implements forwarding [10][11].
Put those two facts together and you get the accounting that matters. The Service-to-endpoint mapping is not held once in the cluster; it is programmed independently on each node, so the total amount of dataplane state a cluster carries is roughly the per-node rule set, driven by Services multiplied by endpoints, multiplied again by node count [12]. A three-endpoint Service in a three-node cluster is trivial. The same arithmetic at a few thousand Services is not, and that is the pressure the article's outline responds to: it places a section titled "The Scaling Problem with iptables" immediately before "IPVS: IP Virtual Server" and "iptables vs IPVS" [13], then "eBPF Enters the Picture", "Cilium and eBPF" and "eBPF Can Replace Parts of kube-proxy" [14], and sums the sequence up as "Three Generations to Remember" [15].
That ordering is the honest version of the story: three implementations of one job, arrived at under load, not three fashions. What the supplied text does not give is any number attached to the wall. There is no rule count, no per-packet cost, no cluster size at which iptables stops being adequate. Treat any specific breaking point you are quoted as a claim requiring the quoter's own measurement.
Two caveats come from the article itself. It reserves a section for "An Important Modern Nuance" on the iptables-versus-IPVS comparison [16], and another warning readers not to confuse a kube-proxy replacement with a CNI [17]. It also notes that modern clusters can implement Service forwarding very differently from the historic kube-proxy path [18].
What to watch is operational, and the article's own checklist is the right one: know which dataplane you are actually running, know what to inspect on a node, and have a troubleshooting tree that separates control plane from dataplane [19]. The return path deserves the same attention, since the article treats SNAT and why return traffic works as separate topics from DNAT [20], and revisits NodePort and LoadBalancer on top of the same machinery [21].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
A Service ClusterIP such as 10.96.120.50 usually is not a real, physical network interface attached to any Pod.
The article is Level 8 of a Kubernetes networking series published on dev.to and states it is where the series goes inside the Service dataplane, unpacking how traffic sent to a Service IP ends up at a real Pod.
In the worked example, a frontend Pod at 10.244.1.5 runs curl http://backend:80, DNS resolves backend to 10.96.120.50, and the outgoing packet has source 10.244.1.5 and destination 10.96.120.50:80.
The example Service named backend, with ClusterIP 10.96.120.50:80, is backed by three Pods: 10.244.1.10:80, 10.244.2.10:80 and 10.244.3.10:80.
DNAT (destination network address translation) rewrites the packet destination from 10.96.120.50:80 to 10.244.2.10:80 while leaving the source as 10.244.1.5.
Despite its name, kube-proxy is not simply a traditional HTTP proxy; the article calls this a genuinely useful interview point.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Internally coherent tutorial, no external corroboration
All claims trace to one explanatory dev.to article. Its mechanism-level statements are concrete and mutually consistent (ClusterIP is not an interface, DNAT rewrites destination only, kube-proxy watches Services and EndpointSlices, DaemonSet per node), which supports the descriptive core. But there are no upstream Kubernetes docs, release notes, benchmarks or rule-count measurements cited anywhere, and the generational iptables/IPVS/eBPF narrative is evidenced only by the article's own section headings.
No adoption signal in supplied sources
The cluster contains no release, deployment, benchmark, usage-disclosure or pricing evidence. The article mentions IPVS, eBPF and Cilium only as concepts and reports no cluster deployments, versions or user counts, so adoption cannot be measured without inferring facts the source does not supply.
Modest framing, slightly ahead of its evidence
The piece makes no product or performance promises and its descriptive claims land at or below what it can show, which keeps the gap small. It tips mildly positive because the framing of an iptables scaling problem and of eBPF replacing parts of kube-proxy is asserted through section structure while no rule counts, latency figures or deployment evidence are offered, and adoption is unmeasurable from the supplied material.
Series audience-building, no disclosed vendor stake
The visible incentive is authorial: this is Level 8 of a numbered dev.to series that trails a next instalment and repeatedly frames points as interview material, which rewards breadth, memorable framing and continuation over evidentiary rigour. No sponsorship, employer or vendor relationship is disclosed or apparent, and no product is being sold, so distortion pressure is real but limited.
Confident on mechanism, thin on everything else
Confidence is moderate: the descriptive Kubernetes mechanics are stated unambiguously by the source and are the kind of claim a single competent explainer can carry, so the mechanism claims are reliable. It is capped by having one publisher, no corroborating documentation or measurement, an unmeasurable adoption dimension, and a body text that is truncated so several outlined sections are known only by title.
build
Deleting kube-proxy moves your service traffic where your SIEM cannot follow it1 distinct publisher
build
Cross-node pod traffic: routing or encapsulation, and why that choice is a debugging decision1 distinct publisher
build
Thirteen tasks green, then "give up (Recommended)" on the one that needed understanding1 distinct publisher
build
Rate limit your MCP servers, because a retrying agent turns one error into a billing incident1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 19, 2026