Lesson 06 — Services & Networking

Learning Objectives

By the end of this lesson, you will be able to:

Understand Kubernetes networking fundamentals
Explain how Pods communicate
Understand the purpose of Kubernetes Services
Differentiate between Service types
Learn how traffic flows inside a Kubernetes cluster
Identify networking security risks
Apply enterprise networking best practices

Why This Matters

Applications rarely consist of a single container.

Modern enterprise applications are built using dozens—or even hundreds—of microservices that must communicate securely and reliably.

For example:

Web applications communicate with APIs.
APIs communicate with databases.
Authentication services communicate with identity providers.
Payment services communicate with external gateways.

Kubernetes networking enables these services to communicate while maintaining scalability, reliability, and security.

Understanding Kubernetes networking is essential before learning Network Policies and Zero Trust networking in later modules.

Kubernetes Networking Principles

Kubernetes networking is based on four key principles:

Every Pod receives its own IP address.
Pods can communicate with each other without Network Address Translation (NAT).
Nodes can communicate with all Pods.
Applications communicate using Services rather than Pod IP addresses.

These principles simplify application deployment and scaling.

High-Level Networking Architecture

                Internet
                    │
                    ▼
          Load Balancer / Ingress
                    │
                    ▼
              Kubernetes Service
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
       Pod A              Pod B
          │                   │
          └─────────┬─────────┘
                    ▼
                Database

Traffic flows through Services before reaching application Pods.

Pod Networking

Every Pod receives:

Its own IP address
A hostname
Network namespace
Shared networking within the Pod

Example:

Worker Node

│

├── Pod A (10.0.1.10)

├── Pod B (10.0.1.11)

└── Pod C (10.0.1.12)

Pods communicate directly using their IP addresses.

However, Pod IPs are temporary.

Why Pod IP Addresses Cannot Be Trusted

Pods are ephemeral.

When a Pod is deleted or recreated, its IP address changes.

Example:

Old Pod

10.0.1.15

↓

Pod Deleted

↓

New Pod

10.0.2.34

Applications should never depend directly on Pod IP addresses.

This is why Kubernetes Services exist.

What is a Kubernetes Service?

A Service provides a stable network endpoint for accessing one or more Pods.

Instead of connecting directly to a Pod, applications communicate through a Service.

Benefits include:

Stable IP address
DNS name
Load balancing
Automatic discovery
High availability

Service Architecture

Application

↓

Service

↓

Pod 1

Pod 2

Pod 3

Even if Pods are replaced, the Service remains unchanged.

Types of Kubernetes Services

Kubernetes provides four primary Service types.

Service Type	Purpose
ClusterIP	Internal communication within the cluster
NodePort	Exposes applications through Worker Node ports
LoadBalancer	Integrates with cloud load balancers
ExternalName	Maps a Service to an external DNS name

Each type serves different networking requirements.

ClusterIP

ClusterIP is the default Service type.

It allows applications inside the cluster to communicate securely.

Example:

Frontend

↓

ClusterIP Service

↓

Backend API

ClusterIP is not accessible from the internet.

NodePort

NodePort exposes an application using a port on every Worker Node.

Example:

Internet

↓

Worker Node

Port 30080

↓

Application

NodePort is commonly used in development environments but is less common in enterprise production due to security considerations.

LoadBalancer

In cloud environments such as Amazon EKS, Azure AKS, or Google GKE, a LoadBalancer Service provisions a cloud-native load balancer automatically.

Internet

↓

AWS Load Balancer

↓

Kubernetes Service

↓

Pods

This is the preferred approach for exposing production applications.

ExternalName

ExternalName allows Kubernetes Services to reference external resources.

Example:

Application

↓

ExternalName Service

↓

database.company.com

No proxying occurs; Kubernetes returns the external DNS name.

Kubernetes DNS

Every Service automatically receives a DNS name.

Example:

payment-service.default.svc.cluster.local

Applications communicate using DNS rather than IP addresses.

Benefits include:

Stable communication
Easier application configuration
Automatic service discovery

kube-proxy

Every Worker Node runs kube-proxy.

Responsibilities include:

Routing traffic
Load balancing requests
Managing Service rules
Updating networking tables
Forwarding requests to healthy Pods

kube-proxy ensures that traffic reaches the correct application.

Container Network Interface (CNI)

The Container Network Interface (CNI) provides networking for Pods.

Popular CNI implementations include:

Amazon VPC CNI
Calico
Cilium
Flannel
Weave Net

In Amazon EKS, the default option is the Amazon VPC CNI plugin.

How Traffic Flows Through Kubernetes

User

↓

Internet

↓

Load Balancer

↓

Service

↓

kube-proxy

↓

Pod

↓

Application

↓

Response

Each component contributes to delivering traffic securely and efficiently.

Internal vs External Communication

Internal communication:

Pod

↓

ClusterIP Service

↓

Pod

External communication:

Internet

↓

Load Balancer

↓

Service

↓

Application

Separating internal and external traffic improves security.

Enterprise Example

A banking application consists of:

Web Frontend
Authentication API
Payments API
Fraud Detection Service
Customer Database

Communication occurs as follows:

Customer

↓

Load Balancer

↓

Frontend Service

↓

Authentication Service

↓

Payment Service

↓

Database

Each component communicates through Kubernetes Services rather than directly to individual Pods.

Common Networking Security Risks

Cloud Security Engineers frequently encounter:

Publicly exposed Services
Unrestricted NodePorts
Missing Network Policies
Weak DNS controls
Insecure Ingress configurations
Excessive east-west traffic
Open cloud Security Groups
Misconfigured load balancers
Exposed internal APIs
Lack of TLS encryption

These issues increase the cluster’s attack surface.

Enterprise Networking Best Practices

Security engineers should:

Use ClusterIP for internal applications.
Use LoadBalancer only when external access is required.
Avoid unnecessary NodePort Services.
Encrypt traffic with TLS.
Implement Network Policies.
Restrict ingress and egress traffic.
Use DNS instead of Pod IP addresses.
Enable logging and monitoring.
Secure cloud load balancers.
Apply Zero Trust networking principles.

These practices reduce the likelihood of unauthorised access.

Enterprise Monitoring

Security teams should monitor:

Service creation
Service deletion
Load Balancer changes
DNS failures
Network latency
Unusual east-west traffic
NodePort usage
Failed connections
Traffic spikes
External exposure of internal services

Monitoring provides visibility into networking behaviour and potential threats.

Real-World Example

An attacker scans an organisation’s public IP addresses and discovers a NodePort Service exposing an internal administration application.

Because authentication is weak, the attacker gains access to the application and moves laterally through the Kubernetes environment.

If the organisation had:

Used a ClusterIP Service
Restricted external exposure
Implemented an Ingress Controller with authentication
Applied Network Policies

the attack surface would have been significantly reduced.

Best Practices Summary

As a Kubernetes Security Engineer:

Use Services instead of Pod IP addresses.
Prefer ClusterIP for internal communication.
Expose applications using secure Load Balancers.
Limit NodePort usage.
Protect DNS infrastructure.
Enable TLS for all application traffic.
Implement Network Policies.
Monitor network traffic continuously.
Review exposed Services regularly.
Follow Zero Trust networking principles.

Secure networking is a foundational component of every production Kubernetes environment.

Key Takeaways

After completing this lesson, you should understand:

How Kubernetes networking works
Why Services are required
The four Kubernetes Service types
How Pods communicate
The role of kube-proxy
The importance of DNS and service discovery
Enterprise networking best practices
Common networking security risks

These concepts prepare you for implementing secure communication between workloads before moving on to Namespaces and network segmentation.

Knowledge Check

Question 1

Why should applications avoid communicating directly with Pod IP addresses?

A. Pod IP addresses are encrypted
B. Pod IP addresses change when Pods are recreated
C. Pods cannot communicate over IP
D. Services do not support IP addresses

Answer: B

Question 2

Which Kubernetes Service type is used for internal cluster communication?

A. LoadBalancer
B. NodePort
C. ClusterIP
D. ExternalName

Answer: C

Question 3

Which Service type automatically provisions a cloud load balancer in Amazon EKS?

A. ClusterIP
B. ExternalName
C. NodePort
D. LoadBalancer

Answer: D

Question 4

Which component is responsible for routing Service traffic on Worker Nodes?

A. kubelet
B. Scheduler
C. kube-proxy
D. etcd

Answer: C

Question 5

Which networking practice best reduces the attack surface of internal applications?

A. Expose all applications using NodePort
B. Use ClusterIP for internal services
C. Disable DNS
D. Assign static Pod IP addresses

Answer: B

What’s Next?

In the next lesson, you will explore Kubernetes Namespaces, learning how organisations logically separate workloads, implement multi-tenancy, enforce access controls, and prepare clusters for secure enterprise operations.

➡️ Next Lesson: Lesson 07 — Namespaces