解锁 Ray 在 Kubernetes 上的弹性伸缩：打造高效、稳定的分布式作业

1. Ray 与 Kubernetes 的"联姻"：为什么需要 Autoscaling？

Ray 的核心魅力在于它的分布式任务调度和 Actor 模型，适合处理动态负载的机器学习训练、推理或大数据处理任务。然而，云上 Kubernetes 环境中的资源管理是个复杂命题：节点资源有限，负载波动频繁，手动调整集群规模显然不现实。Autoscaling 就像给 Ray 装了个智能油门，能根据任务需求动态调整资源，既省钱又高效。

在 Kubernetes 中，Ray 作业通常以 RayCluster 资源的形式部署，结合 Cluster Autoscaler (CA) 和 Horizontal Pod Autoscaler (HPA) 实现节点和 Pod 级别的弹性伸缩。以下是我们要解决的核心问题：

• 何时扩容？ 任务负载激增时，如何快速分配更多节点或 Pod？

• 何时缩容？ 负载降低时，怎样安全释放资源，避免影响运行中的任务？

• 如何避免抢占导致失败？ 设置最小节点数和优雅缩容机制，确保作业稳定性。

• 实例怎么落地？ 提供可复制的配置和代码，降低上手难度。

2. 理解 Ray 的资源需求：任务调度与负载特性

在设计 autoscaling 策略前，先搞清楚 Ray 作业的"脾气"至关重要。Ray 的作业通常分为两类：

1. 计算密集型任务：如深度学习模型训练，需要大量 CPU/GPU 资源，负载高峰通常出现在批量数据处理或梯度计算阶段。

2. 数据密集型任务：如分布式 ETL（提取-转换-加载），对内存和 I/O 需求较高，负载可能因数据量波动而变化。

Ray 的 head 节点 负责任务调度和元数据管理，而 worker 节点 执行具体的计算任务。负载变化可能导致 worker 节点资源不足（触发扩容）或利用率过低（触发缩容）。在 Kubernetes 中，RayCluster 的 Pod 分布在这些节点上，HPA 通过监控 Pod 的资源使用率（如 CPU/内存）调整副本数，而 CA 则根据 Pod 调度需求调整节点数量。

关键点 ：Ray 的任务调度是动态的，作业可能在运行中动态请求资源，因此 autoscaling 策略需要快速响应 且避免频繁抖动。这就要求我们精准设置触发条件和稳定窗口。

3. 扩容策略：让 Ray 作业"火力全开"

触发扩容的信号

Ray 作业的扩容通常由以下场景驱动：

• CPU/内存使用率高：Pod 的 CPU 或内存使用率超过阈值（如 80%），表明当前资源不足。

• 任务队列积压：Ray 的任务调度器检测到待处理任务过多，worker 节点无法及时消化。

• 自定义指标：如 Ray 的任务吞吐量或队列长度，通过 Prometheus 等监控工具暴露。

在 Kubernetes 中，我们主要依赖 HPA 来监控这些指标。以 CPU 使用率为例，HPA 会根据 metrics 字段中的 targetAverageUtilization 决定是否增加 Pod 副本数。如果 Pod 无法调度到现有节点，CA 会上场，请求云厂商（如 AWS、阿里云）创建新节点。

配置 HPA 扩容

假设我们有一个 RayCluster 部署，名为 ray-ml-training，需要根据 CPU 使用率自动扩容。以下是一个 HPA 配置示例：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ray-ml-training-hpa
  namespace: ray-namespace
spec:
  scaleTargetRef:
    apiVersion: ray.io/v1
    kind: RayCluster
    name: ray-ml-training
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15

解析：

• scaleTargetRef 指向 RayCluster 资源，HPA 会调整其 worker Pod 的副本数。

• minReplicas: 2 保证至少有两个 worker Pod，避免单点故障。

• maxReplicas: 10 设置上限，防止资源失控。

• averageUtilization: 80 表示当平均 CPU 使用率超过 80% 时触发扩容。

• stabilizationWindowSeconds: 0 确保扩容立即生效，适合 Ray 作业的突发负载。

实例场景：假设你的 Ray 作业是分布式模型训练，训练数据量突然增加，worker Pod 的 CPU 使用率飙升到 90%。HPA 检测到后，会迅速增加 Pod 副本数（最多翻倍，每 15 秒检查一次）。如果现有节点资源不足，CA 会向云厂商请求新节点。

结合自定义指标

对于 Ray 作业，CPU/内存可能不足以反映任务负载。例如，Ray 的任务队列长度可以通过 Prometheus 暴露为自定义指标。以下是配置自定义指标的 HPA 示例：

metrics:
- type: External
  external:
    metric:
      name: ray_task_queue_length
      selector:
        matchLabels:
          app: ray-ml-training
    target:
      type: AverageValue
      averageValue: 1000

这里，当任务队列长度平均超过 1000 时，HPA 会触发扩容。这种方式特别适合数据驱动的 Ray 作业，能更精准地响应业务需求。

4. 缩容策略：优雅"刹车"以节约成本

缩容的挑战

缩容的目标是在负载降低时释放资源，同时避免中断正在运行的任务 。Ray 作业的 worker 节点可能正在执行长时间运行的任务（如模型训练），直接终止 Pod 会导致任务失败。因此，优雅缩容是设计 autoscaling 策略的核心。

配置 HPA 缩容

HPA 的缩容行为可以通过 scaleDown 字段精细控制。以下是一个示例：

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Pods
      value: 1
      periodSeconds: 600
    - type: Percent
      value: 10
      periodSeconds: 600

解析：

• stabilizationWindowSeconds: 300 表示缩容前需观察 5 分钟，确保负载持续低迷，避免因短暂波动触发缩容。

• policies 定义缩容速率：每 10 分钟最多减少 1 个 Pod 或 10% 的副本数，防止过快缩容导致任务中断。

优雅缩容的实现

Ray 提供了内置机制支持优雅缩容。通过在 RayCluster 配置中启用 enableInTreeAutoscaling，Ray 会与 Kubernetes 的 autoscaler 协同工作，确保缩容时任务被妥善迁移。以下是 RayCluster 的部分配置：

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: ray-ml-training
  namespace: ray-namespace
spec:
  enableInTreeAutoscaling: true
  headGroupSpec:
    # 头节点配置
  workerGroupSpecs:
  - replicas: 2
    minReplicas: 2
    maxReplicas: 10
    groupName: worker-group
    rayStartParams:
      num-cpus: "2"
      num-gpus: "1"

关键点：

• enableInTreeAutoscaling: true 让 Ray 内置 autoscaler 与 HPA 协作，监控任务状态。

• 在缩容时，Ray 会检查 worker 节点的任务状态，确保没有正在运行的任务才允许 Pod 终止。

实例场景：假设训练任务完成，负载下降，HPA 检测到 CPU 使用率低于 20% 持续 5 分钟。它会逐步减少 worker Pod（每次 1 个），Ray 的 autoscaler 确保被终止的 Pod 上的任务已完成或迁移到其他节点。

5. 最小节点设置：为稳定性筑起"防火墙"

为什么需要最小节点？

在云上 Kubernetes 环境中，节点资源由云厂商动态分配。如果节点数缩到 0 或过低，Ray 作业可能因资源不足而失败，尤其是在突发负载时。最小节点数就像一道"防火墙"，确保集群始终有足够的资源应对基本负载。

配置 Cluster Autoscaler

Cluster Autoscaler (CA) 负责节点级别的扩缩容。以下是一个 CA 配置示例（以 AWS 为例）：

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler
  namespace: kube-system
data:
  config: |
    minNodes: 2
    maxNodes: 20
    scaleDownUnneededTime: 15m
    scaleDownUtilizationThreshold: 0.5

解析：

• minNodes: 2 保证集群至少有 2 个节点，避免因缩容过度导致资源不足。

• maxNodes: 20 设置节点上限，控制成本。

• scaleDownUnneededTime: 15m 表示节点利用率低于阈值 15 分钟后才缩容。

• scaleDownUtilizationThreshold: 0.5 表示当节点资源利用率低于 50% 时，CA 考虑缩容。

结合 Ray 的需求

Ray 的 head 节点通常需要固定资源，建议将其调度到专用节点（通过节点亲和性配置）。Worker 节点的最小数量应根据作业的基线负载确定。例如，一个分布式训练任务需要至少 2 个 worker 节点来保证并行性，可在 RayCluster 中设置 minReplicas: 2。

实例场景：你的 Ray 作业需要稳定的 GPU 资源用于推理任务。通过设置 minNodes: 2 和 minReplicas: 2，即使在低负载时，集群也能保持至少 2 个节点和 2 个 worker Pod，确保推理任务不中断。

6. 用 Prometheus 点亮 Ray 的"监控之眼"

监控是 autoscaling 的灵魂，没有精准的数据，HPA 和 CA 就像蒙着眼开车。Ray 作业的动态负载需要更细粒度的监控，而 Prometheus 作为 Kubernetes 生态的监控"神器"，能帮我们捕捉 Ray 的运行状态，从 CPU/内存到任务队列长度，甚至是自定义指标。

配置 Prometheus 监控 Ray

要让 Prometheus 抓取 Ray 作业的指标，首先需要在 RayCluster 中启用 metrics 暴露。Ray 内置了 Prometheus 兼容的端点，通常在 head 节点和 worker 节点的 /metrics 路径上。以下是一个 RayCluster 配置片段，确保 metrics 可用：

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: ray-ml-training
  namespace: ray-namespace
spec:
  headGroupSpec:
    rayStartParams:
      metrics-port: "8080"
    template:
      spec:
        containers:
        - name: ray-head
          ports:
          - containerPort: 8080
            name: metrics
  workerGroupSpecs:
  - groupName: worker-group
    rayStartParams:
      metrics-port: "8080"
    template:
      spec:
        containers:
        - name: ray-worker
          ports:
          - containerPort: 8080
            name: metrics

解析：

• metrics-port: "8080" 告诉 Ray 在 8080 端口暴露 Prometheus 格式的指标。

• 在 template.spec.containers.ports 中声明端口，确保 Kubernetes Service 能访问。

接下来，配置 Prometheus 的 ServiceMonitor，自动发现 Ray 节点的 metrics 端点：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: ray-metrics
  namespace: ray-namespace
spec:
  selector:
    matchLabels:
      app: ray-ml-training
  endpoints:
  - port: metrics
    path: /metrics
    interval: 15s

小贴士：确保 Prometheus Operator 已部署在集群中，否则 ServiceMonitor 无法工作。如果你的集群规模较大，建议为 Ray 作业设置独立的命名空间，方便隔离监控数据。

关键指标一览

Ray 暴露的指标中，以下几个对 autoscaling 尤其重要：

• ray_tasks：任务的运行状态（如 pending、running、failed），可用于检测任务积压。

• ray_object_store_memory：对象存储的内存使用量，适合内存密集型任务的监控。

• ray_node_cpu_utilization：节点的 CPU 使用率，与 HPA 的 CPU 指标对齐。

• ray_scheduling_queue_length：任务调度队列长度，反映系统负载压力。

实例场景：假设你的 Ray 作业在处理实时数据流，任务队列长度（ray_scheduling_queue_length）突然飙升到 2000，表明 worker 节点处理能力不足。Prometheus 捕获这一指标后，HPA 根据自定义指标触发扩容，增加 worker Pod，迅速缓解压力。

7. KEDA：为 Ray 作业注入"事件驱动"魔法

HPA 虽然强大，但对复杂负载的响应可能不够灵活。KEDA（Kubernetes Event-Driven Autoscaling） 就像给 Ray 作业加了个"涡轮增压器"，能基于事件（如消息队列长度、任务吞吐）驱动扩缩容，特别适合 Ray 的动态任务模型。

为什么选择 KEDA？

HPA 主要依赖 CPU/内存或简单自定义指标，而 KEDA 支持更丰富的触发器，比如 Kafka 队列长度、Redis 列表长度，甚至 Ray 内部的任务队列指标。KEDA 与 Ray 的结合，能让 autoscaling 更贴近业务需求。

配置 KEDA 驱动 Ray 扩容

假设你的 Ray 作业处理 Kafka 消息流，需要根据队列长度自动调整 worker Pod 数量。以下是一个 KEDA ScaledObject 配置：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: ray-kafka-scaler
  namespace: ray-namespace
spec:
  scaleTargetRef:
    apiVersion: ray.io/v1
    kind: RayCluster
    name: ray-ml-training
  minReplicaCount: 2
  maxReplicaCount: 12
  triggers:
  - type: kafka
    metadata:
      bootstrapServers: kafka-broker:9092
      consumerGroup: ray-consumer
      topic: data-stream
      lagThreshold: "1000"

解析：

• scaleTargetRef 指向 RayCluster，KEDA 会调整其 worker Pod 数量。

• minReplicaCount: 2 和 maxReplicaCount: 12 定义副本数范围。

• triggers 使用 Kafka 触发器，当队列中未消费消息（lag）超过 1000 时，KEDA 增加 Pod 数量。

实例场景：你的 Ray 作业从 Kafka 读取实时用户行为数据，训练推荐模型。某天流量激增，Kafka 队列积压了 5000 条消息。KEDA 检测到 lag 超过阈值，迅速增加 4 个 worker Pod，任务吞吐恢复正常，模型训练不中断。

KEDA 与 HPA 的协同

KEDA 和 HPA 可以共存，但需避免冲突。建议为 KEDA 和 HPA 设置不同的触发条件，例如：

• HPA 负责 CPU/内存驱动的扩缩容。

• KEDA 负责事件驱动的扩缩容（如 Kafka 队列或 Ray 任务队列）。

通过在 ScaledObject 中设置 cooldownPeriod（如 300 秒），KEDA 能有效避免频繁扩缩导致的抖动。

8. 优雅缩容的"艺术"：保护 Ray 作业不翻车

缩容听起来简单，但稍不留神就可能让 Ray 作业"翻车"。一个运行中的分布式训练任务被突然终止，可能导致数小时的计算成果付诸东流。优雅缩容的目标是像"轻盈落地的舞者"一样，确保任务安全迁移或完成后再释放资源。

Ray 的内置优雅缩容机制

Ray 提供了一个强大的功能：Ray Autoscaler 与 Kubernetes 的协作。当启用 enableInTreeAutoscaling 时，Ray 会监控每个 worker 节点的任务状态，只有在节点上的任务全部完成或迁移后，才允许 Kubernetes 终止 Pod。

以下是启用优雅缩容的 RayCluster 配置：

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: ray-ml-training
spec:
  enableInTreeAutoscaling: true
  workerGroupSpecs:
  - groupName: worker-group
    minReplicas: 2
    maxReplicas: 10
    rayStartParams:
      graceful-shutdown-timeout-s: "300"

解析：

• graceful-shutdown-timeout-s: "300" 给 worker 节点 5 分钟的宽限期，允许任务完成或迁移。

• Ray 的 autoscaler 会与 Kubernetes 的 Pod Disruption Budget (PDB) 协作，确保缩容时不会破坏最小可用副本。

配置 Pod Disruption Budget

为进一步保护 Ray 作业，建议为 RayCluster 配置 PDB：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: ray-ml-training-pdb
  namespace: ray-namespace
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: ray-ml-training

解析：

• minAvailable: 2 保证至少 2 个 worker Pod 始终可用，防止缩容过度。

• PDB 与 Ray 的优雅缩容机制结合，确保任务稳定性。

实例场景：你的 Ray 作业在运行一个多阶段的分布式 ETL 任务，负载降低时，HPA 触发缩容。Ray 检测到一个 worker Pod 仍在处理数据分片，便延迟终止，直到任务完成。PDB 同时保证集群始终有 2 个可用 Pod，避免任务中断。

9. 故障排查：当 Autoscaling "不听话"时怎么办？

即使设计再完美的 autoscaling 策略，也难免遇到"调皮"的问题：扩容太慢、缩容误杀任务，或者 CA 没有按预期添加节点。以下是一些常见问题和解决办法，助你快速定位并修复。

问题 1：扩容反应迟缓

症状 ：负载激增，但新 Pod 或节点迟迟未上线。
可能原因：

• HPA 的 stabilizationWindowSeconds 设置过长。

• CA 的节点启动时间受云厂商限制（例如，AWS EC2 实例启动需 2-5 分钟）。

• Ray 任务调度器未及时分配任务到新节点。

解决办法：

• 将 HPA 的 scaleUp.stabilizationWindowSeconds 调低（如 0 或 15 秒）。

• 使用更快的节点类型（如 AWS 的预留实例或阿里云的抢占式实例）。

• 检查 Ray 的 head 节点日志（kubectl logs -l app=ray-ml-training --container=ray-head），确保任务调度正常。

问题 2：缩容导致任务失败

症状 ：缩容时，任务突然中断，日志显示 worker 节点被意外终止。
可能原因：

• 缺少 PDB 或 graceful-shutdown-timeout-s 设置不足。

• Ray 的 autoscaler 未正确检测任务状态。

解决办法：

• 确保 PDB 配置正确，设置合理的 minAvailable。

• 增加 graceful-shutdown-timeout-s（如 600 秒），给任务更多时间完成。

• 检查 Ray 的 metrics（如 ray_tasks_failed），确认是否有异常任务。

问题 3：节点无法调度

症状 ：HPA 增加了 Pod 副本，但 Pod 处于 Pending 状态，CA 未添加新节点。
可能原因：

• 节点池资源不足，或云厂商配额限制。

• 节点选择器或亲和性规则导致 Pod 无法调度。

解决办法：

• 检查云厂商的配额（如 AWS EC2 实例上限），必要时申请提升。

• 验证 RayCluster 的 nodeSelector 和 affinity 配置，确保与节点池匹配。

• 启用 CA 日志（kubectl logs -n kube-system -l app=cluster-autoscaler），查看调度失败原因。

实例场景：你的 Ray 作业因流量高峰触发扩容，但新 Pod 卡在 Pending 状态。检查发现 AWS 配额已用尽，CA 无法添加节点。提升配额后，CA 成功启动新节点，任务恢复正常。

10. 高级 Autoscaling 优化：让 Ray 作业"飞得更高"

到了这一章，我们已经掌握了 Ray 在 Kubernetes 上的基本扩缩容套路，但要让作业像"火箭"一样高效起飞，还得在 autoscaling 策略上加点"高级燃料"。这一节，我们将聚焦多集群部署、节点亲和性优化和动态资源分配，解锁 Ray 作业的极致性能。

多集群部署：打破单集群瓶颈

在高负载场景下，单个 Kubernetes 集群可能因资源限制或地域延迟而捉襟见肘。多集群部署让 Ray 作业跨集群协同工作，既能提升容错性，又能利用不同地域的资源优势。例如，训练任务可以在 GPU 丰富的集群上运行，而推理任务可以部署在低成本的 CPU 集群上。

实现方式 ：

Ray 支持跨集群的任务调度，通过 Ray Global Scheduler 将任务分发到多个 Kubernetes 集群。每个集群部署一个独立的 RayCluster，但共享同一个 Ray 作业入口点。以下是配置多集群的关键步骤：

1. 部署 Ray Global Scheduler：在主集群中运行一个全局调度器，负责协调任务分配。

2. 配置集群互联：确保各集群的 Ray head 节点可以通过网络通信（例如通过 Service Mesh 或 VPC 对等连接）。

3. 设置资源标签：为每个集群的节点打上标签（如 cluster=training 或 cluster=inference），方便任务路由。

以下是一个 RayCluster 配置，指定节点亲和性以区分训练和推理集群：

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: ray-training-cluster
  namespace: ray-namespace
spec:
  headGroupSpec:
    template:
      spec:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cluster
                operator: In
                values:
                - training
  workerGroupSpecs:
  - groupName: worker-group
    minReplicas: 2
    maxReplicas: 20
    template:
      spec:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cluster
                operator: In
                values:
                - training

解析：

• nodeAffinity 确保 head 和 worker Pod 只调度到标有 cluster=training 的节点。

• 推理集群可类似配置，标签改为 cluster=inference。

实例场景：你的 Ray 作业需要在 AWS 的 us-west-2 运行训练（GPU 资源丰富），而在 ap-southeast-1 运行推理（延迟低）。通过多集群部署，训练任务利用 us-west-2 的 GPU 节点，推理任务则调度到 ap-southeast-1 的 CPU 节点，HPA 和 CA 在各自集群独立工作，任务效率翻倍。

动态资源分配

Ray 作业的资源需求可能随任务阶段变化，例如模型训练的初期需要更多 GPU，后期需要更多内存来处理数据缓存。动态资源分配可以通过调整 RayCluster 的 rayStartParams 实现。例如：

workerGroupSpecs:
- groupName: worker-group
  rayStartParams:
    num-cpus: "4"
    num-gpus: "1"
    memory: "8Gi"
  template:
    spec:
      containers:
      - name: ray-worker
        resources:
          limits:
            cpu: "4"
            memory: "8Gi"
            nvidia.com/gpu: "1"
          requests:
            cpu: "2"
            memory: "4Gi"
            nvidia.com/gpu: "1"

解析：

• requests 定义最小资源需求，limits 设置上限，允许 Kubernetes 在资源紧张时灵活调度。

• 通过定期更新 rayStartParams，可以动态调整每个 worker 的资源分配。

小贴士：结合 Prometheus 监控 ray_object_store_memory，当内存使用率超过 80% 时，动态增加 memory 参数，触发 Pod 重启并重新分配资源。

11. GPU 资源调度：让 Ray 作业"火力全开"

GPU 是 Ray 作业的"核武器"，尤其在深度学习任务中，合理调度 GPU 资源能显著提升性能。但 Kubernetes 对 GPU 的支持需要额外配置，autoscaling 策略也要考虑 GPU 的特殊性。

配置 GPU 支持

在 Kubernetes 中，GPU 资源通过设备插件（如 NVIDIA GPU 插件）暴露。确保节点已安装 NVIDIA 驱动和 nvidia-container-toolkit，然后在 RayCluster 中声明 GPU 需求：

workerGroupSpecs:
- groupName: gpu-worker-group
  replicas: 2
  minReplicas: 2
  maxReplicas: 10
  rayStartParams:
    num-gpus: "1"
  template:
    spec:
      containers:
      - name: ray-worker
        resources:
          limits:
            nvidia.com/gpu: "1"
          requests:
            nvidia.com/gpu: "1"

解析：

• num-gpus: "1" 告诉 Ray 每个 worker 需要 1 个 GPU。

• nvidia.com/gpu 是 Kubernetes 识别 GPU 资源的标准字段。

Autoscaling 与 GPU

HPA 和 CA 默认不直接支持 GPU 使用率的监控，但可以通过自定义指标实现。例如，使用 NVIDIA 的 DCGM Exporter 暴露 GPU 使用率（DCGM_FI_DEV_GPU_UTIL），然后配置 HPA：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ray-gpu-hpa
  namespace: ray-namespace
spec:
  scaleTargetRef:
    apiVersion: ray.io/v1
    kind: RayCluster
    name: ray-ml-training
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: DCGM_FI_DEV_GPU_UTIL
      target:
        type: AverageValue
        averageValue: 80

解析：

• 当平均 GPU 使用率超过 80% 时，HPA 增加 GPU worker Pod 数量。

• CA 随后根据 Pod 调度需求添加 GPU 节点。

实例场景：你的 Ray 作业在训练一个大型 transformer 模型，GPU 使用率持续飙升到 90%。HPA 检测到后，增加 2 个 GPU worker Pod，CA 启动新的 GPU 节点（例如 AWS 的 g5.xlarge 实例），训练任务顺利加速。

注意事项：

• GPU 节点成本较高，建议设置 maxReplicas 和 maxNodes 上限，避免预算超支。

• 使用节点亲和性（如 nvidia.com/gpu=true）确保 GPU Pod 只调度到 GPU 节点。

12. 成本控制：让 Ray 作业"省钱又高效"

云上运行 Ray 作业，成本是个绕不开的话题。Autoscaling 的终极目标不仅是性能，还有性价比。通过优化节点类型、利用抢占式实例和设置缩容策略，我们可以在保证性能的同时大幅降低账单。

使用抢占式实例

云厂商如 AWS、阿里云提供抢占式实例（Spot Instances），价格比按需实例低 50%-70%，但可能被随时回收。Ray 的容错机制（通过 checkpoint 和任务重试）非常适合搭配抢占式实例。

配置抢占式实例 ：

在 CA 中启用抢占式节点池（以 AWS 为例）：

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler
  namespace: kube-system
data:
  config: |
    nodeGroups:
    - name: spot-nodes
      minSize: 1
      maxSize: 10
      instanceType: g5.xlarge
      spot: true

解析：

• spot: true 告诉 CA 使用抢占式实例。

• minSize: 1 确保至少有一个节点，防止任务完全中断。

为确保 Ray 作业在节点抢占时不失败，启用 Ray 的 fault_tolerance 机制：

rayStartParams:
  fault-tolerance: "true"
  max-task-retries: "3"

实例场景：你的 Ray 作业使用 AWS 抢占式 g5.xlarge 实例运行分布式训练。某节点被回收，Ray 检测到后自动将任务迁移到其他节点，最多重试 3 次，确保训练不中断，成本却只有按需实例的 60%。

优化缩容策略

缩容是省钱的关键，但要避免过于激进。以下是一些实用技巧：

• 设置合理的缩容延迟：CA 的 scaleDownUnneededTime 设为 15-30 分钟，确保负载稳定后再释放节点。

• 优先缩容低利用率节点：CA 的 scaleDownUtilizationThreshold 设为 0.4，优先移除利用率低于 40% 的节点。

• 混合节点类型：结合按需实例（用于 head 节点）和抢占式实例（用于 worker 节点），平衡稳定性和成本。

实例场景：通过将 head 节点部署在按需实例上，worker 节点使用抢占式实例，你的 Ray 作业在高负载时扩展到 10 个 GPU 节点，低负载时缩减到 2 个，月度账单降低 40%，性能却丝毫不打折扣。

16. 长期维护：让 Autoscaling 策略"常青不衰"

设计好 Ray 作业的 autoscaling 策略只是第一步，让它像老树般常青，需要持续的监控、日志分析和告警机制。Kubernetes 和 Ray 的动态环境里，问题可能悄无声息地冒出来，比如节点调度失败、任务积压，或者成本默默超支。这一章，我们将探讨如何通过日志、告警和自动化运维，让 autoscaling 策略长期稳定运行。

日志分析：找到"隐藏的刺"

Ray 和 Kubernetes 的日志是排查问题的"金矿"。Ray 的 head 节点和 worker 节点会记录任务调度、资源分配和错误信息，而 Kubernetes 的组件（如 CA 和 HPA）则记录扩缩容决策。

关键日志来源：

• Ray head 节点日志：查看任务调度状态、失败原因（如 ray.exceptions.TaskExecutionException）。

  kubectl logs -l app=ray-ml-training --container=ray-head -n ray-namespace

• Ray worker 节点日志：检查任务执行细节和资源瓶颈。

  kubectl logs -l app=ray-ml-training --container=ray-worker -n ray-namespace

• Cluster Autoscaler 日志：分析节点扩缩容的决策过程。

  kubectl logs -n kube-system -l app=cluster-autoscaler

• Prometheus metrics 日志：结合 Grafana 仪表盘，查看指标趋势（如 ray_tasks_failed 或 ray_node_cpu_utilization）。

日志分析技巧：

• 使用 ELK Stack 或 Loki 聚合日志，设置关键词过滤（如 "error" 或 "out of memory"）。

• 定期检查 Ray 的 raylet 日志，关注任务调度延迟或节点失联问题。

• 结合 Prometheus Alertmanager，监控异常指标（如任务失败率超过 5%）。

实例场景：你的 Ray 作业突然出现任务失败，日志显示 OutOfMemoryError。通过 Loki 搜索发现多个 worker 节点的内存使用率接近 100%。调整 RayCluster 的 memory 参数（从 8Gi 增加到 12Gi），并设置告警规则（内存使用率 > 90% 时触发），问题得以解决，作业恢复稳定。

告警设置：让问题"无处遁形"

告警是长期维护的"哨兵"。通过 Prometheus Alertmanager，可以为 Ray 作业配置多维度告警规则，覆盖性能、稳定性与成本。

推荐告警规则：

• 任务积压：当 ray_scheduling_queue_length > 2000 持续 5 分钟，触发告警，提示需要扩容。

  groups:
  - name: ray-alerts
    rules:
    - alert: HighTaskQueueLength
      expr: ray_scheduling_queue_length{app="ray-ml-training"} > 2000
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Ray task queue length too high"
        description: "Task queue length for {{ $labels.app }} exceeds 2000 for 5 minutes."

• 节点利用率低：当 ray_node_cpu_utilization < 20% 持续 30 分钟，提示缩容以节省成本。

• 任务失败率高：当 ray_tasks_failed > 10 持续 10 分钟，触发告警，可能是代码 bug 或资源不足。

小贴士：将告警集成到 Slack 或 PagerDuty，确保团队能及时响应。设置多级告警（如 warning 和 critical），避免"狼来了"式的告警疲劳。

实例场景：某晚，Ray 作业的任务队列长度激增，触发 Alertmanager 告警，通知运维团队。检查发现数据输入量异常增加，HPA 已自动扩容到 15 个 worker Pod，但仍不足。手动调整 maxReplicas 到 25，问题解决，告警系统成功避免了服务中断。

自动化运维

手动排查问题太累？自动化运维能让你的 Ray 集群像"无人驾驶"一样省心。以下是一些实用工具：

• KubeRay Operator：自动管理 RayCluster 的生命周期，简化部署和升级。

• Argo Workflows：编排 Ray 作业的部署和监控流程，自动触发配置更新。

• Terraform：用 IaC（基础设施即代码）管理 Kubernetes 集群和节点池，确保 autoscaling 配置可重复部署。

实例场景：通过 Terraform 定义 CA 和 RayCluster 配置，团队在 10 分钟内将 autoscaling 策略从测试集群复制到生产环境，省去手动配置的麻烦，部署效率提升 80%。

17. 跨云部署的挑战：让 Ray 作业"全球开花"

云上运行 Ray 作业，不一定非得局限在单一云厂商。跨云部署能利用 AWS 的 GPU 算力、阿里云的低成本存储和 Google Cloud 的高速网络，打造一个"全球化的" Ray 集群。但跨云也带来网络延迟、数据同步和成本管理的挑战。这一节，我们来破解这些难题。

网络延迟与任务调度

跨云部署的核心问题是网络延迟。Ray 的 head 节点需要频繁与 worker 节点通信，跨云的高延迟（通常 50-200ms）可能拖慢任务调度。

解决方案：

• 本地化调度：通过 nodeAffinity 和 scheduling_strategy，将任务优先调度到同一云厂商的节点。

  workerGroupSpecs:
  - groupName: aws-worker
    template:
      spec:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values:
                - us-west-2

• Federated Ray Cluster：在每个云厂商部署一个 RayCluster，通过 Ray 的 Global Control Store 协调任务。

• Service Mesh：使用 Istio 或 Linkerd 优化跨云通信，降低延迟。

实例场景：你的 Ray 作业在 AWS 和阿里云上运行，AWS 提供 GPU 训练，阿里云处理数据预处理。初始部署时，跨云任务调度延迟高达 150ms。通过部署 Istio 和本地化调度，延迟降至 30ms，训练效率提升 25%。

数据同步与一致性

跨云部署需要频繁同步数据（如模型权重、训练数据）。Ray 的对象存储（ray.put 和 ray.get）依赖高效的存储后端。

解决方案：

• 分布式存储：使用 MinIO 或 Ceph 作为跨云对象存储，缓存 Ray 的中间数据。

• 增量同步：通过 Ray 的 fault-tolerance 机制，仅同步变更数据，减少带宽消耗。

• CDN 加速：将静态数据（如数据集）存储在云厂商的 CDN，降低跨云传输成本。

实例场景：你的 Ray 作业在 AWS 和 Google Cloud 之间同步模型权重，初始同步耗时 10 分钟。通过部署 MinIO 和增量同步，同步时间降至 2 分钟，带宽成本降低 60%。

成本管理

跨云部署容易导致成本失控，尤其当多个云厂商的计费规则不同。以下是优化建议：

• 统一监控：使用 Prometheus 监控跨云资源使用率，设置成本告警。

• 优先使用低成本云：将计算密集任务部署在高性能云（如 AWS），将存储密集任务部署在低成本云（如阿里云）。

• 抢占式实例：在非关键任务中使用抢占式实例，降低总体成本。

实例场景：通过将数据预处理任务迁移到阿里云的低成本实例，训练任务保留在 AWS 的 GPU 节点，你的 Ray 作业月度成本降低 30%，性能却未受影响。

18. 端到端案例：从代码到部署的实时推荐系统

场景描述

你为一家电商平台开发实时推荐系统，使用 Ray Serve 处理推理请求，Ray Data 处理数据预处理。系统特点：

• 负载模式：高峰期（如促销活动）每秒处理 10 万请求，低谷期仅 1 万请求。

• 资源需求：推理需要 GPU，数据预处理需要 CPU 和内存。

• 目标：响应延迟 < 100ms，成本控制在预算内。

步骤 1：Ray Serve 推理代码

以下是 Ray Serve 的推理服务代码，使用预训练模型提供推荐：

import ray
from ray import serve
from fastapi import FastAPI

app = FastAPI()

@serve.deployment(num_replicas=2, ray_actor_options={"num_gpus": 1})
@serve.ingress(app)
class RecommendationModel:
    def __init__(self):
        self.model = load_model("pretrained_model")

    @app.post("/recommend")
    async def recommend(self, user_data: dict):
        return self.model.predict(user_data)

serve.run(RecommendationModel.bind(), name="recommendation")

解析：

• num_replicas=2 初始部署 2 个推理副本。

• num_gpus=1 每个副本需要 1 个 GPU。

步骤 2：RayCluster 部署

部署 RayCluster，支持 CPU 和 GPU worker 组：

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: ray-recommendation
  namespace: ray-namespace
spec:
  enableInTreeAutoscaling: true
  headGroupSpec:
    template:
      spec:
        containers:
        - name: ray-head
          resources:
            requests:
              cpu: "8"
              memory: "16Gi"
  workerGroupSpecs:
  - groupName: cpu-worker
    minReplicas: 4
    maxReplicas: 20
    rayStartParams:
      num-cpus: "8"
    template:
      spec:
        containers:
        - name: ray-worker
          resources:
            requests:
              cpu: "8"
              memory: "16Gi"
  - groupName: gpu-worker
    minReplicas: 2
    maxReplicas: 10
    rayStartParams:
      num-gpus: "1"
    template:
      spec:
        containers:
        - name: ray-worker
          resources:
            requests:
              nvidia.com/gpu: "1"

步骤 3：HPA 和 KEDA 配置

结合 HPA（CPU 驱动）和 KEDA（请求队列驱动）实现 autoscaling：

# HPA 配置
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ray-recommendation-hpa
spec:
  scaleTargetRef:
    apiVersion: ray.io/v1
    kind: RayCluster
    name: ray-recommendation
  minReplicas: 4
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80

# KEDA 配置
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: ray-recommendation-scaler
spec:
  scaleTargetRef:
    apiVersion: ray.io/v1
    kind: RayCluster
    name: ray-recommendation
  minReplicaCount: 4
  maxReplicaCount: 20
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      metricName: ray_serve_request_queue
      threshold: "1000"

步骤 4：监控与告警

部署 Prometheus 和 Alertmanager，监控请求队列长度和推理延迟：

groups:
- name: ray-recommendation-alerts
  rules:
  - alert: HighRequestQueue
    expr: ray_serve_request_queue{app="ray-recommendation"} > 1000
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "High request queue for recommendation"
      description: "Request queue for {{ $labels.app }} exceeds 1000 for 5 minutes."

运行效果

实例场景：促销期间，推荐请求激增到每秒 8 万，ray_serve_request_queue 超过 2000。KEDA 迅速扩展到 15 个 CPU worker 和 8 个 GPU worker，CA 添加 10 个节点，响应延迟稳定在 80ms。低谷期，HPA 缩减到 4 个 CPU worker 和 2 个 GPU worker，成本降低 50%，整个系统运行如丝般顺滑。