Kubernetes Services

A Kubernetes Service is an abstraction that defines a stable network identity and routing policy for a set of Pods.

Pods are ephemeral and often have dynamic IPs. Services provide a stable endpoint for clients to connect to.

A Pod IP is the IP address assigned to a pod, which can change when the pod is recreated.

Pods may be rescheduled, restarted, scaled, or replaced, which can change their IP addresses.

Service discovery is the process of finding the network endpoint for a service without hardcoding pod IPs.

A Service selector matches Pods by labels, selecting which pods receive traffic.

A label is a key-value pair used to organize and select objects like Pods.

A selector match identifies Pods whose labels satisfy the Service’s label query.

The default Service type is ClusterIP.

A ClusterIP Service exposes the service internally within the cluster.

A NodePort Service exposes the service on a static port on each node.

A LoadBalancer Service provisions an external load balancer to expose the service outside the cluster.

An ExternalName Service maps a service name to an external hostname, such as an external DNS name.

An Ingress is an HTTP or HTTPS entry point that routes traffic to Services based on rules.

Ingress provides HTTP routing, TLS termination, path routing, and a cleaner external entry point.

A Service provides a stable IP and port, and load balances traffic to matching Pods.

A Service endpoint is the Pod address and port selected by the Service.

Endpoints are the actual IPs and ports of the Pods behind a Service.

Endpoint slicing is the newer API for tracking sets of Pod endpoints behind a Service efficiently.

Because clients should not need to know all Pod IPs or handle churn.

A Service gets a DNS name in the cluster namespace, such as my-service.my-namespace.svc.cluster.local.

A Service is scoped to a namespace and typically discovered via that namespace’s DNS.

Cluster DNS provides name resolution for Services and Pods within the Kubernetes cluster.

A selectorless Service does not match Pods by labels and is often used to point to an external service or manually managed endpoints.

A headless Service has no ClusterIP and exposes each Pod directly through DNS entries.

It is useful for stateful applications and direct Pod access, like a database cluster.

Session affinity keeps requests from the same client bound to the same backend Pod.

Some applications are stateful and require stickiness to a specific Pod.

A Service port is the port exposed by the Service to clients.

A target port is the port on the Pod that receives the traffic.

Because the Service may expose a stable public port while the app listens on another internal port.

A Service manifest is a Kubernetes YAML resource that defines the Service’s selector, ports, and type.

For example: app: api or tier: backend

A Service selects Pods by labels based on the selector field.

The kube-proxy or network plugin routes packets to one of the selected Pods.

kube-proxy is the Kubernetes component that implements Service routing rules in the cluster.

iptables mode is a kube-proxy mode that uses iptables rules for routing and load balancing.

IPVS mode uses IPVS load balancing for service traffic and can be more performant in some large clusters.

Load balancing means distributing requests across multiple matching Pods.

Round-robin is a common load-balancing strategy where traffic is sent to Pods in turn.

A healthy Service endpoint is a Pod that is ready and able to accept traffic.

A readiness probe indicates when a container is ready to receive traffic.

Because Services route only to ready Pods unless explicitly configured otherwise.

A liveness probe indicates whether the container is alive and should be restarted if not.

It is a more advanced readiness mechanism used by workloads to gate traffic acceptance.

A backlog is the queue of connections or requests waiting to be handled by backend Pods.

A network policy allows or denies traffic to and from pods and services based on labels and ports.

Because Services route traffic while network policies enforce who may talk to whom.

Kubernetes assigns a virtual IP address to the Service for intra-cluster access.

A Service can be changed from ClusterIP to NodePort or LoadBalancer depending on exposure requirements.

A Deployment manages ReplicaSets and maintains a desired number of Pods.

A Service selects Pods created by a Deployment by labels.

A ReplicaSet ensures a defined number of Pod replicas are running.

A DaemonSet ensures a Pod runs on every or selected nodes, often relevant for node-level networking services.

A StatefulSet manages stateful Pods that often need stable identities and stable network identities.

Because they need direct Pod-level identities and stable DNS names.

A Service name is the DNS name used by clients to connect to it.

Kubernetes DNS resolves Service names to cluster IP addresses.

A Service port maps external name and port to target port(s) on the Pods.

A namespace isolates Kubernetes objects, including Services, within a logical boundary.

It separates teams, apps, and environments while reducing accidental cross-communication.

An internal service is only reachable within the cluster.

An external service is reachable from outside the cluster, usually via NodePort, LoadBalancer, or Ingress.

Service exposure is the act of making a Service reachable from outside or within the cluster.

Port forwarding is a debugging technique where local traffic is forwarded into a pod or service.

It allows local clients to access a Service or pod as if it were local.

An endpoint is the destination that a Service forwards traffic to, nominally a Pod IP and port.

A Service mesh adds advanced routing, policy, and observability on top of Service networking.

Because Services handle basic routing, while a mesh adds policy, observability, and advanced traffic control.

A Service maps a stable identity to one or more backend Pods.

Because Services target Pods by labels, which makes selection dynamic and resilient.

It happens when the Service selector does not match any Pods or when labels change unexpectedly.

This often causes connection failures because no backends exist for the Service.

Usually yes, because DNS names and service discovery are namespaced.

Pods in different namespaces can resolve a Service with the namespace-qualified DNS name.

A service account is separate from a Service object, though both are K8s objects.

A port number identifies where a Service listens, such as 80 or 443.

A target port may be different from the service port, often 8080 inside a container.

A named port lets you reference a service or container port by a name instead of a number in some APIs.

The IP family indicates IPv4 and/or IPv6 support for the Service.

Some clusters support dual-stack networking, and Services may be assigned IPv4, IPv6, or both.

A dual-stack Service has both IPv4 and IPv6 addresses in a dual-stack cluster.

NodePort ports are allocated from a configurable range, usually 30000-32767.

A NodePort Service opens the port on each cluster node, allowing access through any node IP.

A LoadBalancer Service obtains an external IP assigned by a cloud or external load balancer.

CDNs or cloud load balancers integrate with Kubernetes Services to expose workloads externally.

Because traffic stays inside the cluster and uses the Service’s ClusterIP.

An internal load balancer exposes a Service only inside the private network or VPC.

A health check ensures a Service is reachable and backend Pods are ready.

Because a Service should not send traffic to unhealthy endpoints.

A Service event can indicate changes to endpoints, type, or load balancer configuration.

The endpoint controller maintains the list of backend Pods for Services.

Because otherwise no backend addresses exist and traffic cannot reach the app.

A Deployment defines what Pods should run. A Service defines how to reach them.

It is a query used to identify Pods based on labels.

A Service can expose multiple ports, such as HTTP on 80 and metrics on 9090.

A Pod port may be assigned a name so a Service or app can reference it by name.

The protocol is often TCP or UDP, and for some services it may be SCTP as well.

It occurs when the Service or Pod is configured for one protocol but the application expects another.

A service routing policy governs traffic rules such as load balancing, affinity, and session behavior.

It is an older kube-proxy mode where traffic is proxied by user-space processes.

IPVS is a kernel-space load balancer used by kube-proxy for high-performance L4 service routing.

It can scale better and provide more efficient load balancing for large clusters.

It is virtual IP and port that routes to one or more selected Pods.

It is a low-level rule that sends packets from the Service IP to Pod endpoints.

Because the Service needs to balance traffic among multiple Pods and track readiness.

EndpointSlice is the API object that stores addresses and metadata for Service backends.

To scale better for large numbers of endpoints and Services.

It watches Pods and updates the appropriate Service endpoints as Pods appear, disappear, or become ready.

The Pod ready condition indicates whether Pod containers are ready for service traffic.

Because traffic should not go to Pods still starting up or failing readiness checks.

A startup probe detects whether an app has finished starting up and can delay liveness checks during initialization.

It helps avoid premature restarts when the app starts slowly.

ExternalTrafficPolicy controls whether traffic from outside the cluster is routed through the node or directly to Pods.

Local traffic policy sends external traffic only to local Pods on the same node when possible.

Cluster external traffic policy may route traffic to Pods on other nodes.

A cloud or external LB often performs health checks against the Service’s backend to decide routing.

A NodePort may need health checks at the node or LB layer to know when the endpoints are healthy.

Because they should not route to unhealthy Pods or nodes.

An ingress controller watches Ingress resources and configures an HTTP routing layer.

Ingress routes HTTP traffic to one or more Services, which then route to Pods.

A Service may expose multiple ports, each mapping to a different target port or protocol.

Host-based routing sends traffic for different domains to different Services.

Path-based routing sends /api to one Service and /web to another.

An Ingress can terminate TLS and route incoming HTTPS traffic to a backend Service.

It may be namespaced and connected to a particular team or app.

A stable Service identity means clients can rely on a consistent name and IP without managing Pod churn.

Cluster DNS resolves Service names to an A record or cluster IP.

SRV records can identify named ports for a Service, useful for some protocols.

A headless Service returns individual Pod IPs instead of the ClusterIP.

To give each Pod a stable identity and DNS name independent of the Service IP.

Each StatefulSet Pod gets a stable ordinal-based name and DNS record.

A service mesh adds retries, mTLS, canary releases, and traffic shifting on top of standard Services.

Service topology defines how a Service routes traffic, such as local-only or zone-aware routing.

It routes traffic to nearby backends based on topology, such as the same zone or node.

A cluster IP leak happens when internal Service addresses are exposed unintentionally.

External exposure can create attack surfaces if the Service is not controlled by firewall or ingress policy.

Firewall rules help restrict access to cluster or external entry points.

A NetworkPolicy restricts traffic to and from Pods, which helps control Service accessibility.

A default deny policy blocks most traffic until specific allowed paths are defined.

Because a Service should not be reachable by every pod by default in secure environments.

It assumes workloads are isolated unless explicitly allowed to talk to each other.

It is a Service only reachable within the cluster or VPC.

A public service is reachable by external clients via LoadBalancer, NodePort, or Ingress.

A gateway service handles external traffic and routes it to the correct internal Service.

An ingress sits at the edge and routes HTTP/HTTPS traffic into the cluster.

Because it supports URL routing and TLS termination without exposing many node ports.

A path routes particular URL requests to specific backend Services.

It routes based on hostname, such as api.example.com vs app.example.com.

Ingress can match on both, allowing multiple apps and routes behind one external entry point.

Policies can restrict which Services can be exposed or which types are allowed.

Because names become DNS names and are used by apps and operators to discover them.

It happens when the selector labels do not match Pods, leaving the Service with no endpoints.

A stale endpoint refers to a Pod that was removed but still appears in the endpoint list temporarily.

When a Pod is terminating, it may remain temporarily ready or not, affecting Service routing.

A readiness grace period allows a Pod to start receiving traffic only after it is fully ready.

A timeout occurs when a client waits too long for a response from a backend.

A circuit breaker prevents repeated calls to an unhealthy or overloaded Service.

A retry policy determines whether failed requests are retried and with what backoff.

It includes metrics, logs, traces, and health signals for Service traffic patterns and latency.

Because each request may traverse multiple Services, and tracing helps identify bottlenecks and failures.

It distributes backend Pods across zones or nodes to improve resilience.

High availability means the Service remains reachable even when some Pods or nodes fail.

A Service routes to all ready Pods behind its selector, regardless of deployment scale.

Because clients see a stable per-service endpoint rather than unstable pod IPs.

It happens when multiple Services on the same cluster or nodes try to bind the same port unexpectedly.

It happens when multiple Services try to claim or update the same cloud external IP.

A NodePort conflict occurs when two Services try to use the same node port.

Metadata includes labels, annotations, name, namespace, and other identifying fields.

Annotations are arbitrary metadata used by controllers, ingress, or cloud vendors.

Cloud controllers may use annotations to create or modify load balancers for a Service.

You can convert a Service between ClusterIP, NodePort, and LoadBalancer when you need to change exposure.

Service account token exposure may be affected by policies, but Services themselves are network objects not identity objects.

Because they define the external exposure model and how the Service is accessed by clients.

It is the idea that clients can reach a service without tracking individual pods or their movements.

It is the DNS name that resolves to the Service’s stable cluster IP or other address.

To manually define endpoints that are not Kubernetes Pods, or to integrate with external resources.

Some controllers create Services automatically for external or internal integrations.

Client -> Service IP -> kube-proxy -> selected backend Pod -> app response.

Because it turns the Service abstraction into actual iptables or IPVS rules on the node.

It includes topology-aware routing, zone balancing, and node locality to optimize performance and resilience.

iptables rules are efficient but can scale poorly under extreme endpoint churn or large clusters compared with IPVS.

IPVS supports weighted scheduling and more advanced L4 balancing than simple iptables rules.

kube-proxy runs on each node and maintains the local Service routing rules.

It eliminates the ClusterIP and exposes each pod as a unique DNS endpoint.

Because stateful workloads often need stable Pod DNS names and direct peer discovery.

It resolves to one or more Pod IPs rather than a single Service ClusterIP.

It can expose e.g. TCP and UDP port combinations to match different application protocols.

It is commonly a ClusterIP or LoadBalancer Service exposing the gRPC port to clients.

A Service can route WebSocket traffic just like HTTP traffic, as long as backend Pods are ready and the protocol is supported.

It may enforce mTLS, retries, circuit breakers, and routing rules independent of raw K8s Services.

It means preferring backends in different failure domains to reduce correlated failures.

It spreads Pods across availability zones and uses routing patterns to improve resilience and latency.

It is the partitioning of inbound traffic across ingress controllers or ingress nodes.

L4 routing operates at the transport layer, such as TCP/UDP. L7 routing operates at the application layer, such as HTTP path and host.

The Service mostly functions at the transport layer, balancing connections to backend Pods.

Ingress goes above Service routing and inspects HTTP headers, hosts, and paths.

ExternalDNS syncs DNS records to cloud or external DNS providers based on Kubernetes Services and Ingresses.

It is one of the core building blocks of K8s networking and inter-service communication.

Kubernetes Services turn a dynamic set of Pods into a stable, discoverable, load-balanced endpoint, which is the foundation of resilient and scalable application traffic management.