K8s 和云服务可能没那么可靠！

许多用户在使用 DataFlux Func 时，会选择「云服务 + K8s」的方式部署 DataFlux Func。

这是比较常见的部署方式，但需要注意的是，「云服务 + K8s」并不代表可靠！

除此之外，Func 对接的外部系统可能也不可靠，如果这些外部系统也部署在「云服务 + K8s」上，那么可靠性将更无法保证！

以下是一些实际案例供对比：

A. 正面案例

以下是单机部署也较为可靠的正面案例：

某个人用户。

使用阿里云 ECS 单机部署独立 Func，自行编写脚本用于接收 GitLab Pipeline 的 Webhook 并通过 Bark 触发 iOS 消息通知推送。

截至 2025 年 10 月 25 日，已经连续运行 9 个月无任何故障。

以下是即使使用了「云服务 + K8s」方案也发生故障的反面案例：

某汽车行业 G 公司。

使用私有部署的观测云，并使用 NAS 服务。

2023 年 09 月 24 日，用于独立部署版 Func 的 Redis，其持久化所用的 NAS 无法正常挂载，进而导致相关服务无法正常使用。

某零售行业 X 公司。

2024 年 10 月 31 日，为部署有 DataFlux Func 的云主机开启了 WAF 保护。

导致用户在编写脚本，保存 / 发布时，被认为存在风险，返回 405 阻断了请求。

某互联网公司 Z 公司。

2024 年底，将原本阿里云 K8s 迁移至火山引擎，发现部分网络访问延迟极大甚至无法正常访问。

后查明是网络组件问题，进入隧道的数据包的 MTU 过大导致 TCP 分片丢失。

某专业技术服务行业 S 公司。

使用私有部署的观测云，并使用自建 Redis 服务。

2025 年 4 月 10 日，发现观测云监控器产生事件存在 1 小时延迟。

后查明自建 Redis 存在问题，机器时间与现实时间相差达 1 个小时。

某保险行业 T 公司。

使用阿里云、腾讯 K8s 组件、信创系统私有部署观测云，并在内置的 Func 中额外编写脚本用于简单的用户登录重定向处理。

2025 年 10 月 24 日，突发 Func 任务随机概率无法执行的故障。

后查明为云主机组件存在问题，期间 CPU 占用 90% 以上，腾讯 K8s 组件重启 4000 多次。

某互联网公司 Z 公司。

2025 年 11 月 01 日，发现监控器任务日志无法正常上报至 DataWay，并拖慢所有监控器任务执行。

后查明是集群中某个服务创建了过多的对外连接，导致 NAT 网关连接数过高。

某保险行业 T 公司。

2025 年 11 月 17 日，发现监控器任务存在大量超时、过期任务。

后查明是监控器通知对象最终调用了客户自建的通知组件，而这个通知组件存在问题，拖慢了消息发送处理，导致大量 Read Timeout。

某酒店行业 H 公司。

2025 年 11 月 19 日，发现应当「立即执行」的处理没有按照预期执行。

后查明是服务器之间时间不一致，Redis 时间与服务器时间相差达 10 分钟。