Skip to main content
Kubernetes Introduction
CHAPTER 07 Intermediate

Kubernetes Services and Networking

Updated: May 15, 2026
25 min read

# CHAPTER 7

Kubernetes Services and Networking

1. Introduction

In Kubernetes, Pods are highly volatile. If a Worker Node fails, the Pods on it die, and the Deployment recreates them elsewhere with completely brand new IP addresses. If a frontend React application tries to connect to a backend Node.js Pod using a hardcoded IP address, the connection will break the very first time the backend Pod restarts. To solve this, Kubernetes introduces the Service object. In this chapter, we will learn how Services provide stable IP addresses, reliable DNS names, and built-in load balancing.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Understand the volatility of Pod IP addresses.
  • Define what a Kubernetes Service is.
  • Understand how Services use Selectors to find Pods.
  • Differentiate between ClusterIP, NodePort, and LoadBalancer service types.
  • Expose an application to the internet.

3. Beginner-Friendly Explanation

Imagine a busy hospital call center.
  • The Pods (The Doctors): Doctors are constantly changing shifts, going to lunch, and moving to different rooms. You can never memorize a doctor's direct desk phone number because they keep moving.
  • The Service (The Switchboard): The hospital sets up a single, permanent 1-800 phone number (The Service). When a patient calls that number, the switchboard automatically forwards the call to whichever doctor happens to be on duty at that exact moment.

The frontend application only needs to memorize the permanent switchboard number; Kubernetes handles the messy reality of routing the traffic to the shifting Pods behind the scenes.

4. The 3 Types of Services

When you create a Service, you must define its type. This dictates *who* can access the Pods.
  1. 1. ClusterIP (The Default): Highly secure. The Service gets a stable IP address, but it is ONLY accessible from *inside* the cluster. Used for backend databases or internal APIs that the public internet should never see.
  1. 2. NodePort: Opens a specific, high-numbered port (e.g., 30001) on every single Worker Node's physical IP address. Anyone who can reach your servers can reach the app. Often used for simple external testing.
  1. 3. LoadBalancer: The production standard. If you are running on AWS, Azure, or Google Cloud, this tells the cloud provider to magically provision a physical Cloud Load Balancer (with a public IP address) and route traffic into your cluster.

5. Service Discovery (Internal DNS)

Kubernetes runs its own internal DNS server (CoreDNS). When you create a Service named backend-api, Kubernetes automatically creates a DNS record for it. A frontend Pod can simply make an HTTP request to http://backend-api:8080. The internal DNS instantly resolves that human-readable name to the stable Service IP, which then load-balances the request to the backend Pods. This is the magic of Microservice communication!

6. Anatomy of a Service YAML

How does the Service know which Pods to route traffic to? It uses Labels and Selectors!
yaml
123456789101112 
apiVersion: v1
kind: Service
metadata:
  name: my-web-service
spec:
  type: NodePort
  selector:
    app: webapp # The Service routes traffic to ANY Pod with this label!
  ports:
    - port: 80 # The port the Service listens on
      targetPort: 80 # The port the actual Container is listening on
      nodePort: 30080 # The physical port opened on the Worker Nodes

7. Mini Project: Expose an Application

Let's make our Nginx deployment from Chapter 6 visible to the world.

Step-by-Step Tutorial:

  1. 1. Ensure your webapp deployment from the previous chapter is running (kubectl get pods).
  1. 2. Save the YAML from Section 6 above into a file named service.yaml.
  1. 3. Apply the Service:

bash
1 
kubectl apply -f service.yaml
  1. 4. Verify the Service exists:
bash
1 
kubectl get svc

*(You will see my-web-service with a type of NodePort).*

  1. 5. The Test: Because we are using Minikube (which runs inside a VM), we can't just type localhost:30080. Minikube provides a helper command to open the NodePort in your laptop's browser:

bash
1 
minikube service my-web-service
  1. 6. Your browser will open, and you will see the Nginx welcome page! The traffic is flowing from your browser -> to the Minikube Node -> to the Service -> to one of the 3 Pods.

8. Real-World Scenarios

A company deploys a complex microservice architecture. The Frontend UI needs to talk to the User API, the Cart API, and the Payment API. Instead of configuring complex IP routing tables, the DevOps engineer simply creates 3 ClusterIP services named user-service, cart-service, and payment-service. The Frontend developer simply hardcodes those exact human-readable names into their Axios fetch requests. The networking is entirely abstracted.

9. Best Practices

  • Strict Selector Targeting: Always double-check your Service selector labels. If you accidentally type app: frontend instead of app: front-end, the Service will be created successfully, but it will silently route traffic to nowhere, resulting in endless connection timeouts.

10. Common Mistakes

  • Confusing port and targetPort:
  • port: The port the *Service* itself exposes.
  • targetPort: The port the *Container* is listening on.
If your Node.js app runs on 3000, but you set targetPort: 80, the Service will send traffic to port 80, and the container will reject it.

11. Exercises

  1. 1. Explain the security benefit of utilizing a ClusterIP service for a PostgreSQL database rather than a NodePort service.
  1. 2. How does a Service determine which specific Pods should receive incoming traffic?

12. FAQs

Q: If LoadBalancer is the production standard, why didn't we use it in the Mini Project? A: A LoadBalancer service type requires integration with a cloud provider's API (like AWS). Minikube is just a local VM on your laptop; it cannot magically summon a physical Amazon Load Balancer! Therefore, we simulate it locally using NodePort.

13. Interview Questions

  • Q: Describe the functional differences between ClusterIP, NodePort, and LoadBalancer service types. Under what architectural circumstances would you deploy each?
  • Q: A developer has deployed a Service and a Deployment, but curl requests to the Service IP are timing out. Detail your step-by-step troubleshooting process to identify the disconnect. *(Hint: Check endpoints! kubectl get endpoints)*

14. Summary

In Chapter 7, we solved the problem of Pod volatility. We introduced the Service object as the stable, permanent front door to our shifting applications. We utilized Labels and Selectors to dynamically bind Services to Pods, enabling seamless internal microservice communication via Kubernetes DNS and ClusterIP. Finally, we punched a hole through our local cluster firewall using a NodePort service, exposing our web application to the outside world.

15. Next Chapter Recommendation

Our applications can talk to each other, but how do we securely pass them database passwords without hardcoding them in the YAML? Proceed to Chapter 8: ConfigMaps and Secrets.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Deployments and ReplicaSets
Next Chapter ConfigMaps and Secrets

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 5

❓ Related Quizzes 6