Kubernetes中Runner Pod按需启动Executor Pod的架构实现与安全咨询

开发者阿泽

2026-8-21

Kubernetes Runner-Executor任务调度架构实现思路与安全分析

一、架构落地实现思路

先完成K8s集群搭建，用Deployment托管无状态前端Pod副本，配置Service对外提供访问入口。前端提交的任务需要存储载体：要么用Redis做任务队列（支持并发读写和持久化），要么自定义Task CRD（用K8s原生API管理任务状态：待执行/执行中/完成），后者更贴合K8s生态。

Runner用Deployment多副本部署，每个Runner是Python进程，依赖kubernetes SDK与集群API交互。
轮询任务：定时拉取任务队列/CRD中的待执行任务，拿到任务后先标记为“执行中”，避免多个Runner重复调度同一份任务。
创建Executor：根据任务参数（镜像、资源配额、环境变量）构造Pod对象，调用K8s API创建Executor Pod；给Executor打上task-id: xxx标签，方便后续追踪关联。
状态追踪：Runner需监听Executor的生命周期（运行中/成功/失败），任务结束后更新任务状态，按需清理Executor Pod（或保留日志后再删除）。

镜像封装：把任务执行逻辑打包成专用镜像，可按任务类型分镜像，或采用通用镜像+任务脚本参数的模式。
资源隔离：为Executor配置resources.requests和resources.limits，避免单个任务占用过多集群资源；可用Namespace隔离不同任务组，或通过Pod Security Standards限制Pod权限（比如禁止特权模式）。
日志收集：要么用K8s自带的日志采集机制，要么给Executor添加sidecar容器（比如fluentd），留存执行日志方便问题排查。

绝对不要给Runner开集群管理员权限！用RBAC做细粒度授权：创建专属ServiceAccount给Runner，绑定ClusterRole或Role，只授予完成工作必需的权限——比如仅允许在指定Namespace创建/删除Pod、读取任务CRD、查看Pod状态。示例权限配置：
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: runner-task-role
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["create", "delete", "get", "list", "watch"]
- apiGroups: ["tasks.example.com"] # 你的自定义CRD API组
  resources: ["tasks"]
  verbs: ["get", "list", "update"]
```
随后在Runner的Deployment中指定serviceAccountName，让Runner以该受限账号与集群交互。

若给Runner集群管理员权限，一旦Runner被攻陷，攻击者可直接操控整个集群（删除节点、篡改所有资源）。严格遵循最小权限原则，仅授予Runner完成工作必需的权限，甚至可限制Runner仅能在特定Namespace操作Pod。

不可信镜像、带漏洞的镜像会直接将风险引入集群。镜像必须做签名验证，用K8s的ImagePolicyWebhook拦截未签名镜像，或通过私有仓库（比如Harbor）做漏洞扫描；绝对禁止使用latest标签，固定镜像版本避免意外更新。

前端提交的任务参数若未校验，可能被注入恶意配置（比如指定特权镜像、挂载主机目录）。对所有任务参数做严格校验：限制镜像仅能来自白名单仓库，禁止设置privileged: true、hostNetwork: true这类危险字段，限制资源请求的最大值。

Runner的Python依赖、基础镜像存在漏洞时，易被攻击者利用。定期更新Runner的基础镜像和依赖包，开展漏洞扫描；用Pod Security Standards限制Runner Pod的权限，比如禁止挂载主机目录、禁止特权模式。

任务日志若包含密码、密钥等敏感数据，会直接造成泄露。对日志中的敏感字段做脱敏处理；同时配置集群监控（Prometheus+Grafana），监控Runner和Executor的状态，对异常情况（比如大量失败Pod、异常权限请求）及时告警。

内容的提问来源于stack exchange，提问作者manaaa