影刀RPA 企业级专题篇：Kubernetes 自动化调度与分布式执行集群实践

作者：林焱

很多自动化系统前期。

其实没有“集群”概念。

通常就是：

几台 Windows。

几个浏览器。

几个流程。

任务少的时候。

这种模式没有问题。

但随着业务规模扩大。

问题会越来越明显。

例如：

节点数量增加

浏览器数量增加

任务峰值波动

资源利用不均

节点故障频繁

系统开始进入一个阶段：

单机思维已经不够用了。

这时候。

很多团队会开始接触：

Kubernetes。

有的人第一次看到 Kubernetes。

会觉得特别复杂。

但如果长期做自动化系统。

最后会发现：

很多问题。

Kubernetes 天然就在解决。

这篇文章。

重点聊：

Kubernetes 在自动化平台中的调度与执行体系。

为什么自动化系统后期一定会“集群化”

很多团队最开始。

任务量其实很低。

几百个任务。

几台机器。

完全够用。

但真正进入企业级阶段以后。

任务会逐渐变成：

持续高并发。

例如：

多业务同时运行

多时间段集中执行

大量浏览器同时启动

多节点资源动态变化

这时候。

单节点模式会越来越脆弱。

因为：

任何一个节点故障。

都会影响整体运行。

什么是真正的分布式执行集群

很多人理解集群。

只是“机器变多”。

实际上不是。

真正的集群。

核心是：

统一调度。

例如：

任务中心
↓
统一调度层
↓
多个执行节点
↓
浏览器实例
任务不再依赖某一台机器。

而是：

整个资源池。

Kubernetes 为什么越来越适合自动化系统

Kubernetes 本质上。

是一个：

资源调度系统。

而自动化平台后期。

最核心的问题之一也是：

资源调度。

例如：

哪个节点执行任务

哪个节点资源空闲

哪个容器需要重启

哪个任务需要扩容

这些能力。

Kubernetes 天然具备。

一个典型的 Kubernetes 自动化结构
任务队列
↓
调度服务
↓
Kubernetes 集群
↓
Pod 执行节点
↓
Chromium + 影刀
这里最关键的。

其实是：

Pod。

为什么 Pod 很适合自动化执行

Pod 可以理解成：

轻量执行单元。

自动化任务天然适合：

短生命周期执行。

例如：

启动。

执行。

结束。

销毁。

这和 Pod 的运行模式非常接近。

为什么“任务结束即销毁”很重要

很多传统节点模式。

任务执行完成以后。

环境还在。

久而久之。

系统会越来越脏。

例如：

Cache 堆积

临时文件残留

浏览器状态污染

内存无法彻底释放

而 Pod 最大的优势之一。

就是：

执行完成即回收。

环境天然干净。

一个简单的 Pod 调度模型
Python
运行
class PodScheduler:

def dispatch(self, task):
    pod_name = f"worker-{task.id}"
    return pod_name

真实系统会复杂很多。

因为：

还要考虑资源分配。

为什么资源调度才是 Kubernetes 核心

很多人以为 Kubernetes 的核心是容器。

其实不是。

真正核心是：

调度。

例如：

CPU 空闲节点

内存充足节点

低负载节点

系统会自动选择：

最合适的节点执行任务。

为什么自动扩容特别适合自动化场景

自动化任务有个明显特点：

波峰波谷非常明显。

例如：

白天任务暴增。

夜间任务减少。

如果节点固定。

资源会严重浪费。

Kubernetes 的一个核心能力就是：

自动扩缩容。

例如：

任务增加
↓
自动增加 Pod
任务减少
↓
自动回收 Pod
这样资源利用率会高很多。

为什么节点恢复能力越来越重要

传统模式下。

节点挂了。

通常需要人工处理。

但集群规模扩大以后。

人工恢复会越来越慢。

Kubernetes 最大优势之一。

就是：

自动恢复。

例如：

Pod 崩溃
↓
自动重建
整个过程。

甚至不需要人工介入。

为什么浏览器容器化越来越普遍

以前很多浏览器。

都是直接跑在 Windows。

后期会发现：

环境越来越不可控。

所以越来越多团队。

开始把 Chromium 放进容器。

这样：

浏览器版本。

插件版本。

运行参数。

全部统一。

稳定性会提升很多。

一个典型浏览器容器结构
Docker Container
↓
Chromium
↓
影刀流程
每个任务。

都拥有独立运行环境。

为什么 Kubernetes 特别适合“弹性系统”

传统自动化平台。

资源通常是固定的。

但真实业务。

任务量一定会波动。

Kubernetes 的核心价值之一。

就是：

弹性。

资源可以动态变化。

系统不再依赖：

固定机器数量。

为什么分布式浏览器池越来越重要

很多系统做到后面。

浏览器数量会非常多。

例如：

几十。

上百。

甚至更多。

如果浏览器集中在单节点。

风险会非常高。

所以成熟系统通常会：

浏览器分布式部署。

例如：

Node A：
浏览器池A

Node B：
浏览器池B

Node C：
浏览器池C

这样系统会更稳定。

为什么 Kubernetes 后期越来越像“自动化操作系统”

做到后面。

很多团队会发现：

Kubernetes 不只是部署工具。

它实际上已经成为：

自动化运行底座。

因为它开始负责：

任务调度

节点治理

资源控制

故障恢复

自动扩容

这些能力。

本质上已经接近：

操作系统调度层。

一个真实线上问题

之前有个系统。

浏览器全部集中在单节点。

前期任务少时没问题。

后期高峰阶段。

CPU 被直接打满。

结果：

整批任务全部延迟。

后来改成：

Kubernetes 分布式节点。

问题明显改善。

为什么自动化系统最终会走向“云原生”

很多人以前觉得：

云原生离 RPA 很远。

但真正做大规模系统以后。

两者会越来越接近。

因为：

自动化平台后期的核心问题。

其实和云平台很像。

包括：

调度

扩容

容灾

资源治理

节点恢复

这些都属于：

云原生领域。

为什么系统后期越来越重视“弹性能力”

以前很多系统。

追求固定稳定。

但真实业务环境。

变化永远存在。

所以成熟平台。

更重要的能力是：

弹性。

资源能动态调整。

节点能自动恢复。

任务能自动迁移。

这才是真正长期稳定运行的关键。

影刀真正适合的位置

影刀依然非常适合：

执行层。

例如：

页面交互。

浏览器操作。

流程执行。

但大规模调度。

集群治理。

资源编排。

更适合放在：

Kubernetes + Python 控制层。

典型结构：

Python（调度）

Redis（状态）

Kubernetes（集群）

Docker（运行环境）

影刀（执行）
写在最后

很多人最开始做自动化。

关注的是：

流程能不能自动运行。

但真正进入大规模阶段以后。

系统的核心会逐渐变化。

从：

流程开发。

变成：

资源治理。

节点。

集群。

调度。

弹性。

恢复。

这些能力。

正在成为企业级自动化平台真正的基础设施。

下一篇专栏。

准备继续聊：

《影刀RPA 企业级专题篇：自动化系统中的日志平台与链路追踪设计》。

会深入拆解：

分布式日志

Trace 链路

任务追踪

异常定位

ELK 日志平台

实时监控

可观测性体系

企业级排障设计

作者：林焱