引言
Kubernetes 作為 Cloud Native 技術的核心基礎架構，其在處理狀態連接（Stateful Connections）時面臨獨特的挑戰。隨著 WebSockets 等協議的普及，應用場景對持續雙向通訊的需求日益增加，而 Kubernetes 的設計本質上傾向於無狀態（Stateless）服務。本文探討 Kubernetes 中狀態連接的擴展策略、負載平衡優化及實際實踐，並結合 CNCF（Cloud Native Computing Foundation）生態的技術特性，分析如何在雲原生環境中實現高可用與可擴展的狀態服務。
主要內容
技術定義與核心特性
狀態連接指應用層維持長時間的雙向通訊通道，例如 WebSockets 協議。與傳統 HTTP 的無狀態請求-回應模型不同，狀態連接需要確保連線的持續性、端到端的可靠性，以及對負載的動態分配。在 Kubernetes 中，狀態連接的管理涉及多層次的協議特性、系統限制與雲原生架構的整合。
WebSockets 協議特性：
- 建立連線需經歷 TLS 握手與 HTTP 升級兩階段，導致新連線成本高。
- 連線建立後需維持雙向通訊，增加資源消耗與尾部延遲。
- 空閒超時配置需在應用、負載平衡器與 Linux 系統層級調整，避免連線被提前終止。
Linux 系統限制：
- 臨時端口（ephemeral ports）：每個連線需獨佔端口，Linux 預設限制約 28K，需透過
pod spec 調整。
- 連線追蹤表（connection tracking）：系統維護活動連線狀態表，表滿會導致新連線被靜默拒絕，需預估並擴充表容量。
狀態連接的挑戰
路由與服務發現：
- 傳統 EC2 狀態服務依賴 URL 路徑映射 EC2 實例，導致客戶端需重新協商連線。
- 狀態服務與服務發現系統（如 Consul）可能不同步，引發分裂腦問題。
擴展限制：
- 縱向擴展受臨時端口與連線追蹤表限制，需優先採用橫向擴展（horizontal scaling）。
- 連線數量與資源使用率的非線性關係，傳統資源基準擴展不適用。
負載平衡策略優化
負載均衡算法選擇：
- 輪詢（Round Robin）：會導致舊 Pod 被過度負載，新 Pod 冷啟動時承受高 CPU 負荷與延遲。
- 最少活躍連線（Least Active Connections）：初期因冷啟動問題導致新 Pod 被大量連線佔據，需調整冷啟動速率與預熱策略。
解決方案：
- 建立專用目標組端點，區分新連線與現有連線的處理邏輯。
- 當 Pod 連線數超過閾值（如 10,000）時，標記為非就緒，避免新連線分配，同時保持現有連線。
資源與擴展策略
自動擴展機制：
- 使用 Kada 操作符，根據實際連線數量動態調整 Pod 數量，而非傳統資源使用率。
- 配置策略：
- 快速擴展（無上限）與緩慢縮放（每 5 分鐘最多刪除 1 個 Pod）。
- 滾動窗口採樣與 5 分鐘冷卻期，避免因指標波動導致頻繁擴縮。
性能優化：
- 每個 Pod 能處理約 8,000 個連線，峰值可達更高而不影響效能。
- 透過性能測試確定 CPU 與記憶體資源需求，優化 Pod 大小。
連線管理與優雅關閉
優雅關閉流程：
- 調整 AWS ALB 的註銷延遲（registration delay）至 2 分鐘，確保 RTC Gateway 有足夠時間處理現有連線。
- 使用預終止 Hook，確保 Pod 從負載平衡池移除後才開始關閉連線，避免新連線分配。
連線穩定性：
- 透過自定義控制器自動管理憑證，確保 Pod 啟動時持有有效憑證，避免因憑證過期導致連線中斷。
實測成效
效能提升：
- 降低運營成本，提升擴展靈活性，支援更多並行連線。
- 通過橫向擴展與資源優化，避免縱向擴展的硬體限制。
穩定性改善：
- 有效處理臨時端口耗盡與連線追蹤表滿的問題，減少用戶體驗中斷。
- 通過負載均衡策略調整，平衡 Pod 負載，避免單點過載。
結論
Kubernetes 中狀態連接的擴展與負載平衡需結合協議特性、系統限制與雲原生架構的設計原則。透過橫向擴展、自定義指標監控、負載均衡策略優化及優雅關閉機制，可有效提升狀態服務的穩定性與可擴展性。在 CNCF 生態中，這些實踐體現了 Cloud Native 技術對動態資源管理與彈性擴展的強大支持。