Kthena ModelServing

架构设计

为解决Kubernetes原生资源（如Deployment或StatefulSet）在处理多角色协作场景下的局限性，Kthena采用ModelServing → ServingGroup → Role的三层结构，每一层承担不同的职责，共同协作以实现高性能、可扩展的推理服务。

表1 架构层级与职责

层级	管理对象	核心职责
ModelServing	ServingGroup集合	作为全生命周期的统一控制平面，负责维护全局配置一致性，实现版本控制（Revision），提供推理集群的状态查询能力。提供统一接口，管理全局副本和版本。
ServingGroup	Role集合	作为推理服务的独立功能单元，是连接顶层控制与底层执行的逻辑分组。包含完成一次端到端推理所需的所有角色，确保推理逻辑的完整性和独立性。
Role	Pod集合	作为最小的功能执行单元，负责具体的计算任务，由一组具有确定性编号的Pod组成。执行特定的计算或分发任务，例如Prefill和Decode角色的执行。

在Role层级内部，Kthena采用双Pod模板设计，以支持分布式推理场景中的职责解耦，并通过定义特定的环境变量对Pod进行精细化控制和协作。

• Entry Pod：充当流量入口与任务协调器 。负责接收外部请求并分发计算任务。
• Worker Pod：计算执行单元。专注于执行实际的张量计算与推理任务。

  为便于客户在业务中识别Pod的角色身份，控制器将自动为Entry和Worker Pod注入以下关键环境变量。

  表2 关键环境变量

  环境变量	说明
  GROUP_SIZE	定义当前Role实例中Pod的总数，用于协调Pod之间的协作逻辑。
  ENTRY_ADDRESS	Entry Pod的内网地址（格式为Headless Service），用于Worker Pod通信。
  WORKER_INDEX	每个Worker Pod在当前Role实例中的唯一索引，用于身份识别与任务分配。

前提条件

• 已创建CCE Standard/Turbo集群，集群版本建议为v1.29及以上。
• 已安装1.21.5及以上版本的Volcano插件：在CCE控制台“插件中心”中搜索并安装 “Volcano调度器” 插件。

  若使用弹性伸缩功能，需安装1.22.3及以上版本的Volcano插件。

在使用Volcano作为调度器时，建议将集群中所有相关工作负载统一使用Volcano调度，以避免调度冲突。

约束与限制

• ModelServing依赖Volcano调度器插件，若集群未安装该插件，相关功能将无法生效。
• 当前CCE控制台暂不支持图形化创建ModelServing，需通过kubectl或YAML文件进行部署。
• 若使用minRoleReplicas，需确保集群资源充足，否则可能导致作业长期处于Pending状态。

关键特性解析

使用示例：ModelServing负载完整用例（以Nginx负载为例）

本示例包含prefill和decode两个Role，其中prefill角色有2个副本，每个副本包含1个Entry和1个Worker，共两个Pod；Decode角色有3个副本，每个副本包含1个Entry和2个Worker，共3个Pod。关于其他调度特性的描述，请查看关键特性解析。

apiVersion: workload.serving.volcano.sh/v1alpha1
kind: ModelServing
metadata:
  name: sample
  namespace: default
spec:
  schedulerName: volcano
  replicas: 1  # servingGroup replicas
  recoveryPolicy: RoleRecreate # 重启策略
  template:
    restartGracePeriodSeconds: 60
    gangPolicy: # Gang Scheduling策略
      minRoleReplicas:
        prefill: 2
        decode: 1
    roles:
      - name: prefill
        replicas: 2       # role replicas
        entryTemplate:
          spec:
            containers:
              - name: worker
                image: nginx:latest
                resources:
                  limits:
                    cpu: 250m
                    memory: 512Mi
                  requests:
                    cpu: 250m
                    memory: 512Mi
            imagePullSecrets:
            - name: default-secret
        workerReplicas: 1
        workerTemplate:
          spec:
            containers:
              - name: worker
                image: nginx:latest
                resources:
                  limits:
                    cpu: 250m
                    memory: 512Mi
                  requests:
                    cpu: 250m
                    memory: 512Mi
            imagePullSecrets:
            - name: default-secret
      - name: decode
        replicas: 3  # role replicas
        entryTemplate:
          spec:
            containers:
              - name: worker
                image: nginx:latest
                resources:
                  limits:
                    cpu: 250m
                    memory: 512Mi
                  requests:
                    cpu: 250m
                    memory: 512Mi
            imagePullSecrets:
            - name: default-secret
        workerReplicas: 2
        workerTemplate:
          spec:
            containers:
              - name: worker
                image: nginx:latest
                resources:
                  limits:
                    cpu: 250m
                    memory: 512Mi
                  requests:
                    cpu: 250m
                    memory: 512Mi
            imagePullSecrets:
            - name: default-secret

使用示例：自动扩缩容用例（以vllm负载为例）

Kthena采用策略与目标解耦的设计模式，通过两个核心自定义资源（CRD）实现弹性伸缩的灵活配置：

• AutoscalingPolicy：定义扩缩容策略，包含监控指标、目标值、稳定/紧急模式配置、观测窗口等参数。
• AutoscalingPolicyBinding：定义伸缩目标，将策略绑定到具体的ModelServing或Role，并设置副本数限制、指标拉取端点等运行约束。

Pod需以Prometheus兼容格式（例如，vLLM内置的/metrics端点）暴露业务指标，Autoscaler将定期从此端点抓取指标以驱动扩缩容决策。