Services Interview Questions

ClusterIP is the default Service type in Kubernetes. It assigns a virtual IP address reachable only from within the cluster, making it the standard choice for internal microservice-to-microservice communication.

A NodePort Service exposes a Service on a static port on every node's IP address. External clients can reach the Service by sending traffic to any node's IP on that port, and kube-proxy forwards it to the correct backend Pods.

A Kubernetes Service is an abstraction that provides a stable network endpoint for a set of Pods. Because Pod IPs are ephemeral and change on every restart, a Service gives clients a single DNS name and virtual IP that automatically routes traffic to healthy, matching Pods.

ClusterIP provides internal-only access via a virtual IP, NodePort extends ClusterIP by opening a port on every node for external access, and LoadBalancer extends NodePort by provisioning a cloud load balancer with a dedicated external IP. Each type builds on the previous one.

An ExternalName Service maps a Kubernetes Service name to an external DNS name by returning a CNAME record. It has no selector, no ClusterIP, and no proxying -- it is purely a DNS-level alias that lets in-cluster Pods reference external services using a Kubernetes-native name.

A headless Service is a ClusterIP Service with clusterIP set to None. Instead of providing a single virtual IP, DNS returns the individual IP addresses of all matching Pods directly. This is essential for StatefulSets and applications that need to discover and connect to specific Pod instances.

Kubernetes provides two built-in service discovery mechanisms: DNS-based discovery via CoreDNS (the primary method) and environment variable injection. DNS creates records for every Service, enabling Pods to find other Services by name without hard-coding IP addresses.

A LoadBalancer Service provisions an external load balancer from the cloud provider, giving the Service a public or internal IP address. Traffic flows from the external LB to a NodePort on the cluster nodes and then to the backend Pods.

A service mesh is an infrastructure layer that handles service-to-service communication by deploying sidecar proxies alongside each Pod. It provides features like mutual TLS, advanced load balancing, traffic splitting, and observability that go beyond what native Kubernetes Services offer.

A Service without a selector does not automatically discover Pods. Instead, you manually create Endpoints or EndpointSlice objects to point the Service at specific IP addresses. This is used to proxy traffic to external services, other namespaces, or non-Kubernetes systems while using Kubernetes DNS and kube-proxy.

Session affinity (also called sticky sessions) ensures that all requests from the same client IP are routed to the same backend Pod. Kubernetes supports ClientIP-based session affinity at the Service level, configurable via spec.sessionAffinity and spec.sessionAffinityConfig.

EndpointSlices are a scalable replacement for the legacy Endpoints resource. They split endpoint information into smaller, bounded chunks (default 100 endpoints per slice), reducing the API server and network load when Services back large numbers of Pods.

externalTrafficPolicy controls how a NodePort or LoadBalancer Service routes external traffic. The Cluster policy (default) distributes traffic to Pods on any node but loses the client source IP. The Local policy only sends traffic to Pods on the receiving node, preserving the client IP but potentially causing uneven load distribution.

kube-proxy runs on every node and watches the API server for Service and EndpointSlice changes. It programs the node's networking stack (iptables, IPVS, or nftables) to intercept traffic destined for Service ClusterIPs and perform DNAT to forward it to a healthy backend Pod.