Services

In this lesson you’ll learn how Kubernetes Services provide stable network endpoints so clients can reliably reach applications running in Pods. Services decouple client access from Pod lifecycle events (restart, reschedule, scaling), making it safe to change Pods without changing how clients connect. Common use cases

Expose a front-end application to end users.
Let front-end Pods communicate with back-end Pods.
Provide access to external data sources or users.
Distribute load across multiple Pod instances.

Consider an application split into groups of Pods:

front-end Pods serving user traffic,
back-end Pods handling business logic,
Pods connecting to external data sources.

Services enable connectivity and loose coupling between these groups, ensuring stable discovery and routing as Pods change. External-access example Imagine you deployed a Pod running a web server. Network addressing in the cluster is separate from node and client networks:

Kubernetes node IP: 192.168.1.2
Your laptop IP: 192.168.1.10
Pod network range: 10.244.0.0/16
Pod IP: 10.244.0.2

Pod IPs are internal to the cluster, so you cannot reach 10.244.0.2 directly from your laptop:

# From the Kubernetes node you can curl the Pod:
$ curl http://10.244.0.2
Hello World!

To access the web server from your laptop (without SSH into the node), you need an object that maps a port on the node to the Pod. Kubernetes Service provides that mapping. A Service is a first-class Kubernetes object (like Pod, Deployment) that can expose a port on each node and forward incoming requests to matching Pods. The Service type that exposes a port on every node is called NodePort. Service types overview

The image is a dark-themed diagram titled "Service Types" showing three labeled service types—NodePort, ClusterIP, and LoadBalancer—each illustrated with simple rounded-rectangle containers and blue node icons. It visually contrasts single external node (NodePort), internal cluster IP (ClusterIP), and a load-balanced multi-node setup (LoadBalancer).

Key Service types at a glance

Service Type	Purpose	Typical use
`ClusterIP` (default)	Exposes a Service on a cluster-internal IP	Internal communication between services (microservices)
`NodePort`	Exposes a Service on a static port on every Node	Simple external access on-prem or for demos
`LoadBalancer`	Provisions a cloud provider load balancer and routes traffic	Production external load-balancing on supported clouds

NodePort explained NodePort maps a port on each node to a Service port; the Service then forwards to Pod targetPort. Conceptually there are three ports involved:

Port name	Where it lives	Purpose / example
`targetPort`	Pod (container)	Port where the application listens (e.g., `80`)
`port`	Service (ClusterIP)	Internal Service port (routes to `targetPort`)
`nodePort`	Node	External port on each Node (default range `30000–32767`)

A simple diagram showing a Kubernetes NodePort service: NodePort 30008 on the node forwards to a Service (10.106.1.12:80) which routes traffic to a Pod at 10.244.0.2 on target port 80. The image labels the NodePort range (30000–32767) and the Port → TargetPort mapping.

Important details

ports in a Service manifest is an array; each element must include port.
If targetPort is omitted, it defaults to the same value as port.
If nodePort is omitted, Kubernetes will allocate a free port in the NodePort range.

If you omit targetPort, it defaults to the port value. If you omit nodePort, Kubernetes assigns a free port from the configured NodePort range (default 30000–32767).

Warning about exposing NodePorts

Exposing NodePorts opens a port on every cluster node. For production workloads, prefer LoadBalancer (cloud) or an Ingress controller with proper TLS, authentication, and firewall rules. NodePort can be acceptable for on-prem or debug scenarios.

Example NodePort Service manifest This example exposes port 80 on the Service, maps to container targetPort 80, and selects Pods using the labels app: myapp and type: front-end. It explicitly sets nodePort: 30008.

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: NodePort
  ports:
    - targetPort: 80
      port: 80
      nodePort: 30008
  selector:
    app: myapp
    type: front-end

Matching Pod manifest (labels matter)

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: front-end
spec:
  containers:
    - name: nginx-container
      image: nginx
      ports:
        - containerPort: 80

How to create and verify the Service

Apply the Service manifest:

$ kubectl create -f service-definition.yml
service "myapp-service" created

List Services and confirm the NodePort mapping:

$ kubectl get services
NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
kubernetes       ClusterIP   10.96.0.1        <none>        443/TCP          16d
myapp-service    NodePort    10.106.127.123   <none>        80:30008/TCP     5m

From any client on the same network, curl the node IP and the NodePort:

$ curl http://192.168.1.2:30008

Sample HTML response (truncated):

<html>
<head>
<title>Welcome to nginx!</title>
...

Services and multiple Pods (load distribution) In production you usually run multiple copies of the same application for availability and capacity. If multiple Pods share the same selector labels (e.g., app: myapp), the Service routes traffic to all matching Pods. Kubernetes performs load distribution via kube-proxy. Distribution specifics depend on the kube-proxy mode:

iptables mode uses probabilistic selection across endpoints.
ipvs mode supports round-robin and other algorithms.

As Pods are added or removed, Service endpoints update automatically so traffic keeps flowing to healthy Pod instances. NodePort when Pods run across multiple nodes When Pods are scheduled on different nodes, the NodePort is still exposed on every node. Kubernetes ensures that traffic arriving at any node on the configured NodePort is routed to one of the Service’s Pods (possibly on a different node). This allows you to use any node IP with the same NodePort to reach the application.

A Kubernetes "Service — NodePort" diagram showing three nodes (192.168.1.2, 192.168.1.3, 192.168.1.4) each exposing port 30008 that forwards traffic to pods (10.244.0.3, 10.244.0.2, 10.244.0.4). The central Service load-balances incoming requests across those pods.

You can curl any node IP using the same NodePort:

$ curl http://192.168.1.2:30008
$ curl http://192.168.1.3:30008
$ curl http://192.168.1.4:30008

Summary and best practices

Services provide stable networking for Pods and decouple clients from Pod lifecycles.
NodePort exposes a Service on a static port on every node (default range 30000–32767) and maps nodePort → service port → targetPort.
Use label selectors to connect Services to Pods; when multiple Pods match, the Service distributes traffic across them automatically.
Prefer ClusterIP for internal services and LoadBalancer (or Ingress) for production external access on cloud platforms.
Secure NodePorts with firewall rules, network policies, or by using Ingress/LoadBalancer front-ends in production.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Watch Video