Services

In this lesson we cover Kubernetes Services — the stable network abstractions that enable communication between components inside and outside a cluster. Services decouple clients from ephemeral Pods by providing stable endpoints for discovery and routing. Common scenarios include:

Exposing an application to end users (external access).
Allowing front-end and back-end Pods to discover and reach each other (internal access).
Providing a consistent way to connect to external resources.

We’ll walk through a typical external-access use case, then examine the most common Service types and how Services map traffic to Pods.

Why a Service is needed

Imagine you have a Pod running a web server with IP 10.244.0.2. Your laptop on the same local network has IP 192.168.1.10 and a Kubernetes node has IP 192.168.1.2. Pod IPs live on an internal overlay network (for example 10.244.0.0/16) and are not directly reachable from your laptop. While you could SSH into the node and curl the Pod IP from the node:

$ curl http://10.244.0.2
Hello World!

you don’t want to SSH into the node each time. You want to use the node’s IP and a stable port to reach the web app from your laptop. That mapping — exposing a node-level port and forwarding incoming traffic to Pod ports in the cluster — is what a Kubernetes Service provides.

Common Service types

Kubernetes exposes three common Service types:

Service Type	Purpose	Typical use case
ClusterIP	Internal virtual IP only inside the cluster	Microservice-to-microservice communication (default)
NodePort	Opens a port on every Node and forwards to the Service	Simple external access for development or on-prem deployments
LoadBalancer	Provisions cloud provider load balancer and routes to Service	Production external access using provider-managed LB

A slide titled "Service Types" showing three simplified network diagrams labeled NodePort, ClusterIP, and LoadBalancer. Each diagram uses a rounded rectangle and blue dots to illustrate how traffic connects to services (single node port, internal cluster IP, and a load-balanced front end).

Below we focus on NodePort to illustrate how Services map ports and route external traffic into the cluster.

NodePort — deeper look

A NodePort Service maps three port concepts:

targetPort — the port on the Pod where the application is listening (e.g., 80).
port — the port on the Service (the cluster-internal port used by other cluster clients).
nodePort — the port on every Node that forwards traffic to the Service (e.g., 30008). Default NodePort range: 30000–32767.

When you create a NodePort Service, Kubernetes still assigns the Service a ClusterIP. From inside the cluster you can use the Service’s ClusterIP and port; from outside you use the node IP and nodePort. Quick port mapping reference:

Field	Description	Example
`targetPort`	Port on the container/Pod	`80`
`port`	Service port (ClusterIP)	`80`
`nodePort`	Port opened on each Node for external access	`30008`

Minimal NodePort Service example:

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

Only port is mandatory in the ports entry. If targetPort is omitted it defaults to the same value as port. If nodePort is omitted, Kubernetes will allocate a port in the 30000–32767 range.

Linking a Service to Pods

A Service routes traffic to backend Pods using a selector. The selector must match labels on the target Pods. Example Pod manifest:

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

The Service shown earlier selects Pods with app: myapp and type: front-end. When labels match, traffic sent to the Service is forwarded to these Pods. Create the Service:

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

Verify Services in the cluster:

$ 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

Access the application from your laptop using the node IP and NodePort:

$ curl http://192.168.1.2:30008
<html>
<head>
<title>Welcome to nginx!</title>
...

Services and multiple Pods (load balancing)

In production you’ll usually run multiple replicas of your application for availability and load distribution. Each Pod replica should carry the same label set (for example app: myapp) so the Service selector matches all replicas. When multiple Pods match a Service selector, the Service load-balances traffic across them. The actual packet forwarding behavior depends on kube-proxy mode:

iptables mode: probabilistic selection across endpoints.
IPVS mode: supports multiple scheduling algorithms (round-robin, least connections, etc.).

From an application perspective the Service transparently distributes requests to healthy endpoints without additional configuration.

NodePort across multiple nodes

Kubernetes exposes the nodePort on every Node in the cluster, even if the Pods are only running on a subset of nodes. Any node receiving traffic on that port will forward it to the Service endpoints.

A diagram titled "Service – NodePort" showing three Kubernetes nodes (192.168.1.2/1.3/1.4) each exposing port 30008. Traffic from a user to any node:30008 is routed to backend pods (10.244.0.2/0.3/0.4) via the Service.

You can curl any node’s IP and the same port:

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

Kubernetes ensures the NodePort is available cluster-wide and updates endpoints automatically as Pods are added or removed.

Summary and best practices

Services provide stable network endpoints and abstract away Pod lifecycle and IP churn.
Use ClusterIP for internal-only services, NodePort for simple external access, and LoadBalancer when using cloud provider LBs.
Connect Services to Pods via labels and selectors; ensure consistent labels across replicas.
Prefer Deployments/ReplicaSets for multi-replica workloads rather than single Pods.
For production external access, prefer a provider LoadBalancer or an Ingress (with a LoadBalancer or NodePort backing it) to expose HTTP(S) services.

Introduction

Core Concepts

Configuration

Multi-Container Pods

Observability

POD Design

State Persistence

Certification Tips

Helm Fundamentals

(2025 Updates) Kustomize Basics

Lightning Labs

Mock Exams

Security

Services & Networking

Why a Service is needed

Common Service types

NodePort — deeper look

Linking a Service to Pods

Services and multiple Pods (load balancing)

NodePort across multiple nodes

Summary and best practices

Watch Video

​Why a Service is needed

​Common Service types

​NodePort — deeper look

​Linking a Service to Pods

​Services and multiple Pods (load balancing)

​NodePort across multiple nodes

​Summary and best practices

Watch Video

Why a Service is needed

Common Service types

NodePort — deeper look

Linking a Service to Pods

Services and multiple Pods (load balancing)

NodePort across multiple nodes

Summary and best practices