Belajar WebSocket - Kubernetes Deployment

#Pendahuluan

Docker membuat aplikasi berjalan di satu mesin; Kubernetes membuatnya bertahan dari kegagalan. Saat container mati, Kubernetes menghidupkannya lagi. Saat traffic naik, pod ditambah otomatis. Tapi WebSocket punya kebutuhan khusus: koneksi yang panjang dan stateful.

Episode 28 membahas Kubernetes deployment untuk WebSocket: menulis Deployment dan Service, mengonfigurasi Ingress dengan session affinity, membuat autoscaling berbasis koneksi, dan memahami peran service mesh.

#Resource Dasar

#Deployment

Deployment mendeklarasikan berapa pod yang diinginkan.

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 menjaga tiga pod selalu berjalan. readinessProbe memakai endpoint health check dari episode 27: pod baru tidak menerima traffic sampai siap, pod yang sehat berhenti dihentikan trafficnya sebelum dimatikan.

#Service dan ConfigMap

Service memberikan alamat stabil untuk sekelompok pod.

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

Service tipe ClusterIP membagikan traffic ke pod secara round-robin. Konfigurasi seperti jumlah maksimal koneksi disimpan di ConfigMap agar bisa diubah tanpa membangun ulang image.

#Konfigurasi Khusus WebSocket

#Session Affinity

Koneksi WebSocket harus tetap di pod yang sama. Aktifkan session affinity di Service.

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

sessionAffinity: ClientIP mengarahkan klien dengan IP yang sama ke pod yang sama selama timeout. Untuk distribusi yang lebih halus, kombinasi dengan Redis adapter (episode 16) tetap diperlukan karena affinity berbasis IP tidak menjamin pemerataan.

#Ingress dengan Anotasi

Ingress menghubungkan traffic eksternal ke Service. Anotasi khusus mendukung 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 menandai Service sebagai WebSocket, dan timeout panjang mencegah proxy memutus koneksi idle yang sehat.

#Proxy Protocol

Saat server perlu tahu alamat asli klien (untuk logging atau presence), aktifkan proxy protocol di Ingress dan konfigurasi server agar membaca header tersebut. Tanpa ini, semua koneksi terlihat berasal dari IP proxy.

#Autoscaling

#Horizontal Pod Autoscaling

HPA menambah pod berdasarkan metrik.

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 menambah pod saat CPU rata-rata melewati 70 persen. Untuk skala berbasis koneksi, ekspor metrik kustom (episode 18) dan jadikan target HPA.

#Batasan Scaling

WebSocket tidak seinstan HTTP: pod yang dihentikan harus melepas koneksi dengan graceful shutdown (episode 15). Saat HPA menurunkan skala, koordinasikan dengan session draining agar klien bisa pindah tanpa putus total.

#Service Mesh

#Istio dan Linkerd

Service mesh menambah lapisan kontrol di sisi jaringan: TLS antar pod, tracing, dan traffic management. Di Istio, VirtualService bisa mengarahkan sebagian traffic ke subset canary berdasarkan header — dasar untuk canary release yang dibahas di episode 30. Service mesh memberi observability per koneksi yang sulit dicapai manual.

#Penutup

Episode 28 membawa aplikasi ke orkestrasi: Deployment menjaga replika, Service dan Ingress merutekan traffic dengan affinity yang benar, HPA menambah kapasitas, dan service mesh menambah kontrol serta observability.

Inti yang harus dibawa pulang:

• Deployment menjaga jumlah replika dan memprobe kesehatan pod.
• Service ClusterIP mendistribusikan traffic dengan round-robin.
• Session affinity menjaga koneksi WebSocket di pod yang sama.
• Ingress butuh anotasi WebSocket dan timeout panjang.
• HPA menambah pod berdasarkan CPU atau metrik kustom.
• Service mesh menangani TLS, tracing, dan canary di level jaringan.

Di episode 29 berikutnya kita membahas cloud deployment: AWS, GCP, dan Azure — dari Elastic Beanstalk hingga managed service seperti AWS API Gateway dan Azure SignalR.