Home/Learn/Microservices/Kubernetes for Microservices

Kubernetes for Microservices

Advanced

Deployment

Kubernetes orchestrates containers across nodes; Deployments, Services, ConfigMaps, and HorizontalPodAutoscalers provide self-healing, scaling, and traffic routing.

Overview

Kubernetes (K8s) is the de facto platform for running microservices at scale. It automates container scheduling, self-healing (pod restarts on failure), horizontal scaling, and rolling deployments with zero downtime. The core objects microservice teams interact with are: Deployment (declarative pod management), Service (stable DNS + load balancing), ConfigMap/Secret (configuration injection), HorizontalPodAutoscaler (auto-scaling based on CPU/custom metrics), and Ingress (HTTP routing). A microservice in Kubernetes is typically one Deployment per service, with one or more pods behind a Service. Understanding resource requests/limits, health probes, and graceful shutdown is critical to production stability.

Deployment, Service, and ConfigMap

A Deployment manages a ReplicaSet of pods and handles rolling updates. A Service provides a stable cluster-internal DNS name and load balances across pod replicas. ConfigMaps and Secrets inject configuration as environment variables or mounted files — no application code changes are needed to switch environments.

YAML — Deployment, Service, and ConfigMap for a Spring Boot microservice

# Deployment — manages pod replicas with rolling updates
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0     # zero-downtime rolling update
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service
          image: registry.example.com/order-service:1.2.0
          ports:
            - containerPort: 8080
          envFrom:
            - configMapRef:
                name: order-service-config
          env:
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: order-service-secrets
                  key: db-password
          resources:
            requests: { memory: "256Mi", cpu: "100m" }
            limits:   { memory: "512Mi", cpu: "500m" }
---
# Service — stable DNS: order-service.backend.svc.cluster.local
apiVersion: v1
kind: Service
metadata:
  name: order-service
  namespace: backend
spec:
  selector:
    app: order-service
  ports:
    - port: 80
      targetPort: 8080
---
# ConfigMap — non-sensitive config
apiVersion: v1
kind: ConfigMap
metadata:
  name: order-service-config
  namespace: backend
data:
  SPRING_PROFILES_ACTIVE: "prod"
  KAFKA_BOOTSTRAP_SERVERS: "kafka.infra:9092"

Health probes for self-healing and zero-downtime deployments

Kubernetes uses three probe types: livenessProbe (restart if fails), readinessProbe (remove from Service endpoints if fails — used during rolling update and startup), and startupProbe (replaces liveness during slow startup). Spring Boot Actuator provides /actuator/health/liveness and /actuator/health/readiness endpoints automatically (Spring Boot 2.3+).

YAML — startup, liveness, and readiness probes for Spring Boot

# Health probes — add to container spec
containers:
  - name: order-service
    # ... image, resources ...
    startupProbe:           # replaces liveness during slow startup
      httpGet:
        path: /actuator/health/liveness
        port: 8080
      failureThreshold: 30  # allow 30 * 10s = 5 min to start
      periodSeconds: 10

    livenessProbe:          # restart pod if stuck / deadlocked
      httpGet:
        path: /actuator/health/liveness
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 15
      failureThreshold: 3

    readinessProbe:         # remove from Service LB if not ready
      httpGet:
        path: /actuator/health/readiness
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      failureThreshold: 3

# application.yml — expose readiness/liveness groups
management:
  endpoint:
    health:
      group:
        liveness:
          include: livenessState
        readiness:
          include: "readinessState,db,redis"

HorizontalPodAutoscaler and graceful shutdown

HPA automatically scales the Deployment based on CPU utilisation or custom metrics (via Prometheus Adapter). For microservices, always configure graceful shutdown: the pod has 30 s (terminationGracePeriodSeconds) to finish in-flight requests after receiving SIGTERM. Spring Boot 2.3+ supports graceful shutdown with server.shutdown=graceful.

YAML — HPA with CPU and custom metrics, and graceful shutdown config

# HorizontalPodAutoscaler — scale on CPU utilisation
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
  namespace: backend
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # scale out when avg CPU > 70%
    - type: Pods
      pods:
        metric:
          name: http_server_requests_per_second
        target:
          type: AverageValue
          averageValue: "500"      # custom metric via Prometheus Adapter

# Graceful shutdown — Spring Boot application.yml
server:
  shutdown: graceful   # waits for active requests to complete
spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s

# Kubernetes terminationGracePeriodSeconds (in Deployment spec)
spec:
  template:
    spec:
      terminationGracePeriodSeconds: 60   # K8s waits 60s before SIGKILL

Key Points to Remember

1Deployment manages rolling updates (maxUnavailable=0, maxSurge=1) for zero-downtime deploys across pod replicas
2Service provides stable cluster-internal DNS (<name>.<namespace>.svc.cluster.local) and load balancing
3readinessProbe removes a pod from Service endpoints during rolling update until it is ready to serve traffic
4startupProbe replaces liveness during slow startup, preventing premature restarts of slow-starting JVM applications
5HPA scales replicas based on CPU utilisation or custom Prometheus metrics (via Prometheus Adapter)
6Graceful shutdown (server.shutdown=graceful) combined with terminationGracePeriodSeconds prevents request drops on pod termination

Interview Questions

What is the difference between a liveness probe and a readiness probe in Kubernetes?

EasyGoogle

How would you configure a zero-downtime rolling deployment for a Spring Boot service in Kubernetes?

MediumAmazon

Why must terminationGracePeriodSeconds be greater than the Spring Boot graceful shutdown timeout?

HardNetflix

How does HPA use custom metrics from Prometheus to scale a deployment?

HardUber

A Spring Boot pod keeps restarting in Kubernetes. How would you diagnose whether the liveness or readiness probe is at fault?

MediumThoughtworks

Ask Aria about Kubernetes for Microservices

Your personal AI tutor — ask anything about this concept

Revision Status

Personal Notes

Discussion

Loading discussion…

Containerisation with Docker

Blue-Green Deployment