Kubernetes Networking Explained for Developers

Short answer: Kubernetes networking rests on a few rules: every Pod gets its own IP, every Pod can reach every other Pod, a Service gives a group of Pods one stable address, and an Ingress routes outside HTTP traffic to the right Service. You rarely touch the low-level plumbing — you work with Services and Ingress.

Part 7 of the series. Previous: How Kubernetes Keeps Applications Running.

Introduction

Networking is where Kubernetes feels most mysterious, mostly because people dive into iptables and CNI internals too early. As an application engineer, you need a clear model of how a request reaches your Pod and how your services talk to each other. That is what this article gives you — without the kernel-level detour.

The problem

You have a Market Data service with 4 Pods, each with its own changing IP. Other services need to call it reliably, and external clients need to reach your public APIs over HTTPS at clean URLs. Hardcoding Pod IPs is hopeless — they change constantly. You need stable names and sane routing.

Simple explanation

• Every Pod has its own internal IP, but those are temporary.
• A Service is a permanent nickname for a set of Pods; call the nickname and it picks a healthy Pod.
• ClusterIP Services are reachable only inside the cluster (service-to-service).
• Ingress is the front gate for outside HTTP/HTTPS traffic, routing by hostname and path to the right Service.

Official Kubernetes concept

• ClusterIP (default Service type): internal stable IP/DNS for east-west traffic.
• NodePort / LoadBalancer: expose a Service outside the cluster; LoadBalancer provisions a cloud load balancer.
• Ingress: rules that map hostnames/paths to Services, handled by an Ingress controller.
• Cluster DNS: lets you reach a Service by name, like `market-data.default.svc.cluster.local` (usually just `market-data`).
• kube-proxy: programs each Node so Service IPs forward to backend Pods.

How it works

Service-to-service ("east-west") traffic uses ClusterIP Services and DNS: your Trade API calls `http://market-data/prices/AAPL` and the cluster routes it to a healthy Market Data Pod. Inbound ("north-south") traffic from the internet hits a load balancer, flows into the Ingress controller, which matches the host/path rule and forwards to the right Service, which forwards to a Pod. You configure the rules; kube-proxy and the Ingress controller handle the mechanics.

Finance example

External clients hit `https://api.fintech.example/portfolio`. An Ingress rule routes `/portfolio` to the `portfolio-api` Service and `/trades` to the `trade-api` Service. Internally, the Trade API calls the Market Data Service by name to price an order. None of these components know each other's Pod IPs — only stable Service names — so Pods can be rescheduled freely with zero config changes.

C# example

In-cluster calls use the Service name as the host — clean and stable:

public sealed class MarketDataClient(HttpClient http)
{
    // Base address configured as http://market-data (the Service name).
    public Task<MarketPrice?> GetPrice(string symbol) =>
        http.GetFromJsonAsync<MarketPrice>($"/prices/{symbol}");
}

public record MarketPrice(string Symbol, decimal LastPrice);

AWS example

On EKS, a Service of type `LoadBalancer` provisions an AWS Network or Application Load Balancer. The AWS Load Balancer Controller lets an Ingress provision an ALB with host/path routing and TLS from ACM. Route53 points your domain at the load balancer, and the ALB forwards to the Ingress/Services.

Architecture diagram

Production reality

Networking is where subtle, expensive bugs live:

• DNS is the usual suspect in flaky service-to-service calls. Aggressive client-side DNS caching in .NET (`HttpClient` reusing a stale resolved IP) means a rescheduled Service is missed. Configure `PooledConnectionLifetime` so connections refresh.
• VPC IP exhaustion is a real EKS failure mode. Each Pod gets a VPC IP via the CNI; large clusters can drain subnet IPs and block new Pods. Size subnets for peak Pod count, not Node count.
• East-west traffic is unrestricted by default. Any Pod can talk to any Pod. In finance you must add NetworkPolicies so the payment namespace is not reachable from everything.
• Cost: every `LoadBalancer` Service provisions its own cloud load balancer (a per-hour charge). Consolidate behind one Ingress/ALB instead of one LB per service.
• Security: terminate TLS at the ALB/Ingress with ACM certs, and consider mTLS (a service mesh) for sensitive internal traffic.

AI Engineering connection

An AI agent reaches its MCP servers and model endpoints over exactly this fabric — by stable Service name, load balanced across replicas. NetworkPolicies are how you stop an experimental agent from reaching production payment services, and Ingress is how external AI clients reach your MCP servers securely.

Interview questions

• How do Pods find each other? Through Services and cluster DNS using stable Service names, not Pod IPs.
• Difference between a Service and an Ingress? A Service gives Pods a stable internal address and load balances; an Ingress routes external HTTP/HTTPS traffic to Services by host/path.
• What are the main Service types? ClusterIP (internal), NodePort, and LoadBalancer (external via a cloud load balancer).
• What does kube-proxy do? Programs Node networking so Service virtual IPs forward to backend Pods.
• How is TLS typically terminated? At the Ingress/load balancer layer, often using ACM certificates on AWS.

Key takeaways

• Pods get ephemeral IPs; Services give stable names; Ingress routes external traffic.
• Use Service names for service-to-service calls — never Pod IPs.
• ClusterIP for internal, LoadBalancer/Ingress for external.
• On EKS, the AWS Load Balancer Controller wires Ingress to ALBs with TLS.

Next article

Next: Kubernetes Storage Explained — how data survives when Pods do not. Previous: How Kubernetes Keeps Applications Running.