在 Kata Containers 中编译支持 eBPF 的 Guest Kernel 并验证生效

此前在 8 月份因项目需求我对 Kata 容器进行了调研并在 CentOS 上部署了单机版 Kata 环境。当时受限于进度仅完成基础环境搭建。近期我重新开始探索 eBPF 在 Kata 容器中的支持与适配情况于是有了这篇文章。后续我还会输出 Kata 容器在 K8s 中的完整部署指南敬请关注。1. 背景Kata Containers 与普通容器运行时不同。普通容器直接共享宿主机内核而 Kata Containers 中的工作负载运行在独立的轻量虚拟机内因此实际使用的是Guest Kernel而不是宿主机内核。这意味着仅在宿主机启用 eBPF 相关配置并不能自动让 Kata 容器具备 eBPF 能力。若需要在 Kata 容器内部使用 eBPF必须为 Kata 使用的Guest Kernel启用 eBPF、Tracing、BTF 等相关内核配置。本文档记录了完整的操作流程包括编译支持 eBPF 的 Kata Guest Kernel安装编译产物将实际运行中的 Kata Runtime 切换到新内核在 Kata 容器内验证 eBPF 能力是否可用2. 目标本文档的目标是完成以下工作基于 Kata 官方构建脚本准备 Guest Kernel 源码修改 Guest Kernel 配置启用 eBPF 相关能力编译并安装新的 Guest Kernel让当前 Kata Runtime 使用新的 Guest Kernel启动 Kata 容器并确认Guest Kernel 已切换为新版本eBPF 关键能力已经启用BTF、tracefs、bpffs 等运行时接口可用3. 环境说明本次排查过程中发现系统中同时存在两套 Kata 相关路径编译安装输出路径/usr/share/kata-containers/实际运行中的 Kata 路径/opt/kata/实际运行时使用的是/opt/kata/...这套 Kata 资产而不是/usr/share/kata-containers/...。关键路径如下Kata shim:/opt/kata/bin/containerd-shim-kata-v2Kata 配置文件:/opt/kata/share/defaults/kata-containers/configuration-qemu.toml运行时使用的 Guest Kernel 配置项:kernel /opt/kata/share/kata-containers/vmlinux.container这也是为什么仅执行build-kernel.sh install后虽然新内核已经安装到/usr/share/kata-containers/但 Kata 容器内部仍然使用旧 Guest Kernel 的原因。4. 前提条件在开始前需要满足以下条件已安装 Kata Containers已安装 containerd系统可以正常使用ctr启动 Kata 容器具备 root 或 sudo 权限系统能够获取 Kata 源码系统具备内核编译环境5. 获取 Kata 源码执行以下命令获取源码并进入内核构建目录git clone https://github.com/kata-containers/kata-containers.git cd kata-containers/tools/packaging/kernel目录结构示例ls输出6. 安装并配置yq在执行build-kernel.sh setup时脚本会依赖yq。如果未安装会报错ERROR: yq command is not in your $PATH6.1 安装yq将预先下载好的yq二进制安装到系统 PATHsudo mv ~/yq_linux_amd64 /usr/local/bin/yq sudo chmod x /usr/local/bin/yq yq --version6.2 处理sudo环境无法找到yq在本次环境中发现普通用户可以通过/usr/local/bin/yq找到yq但sudo环境的 PATH 中不包含/usr/local/bin验证命令如下which yqsudo which yq如果输出类似/usr/local/bin/yqwhich: no yq in (/sbin:/bin:/usr/sbin:/usr/bin)则需要将其复制到/usr/binsudo cp /usr/local/bin/yq /usr/bin/yqsudo chmod x /usr/bin/yqsudo /usr/bin/yq --version7. 准备 Guest Kernel 源码执行cd ~/kata-containers/tools/packaging/kernel ./build-kernel.sh setup成功后会输出类似信息Kernel source ready: /home/zain/kata-containers/tools/packaging/kernel/kata-linux-6.18.15-185这表示 Guest Kernel 源码已经准备完成本次实际目录为~/kata-containers/tools/packaging/kernel/kata-linux-6.18.15-1858. 修改 Guest Kernel 配置以启用 eBPF进入源码目录并备份原始配置cd ~/kata-containers/tools/packaging/kernel/kata-linux-6.18.15-185 cp .config .config.bak8.1 追加 eBPF 相关配置将以下配置追加到.configcat .config EOF CONFIG_BPFy CONFIG_BPF_SYSCALLy CONFIG_BPF_JITy CONFIG_BPF_JIT_ALWAYS_ONy CONFIG_BPF_EVENTSy CONFIG_CGROUP_BPFy CONFIG_KPROBESy CONFIG_KPROBE_EVENTSy CONFIG_UPROBESy CONFIG_UPROBE_EVENTSy CONFIG_TRACINGy CONFIG_FTRACEy CONFIG_FUNCTION_TRACERy CONFIG_FUNCTION_GRAPH_TRACERy CONFIG_KALLSYMSy CONFIG_KALLSYMS_ALLy CONFIG_DEBUG_INFOy CONFIG_DEBUG_INFO_DWARF5y CONFIG_DEBUG_INFO_BTFy CONFIG_IKCONFIGy CONFIG_IKCONFIG_PROCy CONFIG_BPF_LSMy CONFIG_BPF_PRELOADy CONFIG_NET_CLS_BPFy CONFIG_NET_ACT_BPFy CONFIG_BPF_STREAM_PARSERy EOF然后执行make olddefconfig8.2 关于override: reassigning to symbol ...警告执行make olddefconfig时可能会看到如下提示.config:3486:warning: override: reassigning to symbol BPF ... # configuration written to .config这是正常现象不表示失败。其含义是某些配置项原本已经存在于.config本次又追加了一次make olddefconfig会采用最新值并重新生成配置文件只要最后看到# configuration written to .config即可认为配置写入成功。9. 检查关键配置项执行以下命令检查grep -E CONFIG_(BPF|BTF|FTRACE|KPROBE|UPROBE|IKCONFIG|TRACING|KALLSYMS|DEBUG_INFO) .config本次确认生效的关键配置包括CONFIG_BPFy CONFIG_BPF_SYSCALLy CONFIG_KPROBESy CONFIG_UPROBESy CONFIG_DEBUG_INFO_BTFy CONFIG_TRACINGy CONFIG_FTRACEy CONFIG_KPROBE_EVENTSy CONFIG_UPROBE_EVENTSy CONFIG_BPF_EVENTSy这些配置表明eBPF 核心能力已启用kprobe / tracing 所需能力已启用BTF 已启用可支持现代 libbpf/CO-RE 场景10. 编译 Guest Kernel返回打包目录并执行编译cd ~/kata-containers/tools/packaging/kernel ./build-kernel.sh build如果编译成功最后会看到类似输出BUILD arch/x86/boot/bzImage Kernel: arch/x86/boot/bzImage is ready (#1)11. 安装 Guest Kernel执行安装sudo ./build-kernel.sh install安装成功后会输出类似内容INFO: Config version: 185 INFO: Kernel version: 6.18.15 lrwxrwxrwx. 1 root root 19 ... /usr/share/kata-containers/vmlinux.container - vmlinux-6.18.15-185 lrwxrwxrwx. 1 root root 19 ... /usr/share/kata-containers/vmlinuz.container - vmlinuz-6.18.15-185说明编译产物已经安装到/usr/share/kata-containers/vmlinux-6.18.15-185/usr/share/kata-containers/vmlinuz-6.18.15-185/usr/share/kata-containers/config-6.18.15-185但此时还需要额外处理因为当前运行中的 Kata 使用的是/opt/kata/...路径而不是/usr/share/kata-containers/...。12. 确认实际运行中的 Kata 配置为了定位当前 Kata 实际使用的 Guest Kernel检查配置文件grep -nE path|kernel|image|initrd /opt/kata/share/defaults/kata-containers/configuration-qemu.toml本次环境中的关键配置为15:path /opt/kata/bin/qemu-system-x86_64 16:kernel /opt/kata/share/kata-containers/vmlinux.container 17:image /opt/kata/share/kata-containers/kata-containers.img说明当前 Kata 实际使用的是kernel /opt/kata/share/kata-containers/vmlinux.container因此必须将新编译好的 Guest Kernel 复制到/opt/kata/share/kata-containers/并更新符号链接。13. 将新内核同步到实际运行路径执行sudo cp /usr/share/kata-containers/vmlinux-6.18.15-185 /opt/kata/share/kata-containers/ sudo cp /usr/share/kata-containers/vmlinuz-6.18.15-185 /opt/kata/share/kata-containers/ sudo cp /usr/share/kata-containers/config-6.18.15-185 /opt/kata/share/kata-containers/更新默认符号链接sudo ln -sf vmlinux-6.18.15-185 /opt/kata/share/kata-containers/vmlinux.container sudo ln -sf vmlinuz-6.18.15-185 /opt/kata/share/kata-containers/vmlinuz.container可使用以下命令检查ls -l /opt/kata/share/kata-containers/vmlinux.container ls -l /opt/kata/share/kata-containers/vmlinuz.container readlink -f /opt/kata/share/kata-containers/vmlinux.container14. 重启 containerd使 containerd 和 Kata Runtime 重新加载配置sudo systemctl restart containerd15. 启动 Kata 容器验证 Guest Kernel 是否生效本次环境中本地已有镜像quay.io/libpod/ubuntu:latest因此直接使用该镜像启动 Kata 容器sudo ctr run --runtime io.containerd.kata.v2 --rm -t quay.io/libpod/ubuntu:latest kata-ebpf bash进入容器后执行uname -r若输出仍为旧版本例如6.12.47说明当前 Kata 运行时仍未切换到新 Guest Kernel需要回头检查/opt/kata/share/defaults/kata-containers/configuration-qemu.toml/opt/kata/share/kata-containers/vmlinux.containercontainerd 是否已经重启16. 验证 Guest Kernel 是否具备 eBPF 能力在 Kata 容器内部执行以下检查。16.1 检查内核配置zgrep -E CONFIG_(BPF|BPF_SYSCALL|BPF_EVENTS|KPROBES|KPROBE_EVENTS|TRACING|FTRACE|DEBUG_INFO_BTF|UPROBES|UPROBE_EVENTS) /proc/config.gz本次验证输出为CONFIG_BPFy CONFIG_BPF_SYSCALLy CONFIG_KPROBESy CONFIG_UPROBESy CONFIG_DEBUG_INFO_BTFy CONFIG_TRACINGy CONFIG_FTRACEy CONFIG_KPROBE_EVENTSy CONFIG_UPROBE_EVENTSy CONFIG_BPF_EVENTSy说明eBPF 核心功能已开启tracing / kprobe 相关能力已开启BTF 已启用16.2 检查运行时文件系统和 BTF 接口ls -ld /sys/fs/bpf ls -ld /sys/kernel/tracing ls -l /sys/kernel/btf/vmlinux本次验证结果表明/sys/fs/bpf存在/sys/kernel/tracing存在/sys/kernel/btf/vmlinux存在这意味着bpffs 可用tracing/tracefs 可用BTF 可用17. 结果判定满足以下条件时可以认为 Kata Guest Kernel 已具备可用的 eBPF 基础能力uname -r显示为新编译安装的 Guest Kernel 版本CONFIG_BPFyCONFIG_BPF_SYSCALLyCONFIG_KPROBESyCONFIG_KPROBE_EVENTSyCONFIG_TRACINGyCONFIG_FTRACEyCONFIG_DEBUG_INFO_BTFy/sys/fs/bpf存在/sys/kernel/tracing存在/sys/kernel/btf/vmlinux存在本次验证结果表明上述条件均已满足因此可以得出结论当前 Kata Guest 已具备可用的 eBPF 基础能力。18. 常见问题18.1build-kernel.sh setup提示yq command is not in your $PATH原因是系统中未安装yq或者sudo环境的 PATH 中不包含yq所在目录。处理方式安装yq如有必要将yq复制到/usr/bin18.2 安装完新内核后Kata 容器内仍然是旧 Guest Kernel常见原因是新内核只安装到了/usr/share/kata-containers/但实际运行中的 Kata 使用的是/opt/kata/...路径需要确认实际配置文件中的kernel ...指向哪个路径并将新内核同步到该路径。18.3 为什么修改宿主机内核配置没有用因为 Kata 容器运行在 Guest VM 内部实际使用的是 Guest Kernel而不是宿主机内核。 因此必须修改 Kata Guest Kernel 配置而不是仅修改宿主机内核。19. 关键经验总结19.1 必须确认“实际运行中的 Kata 路径”不要默认认为运行时一定使用/usr/share/kata-containers/。 不同安装方式可能使用不同的目录例如本次环境中实际使用的是/opt/kata/...。19.2 要以 Guest 内验证为准真正判断是否成功不能只看宿主机上的文件或符号链接而应以 Kata 容器内部的结果为准例如uname -r zgrep ... /proc/config.gz ls /sys/fs/bpf ls /sys/kernel/tracing ls /sys/kernel/btf/vmlinux19.3 eBPF 能力是 Guest Kernel 的能力在 Kata 场景下eBPF 能否使用取决于 Guest Kernel 的配置和运行时接口是否可用。19.4 发现tracing 和 bpf下面没有文件 可能无法运行ebpf去查看了下 /sys/fs/bpf /sys/kernel/tracing发现没有对应的文件在目录下初步判定了下可能是启动kata容器时没有给出高特权具体解决方法和ebpf的运行指南在下一篇给出答案。