In partnership with
TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.
👋 👋 A big thank you to today's sponsor 1440
Smart starts here.
You don't have to read everything — just the right thing. 1440's daily newsletter distills the day's biggest stories from 100+ sources into one quick, 5-minute read. It's the fastest way to stay sharp, sound informed, and actually understand what's happening in the world. Join 4.5 million readers who start their day the smart way.
👀 Remote Jobs
Adapty is hiring a Senior DevOps Engineer
Remote Location: Worldwide
PulsePoint is hiring a Middle/Senior/Staff Site Reliability Engineer (K8s)
Remote Location: Worldwide
📚 Resources
Looking to promote your company, product, service, or event to 50,000+ Cloud Native Professionals? Let's work together. Advertise With Us
🧠 DEEP DIVE USE CASE
Kubernetes Kube Proxy Modes Explained
When you call a Kubernetes Service, you never think about which Pod will receive the request or how the traffic finds it. You just hit a ClusterIP or NodePort and expect the cluster to “do the right thing”. That “right thing” is mostly the work of kube-proxy.
Kubernetes architecture
At a high level, every worker node runs kube-proxy. It watches the API server for Service and Endpoint/EndpointSlice updates and programs the node’s networking layer so that Service virtual IPs exist, traffic to those IPs is load balanced to the correct Pod IPs, and changes are applied automatically as Pods appear or disappear.
Kube-proxy can implement this routing in different ways, called proxy modes. In practice you’ll mostly see:
Iptables Proxy Mode
User Space Proxy Mode
IPVS Proxy Mode
Iptables Proxy Mode
kube-proxy programs iptables DNAT rules on every node. These rules map a Service ClusterIP or NodePort to the Pod IPs. Traffic never touches kube-proxy after rules are written. The Linux kernel handles everything through connection tracking.
What kube-proxy actually does on the node
Watches the API server for: Service objects, Endpoints or EndpointSlice objects
Generates iptables rule chains like: KUBE-SERVICES, KUBE-NODEPORTS, KUBE-SEP-xxxx (service endpoints), KUBE-SVC-xxxx (service VIP rules)
Injects these chains into the node’s PREROUTING and OUTPUT tables. So the node becomes “aware” of all Service virtual IPs and all Pod backends.
Practical nuances that actually matter
Rule explosion in large clusters
Thousands of Services or rapidly changing Endpoints make rule updates slow. kube-proxy may spike CPU during heavy churn.Failover isn’t instant
If a Pod dies, traffic may still hit it for a short time until kube-proxy rewrites the rules. Applications may see brief 502/503 errors.Debugging is straightforward
You can inspect every routing decision with: iptables -t nat -L KUBE-SERVICES -n --line-numbersNodePort behavior is transparent
All NodePort rewrites live underKUBE-NODEPORTS, making it easy to trace external-to-pod traffic.Not ideal for very large clusters
If you have thousands of Services, heavy HPA, or frequent rollouts, iptables may struggle to keep up.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Upgrade to Paid to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content.
UpgradePaid subscriptions get you:
- Access to archive of 200+ use cases
- Deep Dive use case editions (Thursdays and Saturdays)
- Access to Private Discord Community
- Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
- Quarterly 1:1 'Ask Me Anything' power session
