Kubernetes Deployments, Services and Ingress Explained

As containerized applications scale from single Docker containers to multi-node microservice architectures, manual container management becomes untenable. **Kubernetes (K8s)** has become the industry-standard container orchestration platform, automating deployment, scaling, networking, and load balancing.

This comprehensive guide breaks down the foundational architecture of Kubernetes—specifically focusing on **Deployments**, **Services**, and **Ingress controllers**—complete with production-grade YAML configuration examples.

1. Kubernetes Deployments & ReplicaSets

A **Deployment** provides declarative updates for Pods and ReplicaSets. Instead of manually creating individual Pods (which are ephemeral and prone to failure), a Deployment ensures that a specified number of identical pod replicas are running at all times.

• Rolling Updates & Rollbacks: Deployments allow seamless zero-downtime rolling updates, automatically shifting traffic from old pod versions to new ones, with instant rollback capabilities if issues arise.
• Self-Healing: If a node or pod crashes, the ReplicaSet managed by the Deployment automatically spins up a new instance.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-deployment
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

2. Kubernetes Services (ClusterIP, NodePort, LoadBalancer)

Pods in Kubernetes are ephemeral; their IP addresses change whenever they are restarted or scaled. A **Service** is an abstract abstraction layer that defines a logical set of Pods and a policy to access them, providing a stable networking endpoint.

• ClusterIP (Default): Exposes the service on an internal cluster-only IP. Accessible exclusively within the Kubernetes cluster (internal microservice communication).
• NodePort: Exposes the service on each node's IP at a static port (typically 30000-32767), allowing external traffic to reach the cluster.
• LoadBalancer: Provisions an external cloud load balancer (e.g., AWS ELB or GCP HTTP Load Balancer) that routes traffic directly to the service.

apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

3. Kubernetes Ingress & Controllers

While LoadBalancer services work well, provisioning a separate cloud load balancer for every microservice is expensive. An **Ingress** acts as an intelligent API gateway and Layer 7 HTTP/HTTPS reverse proxy that manages external access to services within a cluster.

• Path-Based & Host-Based Routing: Route traffic based on URL paths (`/api` vs `/shop`) or domain names (`api.example.com` vs `shop.example.com`) to different backend services.
• TLS / SSL Termination: Handles secure HTTPS certificates centrally at the ingress boundary.
• Popular Ingress Controllers: NGINX Ingress Controller, Traefik, HAProxy, and Gateway API.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-app-service
            port:
              number: 80

Conclusion

Mastering Kubernetes architecture—combining declarative **Deployments** for pod lifecycle management, internal **Services** for stable networking, and **Ingress controllers** for advanced HTTP/HTTPS routing—is essential for running scalable, production-grade cloud-native applications.