Kata Containers 内核构建完全指南：基于 build-kernel.sh 的源码级实战

导读：Kata Containers 的每个沙箱都运行在一个轻量级虚拟机中，而 guest 内核正是这个 VM 的“操作系统心脏”。本篇指南以 tools/packaging/kernel/README.md 为骨架，结合 build-kernel.sh 源码、configs 配置碎片体系、patches 补丁目录以及 versions.yaml 版本管理机制，完整讲解从环境准备、setup/build/install 三阶段构建，到 debug 内核、NVIDIA GPU 内核、机密计算内核（TDX/SNP/CCA）、内核版本与 kata_config_version 联动机制的全链路，让读者既能照着命令跑通构建，又能理解每一步背后的实现原理。

目录

1. 构建脚本概览：一条命令背后的完整流水线
2. 环境准备与依赖要求
3. 命令与参数详解
4. Setup：下载源码、打补丁、生成配置
5. Build：编译内核
6. Install：安装到 Kata 默认路径
7. Debug 内核与 eBPF 支持
8. 内核配置体系：fragments 配置碎片详解
9. GPU 内核、机密计算与实验性内核
10. 版本管理：kata_config_version 与 CI 联动
11. 如何提交内核改动
12. 常见问题与排查思路

一、构建脚本概览：一条命令背后的完整流水线

Kata Containers 官方推荐的 guest 内核构建方式是使用 build-kernel.sh。该脚本位于 tools/packaging/kernel/ 目录，是一个约 760 行的 Bash 脚本，它把整个内核构建流程封装为三个子命令：

子命令	职责	对应脚本函数
setup	下载/克隆内核源码、应用补丁、生成 .config	setup_kernel()
build	编译内核镜像与模块	build_kernel()
install	安装到 Kata 默认查找路径	install_kata()

此外脚本还支持一个隐藏子命令 build-headers（对应 build_kernel_headers()），用于构建 guest fs 模块编译所需的 Linux 头文件（deb 或 rpm 格式）。

从源码结构看，脚本的关键路径常量定义如下（build-kernel.sh）：

readonly default_patches_dir="${script_dir}/patches"           # 默认补丁目录
readonly default_kernel_config_dir="${script_dir}/configs"     # 默认完整配置目录
readonly default_config_frags_dir="${script_dir}/configs/fragments"   # 默认配置碎片目录
readonly default_config_whitelist="${script_dir}/configs/fragments/whitelist.conf"  # 白名单

这三个目录是理解整个构建系统的钥匙：patches 存放针对各内核大版本（如 6.18.x）的补丁，configs 存放完整的内核配置文件（如 x86_64_kata_kvm_4.19.x），configs/fragments 则是推荐使用的"配置碎片"体系——用多个小 .conf 文件按 arch/common/gpu/debug/confidential 等维度拼出最终 .config。

从源码看，脚本执行时首先会检查 GOPATH（默认为 ${HOME}/go，取第一个元素），并 source 了 tools/packaging/scripts/lib.sh 工具库（build-kernel.sh），其中 get_from_kata_deps 函数负责从 versions.yaml 中读取各类组件版本。

二、环境准备与依赖要求

根据原文档，构建前需要满足以下依赖：

1. Go 工具链

build-kernel.sh 需要与 docs/Developer-Guide.md 中"组件构建要求"匹配的 Golang 版本。脚本本身在解析 versions.yaml 获取版本号时需要 Go（get_from_kata_deps 底层依赖 kata 的版本解析工具链）。

2. yq 工具（v4.40.7）

versions.yaml 是 YAML 格式，脚本需要 yq 来读取其中的版本字段。原文档给出的安装提示：

$ go install github.com/mikefarah/yq/v4@latest

3. Linux 内核编译相关系统包

原文档明确指出需要以下包：

包名	用途
flex	内核词法分析器生成
bison	内核语法分析器生成
libelf-dev	内核符号与模块的 ELF 处理
dwarves	生成 BTF 类型信息（CONFIG_DEBUG_INFO_BTF，debug 内核必需）

此外根据实际编译需要，通常还建议安装 gcc、make、patch、curl、tar、xz-utils（解压 tar.xz 内核源码包）以及 openssl（模块签名场景，见下文 KBUILD_SIGN_PIN）。

三、命令与参数详解

查看全部可用参数：

$ ./build-kernel.sh -h

脚本完整支持以下选项（来源：build-kernel.sh 的 usage() 函数）：

参数	含义	默认值/说明
-a <arch>	目标架构	支持 aarch64/ppc64le/riscv64/s390x/x86_64，未指定时取 uname -m
-b <type>	可选配置类型	如 experimental、dragonball-experimental 等 build-type
-c <path>	指定内核配置文件路径	覆盖默认配置查找逻辑
-d	开启 bash 调试（set -x）	打印每条命令
-e	启用实验性内核	等价于 -b experimental
-f	setup 时强制重新生成配置	会删除已存在的内核目录与旧 .config
-g <vendor>	GPU 厂商	仅支持 intel 或 nvidia
-h	显示帮助
-H <deb|rpm>	构建 Linux 头文件（guest fs 模块用）	触发 build-headers 子命令逻辑
-m	启用 measured rootfs	追加 cryptsetup.conf 配置碎片
-k <path>	指定内核源码路径	默认 ./kata-linux-<version>-<config_version>
-p <path>	指定补丁目录	默认 patches/
-r <ref>	以 git 方式按 ref 拉取内核	走 get_git_kernel()
-s	跳过 .config 检查	不校验缺失/重复/重定义配置
-t <hypervisor>	hypervisor 目标	默认 kvm；firecracker 会映射为 kvm 配置
-u <url>	内核下载 URL	覆盖 kernel.org 默认地址
-v <version>	内核版本	如 5.10.25；未指定时从 versions.yaml 读取
-x	机密计算 guest 类型	设为 confidential

原文档给出的典型示例：

$ ./build-kernel.sh -v 5.10.25 -g nvidia -f -d setup

参数含义拆解：

• -v 5.10.25：指定 guest 内核版本为 5.10.25；
• -g nvidia：构建支持 NVIDIA GPU 的 guest 内核（会追加 GPU 配置碎片，并在 setup 阶段下载 NVIDIA open-gpu-kernel-modules 源码）；
• -f：即使内核目录已存在，也强制重新生成 .config（删除旧目录与旧配置）；
• -d：开启 bash 调试模式，方便排查脚本执行过程。

提示：当不确定该用哪个内核版本时，直接查看 versions.yaml 中的 assets.kernel.version 字段——这正是 CI 当前使用的内核版本。本仓库当前为 v6.18.52。

四、Setup：下载源码、打补丁、生成配置

4.1 基本流程

$ git clone https://github.com/kata-containers/kata-containers.git
$ cd kata-containers/tools/packaging/kernel
$ ./build-kernel.sh setup

setup 阶段（对应 setup_kernel() 函数，build-kernel.sh）按以下顺序工作：

1. 确定内核版本：若未通过 -v 指定，则从 versions.yaml 读取（普通构建读 .assets.kernel.version，实验性构建读 .assets.kernel-experimental.tag，机密计算构建读 .assets.kernel.confidential.version/tag，见 build-kernel.sh）。
2. 获取内核源码：默认走 get_kernel()——从 https://www.kernel.org/pub/linux/kernel/v<major>.x/ 下载 linux-<version>.tar.xz 并校验 sha256（sha256sums.asc）；-r 模式则走 get_git_kernel()，从 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 按 ref 浅克隆。RC 版本（如 -rcN）会改用 .tar.gz 后缀，且跳过 sha256 校验（RC 不在官方 checksum 列表中）。
3. 应用补丁：调用 tools/packaging/scripts/apply_patches.sh，依次应用 patches/<major.minor>.x/ 目录下的补丁（若有 -b build-type，还会应用 patches/<major.minor>.x/<build_type>/ 下的补丁）。
4. 生成 .config：把配置写入内核源码根目录的 .config，随后执行 ARCH=<arch> make oldconfig 使新配置与内核源码的 Kconfig 体系对齐。

4.2 补丁机制（patches 目录）

原文档关键说明：setup 时会自动应用 ${GOPATH}/src/github.com/kata-containers/kata-containers/tools/packaging/kernel/patches/ 下的补丁；只有顶层目录下的补丁会被应用，子目录会被忽略。

实际源码中，setup_kernel() 调用：

"${packaging_scripts_dir}/apply_patches.sh" "${patches_dir_for_version}"

其中 patches_dir_for_version="${patches_path}/${major_kernel}.x"，即按内核大版本（如 4.19.x、5.15.x、6.18.x）组织补丁目录。查看 apply_patches.sh 源码可知：脚本只取 -maxdepth 1 下的 *.patch 文件，按文件名数字前缀排序后逐个 patch -p1 应用。当前仓库 patches/ 下已收录从 4.19.x 到 6.18.x 以及 TDX、virtio-fs、efi-secret 等专题补丁集。

如果你想为 Kata 内核添加自己的源码修改，把 .patch 文件（git format-patch 格式，命名为 NUMBER-DESCRIPTION.patch）放进对应大版本目录即可，子目录（如 6.18.x/dragonball-experimental/）只在对应 build-type 时才会被应用。

4.3 配置生成机制

setup 会从 configs/ 目录挑选配置写入内核源码的 .config：

cp "${kernel_config_path}" ./.config
ARCH=${arch_target} make oldconfig

默认配置路径由 get_default_kernel_config() 决定（build-kernel.sh）：

• 若 configs/fragments/<arch>/ 目录存在（现代版本，推荐方式）：走 get_kernel_frag_path() 用 merge_config.sh 从碎片拼装配置；
• 否则（旧版完整配置）：查找 configs/<arch>_kata_<hypervisor>_<major>.x 文件（如 x86_64_kata_kvm_4.19.x），此时 firecracker 会被当作 kvm 处理（[[ "${hypervisor}" == "firecracker" ]] && hypervisor="kvm"）。

从源码结构看，当前仓库 configs 目录下同时保留了旧式完整配置（如 arm64_kata_kvm_4.14.x）和新的 fragments/ 配置碎片树，且新版 fragments 是官方推荐方式（见 configs/README.md）。

你完全可以修改生成的 .config，例如用 make menuconfig 做交互式调整后再重新 build。

五、Build：编译内核

$ ./build-kernel.sh build

build_kernel()（build-kernel.sh）执行核心编译动作：

make -j "$(nproc)" ARCH="${arch_target}"

随后校验关键产物存在性：

• arch/<arch>/boot/bzImage 或 arch/<arch>/boot/Image.gz（powerpc 除外）；
• vmlinux 未压缩内核；
• 对 firecracker/cloud-hypervisor + arm64 组合，额外要求 arch/arm64/boot/Image。

若 conf_guest == "confidential"（即 -x），还会执行 modules_install 把内核模块安装到内核源码树内（INSTALL_MOD_PATH="${kernel_path}"），便于后续与 guest 镜像打包。

NVIDIA GPU 内核的 build 阶段（-g nvidia）会额外：

make -C "${kernel_path}" ... modules_install   # 内核内置模块
pushd open-gpu-kernel-modules                   # 之前在 setup 阶段下载的源码
make CC=gcc SYSSRC="${kernel_path}"             # 编译 out-of-tree 驱动
make ... modules_install

即 NVIDIA 场景需要树内模块 + 树外 open-gpu-kernel-modules 驱动一起编译安装（SYSSRC 指向内核源码路径）。

六、Install：安装到 Kata 默认路径

$ sudo ./build-kernel.sh install

Kata Containers 运行时会在固定路径查找内核镜像。从 config-settings.go.in 可以看到运行时默认值：

var defaultKernelPath = "/usr/share/kata-containers/vmlinuz.container"
var defaultInitrdPath = "/usr/share/kata-containers/kata-containers-initrd.img"
var defaultImagePath = "/usr/share/kata-containers/kata-containers.img"

因此 install 子命令默认把产物安装到 /usr/share/kata-containers/（实际路径由 DESTDIR/${PREFIX}/share/kata-containers 计算，DESTDIR 与 PREFIX 均可用环境变量覆盖，默认分别为 / 与 /usr）。

install_kata()（build-kernel.sh）会生成带完整版本标识的文件名：

vmlinuz-<kernel_version>-<config_version>[<suffix>]
vmlinux-<kernel_version>-<config_version>[<suffix>]
config-<kernel_version>-<config_version>[<suffix>]
System.map-<kernel_version>-<config_version>[<suffix>]

其中 <suffix> 由三部分拼出（install_kata() 内）：

• build_type 非空 → -<build_type>；
• gpu_vendor 非空 → -<vendor>-gpu；
• KERNEL_DEBUG_ENABLED=yes → 前缀 -debug。

最后建立软链接：

ln -sf "${vmlinuz}" "${install_path}/vmlinuz${suffix}.container"
ln -sf "${vmlinux}" "${install_path}/vmlinux${suffix}.container"

即最终让运行时默认路径 /usr/share/kata-containers/vmlinuz.container（以及 vmlinux.container）指向刚构建的内核。若构建了 debug 内核，则软链接名为 vmlinuz-debug.container，需在运行时配置中通过 kernel 路径选项指向它。

七、Debug 内核与 eBPF 支持

Kata Containers 提供启用 debug 与 eBPF 配置的内核，用于排障、内核跟踪与性能分析。构建 debug 内核需在所有阶段设置环境变量：

$ KERNEL_DEBUG_ENABLED=yes ./build-kernel.sh setup
$ KERNEL_DEBUG_ENABLED=yes ./build-kernel.sh build
$ sudo KERNEL_DEBUG_ENABLED=yes ./build-kernel.sh install

对应源码：KERNEL_DEBUG_ENABLED 默认 "no"（build-kernel.sh），为 yes 时 get_kernel_frag_path() 会把 configs/fragments/debug/*.conf 全部并入配置集（build-kernel.sh）。

查看 debug.conf 与 ebpf.conf 可知 debug 内核开启的核心能力：

• CONFIG_IKCONFIG=y / CONFIG_IKCONFIG_PROC=y：guest 内可通过 /proc/config.gz 查询运行内核的配置；
• CONFIG_DEBUG_INFO=y / CONFIG_DEBUG_KERNEL=y / CONFIG_DEBUG_FS=y：调试信息与 debugfs；
• CONFIG_DEBUG_INFO_BTF=y：生成 BTF 类型信息——这正是原文档提到需要 dwarves 包的原因；
• CONFIG_BPF_JIT=y / CONFIG_BPF_EVENTS=y：BPF JIT 编译与事件；
• CONFIG_KPROBES=y / CONFIG_KPROBE_EVENTS=y / CONFIG_UPROBES=y / CONFIG_UPROBE_EVENTS=y：内核/用户态探针；
• CONFIG_DYNAMIC_FTRACE=y / CONFIG_FTRACE=y / CONFIG_FTRACE_SYSCALLS=y / CONFIG_FUNCTION_TRACER=y：ftrace 跟踪基础设施。

这意味着 debug 内核可直接承载 bpftrace、perf、kprobe/uprobe 等观测手段，方便深入分析 guest 内核行为。也正因启用了 BTF，debug 内核的构建需要 dwarves 工具包。

八、内核配置体系：fragments 配置碎片详解

8.1 两种配置形态

按 configs/README.md，Kata 内核配置存在两种形态：

1. fragments 配置碎片树（configs/fragments/）：优先推荐。用内核自带 scripts/kconfig/merge_config.sh 把多个 .conf 小文件合并为完整 .config，清晰易维护；
2. 完整配置文件（configs/*.x）：如 arm64_kata_kvm_4.19.x、x86_64_kata_kvm_4.14.x，可直接整体使用。

8.2 碎片目录结构

当前仓库的 configs/fragments/ 按维度组织（源码可见）：

目录	内容
common/	通用碎片：9p.conf、acpi.conf、base.conf、cgroup.conf、cpu.conf、crypto.conf、dax.conf、fs.conf、hotplug.conf、huge.conf、landlock.conf、lsm.conf、mem_agent.conf、mmio.conf、mmu.conf、namespaces.conf、netfilter.conf、network.conf、pmem.conf、seccomp.conf、security.conf、serial.conf、vfio.conf、virtio.conf、virtio-extras.conf 等
common/confidential_containers/	cryptsetup.conf（measured rootfs/-m 时追加）、tmpfs.conf（机密计算时追加）
common/signing/	module_signing.conf（设置 KBUILD_SIGN_PIN 时追加，用于内核模块签名）
<arch>/（arm64/x86_64/powerpc/riscv/s390）	架构相关碎片，如 x86_64 下有 acpi.conf、base.conf、crypto.conf、fs.conf、hotplug.conf、mmu.conf、network.conf、numa.conf、pci.conf、ptp.conf、sgx.conf、vfio.conf、virtio.conf
<arch>/confidential/	机密计算碎片，如 x86_64 下 fips.conf、snp.conf、tdx.conf；arm64 下 cca.conf、hotplug.conf、rme.conf
debug/	debug.conf、ebpf.conf（KERNEL_DEBUG_ENABLED=yes 时追加）
gpu/	intel.x86_64.conf.in、nvidia.x86_64.conf.in、nvidia.arm64.conf.in（-g 指定厂商时经 envsubst 生成临时配置追加）
build-type/	arm-experimental/、dragonball-experimental/（-b/-e 指定时追加）
whitelist.conf	配置白名单：被合并脚本判定为 "not in final" 但属于已知在新内核中消失的选项，不视为错误

8.3 合并与校验逻辑

get_kernel_frag_path()（build-kernel.sh）的核心逻辑：

1. 列出 common/*.conf 与 <arch>/*.conf（支持在碎片首行用 # !<arch> / # !confidential 标签排除，如 # !s390x !ppc64le）；
2. 按 -g、-m、-x、KBUILD_SIGN_PIN、KERNEL_DEBUG_ENABLED 等开关追加 GPU / cryptsetup / tmpfs / 机密计算 / 签名 / debug 碎片；
3. 调用内核源码 scripts/kconfig/merge_config.sh -r -n 合并出 .config.generated；
4. 校验三类异常，任一出现即 die 失败：
   • 有配置项未进入最终 .config（"not in final"，白名单中的除外）；
   • 同一选项在碎片中被定义成不同值（"redefined"）；
   • 同一选项被重复定义（"redundant"）。

-s 参数可跳过这些校验（skip_config_checks）。

九、GPU 内核、机密计算与实验性内核

9.1 NVIDIA GPU 内核

$ ./build-kernel.sh -v 5.10.25 -g nvidia -f -d setup

-g nvidia 触发两条路径：

• setup 阶段（build-kernel.sh）：从 versions.yaml 的 externals.nvidia.driver 读取驱动版本（当前仓库为 595.58.03）与 URL，下载 open-gpu-kernel-modules 源码；
• 配置阶段：get_kernel_frag_path() 把 gpu/nvidia.x86_64.conf.in 经 envsubst 展开后并入配置（CONF_GUEST_SUFFIX 用于 CONFIG_LOCALVERSION="-nvidia-gpu..." 后缀）。

查看 nvidia.x86_64.conf.in 可见其启用 CONFIG_MODULES、CONFIG_FW_LOADER、CONFIG_MEMORY_FAILURE、CONFIG_MTRR、CONFIG_X86_PAT、CONFIG_MODULE_SIG 以及 CRYPTO 相关依赖等 NVIDIA 驱动所需内核特性。

注意：-g 只接受 intel 或 nvidia（源码 die 校验）。GPU 内核主要服务于 Kata 的 GPU passthrough 使用场景（参见 docs/use-cases/GPU-passthrough-and-Kata.md）。

9.2 机密计算（Confidential Computing）内核

-x 参数把 conf_guest 设为 confidential，其行为（build-kernel.sh）：

• 内核版本自动读取 versions.yaml 的 .assets.kernel.confidential.version（不存在则回退 .tag）；
• 配置阶段追加 <arch>/confidential/*.conf（如 x86_64 的 tdx.conf、snp.conf、fips.conf，arm64 的 cca.conf）以及 common/confidential_containers/tmpfs.conf；
• build 阶段额外执行 modules_install 到内核树内；
• 同时还会排除带 !confidential 标签的碎片（这类碎片可能包含机密计算场景下不安全/不兼容的配置）。

9.3 实验性内核与 Dragonball

• -e 等价于 -b experimental，构建 versions.yaml 中 assets.kernel-experimental.tag 指定的内核；
• -b dragonball-experimental（或 -e + -t dragonball）会读取 assets.kernel-dragonball-experimental.version，并应用 patches/<ver>/dragonball-experimental/ 补丁、configs/fragments/build-type/dragonball-experimental/ 碎片（upcall.conf、virtio.conf、mm.conf）。源码中还提示：dragonball-experimental 补丁目前仅针对 6.18.x 内核验证过（build-kernel.sh）。

十、版本管理：kata_config_version 与 CI 联动

10.1 双版本标识机制

Kata 的内核版本号由两部分组成：

• 内核版本：来自 versions.yaml 的 assets.kernel.version（当前为 v6.18.52）；
• 配置版本：来自 tools/packaging/kernel/kata_config_version 文件（当前仓库值为 204）。

两者拼出的完整版本形如：

# 来自 versions.yaml
kernel_version_in_versions_file=5.4.60
# 来自 kata_config_version
kata_config_version=83
# 拼接结果
latest_kernel_version=${kernel_version_in_versions_file}-${kata_config_version}
# => 5.4.60-83

对应源码 get_config_version()（build-kernel.sh）直接 cat 该文件。install 阶段生成的内核文件名即采用 vmlinuz-<version>-<config_version> 格式（如 vmlinuz-6.18.52-204）。

10.2 为什么需要 kata_config_version

因为同一个内核版本可以搭配不同的配置（不同的碎片组合、补丁集合）。如果只改配置而不升内核版本，文件名将无法区分新旧配置。kata_config_version 的存在让 CI 与用户能一眼判断某个缓存内核是否携带了最新的推荐配置——只要 config_version 落后于当前仓库值，就说明该构建不是最新配置。

10.3 CI 测试方式

按原文档说明，Kata CI 的内核获取策略是二选一（优先缓存，缺失则源码构建）：

1. CI 缓存：若 versions.yaml 定义的内核版本 + 最新 configs/patches 已构建并缓存，则直接安装；
2. 源码构建：否则走 build-kernel.sh 从源码构建。

因此任何对内核 configs 或 patches 的改动，都必须同步递增 kata_config_version，否则 CI 会因为"配置版本未变"而使用旧缓存，改动不会被实际测试到。这是提交内核改动时最容易忽略、也最关键的一步。

十一、如何提交内核改动

原文档给出两条贡献路径：

11.1 升级内核版本 → 改 versions.yaml

修改 versions.yaml 中 assets.kernel.version（及 nvidia 场景的 assets.kernel.nvidia.version），提交 PR。Kata CI 会运行全部用例验证新内核可用性。

11.2 修改配置/补丁 → 提交到 packaging 仓库并升 kata_config_version

Kata 的 configs 与 patches 都在 tools/packaging/kernel/ 下。要点：

1. 新增配置：若新增某个版本/架构的完整配置，文件名必须遵循如下格式（原文档明确）：

# 格式：
${arch}_kata_${hypervisor_target}_${major_kernel_version}.x

# 示例：
arch=x86_64
hypervisor_target=kvm
major_kernel_version=4.19
# 结果文件：x86_64_kata_kvm_4.19.x

2. 新增补丁：放入 patches/<major.minor>.x/ 顶层目录（子目录会被忽略，除非属于对应 build-type），采用 NNNN-description.patch 命名以控制应用顺序（参考 apply_patches.sh 的排序逻辑：find -maxdepth 1 -name '*.patch' | sort -t- -k1,1n）。

3. 同步递增 kata_config_version：任何 configs/patches 变更都必须递增该文件中的数字，CI 才能识别配置已更新并重新测试。

4. 注意测试边界：configs 与 patches 理论上可适配多版本，但 Kata 只对 versions.yaml 中定义的版本进行 CI 验证，自定义版本需要自行承担验证责任。

十二、常见问题与排查思路

问题	排查方向
die: kernel_path already exist	内核目录已存在；使用 -f 强制清理重建
合并配置失败报 "not in final"	碎片中的 CONFIG 未进入最终 .config：确认该选项在当前内核版本存在，或加入 whitelist.conf
"redefined"/"redundant" 报错	同一 CONFIG 在不同碎片中被赋予不同值/重复定义，检查 common/ 与 <arch>/ 碎片是否有交集
debug 内核构建缺少 BTF	确认已安装 dwarves（CONFIG_DEBUG_INFO_BTF 依赖）
需要自定义配置	修改 .config 后执行 make menuconfig/make oldconfig；或修改 fragments 后重建
判断 CI 缓存内核是否过期	比较安装内核文件名中的 config_version 与仓库 kata_config_version（当前 204）是否一致
安装路径不对	检查 DESTDIR/PREFIX 环境变量，默认安装到 /usr/share/kata-containers/，运行时默认从 vmlinuz.container 读取（见 config-settings.go.in）

总结

Kata Containers 的 guest 内核构建是一个"脚本封装 + 配置碎片体系 + 版本双标识"的完整工程：build-kernel.sh 将下载源码、打补丁、拼配置、编译、安装串成 setup → build → install 三段式流程；configs/fragments/ 用模块化 .conf 碎片按 arch/common/gpu/debug/confidential 维度灵活组合；versions.yaml 与 kata_config_version 双文件共同管理内核版本与配置版本，保证 CI 缓存与源码构建的可追溯性。无论是构建标准内核、debug/eBPF 内核、NVIDIA GPU 内核，还是 TDX/SNP/CCA 机密计算内核，都可以在本指南的基础上直接上手并深入源码验证每一步行为。