Kubernetes Networking & Services
Services — ClusterIP, NodePort, LoadBalancer
Exposing pod workloads internally and externally.
Interview: Be ready to write a Service manifest and explain the different Service types: ClusterIP (internal), NodePort (opens a port on every node), and LoadBalancer (provisions a cloud LB). Understand EndpointSlices and how kube-proxy maintains forwarding rules.
Why Do We Need Services?
Because Pods are ephemeral, they are constantly created, deleted, and rescheduled on different hosts. When a Pod restarts, it gets a new IP address. If a frontend application connects directly to a backend Pod's IP address, the connection will break as soon as that backend Pod is rescheduled.
A **Service** provides a stable IP address and DNS hostname that sits in front of a dynamic group of Pods, load-balancing traffic across them automatically.
The Three Primary Service Types
Kubernetes offers three core service configurations depending on exposure requirements:
- ClusterIP (Default): Exposes the Service on an internal cluster IP. This Service is only accessible from within the cluster (e.g. database or cache layers).
- NodePort: Exposes the Service on each node's IP at a static port (in the range
30000-32767). External traffic hitting<NodeIP>:<NodePort>is automatically routed to the internal ClusterIP. - LoadBalancer: Provisions a cloud provider's external load balancer (such as an AWS Network Load Balancer or GCP Load Balancer) that routes external traffic directly to NodePorts and ClusterIPs.
Service Discovery via CoreDNS
Kubernetes runs a cluster-internal DNS service (**CoreDNS**). When a Service is created, it automatically gets a DNS record resolved by its service name.
For example, a service named catalog-service running in the production namespace resolves internally to its stable ClusterIP using the hostname:
catalog-service.production.svc.cluster.local
kube-proxy and EndpointSlices
Services identify target Pods using label selectors. The control plane watches these selectors and maintains lists of active Pod IPs in **EndpointSlices**.
The kube-proxy daemon running on each worker node listens to these changes and writes local iptables or IPVS forwarding rules. When packets hit a Service ClusterIP, the node's local routing rules redirect the traffic directly to an active Pod IP.