Kata Container 部署与应用实践

一、背景

随着公司云原生技术的深入应用，业务场景对容器隔离性和性能的要求日益严苛，传统运行时，如Docker、containerd在安全隔离性和资源开销方面的局限性逐渐显现，在此背景下，引入Kata Containers作为安全容器解决方案。
Kata Containers 为每个容器实例创建一个非常轻量级的MicroVM，每个容器不再直接共享宿主机的操作系统内核，而是有自己的隔离的硬件抽象层，包括CPU、内存、I/O设备等，以及一个独立的内核。通过硬件虚拟化与容器敏捷性的结合，为金融等对安全要求较高的业务提供了符合安全标准的解决方案，同时避免传统虚拟化的性能瓶颈。

二、构建方案

1、修改 MTU 值

Docker 默认 MTU 为 1500，虽然 Docker 会自动检测主机网络接口的 MTU 值，若主机接口 MTU 小于 1500，Docker 会继承主机 MTU 值，但若使用 bridge 模式，Docker 会创建独立网桥 docker0，其 MTU 默认不继承虚拟机接口值，依然使用默认值 1500。
而虚拟机通常使用 NAT 或桥接模式，底层会添加额外的协议头，如虚拟网卡驱动、Overlay 封装，导致实际可用 MTU 小于标准以太网的 1500 字节。例如虚拟化层可能占用 50 字节，实际有效 MTU 仅为 1450。
Docker 此时使用默认的 1500，考虑虚拟化层的额外开销，会导致数据包超过物理链路承载能力，引发分片丢失或校验失败。
此时有两种解决方式：

• 指定 --network host 使容器直接共享宿主机网络栈，绕过 Docker 虚拟网络 docker0 网桥，使用的就是主机网络，无需匹配 MTU。但这需放弃容器网络隔离性，仅用于测试环境。

• 配置 docker 引擎的配置文件 daemon.json，文件用于自定义 docker 守护进程的配置，默认情况下没有，daemon.json: "mtu": 1450 强制所有容器网络接口使用指定 MTU，匹配虚拟机主机网络的实际承载能力，保持容器网络隔离，适用于生产环境。

$ systemctl status docker
$ systemctl start docker$ mkdir -p /etc/docker  # 创建配置目录
$ touch /etc/docker/daemon.json   # 创建空配置文件 
$ chmod 644 /etc/docker/daemon.json   # 设置权限$ systemctl restart docker

配置文件内容如下：

{# 允许Docker守护进程通过HTTP协议访问指定的私有镜像仓库"insecure-registries": ["r.addops.soft.360.cn"],# 设置容器网络的最大传输单元，需匹配底层网络，避免因MTU不匹配导致分片丢包"mtu": 1450,# 启用Docker自动管理iptables规则，实现容器网络NAT和端口转发"iptables": true,# 当Docker守护进程崩溃或升级时，保持运行中的容器继续存活"live-restore": true,# 在每个容器内注入轻量级初始化进程，负责回收僵尸进程"init": true,# 自定义Docker的存储路径，默认在/var/lib/docker"data-root": "/data/docker",# 禁用SELinux对Docker的强制访问控制，仅在SELinux导致兼容性问题时关闭"selinux-enabled": false
}

此外，VPC 是云计算平台提供的隔离虚拟网络环境，允许用户在云中自定义私有网络空间，VPC 底层使用 Overlay 网络，添加额外的隧道头，占用原始数据包空间，因此在云服务器环境下也需要设为 1450 或更低。

2、构建文件系统镜像

根据下述命令所列出的distributions：

$ ./kata-containers/tools/osbuilder/rootfs-builder/rootfs.sh -l

选择需要构建的镜像 distro 创建本地根文件系统：

$ export distro="ubuntu" # example
$ export ROOTFS_DIR="$(realpath kata-containers/tools/osbuilder/rootfs-builder/rootfs)"
$ sudo rm -rf "${ROOTFS_DIR}"
$ pushd kata-containers/tools/osbuilder/rootfs-builder
$ script -fec 'sudo -E USE_DOCKER=true ./rootfs.sh "${distro}"'
$ popd

然后执行下述命令创建根文件系统镜像：

$ pushd  kata-containers/tools/osbuilder/image-builder
$ script -fec 'sudo -E USE_DOCKER=true ./image_builder.sh "${ROOTFS_DIR}"'
$ popd

最终会在 kata-containers/tools/osbuilder/ 目录下生成 *.img 文件。

3、构建自定义内核

首先根据下述命令所列出的选项构建所需要的自定义内核：

$ ./build-kernel.sh -h

然后配置内核源代码：

$ cd kata-containers/tools/packaging/kernel
$ ./build-kernel.sh setup -v 5.19 -a x86_64 -g nvidia

最后构建自定义内核：

$ ./build-kernel.sh -h
$ ./build-kernel.sh -v 5.19 -a x86_64 -g nvidia build

• -v 5.19 : 确认 guest kernel 版本

• -a:指定 guest kernel 架构

• -g nvidia: ：构建支持Nvidia GPU的 guest kernel

最终会在 kata-containers/packaging/kernel/kata-linux-5.19-114/arch/x86/boot/ 目录下生成 bzImage 文件。

三、部署方案

# 在宿主机执行部署文件
kubectl apply -f kata-rbac.yaml
kubectl apply -f kata-deploy-stable.yaml
kubectl apply -f kata-runtimeClasses.yamlsystemctl restart containerd# 在宿主机的/etc/containerd/config.toml搜索kata相关字段，验证部署成功
cat /etc/containerd/config.toml# 也可以进入部署容器查看
kubectl $c get po -n kube-system | grep kata-deploy
kubectl $c exec -it -n kube-system kata-deploy-4qgzf -c kube-kata -- /bin/bash

部署成功后，在宿主机的 /opt/kata/share/defaults/kata-containers/configuration.toml 中配置之前构建的镜像和内核：

# 复制到指定目录
cp kata-containers-anolis.img /opt/kata/share/kata-containers/
cp bzImage /opt/kata/share/kata-containers/vmlinuz-5.19# 修改下述字段
[hypervisor.qemu]
path = "/opt/kata/bin/qemu-system-x86_64"
#kernel = "/opt/kata/share/kata-containers/vmlinux.container"
#image = "/opt/kata/share/kata-containers/kata-containers.img"
kernel = "/opt/kata/share/kata-containers/vmlinuz-5.19"
image = "/opt/kata/share/kata-containers/kata-containers-anolis.img"

配置完成后，在 template.spec 字段指定 runtimeClassName 字段创建 kata 容器。

四、virtiofsd限速方案

git clone -b devel https://code.geelib.qihoo.net:11443/g-virt-dev/virtiofsd.git
dnf install libcap-ng-devel libseccomp-devel
cargo build --release
cd ./virtiofsd/target/release

使用build后的virtiofsd替换宿主机的/opt/kata/libexec/virtiofsd，然后在宿主机的 /opt/kata/share/defaults/kata-containers/configuration.toml 中配置，配置shared_fs与virtio_fs_extra_args：

# 修改下述字段
# Shared file system type:
#   - virtio-fs (default)
#   - virtio-9p
#   - virtio-fs-nydus
#   - none
# WARNING: "none" should be carefully used, and only used in very few specific cases, as
# any update to the mount will *NOT* be reflected during the lifecycle of the pod, causing
# issues with rotation of secrets, certs, or configurations via kubernetes objects like
# configMaps or secrets, as those will be copied into the guest at *pod* *creation* *time*.
shared_fs = "virtio-fs"# Path to vhost-user-fs daemon.
virtio_fs_daemon = "/opt/kata/libexec/virtiofsd"# List of valid annotations values for the virtiofs daemon
# The default if not set is empty (all annotations rejected.)
# Your distribution recommends: ["/opt/kata/libexec/virtiofsd"]
valid_virtio_fs_daemon_paths = ["/opt/kata/libexec/virtiofsd"]# Default size of DAX cache in MiB
virtio_fs_cache_size = 0# Default size of virtqueues
virtio_fs_queue_size = 1024# Extra args for virtiofsd daemon
#
# Format example:
#   ["--arg1=xxx", "--arg2=yyy"]
# Examples:
#   Set virtiofsd log level to debug : ["--log-level=debug"]
#
# see `virtiofsd -h` for possible options.
#virtio_fs_extra_args = ["--thread-pool-size=1", "--announce-submounts"]
virtio_fs_extra_args = ["--fs-bw-burst=20000000", "--fs-bw-size=10000000", "--thread-pool-size=1", "--announce-submounts"]

之后创建 kata 容器，为使用virtiofsd限速功能，所选镜像需要支持virtio-fs，若镜像不支持virtio-fs，即使配置字段shared_fs，创建后的kata容器也无法正常运行：

image: harbor.qihoo.net/kata-containers/kata-deploy:2.1

五、总结

在整个流程中：

• 需要特别注意版本问题，大多数报错均因版本不匹配而引起

• 必须安装 go 最新版本才能安装 yq

• 必须要安装 docker-ce，不要使用yum install docker自动安装为 podman

• Kubernetes 通过 CRI 默认调用 containerd 作为容器运行时管理器，因此整个流程需要 containerd 支持

通过构建与部署 Kata Container，既解决了传统虚拟机隔离性强但启动慢、资源占用高的问题，又为关键业务，如金融交易、AI训练等提供内核级隔离，而virtiofsd限速，则可动态分配计算资源，防止底层共享内核被低优先级任务抢占资源。