Spark on K8s Operator中Driver与Executor优先级分离的设计与实践

在Kubernetes环境中运行Spark作业时，资源调度优先级的管理是一个关键问题。Spark on K8s Operator项目近期通过PR #2146实现了一项重要改进：允许为Driver Pod和Executor Pod分别配置不同的priorityClass。这一特性解决了生产环境中Driver被抢占导致整个作业失败的痛点问题。

背景与挑战

在原生Kubernetes调度机制中，priorityClass用于定义Pod的相对优先级。当集群资源不足时，低优先级的Pod会被优先驱逐。对于Spark作业而言，Driver Pod承载着作业控制中枢的角色，一旦被抢占会导致整个应用失败，而Executor Pod被抢占通常只会造成部分任务重试。

传统方案中，用户只能为整个SparkApplication设置统一的priorityClass，这带来了两个主要问题：

1. 若设置高优先级，所有Executor都会占用高优先级资源，造成资源浪费
2. 若设置低优先级，Driver可能被抢占导致作业失败

技术实现解析

新版本通过在SparkApplication CRD中扩展调度配置，允许分别指定driver和executor的priorityClass。其核心数据结构如下：

spec:
  driver:
    priorityClassName: "high-priority" 
  executor:
    priorityClassName: "low-priority"

这种设计带来了三个显著优势：

1. 资源隔离：Driver可以独占高优先级资源，确保控制平面稳定性
2. 成本优化：Executor使用低优先级资源，提高集群利用率
3. 灵活配置：支持根据作业重要性动态调整优先级策略

最佳实践建议

在实际部署时，建议采用以下策略：

1. 为关键业务Driver设置保障性优先级（如system-cluster-critical）
2. 对批处理作业的Executor使用可抢占优先级（如batch-processing）
3. 通过ResourceQuota限制各优先级类别的总资源用量
4. 结合PodDisruptionBudget确保至少保留最小可用Executor数量

未来演进方向

这一特性为更精细化的资源调度奠定了基础，后续可考虑：

1. 动态优先级调整机制，根据作业阶段自动切换
2. 与K8s弹性资源（如Spot实例）的深度集成
3. 基于实际负载的自动优先级推荐系统

该改进已稳定运行于生产环境，显著提升了Spark作业在共享Kubernetes集群中的可靠性和资源利用率。用户升级到最新版本即可体验这一特性。