Swoole在Kubernetes中部署需结合liveness/readiness探针保障可用性，通过resource quotas限制资源，用helm chart部署，service mesh优化通信，并外置日志与会话状态。
单机 Swoole 无法替代 Kubernetes 集群，不是“能不能跑”的问题，而是“跑起来后是否可控、可观测、可伸缩、可恢复”的问题。Kubernetes 不是容器运行时，而是对长连接服务（如 Swoole）的生存环境做系统性加固。
单机 Swoole 的进程管理缺陷直接暴露在生产中
单机直接运行 Swoole\Server（尤其是 SWOOLE_PROCESS 模式）时，Swoole 自身不提供进程健康看护能力：worker 进程睡死、task 进程卡住、信号未被正确转发、max_request 触发后 reload 失败 —— 这些都会导致服务静默不可用。Kubernetes 的 livenessProbe 和 readinessProbe 能在秒级发现并重启异常 Pod；而单机靠 supervisord 或自写脚本，既难覆盖所有异常路径，也无法感知网络就绪状态。
- 不要依赖
php start.php start -d在宿主机长期运行 Swoole 服务 -
kill -USR1等信号在 Docker 容器内默认被屏蔽，必须显式配置init: true或使用tini - 单机无跨节点连接复用机制，WebSocket 客户端断线重连后，无法自动调度到原会话所在进程（除非自己实现全局 session 存储 + 路由表）
Kubernetes 中的 Swoole 必须配合探针与资源限制
裸跑 Swoole 时，常忽略内存泄漏或协程阻塞对整体进程的影响；而在 Kubernetes 中，不设 resources.limits.memory 可能导致 OOMKilled，不配 livenessProbe 则故障 Pod 永远卡在 Running 状态。尤其注意：livenessProbe 若调用的是业务接口（如 /health），必须确保该接口不依赖外部服务（如 Redis、MySQL），否则探针失败会引发雪崩式驱逐。
-
livenessProbe.httpGet.path应返回纯内存态检查结果（例如Server::stats()中start_time是否为 0） -
readinessProbe建议加failureThreshold: 2，避免因瞬时 GC 导致误判 -
worker_num不应硬编码为 CPU 核数 × 2；需根据容器requests.cpu动态计算，例如4核请求下设worker_num=4更稳妥
连接生命周期和会话状态必须脱离单机视角
单机 Swoole 常把用户连接 ID（$fd）、用户身份、上下文缓存全存在内存里，这在 Kubernetes 下完全失效：Pod 重建后所有内存丢失，且新连接可能落在任意节点。真正的解法是将状态外置，并通过网关层统一收敛流量。
- 不要用
$_SESSION或静态变量存用户上下文；改用 Redis Hash 存fd → user_id映射 - WebSocket 心跳检测（
heartbeat_check_interval）必须与 KubernetesreadinessProbe.periodSeconds错开，避免探测冲突 - 若用 Gateway-Worker 架构，
Gateway节点需通过Redis Pub/Sub或gRPC向Worker广播广播消息，不能走本地 IPC
真正容易被忽略的点在于：Kubernetes 不解决 Swoole 内部的协程调度抖动或 LLM 流式输出乱序问题，它只保证“这个进程活着、能连上、能被发现”。那些需要靠 Co\Channel 控制并发、用 defer 保证清理、靠 Runtime::enableCoroutine(true, ['stream_function' => true]) 安全 Hook 的细节，一个都不能少——集群只是舞台，代码才是演员。
