When you run an application inside Kubernetes, the application normally runs inside one or more Pods. But Pods are not designed to provide a permanent network endpoint.
Pods can be replaced, recreated and moved between nodes. Their IP addresses can therefore change during the lifetime of an application.
This creates an important networking question: How does another application or a user reliably connect to those Pods?
Kubernetes provides a resource called a Service to solve this problem.
A Kubernetes Service provides a stable network endpoint for accessing a group of Pods selected by labels.
In this guide, we will focus on three commonly encountered Kubernetes Service types: ClusterIP, NodePort and LoadBalancer.
Why Do We Need a Kubernetes Service?
Imagine an application running with three Pods:
web-pod-2 → 10.10.2.15
web-pod-3 → 10.10.3.20
If another application needs to communicate with the web application, directly depending on these Pod IP addresses would be fragile.
If one Pod is deleted and another is created, the replacement Pod may have a different IP address.
A Service provides a stable abstraction in front of those Pods.
Application
Stable Endpoint
How Does a Service Find Pods?
Kubernetes Services commonly use selectors to identify the Pods that should receive traffic.
For example, a Pod might have this label:
app: web
A Service can use the same label in its selector:
selector: app: web
The Service can then target Pods carrying that label.
Pod 1 → app=web ✓
Pod 2 → app=web ✓
Pod 3 → app=database ✗
1. ClusterIP
ClusterIP is the default Service type in Kubernetes.
It provides a virtual IP address that is normally reachable from within the Kubernetes cluster.
This makes ClusterIP particularly useful for communication between applications inside the cluster.
A simple ClusterIP Service can look like this:
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
type: ClusterIP
selector:
app: web
ports:
- port: 80
targetPort: 80
Because ClusterIP is the default Service type, the type field can also be omitted in a basic configuration.
2. NodePort
NodePort makes a Service accessible through a port on each node that is configured to serve the NodePort traffic.
Conceptually, traffic can enter through a node's address and the assigned NodePort, and Kubernetes can direct that traffic toward the Service's selected Pods.
NodePort
A simplified NodePort configuration could look like:
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
type: NodePort
selector:
app: web
ports:
- port: 80
targetPort: 80
nodePort: 30080
The explicit NodePort value must be within the range configured for NodePort Services by the Kubernetes cluster.
NodePort can be useful for learning, testing and certain network architectures, although production environments often use other exposure mechanisms depending on their requirements.
3. LoadBalancer
LoadBalancer is commonly used when a Kubernetes environment is integrated with infrastructure capable of providing an external load balancer.
The exact behavior depends on the Kubernetes environment and the infrastructure integration available.
Load Balancer
Service
A basic LoadBalancer Service can be defined as:
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
type: LoadBalancer
selector:
app: web
ports:
- port: 80
targetPort: 80
In a cloud environment, the platform's integration may provision or configure an external load-balancing resource. In other environments, additional infrastructure may be required.
ClusterIP vs NodePort vs LoadBalancer
| Service Type | Typical Purpose | Typical Access |
|---|---|---|
| ClusterIP | Internal application communication | Inside the cluster |
| NodePort | Expose a Service through node ports | Node address + NodePort |
| LoadBalancer | External load-balancer integration | External endpoint, depending on environment |
Understanding port and targetPort
Beginners often get confused by the difference between port and targetPort.
Consider this example:
ports:
- port: 80
targetPort: 8080
The Service listens on its Service port, while targetPort identifies the port on the selected Pod that should receive the traffic.
Service port → the Service-facing port
Pod targetPort → the application port receiving the traffic
Kubernetes Service Discovery
Kubernetes also provides service discovery mechanisms that allow applications to locate Services using names rather than manually tracking Pod IP addresses.
In many Kubernetes configurations, applications can use a Service name such as:
web-service
rather than depending directly on individual Pod IP addresses.
DNS is an important part of Kubernetes service discovery, which is why understanding DNS is useful before learning Kubernetes networking in greater depth.
What Happens When a Pod Changes?
Suppose a Deployment initially has three Pods:
Pod A Pod B Pod C
The Service selects the Pods according to its configuration.
If Pod B is replaced, Kubernetes can update the set of destinations associated with the Service. Applications using the Service do not need to manually discover the replacement Pod's new IP address.
→ Pod B
→ Pod C
→ Pod B-new
→ Pod C
Useful Kubernetes Service Commands
List Services
kubectl get services
Get detailed Service information
kubectl describe service web-service
Check Pods
kubectl get pods
Check Services and Pods together
kubectl get svc,pods
Check Service endpoints
kubectl get endpoints
The exact endpoint representation can vary with Kubernetes versions and features, but examining the Service's selected destinations is an important troubleshooting step.
Kubernetes Service Troubleshooting
If an application is not reachable through a Service, work through the problem systematically.
- Check that the Service exists.
- Check the Service type.
- Check the Service selector.
- Check whether the expected Pods have matching labels.
- Check the Service port and targetPort.
- Check whether the application is actually listening on the expected port.
- Check the Service's selected endpoints.
- Check Kubernetes networking and any network policies involved.
Useful commands include:
kubectl get svc kubectl describe svc web-service kubectl get pods --show-labels kubectl get endpoints kubectl get pods
Why Kubernetes Services Matter in DevOps
Modern applications are often made up of multiple services. A frontend may need to communicate with a backend API, while the backend may need to communicate with a database or another internal application.
Kubernetes Services provide an abstraction that helps applications communicate without requiring them to track individual Pod IP addresses.
Understanding Services is therefore an important foundation for learning Kubernetes networking, Ingress, Gateway API, service discovery and cloud load balancing.
Kubernetes Service Interview Questions
1. What is a Kubernetes Service?
A Kubernetes Service provides a stable network endpoint for accessing a selected group of Pods.
2. What is the default Service type?
ClusterIP is the default Service type.
3. What is ClusterIP used for?
ClusterIP is commonly used for communication with a Service from within the Kubernetes cluster.
4. What is NodePort?
NodePort exposes a Service through a port on Kubernetes nodes.
5. What is LoadBalancer?
LoadBalancer requests or represents integration with an external load-balancing mechanism, depending on the Kubernetes environment.
6. What is the difference between port and targetPort?
The Service's port is the port exposed by the Service, while targetPort identifies the port on the selected Pod that should receive traffic.
7. How does a Service select Pods?
A Service commonly uses label selectors to identify its target Pods.
Frequently Asked Questions
Can a Kubernetes Service point to multiple Pods?
Yes. A Service can select multiple Pods that match its selector.
Does a Service have its own IP address?
A ClusterIP Service has a virtual IP address used to provide a stable access point inside the cluster.
Can a Service work without a Deployment?
Yes. A Service and Deployment are separate Kubernetes resources. A Service can select Pods created by different mechanisms, provided the appropriate endpoints exist.
Is NodePort always required before LoadBalancer?
The exact implementation depends on the Kubernetes environment. Do not assume that every cluster implements external load balancing in exactly the same way.
Practical Kubernetes Service Exercise
If you have access to a Kubernetes cluster, try this exercise.
Step 1: Create a Deployment
kubectl create deployment web --image=nginx
Step 2: Check the Pod
kubectl get pods --show-labels
Step 3: Create a ClusterIP Service
kubectl expose deployment web --port=80 --target-port=80
Step 4: Check the Service
kubectl get service
Step 5: Describe the Service
kubectl describe service web
Look at the Service's selector, ports and selected destinations. This is a simple way to connect the concepts of Deployment → Pod → Service.
Key Takeaways
- A Kubernetes Service provides a stable way to access selected Pods.
- Pods can be replaced, so applications should not depend directly on individual Pod IP addresses.
- ClusterIP is the default Service type.
- ClusterIP is commonly used for internal cluster communication.
- NodePort exposes a Service through a port on Kubernetes nodes.
- LoadBalancer can integrate a Service with external load-balancing infrastructure.
- Services commonly use label selectors to identify target Pods.
- The Service port and targetPort have different purposes.
- DNS plays an important role in Kubernetes service discovery.
- Understanding Services is essential before learning advanced Kubernetes networking.
Related Topics
- Kubernetes Pods, Deployments and Services
- What Is DNS?
- Kubernetes Networking Explained
- What Is a Kubernetes CNI?
- Kubernetes Ingress
- Kubernetes Gateway API
- Docker Containers Explained
- Load Balancing Explained
Post a Comment