Learn WebSocket - Kubernetes Deployment

#Introduction

Docker makes an application run on one machine; Kubernetes makes it survive failures. When a container dies, Kubernetes brings it back. When traffic rises, pods are added automatically. But WebSocket has special needs: long-lived, stateful connections.

Episode 28 covers Kubernetes deployment for WebSocket: writing Deployment and Service, configuring Ingress with session affinity, connection-based autoscaling, and understanding the role of a service mesh.

#Basic Resources

#Deployment

A Deployment declares how many pods are desired.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ws-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ws-server
  template:
    metadata:
      labels:
        app: ws-server
    spec:
      containers:
        - name: ws-server
          image: registry.example.com/ws-server:1.4.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
          resources:
            requests:
              cpu: 100m
              memory: 128Mi

replicas: 3 keeps three pods running at all times. readinessProbe uses the health check endpoint from episode 27: a new pod receives no traffic until ready, and a healthy pod stops receiving traffic before being terminated.

#Service and ConfigMap

A Service provides a stable address for a group of pods.

apiVersion: v1
kind: Service
metadata:
  name: ws-server
spec:
  selector:
    app: ws-server
  ports:
    - port: 8080
      targetPort: 8080

A ClusterIP Service distributes traffic to pods round-robin. Configuration like the maximum connection count is kept in a ConfigMap so it can change without rebuilding the image.

#WebSocket-Specific Configuration

#Session Affinity

A WebSocket connection must stay on the same pod. Enable session affinity on the Service.

spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800

sessionAffinity: ClientIP routes clients with the same IP to the same pod for the timeout duration. For finer distribution, combining with the Redis adapter (episode 16) is still needed because IP-based affinity does not guarantee even distribution.

#Ingress with Annotations

An Ingress connects external traffic to the Service. Special annotations support WebSocket.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ws-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
    nginx.ingress.kubernetes.io/websocket-services: ws-server
spec:
  rules:
    - host: ws.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: ws-server
                port:
                  number: 8080

nginx.ingress.kubernetes.io/websocket-services marks the Service as WebSocket, and the long timeouts prevent the proxy from cutting healthy idle connections.

#Proxy Protocol

When the server needs to know the client's real address (for logging or presence), enable proxy protocol on the Ingress and configure the server to read those headers. Without it, all connections appear to come from the proxy's IP.

#Autoscaling

#Horizontal Pod Autoscaling

HPA adds pods based on metrics.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ws-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ws-server
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

averageUtilization: 70 adds pods when average CPU passes 70 percent. For connection-based scaling, export custom metrics (episode 18) and make them the HPA target.

#Scaling Limits

WebSocket is not as instant as HTTP: a terminating pod must release connections with graceful shutdown (episode 15). When HPA scales down, coordinate with session draining so clients can move without a total disconnect.

#Service Mesh

#Istio and Linkerd

A service mesh adds a control layer on the network side: inter-pod TLS, tracing, and traffic management. In Istio, a VirtualService can route a portion of traffic to a canary subset based on headers — the foundation for the canary releases covered in episode 30. A service mesh gives per-connection observability that is hard to achieve manually.

#Closing

Episode 28 brought the application to orchestration: Deployment maintains replicas, Service and Ingress route traffic with the right affinity, HPA adds capacity, and a service mesh adds control and observability.

Key takeaways:

• Deployment maintains the replica count and probes pod health.
• A ClusterIP Service distributes traffic round-robin.
• Session affinity keeps WebSocket connections on the same pod.
• Ingress needs WebSocket annotations and long timeouts.
• HPA adds pods based on CPU or custom metrics.
• A service mesh handles TLS, tracing, and canaries at the network level.

In the next episode we cover cloud deployment: AWS, GCP, and Azure — from Elastic Beanstalk to managed services like AWS API Gateway and Azure SignalR.