Kubernetes 中使用 CRIU 实现 GPU进程实时迁移：基础篇

原文: Kubernetes 中使用 CRIU 实现 GPU进程实时迁移：基础篇

CRIU 概述

CRIU，全称 (checkpoint/restore in userspace)，是运行在 Linux 操作系统上的一个软件工具，在用户空间实现 checkpoint/restore 功能。

使用 CRIU 可以冻结一个正在运行的程序，并且 checkpoint 到程序关联的一系列文件，然后用这些文件在任何主机上重新恢复这个程序被冻结时的那个点，换句话说，也就是对正在运行程序环境的一个备份与恢复；这些资源包括：

文件描述信息（/proc/pid/fd/ 和 /proc/pid/fdinfo/ ）
管道参数信息
内存表（ /proc/pid/maps/ 和 /proc/pid/map_files/ ）
线程信息

下图是 CRIU 的工作原理图，这里只是做一个简单科普，不做过多深入。

图片来源网络

Kubernete CRIU

功能概述

Kubernetes v1.25 引入了容器检查点 API 作为 Alpha 功能，并在 Kubernetes v1.30 中达到了 beta 版本。这提供了一种无需停止 Pod 即可备份和恢复运行在 Pod 中的容器的方法。此功能主要针对安全性和取证分析，但一般的备份和恢复是任何 Kubernetes 用户都可以利用的。

Container Checkpointing

容器检查点是 Kubernetes 中的一项功能，允许创建正在运行的容器状态的快照。此快照包括有关容器当前状态的所有内容，例如其内存、文件描述符和其他重要数据。

关键是，可以在不停止容器的情况下拍摄此快照，这意味着应用程序将继续不间断地运行。

此功能特别适用于：

取证分析：您可以在沙盒环境中分析快照，以调查任何问题或安全问题，而不会影响原始容器。
备份和还原：您可以使用快照在发生故障时将容器还原到以前的状态，从而确保将停机时间和数据丢失降至最低。

Kubelet Checkpoint API

Kubelet Checkpoint API 是 Kubernetes 中容器 checkpointing 过程中的一个重要组成部分。Kubelet 是在 Kubernetes 集群中的每个节点上运行的主节点代理。它负责管理其节点上容器的生命周期，包括启动、停止和监控它们。

Kubelet 检查点 API 在容器检查点中的作用：

启动检查点：Kubelet 检查点 API 允许用户为正在运行的容器启动检查点过程。当发出检查点请求时，Kubelet 会与 CRIU 交互以捕获容器的状态。
存储检查点：创建检查点后，Kubelet 检查点 API 会确保检查点数据得到安全存储。此数据包括容器的内存、文件描述符和其他元数据，这些元数据对于以后还原容器至关重要。
恢复容器：Kubelet 检查点 API 还有助于从检查点恢复容器。发出还原请求时，Kubelet 使用 CRIU 加载检查点数据并从其保存状态恢复容器。
管理检查点数据：API 提供了管理检查点数据的机制，例如列出可用的检查点、删除旧检查点以及验证检查点数据的完整性。这有助于维护一个有序和高效的检查点系统。
确保一致性：Kubelet Checkpoint API 确保 checkpoint 和恢复过程一致可靠。它处理 Kubelet 和 CRIU 之间的协调，确保准确捕获和恢复容器的状态。

CRIU & Kubernetes 实践

先决条件

CRI-O 配置：要将检查点与 CRI-O 一起使用，需要使用命令行选项 --enable-criu-support=true 启动运行时。

下面我们创建一个示例：创建检查点并恢复它

运行 Pod

$ kubectl run nginx --image=nginx

创建 Checkpoint

curl -sk -X POST "https://localhost:10250/checkpoint/default/nginx/nginx" \
--key /etc/kubernetes/pki/apiserver-kubelet-client.key \
--cacert /etc/kubernetes/pki/ca.crt \
--cert /etc/kubernetes/pki/apiserver-kubelet-client.crt

检查目录

$ ls -l /var/lib/kubelet/checkpoints/
total 4219
-rw------- 1 root root 5834428 Sep 08 11:44 checkpoint-nginx_default-nginx-2024-09-08T11:44:52Z.tar

验证容器是否还在运行

$ crictl ps --name nginx
CONTAINER      IMAGE                          CREATED       STATE    NAME       ATTEMPT  POD ID    POD
3bea98a12  docker.io/library/nginx@sha256:...  2m ago       Running  nginx       0     3bea98a12  nginx

恢复: 要直接在 Kubernetes 中恢复之前检查点的容器，需要将检查点存档转换为可以推送到注册表的镜像。转换本地检查点存档

newcontainer=$(buildah from scratch)
$ buildah add $newcontainer /var/lib/kubelet/checkpoints/checkpoint-nginx_default-nginx-2024-08-09T11:44:13Z.tar /
$ buildah config --annotation=io.kubernetes.cri-o.annotations.checkpoint.name=nginx $newcontainer
$ buildah commit $newcontainer localhost/checkpoint-image:latest

将镜像推送到注册表

$ buildah push localhost/checkpoint-image:latest container-image-registry.example/user/checkpoint-image:latest

使用checkpoint 镜像去创建 Pod

apiVersion: v1
kind: Pod
metadata:
    name: example-nginx
spec:
    containers:
    - name: nginx
        image: container-image-registry.example/user/checkpoint-image:latest
    nodeName: <destination-node>

CRI-O 检测到 container-image-registry.example/user/checkpoint-image:latest 镜像是对检查点数据的引用，而不是普通映像。然后，CRI-O 获取检查点数据并从该指定检查点恢复容器，而不是通常的步骤来创建和启动容器。

缺点

这个方案目前还不成熟，还存在一些问题；

不能动态的进行 Restoring 恢复；而是需要通过构建镜像的方式来实现。
只能保存 CPU、Memory、File 相关的这些资源，还不能实现 GPU 任务的保存。

cuda-checkpoint

功能概述

CUDA 的检查点和恢复功能通过名为 cuda-checkpoint 的命令行实用程序公开，该实用程序可用于在正在运行的 Linux 进程中以透明方式检查点和恢复 CUDA 状态，同时也可以与开源检查点实用程序 CRIU（用户空间中的检查点/恢复）相结合，以完全检查点 CUDA 应用程序。

由于 NVIDIA GPU 提供的功能超出了标准 Linux 内核的功能，因此 CRIU 无法管理它们。cuda-checkpoint 增加了此功能，因此可以与 CRIU 一起使用来检查点和恢复 CUDA 应用程序。

使用原理

cuda-checkpoint 检查点并恢复单个 Linux 进程的 CUDA 状态。cuda-checkpoint 实用程序支持显示驱动程序版本 550 及更高版本，位于此仓库的 bin 目录中。

localhost$ cuda-checkpoint --help
CUDA checkpoint and restore utility.
Version 570.86.10. Copyright (C) 2025 NVIDIA Corporation. All rights reserved.

Operations:
--get-state --pid <pid>
        Prints the current checkpoint state of the process specified by <pid>

--action lock | checkpoint | restore | unlock --pid <pid> [--timeout <ms>]
        Performs the specified action on <pid>.
        For the lock action a timeout can be provided, the lock operation will wait up to <ms> milliseconds for the operation to succeed.

--toggle --pid <pid>
        Toggles the CUDA state in the specified process between the running and checkpointed states

--get-restore-tid --pid <pid>
        Retrieves the CUDA restore thread ID of the process specified by <pid>

Options:
--pid|-p <pid>
        The pid upon which to perform the operation

--timeout|-t <timeout>
        Optional timeout that can be specified for the lock action in milliseconds

--help|-h
        Print this help message

cuda-checkpoint 二进制文件可以在暂停和运行之间切换进程（由 PID 指定）的 CUDA 状态。从运行到暂停的过渡称为暂停，相反的过渡称为恢复。

Checkpoint 操作流程：

进程的 CUDA 状态最初是 running。当使用 cuda-checkpoint 在进程中暂停 CUDA 时：

任何启动工作、管理资源或以其他方式影响 GPU 状态的 CUDA 驱动程序 API 都将被锁定;
继续完成已提交的 CUDA 工作，包括 stream callback;
设备内存被复制到主机中，由 CUDA 驱动程序管理的分配中。（会增加宿主机的内存使用）
CUDA 的所有 GPU 资源进行释放。

cuda-checkpoint 不会暂停 CPU 线程，这些线程可以通过以下方式继续安全地与 CUDA 交互：调用运行时或驱动程序 API，但是在 CUDA 恢复之前可能会阻塞。

暂停的 CUDA 进程不再直接引用作系统级别的任何 GPU 硬件，因此可以由 CPU 检查点实用程序（如 CRIU）进行检查点作。

Restore 操作流程：

当使用 cuda-checkpoint 恢复进程的 CUDA 状态时：

GPU 被该进程重新获取
设备内存被复制回 GPU，GPU 内存映射在其原始地址处恢复;
恢复 CUDA 对象（如 Stream 和 Context）
CUDA 驱动程序 API 解锁。

此时，CUDA 调用将解除阻塞，CUDA 可能会再次开始在 GPU 上运行。

例子

此示例将使用 cuda-checkpoint 和 criu 对名为 counter 的 CUDA 应用程序进行检查点作。每次 counter 收到数据包时，它都会增加 GPU 内存并使用更新的值进行回复。然后 CPU 中有一个变量会利用这个值进行操作，counter 的源代码如下所示。

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define PORT 10000

__device__ int counter = 100;
__global__ void increment()
{
    counter++;
}

int main(void)
{
    cudaFree(0);

    int sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
    sockaddr_in addr = {AF_INET, htons(PORT), inet_addr("127.0.0.1")};
    bind(sock, (sockaddr *)&addr, sizeof addr);

    while (true) {
        char buffer[16] = {0};
        sockaddr_in peer = {0};
        socklen_t inetSize = sizeof peer;
        int hCounter = 0;

        recvfrom(sock, buffer, sizeof buffer, 0, (sockaddr *)&peer, &inetSize);

        increment<<<1,1>>>();
        cudaMemcpyFromSymbol(&hCounter, counter, sizeof counter);

        size_t bytes = sprintf(buffer, "%d\n", hCounter);
        sendto(sock, buffer, bytes, 0, (sockaddr *)&peer, inetSize);
    }
    return 0;
}

可以使用 nvcc 构建 counter 应用程序

$ nvcc counter.cu -o counter

接下来，启动 counter 并等待以确保它正在侦听其套接字

$ ./counter &
[1] 298027
$ sleep 1

向 counter 发送一个数据包并观察返回的值。初始值为 100，但响应为 101，这表明 GPU 内存自初始化以来已更改。

$ echo hello | nc -u localhost 10000 -W 1
101

使用 nvidia-***i 确认计数器正在 GPU 上运行。

$ nvidia-***i --query --display=PIDS | grep $PID
        Process ID                        : 298027

使用 cuda-checkpoint 暂停计数器的 CUDA 状态

$ PID=$! #保存进程ID
$ cuda-checkpoint --toggle --pid $PID

使用 nvidia-***i 确认计数器不再在 GPU 上运行

$ nvidia-***i --query --display=PIDS | grep $PID

使用criu 进行 checkpoint 进程

$ mkdir -p demo
$ criu dump --shell-job --images-dir demo --tree $PID
[1]+  Killed                  ./counter
$ ps --pid $PID #确认计数器不再运行
PID TTY          TIME CMD

使用 criu 恢复计数器

$ criu restore --shell-job --restore-detached --images-dir demo
$ cuda-checkpoint --toggle --pid $PID

现在该计数器已完全恢复，请向其发送另一个数据包。响应为 102，表明早期的 GPU作已正确保留！

$ echo hello | nc -u localhost 10000 -W 1
102

缺点

改方案存在的不足：

GPU 进程和 CPU 进程不能同时进行 checkpoint，它们是分开执行的，cuda-checkpoint 只是把GPU上的任务暂停下来，这个时候 CPU 进程还是可以调用 CUDA 代码，只是不会有响应，会阻塞住。
cuda-checkpoint 不支持 GPU 迁移，只能在固定 GPU 上进行 checkpoint 和 restore.