Kubernetes Services & Networking: A Practical Deep Dive

Architecture Overview (Mental Model)

Kubernetes traffic flows from a browser through Ingress, to a Service, then to a Pod, and finally to a Container. Understanding this flow is fundamental to managing applications in Kubernetes, as Pod IPs are dynamic and must never be accessed directly.

This article provides a hands-on walkthrough of Kubernetes networking concepts, progressing from basic Service types to advanced features like Ingress, ConfigMaps, and autoscaling. It aims to bridge the gap between theoretical understanding and practical application, mirroring real-world Kubernetes deployments.

Why This Matters

Idealized Kubernetes models assume perfect pod health and predictable resource needs. In reality, Pods can fail, scale dynamically, and require externalized configuration. Without Services, Ingress, and robust resource management, applications face instability, downtime, and increased operational costs—potentially leading to significant revenue loss or service disruption.

Key Insights

• Dynamic Pod IPs: Kubernetes assigns Pods ephemeral IP addresses, necessitating the use of Services for stable access.
• Ingress as a Reverse Proxy: Ingress controllers act as reverse proxies, providing a single entry point and routing traffic based on paths and hostnames.
• Horizontal Pod Autoscaler (HPA): HPA automatically scales the number of Pods based on observed CPU utilization, ensuring application responsiveness under varying load, with a common target of 50% CPU utilization.

Working Example

apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: app
image: hashicorp/http-echo:0.2.3
args:
- "-listen=:8080"
- "-text=SERVICE WORKS"
ports:
- containerPort: 8080

apiVersion: v1
kind: Service
metadata:
name: web-svc
spec:
selector:
app: web
ports:
- port: 80
targetPort: 8080

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: stable-svc
port:
number: 80
- path: /canary
pathType: Prefix
backend:
service:
name: canary-svc
port:
number: 80

Practical Applications

• E-commerce Platform: Utilizing Ingress for routing traffic to different versions of a storefront (A/B testing or canary deployments) based on URL paths.
• Pitfall: Directly exposing Pods via NodePort without a Service or Ingress exposes the application to instability due to Pod IP address changes and lacks load balancing.

References:

• https://dev.to/jumptotech/kubernetes-services-networking-1apj