最初，当我开始设计一个大规模的视频转码平台时，我们的架构仅仅部署在 香港 MEGA-i 数据中心。随着短视频平台内容量的激增，流量逐渐突破了原先架构的承载极限。每次面对高峰期，香港机房的带宽和硬件资源很快就变得捉襟见肘。并且，随着跨境视频传输的需求，全球用户的访问延迟显著增加，系统稳定性也面临挑战。

最初，我尝试了通过 多机房 BGP Anycast 和 NVIDIA GPU 加速 来解决全球加速问题，但随着我们进入多地区部署的需求，发现传统的“单机房”架构已经无法满足跨境电商平台的全球扩展需求。于是，我决定将整个 GPU 转码平台和调度系统 云原生化，并迁移至 边缘云 + 多地域机房架构。

在这篇文章中，我将分享如何将 GPU 转码平台从传统的数据中心架构，迁移到更高效、更灵活的云原生架构，并在多地域机房中部署 GPU 转码服务。

一、机房和基础架构概述

1. 原始机房部署背景

在开始迁移之前，我们的系统运行在 香港 MEGA-i 数据中心，主要使用以下硬件：

• 服务器配置：Dell R740xa + NVIDIA A5000 GPU
• 网络：10Gbps 带宽，BGP 多线（CMI, HGC, PCCW）
• 存储：Ceph 分布式存储，3 台存储节点
• 调度系统：自研基于 K8s 和 NVIDIA GPU Operator 的调度器

然而，随着需求的增加，流量逐渐突破了单机房的带宽，特别是欧美和东南亚的用户请求延迟越来越大，GPU 资源也变得越来越紧张。为了优化这些问题，我开始考虑将平台云原生化，并迁移到更为灵活的 多地域边缘云架构。

2. 新架构设计目标

高可用：跨地域的服务调度，保证全球任何地区用户的快速响应

弹性伸缩：根据实时流量负载自动扩展资源

边缘计算：将视频转码任务更靠近用户，减少跨境带宽使用和延迟

自动化运维：使用 Kubernetes 原生工具简化运维管理

二、迁移到云原生架构的步骤

1. 选择适合的云环境与边缘计算平台

首先，我考虑了以下几种云环境的选择：

边缘云平台：由于视频转码属于高吞吐、低延迟的计算任务，我决定选择 AWS Outposts 和 Google Anthos 等边缘云平台，允许我们将 K8s 集群延伸至多个地域的边缘机房，靠近用户。

多区域机房：为了保证全球用户都能访问到就近的转码节点，我们在 香港、美国、欧洲 等地分别建立了 GPU 节点，并通过 BGP Anycast 来保证最优路由。

我将边缘云作为扩展的核心平台，利用其 本地计算能力 和 低延迟的网络连接，来实现跨地域的 GPU 转码服务。

2. 转码平台的容器化与调度

2.1 容器化部署 GPU 转码服务

为了将 GPU 转码服务 云原生化，首先我们将所有转码任务包装为 Docker 容器。每个容器运行 FFmpeg 加速任务，并且为容器提供 GPU 资源。我们使用了 NVIDIA GPU Operator 来自动管理 GPU 驱动和设备插件。

我们基于 Docker 构建了支持 NVENC 和 CUDA 加速的 FFmpeg 镜像，并推送到 Harbor 仓库：

FROM nvidia/cuda:11.8-runtime-ubuntu22.04

RUN apt update && apt install -y \
  ffmpeg \
  libnpp-dev libx264-dev libx265-dev libfdk-aac-dev

COPY entrypoint.sh /usr/local/bin/

CMD ["ffmpeg"]

每个容器实例中，我们通过 Kubernetes 的 nvidia.com/gpu 调度器来绑定 GPU，并确保每个容器能够访问 NVIDIA GPU 资源：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: transcoder
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: transcoder
          image: my-registry/transcoder:latest
          resources:
            limits:
              nvidia.com/gpu: 1
          command: ["ffmpeg", "-hwaccel", "cuda", "-i", "input.mp4", "-c:v", "h264_nvenc", "-b:v", "5M", "output.mp4"]
      restartPolicy: Always

2.2 跨地域调度与高可用性

为了实现跨地域的负载均衡，我配置了 Kubernetes Federation，允许集群之间共享负载调度任务。我们将每个区域的 Kubernetes 集群加入到联邦中，确保任务可以在最优节点上执行：

Kubernetes Federation：通过配置集群联邦，我们能够跨越多个区域执行任务调度。

BGP Anycast：通过配置 BGP 路由，将全球的用户请求智能路由到负载较低的转码节点。

此外，为了确保高可用性，我们使用 PodAntiAffinity 策略，避免跨区域的 Pod 调度到同一物理机上，提升系统的容错能力。

3. 数据存储与跨地域同步

由于视频转码任务需要大量的输入和输出文件，我们将 Ceph RBD 存储系统迁移到了 AWS S3 + Google Cloud Storage 的混合云存储架构，确保视频数据可以跨地域同步。利用 RadosGW 和 K8s persistent volume，使得每个地区的转码节点都能高效访问源数据。

为了处理转码任务的缓存和临时文件，我们在 边缘计算节点 使用本地 SSD 存储，避免每次任务执行时都去访问云存储。

三、遇到的问题与解决方案

问题 1：GPU 资源调度不平衡

表现：尽管我们使用了 Kubernetes 和 BGP Anycast，但在高峰期某些 GPU 节点资源过度占用，而另一些节点则空闲，导致 GPU 使用效率低。

解决方案：

我们通过 NVIDIA MPS（多进程服务） 启用了每个 GPU 的多进程模式，允许每块 GPU 并发处理多个任务，从而提高 GPU 资源利用率。

使用 Prometheus + Grafana 监控每个节点的 GPU 温度、session 数、显存使用情况，并通过 K8s Horizontal Pod Autoscaler 和 K8s Pod Priority 实现负载感知调度。

问题 2：跨地域数据同步延迟

表现：视频转码时，由于数据同步延迟，任务的开始时间被拖慢，尤其是在欧洲和亚洲之间的传输。

解决方案：

通过 Ceph RBD 和 S3 混合存储，所有视频数据的缓存和临时文件都在本地存储。仅将最终输出文件同步至云端存储，避免了不必要的延迟。

在任务调度时，通过 Locality-Aware Scheduling 优先选择地理位置接近的存储节点。

问题 3：边缘云集群管理复杂

表现：多地域部署后，集群管理复杂，尤其是当节点动态增加或减少时，如何快速在不同机房间调度任务。

解决方案：

我们使用了 K8s Operator 来动态管理边缘云集群中的节点，自动处理节点的注册与注销。

Helm + GitOps：通过 Helm charts 管理部署模板，使用 GitOps 自动同步配置，实现集群的无缝管理。

四、总结与未来展望

通过将整个 GPU 转码平台和调度系统云原生化，我们成功实现了以下目标：

• 弹性伸缩：基于 Kubernetes 和边缘计算平台，能够根据全球流量自动扩展 GPU 资源。
• 跨地域高可用：通过 BGP Anycast 和 Kubernetes Federation，确保了全球任何地区用户的低延迟访问。
• 智能调度：通过负载感知调度，确保 GPU 资源高效利用，避免资源浪费。

未来，我们还计划进一步扩展平台至更多的 多云 环境，增加 AI 视频分析 与 实时流媒体处理 能力，将整个视频转码平台发展成一个全面的 全球视频处理平台。