You have learned:

Deployment
     ↓
ReplicaSet
     ↓
Pod 1
Pod 2
Pod 3

But Pods are ephemeral.

If Pod 1 dies, Kubernetes may create:

Pod 4

And Pod 4 can have a different IP.

So we need a stable way to communicate with Pods.

That's exactly what a Kubernetes Service provides.

1. The Problem with Pod IPs#

Suppose your backend has:

Pod 1 → 10.244.0.10
Pod 2 → 10.244.0.11
Pod 3 → 10.244.0.12

Your frontend wants to call the backend.

It could call:

10.244.0.10

But then Pod 1 dies:

Pod 1 ❌

Kubernetes creates a replacement:

Pod 4 → 10.244.0.20

Now:

10.244.0.10 ❌
10.244.0.20 ✅

Your frontend's old address is useless.

2. Kubernetes Service#

A Service provides a stable network endpoint for a set of Pods.

Instead of:

Frontend
   ↓
Pod 1

we use:

Frontend
   ↓
Service
   ↓
┌───────┬───────┬───────┐
Pod 1   Pod 2   Pod 3

The Service provides a stable IP/DNS name while the backend Pods can come and go.

3. Service's Main Jobs#

A Kubernetes Service primarily provides:

1. Stable endpoint#

Pods change, Service stays stable.

2. Service discovery#

Other applications can find the Service by DNS.

3. Traffic distribution#

Traffic can be sent to the selected backend Pods.

4. Simple Analogy#

Imagine a company.

Employees change:

Employee A
Employee B
Employee C

People don't want to remember each employee's personal phone number.

Instead, they call:

Customer Support

The company routes the call to an available employee.

Similarly:

Service
   ↓
Available Pods

5. Service Architecture#

Suppose:

Deployment
     ↓
3 Pods

Create:

Service

Now:

                 Service
                    │
          ┌─────────┼─────────┐
          ↓         ↓         ↓
        Pod 1     Pod 2     Pod 3

The Service uses labels/selectors to determine which Pods are its backends.

6. Labels Are Important Again#

Suppose your Pods have:

labels:
  app: node-api

Your Service can select them:

selector:
  app: node-api

So:

Service
selector:
  app=node-api
 
        ↓
 
Pod A
app=node-api    ✅
 
Pod B
app=node-api    ✅
 
Pod C
app=frontend    ❌

The Service sends traffic to the matching Pods.

7. Your First Service#

Let's use our Nginx Deployment from Chapter 6.

First check:

kubectl get pods

You should have something like:

nginx-deployment-xxx   Running
nginx-deployment-yyy   Running
nginx-deployment-zzz   Running

Now create:

apiVersion: v1
kind: Service
 
metadata:
  name: nginx-service
 
spec:
  selector:
    app: nginx
 
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Save:

service.yaml

Apply:

kubectl apply -f service.yaml

8. Check the Service#

Run:

kubectl get services

or:

kubectl get svc

You may see:

NAME            TYPE        CLUSTER-IP      PORT(S)
nginx-service   ClusterIP   10.96.100.10   80/TCP

The important thing is:

CLUSTER-IP

This is the Service's stable virtual IP.

9. Service IP vs Pod IP#

This distinction is very important.

Pods:

Pod 1 → 10.244.0.10
Pod 2 → 10.244.0.11
Pod 3 → 10.244.0.12

Service:

Service → 10.96.100.10

The Service IP is designed to provide a stable endpoint.

10. Service Types#

There are several Service types you'll encounter:

ClusterIP
NodePort
LoadBalancer
ExternalName

The three most important for beginners are:

ClusterIP
NodePort
LoadBalancer

Let's understand each.

11. ClusterIP#

ClusterIP is the default Service type.

Example:

spec:
  type: ClusterIP

or simply omit type.

It provides access inside the Kubernetes cluster.

Architecture:

Frontend Pod
      ↓
Backend Service
      ↓
Backend Pods

The backend isn't directly exposed to the public internet by a ClusterIP Service.

This is perfect for internal communication.

12. Real Example#

Suppose your application has:

Frontend
   ↓
Backend API
   ↓
PostgreSQL

You might use:

frontend-service
backend-service
database-service

Internal traffic:

Frontend Pod
     ↓
backend-service
     ↓
Backend Pods

The frontend doesn't need to know individual backend Pod IPs.

13. Service DNS#

This is one of the most useful Kubernetes features.

Suppose your Service is:

backend-service

A Pod in the same namespace can typically reach it using:

http://backend-service

For example, your Node.js application might call:

fetch("http://backend-service/users");

Kubernetes DNS resolves the Service name.

14. Fully Qualified Service DNS#

A Kubernetes Service can also be addressed using a DNS name like:

backend-service.production.svc.cluster.local

The general structure is:

<service>.<namespace>.svc.cluster.local

So:

backend-service

can be used within the appropriate namespace, while the fully qualified form identifies the namespace explicitly.

15. Why DNS Is Better Than IP#

Don't hardcode:

10.96.100.10

Instead:

backend-service

Why?

Because the Service IP can be abstracted behind a stable DNS name, and applications become easier to configure.

16. port vs targetPort#

This confuses many beginners.

Consider:

ports:
  - port: 80
    targetPort: 8080

What does it mean?

Client
  ↓
Service :80
  ↓
Pod :8080

port#

The port exposed by the Service.

targetPort#

The port on the selected Pod/container that receives the traffic.

17. Example With Node.js#

Suppose your Node.js application listens on:

3000

Your Service can be:

ports:
  - port: 80
    targetPort: 3000

Then:

Client
   ↓
Service:80
   ↓
Pod:3000

This is extremely common.

18. containerPort#

You may also have:

containers:
  - name: api
    image: my-api
    ports:
      - containerPort: 3000

Don't confuse this with:

Service:
  ports:
    - port: 80
      targetPort: 3000

Think:

Container
   ↓
containerPort = 3000
 
Service
   ↓
port = 80
targetPort = 3000

19. NodePort#

Now suppose you want to access your application from outside the cluster without using an external cloud load balancer.

You can use:

type: NodePort

Architecture:

External Client
      ↓
Node IP:NodePort
      ↓
Service
      ↓
Pods

Example:

apiVersion: v1
kind: Service
 
metadata:
  name: nginx-service
 
spec:
  type: NodePort
 
  selector:
    app: nginx
 
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080

Now:

Node IP:30080
      ↓
Service :80
      ↓
Pod :80

20. NodePort Range#

Kubernetes normally restricts NodePort values to a configured range, commonly:

30000–32767

So:

nodePort: 30080

is a typical example.

21. LoadBalancer#

In cloud environments, you can use:

type: LoadBalancer

The cloud provider can provision an external load-balancing mechanism.

Conceptually:

Internet
   ↓
Cloud Load Balancer
   ↓
Kubernetes Service
   ↓
Pods

For example:

AWS
 ↓
Load Balancer
 ↓
Kubernetes Service
 ↓
Pods

We'll explore EKS/GKE/AKS later.

22. ClusterIP vs NodePort vs LoadBalancer#

A typical production architecture might not expose every application with a LoadBalancer.

Often you use:

Internet
   ↓
Ingress / Gateway
   ↓
Service
   ↓
Pods

We'll study Ingress in Chapter 12.

23. How Does a Service Find Pods?#

Through labels and selectors.

Pods:

labels:
  app: backend

Service:

selector:
  app: backend

Kubernetes associates the Service with matching endpoints.

Conceptually:

Service
selector:
  app=backend
       ↓
┌──────┼──────┐
↓      ↓      ↓
Pod A  Pod B  Pod C

24. What if a Pod Dies?#

Suppose:

Service
   ↓
Pod A
Pod B
Pod C

Pod B dies.

Deployment creates:

Pod D

The Service can then route to the current matching Pods.

Service
   ↓
Pod A
Pod C
Pod D

This is the major advantage:

The Service remains stable while the backend Pods can change.

25. Service Discovery#

Suppose you have:

frontend-service
backend-service
database-service

A backend Pod can communicate with:

database-service

instead of:

10.244.1.25

Kubernetes DNS handles the name resolution.

This is called service discovery.

26. Real Application Architecture#

Now our application becomes:

                   Client
                     │
                     ↓
              ┌─────────────┐
              │   Service   │
              └──────┬──────┘
                     │
              ┌──────┼──────┐
              ↓      ↓      ↓
            Pod 1  Pod 2  Pod 3
              │      │      │
              └──────┼──────┘
                     ↓
                Node.js API

The client doesn't need to know which Pod is handling the request.

27. Service and Deployment Work Together#

This is a very important relationship:

Deployment
    ↓
ReplicaSet
    ↓
Pods

And:

Service
    ↓
Selects Pods

Together:

                 Deployment
                     ↓
               ┌─────┼─────┐
               ↓     ↓     ↓
             Pod 1  Pod 2  Pod 3
               ↑     ↑     ↑
               └─────┼─────┘
                     │
                  Service
                     ↑
                     │
                  Client

28. Practical Example — Node.js API#

Imagine:

Node.js listens on port 3000

Deployment:

apiVersion: apps/v1
kind: Deployment
 
metadata:
  name: node-api
 
spec:
  replicas: 3
 
  selector:
    matchLabels:
      app: node-api
 
  template:
    metadata:
      labels:
        app: node-api
 
    spec:
      containers:
        - name: node-api
          image: mycompany/node-api:v1
          ports:
            - containerPort: 3000

Service:

apiVersion: v1
kind: Service
 
metadata:
  name: node-api-service
 
spec:
  selector:
    app: node-api
 
  ports:
    - port: 80
      targetPort: 3000
 
  type: ClusterIP

Now:

Frontend
    ↓
node-api-service:80
    ↓
┌──────────┬──────────┬──────────┐
Pod 1      Pod 2      Pod 3
:3000      :3000      :3000

29. Test the Service Locally#

If you're using a local cluster, you can inspect:

kubectl get svc

For a ClusterIP Service, you can test it from inside the cluster.

For example, create a temporary Pod:

kubectl run curl --image=curlimages/curl -it --rm -- sh

Then inside:

curl http://nginx-service

You should get the Nginx response.

This demonstrates:

Temporary Pod
     ↓
nginx-service
     ↓
Nginx Pods

30. EndpointSlices#

Here's a modern Kubernetes concept worth knowing.

A Service doesn't simply contain a static list of Pod IPs.

Kubernetes maintains EndpointSlices to represent the network endpoints associated with Services.

Conceptually:

Service
   ↓
EndpointSlice
   ↓
Pod IPs / endpoints

You can inspect them:

kubectl get endpointslices

You don't need to manage EndpointSlices manually in normal application development.

31. What Happens When a Pod Becomes Unready?#

Suppose:

Pod A → Ready
Pod B → Ready
Pod C → Not Ready

A properly configured Kubernetes Service should not send normal traffic to an endpoint that is considered not ready.

This becomes especially important with readiness probes.

We'll study readiness probes later.

32. Service vs Ingress#

This is a common interview question.

Service#

Provides stable access to a set of Pods.

Service
 ↓
Pods

Ingress#

Provides HTTP/HTTPS routing from outside the cluster to Services.

Internet
   ↓
Ingress
   ↓
Service
   ↓
Pods

We'll study Ingress in Chapter 12.

33. Service vs Load Balancer#

Another common confusion.

A Service of type:

LoadBalancer

can integrate with cloud infrastructure to expose a Service externally.

But a Service itself is not the same thing as every possible external load balancer architecture.

In production, you might have:

Internet
   ↓
Cloud Load Balancer
   ↓
Ingress Controller
   ↓
Service
   ↓
Pods

or other architectures depending on the platform.

34. Practical Exercise#

Let's expose our Nginx Deployment internally.

Step 1 — Check Pods#

kubectl get pods

You should see:

nginx-deployment-xxx
nginx-deployment-yyy
nginx-deployment-zzz

Step 2 — Create Service#

apiVersion: v1
kind: Service
 
metadata:
  name: nginx-service
 
spec:
  selector:
    app: nginx
 
  ports:
    - port: 80
      targetPort: 80

Apply:

kubectl apply -f service.yaml

Step 3 — Check#

kubectl get svc

Step 4 — Check the selected endpoints#

Depending on your Kubernetes version:

kubectl get endpoints nginx-service

or preferably inspect EndpointSlices:

kubectl get endpointslices

You should see endpoints corresponding to your Nginx Pods.

35. Test the Self-Healing + Service Combination#

This is a great experiment.

Initially:

Service
  ↓
Pod A
Pod B
Pod C

Delete Pod A:

kubectl delete pod <pod-name>

Then:

kubectl get pods

A replacement appears:

Pod B
Pod C
Pod D

The Service continues selecting the Pods with:

app=nginx

So the client doesn't need to know about the Pod replacement.

This is exactly why Deployment + Service is such a fundamental Kubernetes combination.

36. The Complete Picture So Far#

You now have:

                         Internet
                            │
                            ↓
                         Service
                            │
                 ┌──────────┼──────────┐
                 ↓          ↓          ↓
               Pod 1      Pod 2      Pod 3
                 │          │          │
                 └──────────┼──────────┘
                            ↑
                        Deployment
                            │
                        ReplicaSet

Later we'll add:

Internet
   ↓
Load Balancer
   ↓
Ingress
   ↓
Service
   ↓
Deployment
   ↓
Pods

🧠 Chapter 7 Cheat Sheet#

Remember this:#

Pod IP
   ↓
Can change
 
Service IP/DNS
   ↓
Stable endpoint

🎯 Interview Questions#

Q1. Why do we need a Service?#

Pods are ephemeral and their IP addresses can change. A Service provides a stable network endpoint and routes traffic to matching Pods.

Q2. What is ClusterIP?#

The default Service type that provides internal cluster access.

Q3. What is NodePort?#

It exposes a Service through a port on each node.

Q4. What is LoadBalancer?#

A Service type commonly used with cloud-provider integrations to expose a Service externally through load-balancing infrastructure.

Q5. How does a Service find Pods?#

Through label selectors.

Q6. What is the difference between port and targetPort?#

Service port → port
Pod/container port → targetPort

Example:

port: 80
targetPort: 3000

means:

Client
 ↓
Service :80
 ↓
Pod :3000

Q7. Can a Service survive when Pods are replaced?#

Yes. That's one of its main purposes.

⭐ The Most Important Mental Model#

At this point, you should think:

                 Deployment
                     ↓
                ReplicaSet
                     ↓
             ┌───────┼───────┐
             ↓       ↓       ↓
            Pod     Pod     Pod
             ↑       ↑       ↑
             └───────┼───────┘
                     │
                  Service
                     │
                     ↓
                  Client

Deployment manages the Pods.

Service provides stable access to the Pods.

That's the foundation of most Kubernetes applications.

🚀 Next — Chapter 8: Namespaces#

We'll learn how to organize a Kubernetes cluster into environments such as:

Cluster
│
├── development
├── staging
└── production

You'll learn:

• What namespaces are
• Why they're needed
• default namespace
• kube-system
• Creating namespaces
• Deploying into a namespace
• Resource isolation
• Namespace-specific Services
• Cross-namespace communication
• kubectl -n
• Namespace best practices
• How companies structure multi-environment Kubernetes clusters