> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Services
> Explanation of Kubernetes Services, service types like ClusterIP NodePort LoadBalancer, port mapping, selectors, and routing traffic to Pods for internal and external access.
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:
```bash theme={null}
$ 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 |
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:
```yaml theme={null}
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:
```yaml theme={null}
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:
```bash theme={null}
$ kubectl create -f service-definition.yml
service/myapp-service created
```
Verify Services in the cluster:
```bash theme={null}
$ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 443/TCP 16d
myapp-service NodePort 10.106.127.123 80:30008/TCP 5m
```
Access the application from your laptop using the node IP and NodePort:
```bash theme={null}
$ curl http://192.168.1.2:30008
Welcome to nginx!
...
```
## 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.
You can curl any node’s IP and the same port:
```bash theme={null}
$ 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.
Further reading and references:
* [Kubernetes Services documentation](https://kubernetes.io/docs/concepts/services-networking/service/)
* [Service Types: ClusterIP, NodePort, LoadBalancer](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types)
* [Kube-Proxy modes (iptables vs IPVS)](https://kubernetes.io/docs/concepts/services-networking/service/#kube-proxy)
Create and interact with Services in a cluster to practice these concepts and solidify your understanding.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.