EKS Üzerinde WebSocket Trafiği Yönetimi

WebSocket, sunucu ve istemci arasında sürekli açık kalan (persistent) bir bağlantı sağlar. Bu durum, HTTP gibi "istek-yanıt" (request-response) mantığıyla çalışan protokollerden farklıdır ve ölçekleme (scaling) konusunda özel dikkat gerektirir.

Amazon EKS üzerinde WebSocket trafiğini yönetirken karşılaşacağınız zorluklar ve çözümleri:

1. Load Balancer Ayarı (Stickiness)

WebSocket bağlantısı kurulurken (Handshake), istemci ve sunucunun el sıkışması gerekir. Eğer Load Balancer, handshake'in ortasında trafiği başka bir pod'a gönderirse bağlantı kopar.

Çözüm: Application Load Balancer (ALB) üzerinde Sticky Sessions (Session Affinity) açarak, bir istemcinin hep aynı pod ile konuşmasını sağlayabilirsiniz. Ancak WebSocket doğası gereği zaten tek bir TCP bağlantısıdır, bağlantı kurulduktan sonra stickiness gerekmez.

2. Bağlantı Süreleri (Timeouts)

Load Balancer'ların varsayılan boşta kalma süresi (idle timeout) genellikle 60 saniyedir. WebSocket üzerinden 60 saniye veri akmazsa LB bağlantıyı keser.

Çözüm: ALB Idle Timeout süresini artırın (örn: 3600 saniye). Ayrıca uygulamanızda "Heartbeat" (Ping/Pong) mekanizması kurarak hattı canlı tutun.

3. Ölçekleme Zorluğu

10 bin kullanıcılı bir WebSocket sunucusunu (Pod A) kapatıp (scale down), kullanıcıları Pod B'ye taşımak zordur. Çünkü bağlantılar canlıdır.

Çözüm: Pod kapanırken (SIGTERM sinyali aldığında), yeni bağlantı kabul etmeyi durdurmalı, mevcut bağlantıların bitmesini beklemeli veya istemcilere "Bağlantıyı kes ve tekrar bağlan" (Reconnect) mesajı göndererek onları diğer podlara yönlendirmelidir.

4. Ingress Annotations

NGINX Ingress kullanıyorsanız, WebSocket desteği için şu notasyonları eklemelisiniz:

nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"

WebSocket, modern web'in olmazsa olmazıdır ve EKS üzerinde doğru yapılandırma ile milyonlarca anlık bağlantıyı destekleyebilir.