Ingress vs. Service
Service (L4 Perspective) #
A Service is a stable network endpoint placed in front of a set of Pods.
Since Pods' IPs change when they die and restart, a Service is needed to abstract this.
Key Roles
- Hides Pod IP changes
- Load balancing (L4 TCP UDP)
- Service discovery (provides DNS names)
Meaning by Service Type
- ClusterIP: Internal cluster-only access, default
- NodePort: External access possible via a fixed port on each node, but not typically used in practice for security/operational reasons
- LoadBalancer: Cloud Provider L4, creates an LB, e.g., AWS NLB, GCP TCP LB
How it works internally
kube-proxymonitors Services.- Creates iptables or IPVS rules
- Forwards L4 traffic from Service IP -> Pod IP
In essence, a Service is a set of rules mapping ip:port -> pod.
Kubernetes Service Types
Ingress (L7 Perspective) #
Ingress is a collection of rules for routing HTTP/HTTPS traffic. The actual network handling is done by an Ingress Controller, while Ingress itself is a configuration object.
- Handles URL / Host-based routing
- HTTP-level processing
- path rewriting
- header manipulation
- TLS termination (HTTPS -> HTTP)
It's important to note that Ingress itself does not receive traffic; it only makes sense with an Ingress Controller, such as NGINX Ingress, ALB Ingress Controller, Traefik, etc.
Operation Flow #
- External request arrives (LB, NodePort)
- Ingress Controller Pod receives the request
- Host / Path rule matching
- Traffic forwarded to Service
- Service distributes to Pods
In essence, Ingress acts as a higher-level router operating on top of Services.
Ingress Controller
| Category | Service | Ingress |
|---|---|---|
| OSI Layer | L4 (TCP/UDP) | L7 (HTTP/HTTPS) |
| Target | Pod | Service |
| Routing Criteria | IP / Port | Host / Path / Header |
| TLS Handling | Not possible | Possible |
| Necessity | Required for Pod exposure | Optional for external HTTP exposure |
Traffic flow based on EKS
Client
↓
AWS ALB / NLB
↓
Ingress Controller (NGINX Pod)
↓
Service (ClusterIP)
↓
Application Pod
Why are Service and Ingress separated? #
This is due to Kubernetes' core design philosophy.
- Network simplification: Ingress rules connect to Services
- Protocol separation: Not all traffic is HTTP
- Controller extensibility: Ingress implementations can be swapped, while Service is a common cluster abstraction.
Thanks to this structure, TCP can operate without Ingress, while HTTP allows for advanced control with Ingress. This means separation of concerns between infrastructure and application.