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

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

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

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

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

1. 简单部署也可能长期稳定

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

单机部署虽然经常，也很容易被人以「单点」为理由诟病，但其系统复杂性低，依赖少，本身能够成为故障点的地方就少。

1.1 单机部署连续运行 9 个月

某个人用户。

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

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

这个案例的特点是：系统链路短、依赖少、流量规模可控、业务逻辑清晰。因此，即使没有使用复杂的高可用架构，也能够稳定运行较长时间。

2. 反面案例

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

随着系统复杂度越高，故障来源也越多。即使底层使用了云服务和 K8s，存储、网络、时间同步、安全策略、自建中间件和外部依赖等环节都会成为潜在的故障点。

2.1 NAS 故障导致系统异常

某汽车行业 G 公司。

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

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

2.2 阿里云 WAF 阻断正常使用

某零售行业 X 公司。

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

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

2.3 测试环境迁移至火山引擎后网络存在问题

某互联网公司 Z 公司。

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

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

2.4 自建 Redis 存在问题

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

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

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

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

2.5 腾讯 K8s 组件故障

某保险行业 T 公司。

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

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

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

2.6 NAT 网关连接数过高导致网络异常

某互联网公司 Z 公司。

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

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

2.7 自建通知组件故障

某保险行业 T 公司。

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

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

2.8 服务器之间时间不一致

某酒店行业 H 公司。

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

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

2.9 Redis 连接存在问题

某汽车行业 G 公司。

使用火山云的 Redis 服务。

2026 年 4 月 9 日，发现 Func Worker 服务经常性崩溃，报错内容为 redis.exceptions.ResponseError: redis server closed connection

虽然无直接证据，但推测为火山云本身问题，火山云链路中的某个组件无法连上 Redis 导致，推测依据如下：

这个报错应当属于「连接错误 ConnectonError」而不是「响应错误 ResponseError」，响应错误一般是指类似参数不正确才会报的错，此报错和实际内容不符
redis-py 项目代码中并没有 redis server closed connection 这句话，且只能找到 Connection closed by server，此报错非 Redis 客户端 redis-py 产生
官方正常都会写 Redis 而不是 redis（R 大写）。同时，这句报错本身有语法错误，应当写 Redis server closed the connection，且这类描述一般都写作被动句式 Connection closed by Redis server。主观上来说，这条描述的作者的母语不太像英语

2.10 ...

后续将搜集更多案例于此……

3. 为什么？

诚然，K8s 和云服务的确为现代复杂系统的平稳运行提供了有效支撑。

但有句老话说得好「没有银弹」（人月神话），简单地认为 K8s + 云服务就是好，就是稳，只是一厢情愿。

一个系统是否稳定，最重要的指标就是复杂度，一般来说，一个系统越简单，就越不容易出故障。

至于 K8s 和云服务，其本身是必然增加复杂度的，只有当其提供的优势（即各种运维、部署机制）超过其自身增加的复杂度，才有实际意义，否则只是一种形式主义而已。

具体来说，我们把系统中的服务数量视为复杂度，且运行 K8s 本身就需要 10 个服务，那么：

	原系统服务数量	增加 K8s 后的服务数量	复杂度增加量
案例 1	1000	1010	+1%
案例 2	3	13	+333%

很容易可以看出，只有像「案例 1」这种，原系统本来就足够复杂时，引入 K8s 才能实现「在增加少量复杂度的同时，增强运维、部署能力」

否则，如在「案例 2」中，K8s 引入的复杂度都超过了原系统本身，运维人员可能大部分时间都在对付 K8s 而已。更可气的是，客户只会抓着原系统团队不放，而从来没有人会致电 K8s 团队！