Day 6: Kubernetes Networking in Amazon EKS
As part of my AWS DevOps Community Builders learning journey, Day 6 focused on understanding Kubernetes Networking in Amazon EKS and how application traffic flows inside and outside a Kubernetes cluster.
Today’s main focus was:
ClusterIP → NodePort → LoadBalancer → Ingress → AWS Load Balancer → EKS Pods
Understanding Kubernetes networking is important because applications running on EKS need reliable, scalable, and secure communication between Pods, Services, external users, and AWS resources.
## What I Learned
- Kubernetes networking fundamentals
- Pod networking
- Pod-to-Pod communication
- Kubernetes Services
- ClusterIP
- NodePort
- LoadBalancer
- Headless Services
- Kubernetes DNS
- Ingress
- AWS Load Balancer Controller
- Application Load Balancer (ALB)
- Network Load Balancer (NLB)
- EKS VPC networking
- Security Groups
- Private and public subnets
- End-to-end traffic flow
## 1. Kubernetes Networking Basics
Every application running on Kubernetes depends on networking.
A typical application might contain:
Frontend
↓
Backend
↓
Database
In Kubernetes, these components may run as different Pods.
The challenge is that Pods are dynamic.
A Pod can be:
- Created
- Deleted
- Restarted
- Rescheduled
- Moved to another node
Because of this, directly depending on Pod IP addresses is not a reliable application architecture.
Kubernetes Services solve this problem by providing stable networking endpoints.
The basic concept is:
Pod
↓
Service
↓
Application
## 2. Pod-to-Pod Communication
Pods need to communicate with each other.
For example:
Frontend Pod
↓
Backend Service
↓
Backend Pods
In Amazon EKS, Kubernetes networking integrates with AWS VPC networking.
This allows Pods and AWS resources to communicate through the AWS networking infrastructure, depending on the EKS networking configuration.
A simplified view is:
EKS
↓
VPC
↓
Subnets
↓
Nodes
↓
Pods
## 3. Kubernetes Service
A Kubernetes Service provides a stable networking endpoint for a group of Pods.
For example:
Pod 1
Pod 2
Pod 3
↓
Backend Service
Even if one Pod is deleted and another Pod is created, the Service remains available.
This gives applications a stable way to communicate with workloads.
## 4. ClusterIP
ClusterIP is the default Kubernetes Service type.
It provides internal connectivity within the cluster.
Example:
Frontend Pod
↓
Backend ClusterIP Service
↓
Backend Pod 1
Backend Pod 2
Backend Pod 3
Example Service:
apiVersion: v1
kind: Service
metadata:
name: backend-service
spec:
selector:
app: backend
ports:
— port: 80
targetPort: 8080
type: ClusterIP
ClusterIP is commonly used for internal application communication.
For example:
Frontend → Backend
or:
Backend → Internal API
## 5. NodePort
NodePort exposes a Kubernetes Service through a port on each Kubernetes node.
The traffic flow is:
Client
↓
Node IP : NodePort
↓
Kubernetes Service
↓
Pods
Example:
apiVersion: v1
kind: Service
metadata:
name: backend-service
spec:
selector:
app: backend
ports:
— port: 80
targetPort: 8080
nodePort: 30080
type: NodePort
NodePort is useful for understanding Kubernetes networking and can be part of certain architectures, although production EKS applications commonly use AWS load balancing and Ingress for external HTTP/HTTPS traffic.
## 6. LoadBalancer Service
The LoadBalancer Service type can integrate Kubernetes Services with AWS load balancing.
The simplified flow is:
Internet
↓
AWS Load Balancer
↓
Kubernetes Service
↓
Pods
Example:
apiVersion: v1
kind: Service
metadata:
name: backend-service
spec:
selector:
app: backend
ports:
— port: 80
targetPort: 8080
type: LoadBalancer
The exact AWS load balancer behavior depends on the EKS configuration and AWS load balancing components being used.
## 7. Headless Service
A Headless Service is created by setting:
clusterIP: None
Example:
apiVersion: v1
kind: Service
metadata:
name: mysql
spec:
clusterIP: None
selector:
app: mysql
ports:
— port: 3306
A Headless Service does not provide a normal ClusterIP.
Instead, DNS can provide the addresses of the Pods behind the Service.
This is particularly useful for stateful workloads and StatefulSets where applications may need direct Pod discovery.
## 8. Kubernetes DNS
Kubernetes provides built-in DNS-based service discovery.
For example:
backend-service.default.svc.cluster.local
Applications can use Service names instead of directly using Pod IP addresses.
Example:
Frontend
↓
backend-service
↓
Backend Pods
This makes application communication more reliable because the Service remains stable even when individual Pods change.
## 9. Kubernetes Ingress
Ingress provides HTTP and HTTPS routing rules for applications.
For example:
example.com/
↓
Frontend Service
example.com/api
↓
Backend Service
A simplified architecture is:
User
↓
Load Balancer
↓
Ingress
↓
+ — — — — — — — — — -+
| |
↓ ↓
Frontend Service Backend Service
↓ ↓
Frontend Pods Backend Pods
Ingress allows multiple application routes to be managed through a common entry point.
## 10. AWS Load Balancer Controller
The AWS Load Balancer Controller allows Kubernetes resources to integrate with AWS load balancing services.
For example, Kubernetes Ingress can be used with the AWS Load Balancer Controller to provision and configure an Application Load Balancer.
The architecture becomes:
Internet
↓
Application Load Balancer
↓
Kubernetes Ingress
↓
Kubernetes Service
↓
EKS Pods
This is an important pattern for exposing web applications running on Amazon EKS.
## 11. Application Load Balancer
An Application Load Balancer, or ALB, is designed for application-level HTTP and HTTPS traffic.
It can route requests using host-based or path-based rules.
For example:
api.example.com
↓
Backend Service
app.example.com
↓
Frontend Service
Or:
example.com/api
↓
Backend Service
Get Kashif Syed’s stories in your inbox
Join Medium for free to get updates from this writer.
example.com/
↓
Frontend Service
A typical flow is:
User
↓
Route 53
↓
ALB
↓
Ingress
↓
Service
↓
Pods
## 12. Network Load Balancer
A Network Load Balancer, or NLB, is designed for high-performance network traffic such as TCP, UDP, and TLS use cases.
A simplified flow is:
Internet
↓
NLB
↓
Kubernetes Service
↓
Pods
ALB and NLB are designed for different networking requirements, so the appropriate choice depends on the application architecture and traffic requirements.
## 13. EKS VPC Networking
Amazon EKS runs within an AWS VPC.
A simplified architecture is:
AWS VPC
|
+ — Public Subnets
| |
| + — Application Load Balancer
|
+ — Private Subnets
|
+ — EKS Nodes
| |
| + — Application Pods
|
+ — Amazon RDS
A common production architecture keeps the application and database layers in private subnets while using controlled public entry points such as an ALB.
## 14. Public vs Private Subnets
Public subnets can contain resources that need controlled internet-facing connectivity.
Private subnets are commonly used for internal workloads such as:
- EKS worker nodes
- Application Pods
- Databases
- Internal services
A common production pattern is:
Internet
↓
Public ALB
↓
Private EKS Pods
↓
Private RDS
This helps reduce the public attack surface.
## 15. Security Groups
Networking also requires security controls.
Important security components include:
- AWS Security Groups
- Kubernetes Network Policies
- Ingress rules
- VPC routing
- Private subnets
- IAM permissions
- Database security groups
A simplified security flow is:
Internet
↓
ALB Security Group
↓
EKS Networking
↓
Application Pods
↓
RDS Security Group
↓
Amazon RDS
The goal is to allow only the traffic that is required.
## 16. End-to-End Application Traffic
A typical production EKS application can have this traffic flow:
User
↓
Route 53 / DNS
↓
Application Load Balancer
↓
Kubernetes Ingress
↓
Kubernetes Service
↓
EKS Pods
↓
Application
If the application communicates with a database:
User
↓
Route 53
↓
ALB
↓
Ingress
↓
Service
↓
Application Pods
↓
Amazon RDS
The database can remain inside private subnets and should not be directly exposed to the internet.
## 17. Complete EKS Networking Architecture
A simplified production architecture:
INTERNET
|
↓
Route 53
|
↓
Application Load Balancer
|
↓
Kubernetes Ingress
|
↓
Kubernetes Service
|
+ — — — — — + — — — — — +
| |
↓ ↓
EKS Pod EKS Pod
| |
+ — — — — — + — — — — — +
|
↓
Application
|
↓
Amazon RDS
AWS infrastructure:
AWS VPC
|
+ — Public Subnets
| |
| + — ALB
|
+ — Private Subnets
|
+ — EKS Nodes
| |
| + — Application Pods
|
+ — RDS
## 18. Comparing Kubernetes Service Types
ClusterIP:
Used for internal communication inside the cluster.
NodePort:
Exposes a Service through a port on Kubernetes nodes.
LoadBalancer:
Provides external load balancing integration.
Headless Service:
Provides direct Pod discovery and is commonly useful for stateful applications.
Simple comparison:
ClusterIP → Internal access
NodePort → Node-level access
LoadBalancer → External load balancer
Headless → Direct Pod discovery
## 19. Why Services Matter
Imagine an application has three Pods:
Pod 1 → 10.0.1.10
Pod 2 → 10.0.2.15
Pod 3 → 10.0.3.20
These Pod IP addresses can change.
Instead of connecting directly to the Pods, an application connects to:
backend-service
The Service then routes traffic to the available Backend Pods.
This provides:
- Stable networking
- Service discovery
- Load distribution
- Decoupling between applications and Pods
## 20. Troubleshooting Networking
Understanding the traffic flow also helps with troubleshooting.
When an application cannot be reached, I can check the path step by step:
User
↓
DNS
↓
Load Balancer
↓
Ingress
↓
Service
↓
Endpoints
↓
Pods
↓
Application
Useful Kubernetes commands include:
kubectl get pods
kubectl get svc
kubectl get ingress
kubectl get endpoints
kubectl describe service <service-name>
kubectl describe ingress <ingress-name>
kubectl logs <pod-name>
These commands help identify where the networking problem is occurring.
## Key Takeaway
The biggest lesson from Day 6 is:
Pods are dynamic, but Kubernetes Services provide stable networking and service discovery.
Ingress and AWS Load Balancers provide controlled access to applications from outside the cluster.
The complete application flow can be summarized as:
User
↓
DNS
↓
ALB / NLB
↓
Ingress
↓
Kubernetes Service
↓
EKS Pods
↓
Application
↓
Amazon RDS
Understanding this traffic flow is essential when designing, securing, and troubleshooting production EKS environments.
## Connecting Day 5 and Day 6
Day 5 focused on application delivery:
Docker
↓
Amazon ECR
↓
Amazon EKS
↓
Kubernetes Pods
Day 6 focuses on networking:
Kubernetes Pods
↓
Services
↓
Ingress
↓
AWS Load Balancer
↓
Users
Together, these concepts connect the application deployment layer with the networking layer.
## My Day 6 Takeaway
Today I learned that Kubernetes networking is much more than simply connecting Pods.
It involves:
- Pod networking
- Service discovery
- DNS
- Load balancing
- Ingress
- AWS VPC networking
- Security Groups
- Network isolation
- External traffic routing
- Internal application communication
The goal is to build networking that is secure, scalable, reliable, and easy to troubleshoot.
## What’s Next?
Day 7: EKS Stateful vs Stateless
Topics:
- Stateless Applications
- Stateful Applications
- Deployment
- StatefulSet
- PersistentVolume
- PersistentVolumeClaim
- AWS EBS
- Headless Service
- MySQL on EKS
- MySQL on Amazon RDS
- EKS + RDS Architecture
The journey continues:
Learn → Build → Secure → Automate → Deploy → Improve
#AWS #AWSCommunityBuilders #DevOps #AmazonEKS #Kubernetes #KubernetesNetworking #Ingress #ALB #NLB #AWSVPC #CloudComputing #DevOpsJourney #LearningInPublic
