Service Networking — Stable Communication Between Kubernetes Applications¶

Service Networking is the Kubernetes networking model that provides stable, reliable, and discoverable access to Pods. Since Pods are ephemeral and their IP addresses change whenever they are recreated, Kubernetes introduces Services as stable network endpoints that automatically route traffic to healthy Pods. Services enable communication between applications inside and outside the cluster while providing load balancing, service discovery, and high availability. Every Kubernetes Administrator, DevOps Engineer, Platform Engineer, Site Reliability Engineer (SRE), Cloud Architect, and Network Engineer should understand Kubernetes Service Networking.

Learning Path¶

Networking Mastery → Module 11: Kubernetes Networking → Lesson 3

Difficulty: Advanced

Reading Time: 210 Minutes

Course Progress

Course: Networking Mastery

Module: Kubernetes Networking

Lesson: 3 of 9

What You'll Learn¶

After completing this lesson, you'll be able to:

Understand Kubernetes Services
Learn Service Discovery
Configure ClusterIP, NodePort, LoadBalancer, and ExternalName Services
Understand Service Load Balancing
Learn kube-proxy's role
Explore Endpoint and EndpointSlice resources
Troubleshoot Service networking

Prerequisites¶

Complete:

CNI
Pod Networking
Kubernetes Fundamentals
DNS Fundamentals

Basic understanding of:

IP Routing
TCP/IP
Linux Networking

Why Do We Need Services?¶

Imagine a Deployment running three Pods.

Frontend

↓

Pod 1

10.244.1.5

Pod 2

10.244.2.8

Pod 3

10.244.3.4

If Pod 2 crashes:

Deleted

↓

New Pod

↓

10.244.5.10

The application cannot rely on changing Pod IPs.

Kubernetes solves this using:

Service

What is a Kubernetes Service?¶

A Service is:

A

Stable

Virtual

Network

Endpoint

that automatically forwards traffic to healthy Pods.

Applications connect to:

Service

↓

Pods

instead of individual Pod IP addresses.

Kubernetes Service Model¶

Client

↓

Service

↓

Pod A

↓

Pod B

↓

Pod C

The Service automatically distributes requests across available Pods.

Service Components¶

A Service consists of:

Service IP (ClusterIP)
Domain Name System (DNS) Name
Selector
Endpoints
EndpointSlices
kube-proxy Rules

Service Discovery¶

Every Service automatically receives:

Stable DNS Name
Stable Virtual IP

Example:

frontend.default.svc.cluster.local

Applications communicate using the DNS name rather than Pod IPs.

ClusterIP Service¶

Default Service type.

Accessible only inside the cluster.

Architecture:

Application

↓

ClusterIP

↓

Pods

Example use cases:

Backend APIs
Databases
Internal Microservices

NodePort Service¶

Exposes a Service through a port on every Kubernetes node.

Architecture:

Client

↓

NodeIP:30080

↓

Service

↓

Pods

Useful for:

Testing
Development
Simple External Access

LoadBalancer Service¶

Used in cloud environments.

Architecture:

Internet

↓

Cloud Load Balancer

↓

Service

↓

Pods

Supported by:

Amazon EKS
Azure AKS
Google GKE

Cloud providers automatically provision an external load balancer.

ExternalName Service¶

Maps a Kubernetes Service to an external DNS name.

Example:

database

↓

db.company.com

No proxying occurs.

Kubernetes returns a DNS CNAME record.

Useful for:

External Databases
Software as a Service (SaaS) APIs
Legacy Applications

Service Selectors¶

Services identify Pods using labels.

Example:

Pods:

labels:
  app: nginx

Service:

selector:
  app: nginx

Only matching Pods receive traffic.

Endpoints¶

Endpoints represent the actual Pod IPs behind a Service.

Example:

Service

↓

10.244.1.5

↓

10.244.2.8

↓

10.244.3.4

Kubernetes updates Endpoints automatically as Pods are added or removed.

EndpointSlices¶

Modern Kubernetes uses:

EndpointSlice

instead of one large Endpoints object.

Benefits:

Better Scalability
Lower API Load
Faster Updates

Especially useful for Services with hundreds or thousands of Pods.

kube-proxy¶

kube-proxy implements Service networking.

Responsibilities:

Service Routing
Load Balancing
Packet Forwarding
Network Rules

It typically uses:

iptables
IPVS
nftables (depending on Kubernetes version and configuration)

Traffic Flow¶

Client

↓

Service IP

↓

kube-proxy

↓

Selected Pod

Applications never communicate directly with Service rules.

kube-proxy transparently forwards traffic.

Internal Service Communication¶

Example:

Frontend

↓

frontend-service

↓

Backend

↓

backend-service

↓

Database

↓

database-service

Every application communicates using Service names.

External Client Access¶

Internet

↓

LoadBalancer

↓

ClusterIP

↓

Pods

The cloud load balancer forwards traffic to the Kubernetes Service.

Session Affinity¶

By default:

Client

↓

Any Healthy Pod

Optionally:

Client

↓

Same Pod

using:

sessionAffinity: ClientIP

Useful for stateful applications.

Headless Services¶

Headless Services have:

clusterIP: None

DNS returns:

Pod IPs

instead of a virtual Service IP.

Common use cases:

StatefulSets
Databases
Distributed Systems
Kafka
Cassandra

Service Types¶

Service Type	Purpose
ClusterIP	Internal Communication
NodePort	External Access via Node
LoadBalancer	Cloud External Access
ExternalName	External DNS Mapping
Headless	Direct Pod Discovery

Cloud Provider Perspective¶

Amazon EKS¶

LoadBalancer Services create:

AWS Network Load Balancer (NLB) or Application Load Balancer (via AWS Load Balancer Controller)
Elastic IPs (where applicable)

Azure AKS¶

LoadBalancer Services create:

Azure Load Balancer

Integrated with Azure networking.

Google GKE¶

LoadBalancer Services create:

Google Cloud Load Balancer

Integrated with Google Cloud networking.

Enterprise Architecture¶

Internet

↓

Cloud Load Balancer

↓

Ingress

↓

Frontend Service

↓

Frontend Pods

↓

Backend Service

↓

Backend Pods

↓

Database Service

↓

Database Pods

Every communication path uses Services rather than Pod IPs.

CLI Examples¶

List Services.

kubectl get svc

Describe a Service.

kubectl describe svc frontend

List Endpoints.

kubectl get endpoints

List EndpointSlices.

kubectl get endpointslices

Display Service YAML.

kubectl get svc frontend -o yaml

Common Service Components¶

Component	Purpose
ClusterIP	Stable Internal IP
Selector	Pod Matching
Endpoint	Pod Address
EndpointSlice	Scalable Endpoint Management
kube-proxy	Traffic Forwarding
DNS	Service Discovery

Hands-on Lab¶

Task 1¶

List Services.

kubectl get svc

Task 2¶

Describe a Service.

kubectl describe svc nginx

Task 3¶

Display Endpoints.

kubectl get endpoints

Task 4¶

Display EndpointSlices.

kubectl get endpointslices

Task 5¶

Create:

Deployment
ClusterIP Service

Verify communication between Pods.

Task 6¶

Create a NodePort Service and access the application using:

NodeIP:NodePort

Task 7¶

Deploy a LoadBalancer Service in a cloud Kubernetes cluster and verify external access.

Task 8¶

Draw a Kubernetes Service networking architecture showing:

Client
LoadBalancer
ClusterIP
kube-proxy
Service
EndpointSlice
Pods

Explain how a request reaches a backend Pod.

Production Troubleshooting¶

Problem:

Application

Cannot

Reach

Service

Check:

Service Selector
Pod Labels
Endpoint Availability
EndpointSlices
kube-proxy Status
DNS Resolution
Network Policies

Workflow:

Application

↓

DNS

↓

Service

↓

Endpoint

↓

Pod

Service vs Pod¶

Pod	Service
Temporary IP	Stable IP
Can Be Recreated	Persistent Endpoint
Not Discoverable	DNS Discoverable
Single Workload	Multiple Pods
Dynamic	Stable

Common Mistakes¶

❌ Accessing Pods directly.

✅ Access workloads through Services.

❌ Incorrect label selectors.

✅ Verify that Service selectors match Pod labels.

❌ Assuming Service creates Pods.

✅ Deploy Pods or Deployments separately.

❌ Ignoring Endpoint health.

✅ Check Endpoints and EndpointSlices during troubleshooting.

❌ Exposing every Service externally.

✅ Use ClusterIP for internal communication whenever possible.

Best Practices¶

Use ClusterIP for internal services.
Use LoadBalancer for cloud-based external access.
Use Ingress to expose multiple HTTP/HTTPS applications.
Use meaningful labels and selectors.
Monitor Service health and Endpoint updates.
Avoid direct Pod communication in production.
Prefer EndpointSlices for large-scale deployments.
Implement Network Policies to secure Service traffic.

Interview Questions¶

Beginner¶

What is a Kubernetes Service?
Why do Pods need Services?
What is ClusterIP?
What is NodePort?

Intermediate¶

Compare ClusterIP, NodePort, and LoadBalancer.
What is an EndpointSlice?
How does kube-proxy route traffic?
What is a Headless Service?

Architect Level¶

Design Service networking for a large microservices platform.
Explain how Service discovery works in Kubernetes.
How would you troubleshoot a Service that has no available Endpoints?

Summary¶

In this lesson, you learned:

Kubernetes Services
Service Discovery
ClusterIP
NodePort
LoadBalancer
ExternalName
Headless Services
Endpoints
EndpointSlices
kube-proxy

Service networking provides stable communication in Kubernetes by abstracting dynamic Pods behind consistent virtual IP addresses and DNS names. Services automatically discover healthy Pods, distribute traffic, and integrate with cloud load balancers, enabling scalable and resilient application architectures.

Key Takeaways¶

Services provide stable networking for dynamic Pods.
ClusterIP is the default Service type for internal communication.
NodePort exposes applications through node ports.
LoadBalancer integrates Kubernetes with cloud load balancers.
EndpointSlices improve scalability for large clusters.
kube-proxy implements Service networking by forwarding traffic to healthy Pods.
Applications should communicate using Service DNS names, not Pod IP addresses.

What's Next?¶

Ingress

In the next lesson, you'll learn about Ingress.

You'll explore:

What Ingress is
Ingress Controllers
HTTP and HTTPS Routing
Host-Based Routing
Path-Based Routing
TLS Termination
Production Ingress Architectures

By the end of the lesson, you'll understand how Kubernetes exposes multiple web applications through a single entry point with advanced routing, security, and traffic management capabilities.