Kubernetes Service

This document explores Kubernetes services and related objects, detailing their purposes, properties, and use cases. It covers service types (ClusterIP, NodePort, LoadBalancer, ExternalName), Ingress for routing, and workload controllers like DaemonSet, StatefulSet, and Job, providing practical insights into application networking and management.

Kubernetes Services and Related Objects

A service in Kubernetes is a REST object that provides a logical abstraction for a set of Pods, enabling policies for accessing Pods and acting as a load balancer. Each service is assigned a unique IP address, simplifying application access and eliminating the need for separate service discovery. Services support multiple protocols, such as TCP (default) and UDP, and can define multiple ports. Optional selectors and port mappings allow flexible targeting of backend Pods.

Why Services Are Needed

Pods in a Kubernetes cluster are ephemeral; they can be destroyed and recreated at any time, leading to changing IP addresses and discoverability issues. Services address this by tracking Pod changes and exposing a single IP or DNS name, using selectors to target sets of Pods. For native Kubernetes applications, API endpoints update automatically as Pods change. For non-native applications, Kubernetes uses a virtual IP-based bridge or load balancer between applications and backend Pods.

Types of Kubernetes Services

	flowchart TD
	subgraph Cluster
	direction TB
	A[Pod 1] -- Service Selector --> S[Service: ClusterIP]
	B[Pod 2] -- Service Selector --> S
	end
	S -- Internal IP --> User[Internal Client]
	S -. NodePort .-> NP[Service: NodePort]
	NP -- Node IP:Port --> ExtUser[External Client]
	NP -. LoadBalancer .-> LB[Service: LoadBalancer]
	LB -- Public IP --> Internet[Internet User]
	S -. ExternalName .-> EN[Service: ExternalName]
	EN -- DNS CNAME --> ExtDNS[External Resource]
	

ClusterIP

ClusterIP is the default and most common service type. It assigns a cluster-internal IP address, making the service reachable only within the cluster. ClusterIP is used for internal communication, such as between frontend and backend components.

NodePort

NodePort extends ClusterIP by exposing the service on each node’s IP at a static port. Incoming requests are routed to the ClusterIP service. NodePort is generally not recommended for production due to security concerns.

LoadBalancer

LoadBalancer builds on NodePort and ClusterIP, automatically creating both and integrating with an external load balancer. This exposes the service to the Internet, typically using a cloud provider’s load balancer.

ExternalName

ExternalName maps a service to a DNS name using the spec.externalName parameter. It returns a CNAME record and is useful for representing external resources or enabling cross-namespace communication.

Ingress: Managing External Access

	flowchart LR
	subgraph Cluster
	direction TB
	S1[Service: App1]
	S2[Service: App2]
	S3[Service: App3]
	IG[Ingress Controller]
	IG -- Path /app1 --> S1
	IG -- Path /app2 --> S2
	IG -- Path /app3 --> S3
	end
	User[Internet User] -- HTTP/HTTPS --> IG
	

Ingress is an API object that, with a controller, provides routing rules for managing external user access to multiple services in a cluster. In production, Ingress exposes applications via HTTP (port 80) or HTTPS (port 443). While Ingress simplifies routing, external load balancers remain managed outside the cluster and can be costly.

Workload Controllers - DaemonSet, StatefulSet, and Job

	flowchart TD
	subgraph DaemonSet
	direction TB
	DS[DaemonSet]
	DS -- Schedules --> N1[Node 1]
	DS -- Schedules --> N2[Node 2]
	DS -- Schedules --> N3[Node 3]
	end
	subgraph StatefulSet
	direction TB
	SS[StatefulSet]
	SS -- Pod 0 --> P0[Pod 0]
	SS -- Pod 1 --> P1[Pod 1]
	SS -- Pod 2 --> P2[Pod 2]
	P0 -- Persistent Volume --> PV0[PV 0]
	P1 -- Persistent Volume --> PV1[PV 1]
	P2 -- Persistent Volume --> PV2[PV 2]
	end
	subgraph Job
	direction TB
	J[Job]
	J -- Creates --> JP1[Pod A]
	J -- Creates --> JP2[Pod B]
	J -- Creates --> JP3[Pod C]
	end
	

DaemonSet

A DaemonSet ensures that a copy of a Pod runs on all (or selected) nodes. As nodes are added, Pods are created; when nodes are removed, Pods are garbage collected. Deleting a DaemonSet removes all its Pods. DaemonSets are ideal for storage, logging, and monitoring tasks.

StatefulSet

StatefulSet manages stateful applications, handling deployment and scaling of Pods with guarantees about ordering and uniqueness. It maintains a sticky identity for each Pod and provides persistent storage volumes, supporting workloads that require stable network identities and storage.

Job

A Job creates Pods to perform tasks and tracks their completion. Jobs are retried until successful. Deleting a Job removes its Pods, and suspending a Job deletes active Pods until resumed. Jobs can run multiple Pods in parallel, and CronJobs schedule Jobs at regular intervals.

Conclusion

Kubernetes services provide stable networking and access policies for dynamic sets of Pods, supporting both internal and external communication. Service types like ClusterIP, NodePort, LoadBalancer, and ExternalName address different networking needs, while Ingress manages external routing. Workload controllers such as DaemonSet, StatefulSet, and Job enable robust application management and automation.

FAQ