Kubernetes Deployment Patterns

Pods, services, ingress, HPA and rolling updates for stateless microservices on K8s.

ExpertOps14 min read

Read these first

Nearby Friends Location

Why this matters

StreamHub runs 40+ microservices on EKS — understanding Deployments, Services, Ingress, and HPA is how you ship without downtime.
Stateless services scale horizontally by adding pods; stateful workloads need StatefulSets, persistent volumes, and careful rollout strategy.
Probes (liveness, readiness, startup) are the difference between graceful deploys and cascading failures.

Kubernetes primitives for StreamHub

Deployment — manages ReplicaSets; declarative rolling updates and rollbacks.
Service — stable ClusterIP or LoadBalancer endpoint across pod IPs.
Ingress — L7 routing, TLS termination, path-based rules to backend services.
HPA — Horizontal Pod Autoscaler scales replicas on CPU, memory, or custom metrics.
ConfigMap / Secret — externalise configuration; mount as env vars or files.

StreamHub on Amazon EKS

Ingress → Deployments with HPA, probes, and IRSA for AWS access.

Deployment manifest

Java

apiVersion: apps/v1
kind: Deployment
metadata:
  name: streamhub-api
  labels:
    app: streamhub-api
    version: v2.8.1
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  selector:
    matchLabels:
      app: streamhub-api
  template:
    metadata:
      labels:
        app: streamhub-api
        version: v2.8.1
    spec:
      terminationGracePeriodSeconds: 45
      containers:
        - name: api
          image: registry.streamhub.io/api:2.8.1
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 500m
              memory: 512Mi
            limits:
              cpu: 1000m
              memory: 1Gi
          env:
            - name: OTEL_EXPORTER_OTLP_ENDPOINT
              value: http://otel-collector:4317
          livenessProbe:
            httpGet:
              path: /health/live
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
          startupProbe:
            httpGet:
              path: /health/ready
              port: 8080
            failureThreshold: 30
            periodSeconds: 5

Service and Ingress

Java

apiVersion: v1
kind: Service
metadata:
  name: streamhub-api
spec:
  selector:
    app: streamhub-api
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: streamhub-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts: [api.streamhub.com]
      secretName: streamhub-tls
  rules:
    - host: api.streamhub.com
      http:
        paths:
          - path: /v1
            pathType: Prefix
            backend:
              service:
                name: streamhub-api
                port:
                  number: 80

Horizontal Pod Autoscaler

Java

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: streamhub-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: streamhub-api
  minReplicas: 3
  maxReplicas: 30
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "500"

Aspect	Deployment strategy	When to use
RollingUpdate	Gradual pod replacement	Default for stateless services
Recreate	Kill all, then start new	Dev/staging only; causes downtime
Blue-green	Two full environments, switch traffic	Zero-downtime with instant rollback
Canary	Route 5% traffic to new version	Risk reduction for risky changes

RollingUpdate
Deployment strategyGradual pod replacement
When to useDefault for stateless services
Recreate
Deployment strategyKill all, then start new
When to useDev/staging only; causes downtime
Blue-green
Deployment strategyTwo full environments, switch traffic
When to useZero-downtime with instant rollback
Canary
Deployment strategyRoute 5% traffic to new version
When to useRisk reduction for risky changes

StreamHub uses rolling updates with maxUnavailable=1 for most services; canary via service mesh for high-risk deploys.

Pod Disruption Budget

Prevent voluntary disruptions (node drains, cluster upgrades) from taking down too many pods at once.

Java

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: streamhub-api-pdb
spec:
  minAvailable: 4
  selector:
    matchLabels:
      app: streamhub-api

Observability hooks

Every pod should export metrics and traces from day one.

Java

env:
  - name: OTEL_SERVICE_NAME
    value: streamhub-api
  - name: OTEL_EXPORTER_OTLP_ENDPOINT
    value: http://otel-collector.observability:4317
  - name: OTEL_RESOURCE_ATTRIBUTES
    value: deployment.environment=production,service.version=2.8.1

Quick recall

Everything you need if you only revisit this box.

Deployment manages desired replica count and rolling update strategy.
Service provides stable endpoint; Ingress handles L7 routing and TLS.
Liveness restarts wedged pods; readiness gates traffic; startup handles slow JVM boot.
HPA scales on CPU, memory, or custom metrics (requests/s).
PDB ensures minimum availability during voluntary disruptions.

Test yourself

Answer these before moving on — recall is what makes it stick.