云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载导读本文基于 Kata Containers 仓库官方文档 how-to-run-kata-containers-with-SE-VMs.md 展开完整讲解如何让 Kata Containers 运行在具备 IBM Secure Execution受保护虚拟化能力的 IBM zSystems / LinuxONE 主机上从主机能力核验、内核与 initrd 构件准备、genprotimg生成安全镜像、运行时配置调整到 QEMU 直接启动验证与 Kubernetes 集群内端到端验证并覆盖通过 Confidential Containers Operator kata-deploy 载荷镜像交付的自动化路径。读完本文你将掌握手工构建 IBM SE 镜像的完整命令序列、两种运行时Go 运行时qemu-se与 Rust 可组合运行时qemu-se-runtime-rs的差异与取舍以及 CI 集成的关键环境变量配置。适用前提本文针对 IBM zSystemsz15 及更新型号与 IBM LinuxONE III 及更新硬件平台文中命令在 s390x 架构上验证测试环境为 IBM z16 LPAR Ubuntu 22.04.1 LTS。背景与安全模型IBM Secure ExecutionSE是 IBM zSystems / LinuxONE 平台上的受保护虚拟机Protected Virtual Machine能力。与 TDX、SEV-SNP 等 TEE 类似SE 依靠固件级超管理器Ultravisor将客户虚拟机与宿主机、Hypervisor 隔离安全镜像在构建时使用**主机密钥文档Host Key Document, HKD**加密虚拟机启动时由 Ultravisor 使用对应的私钥解密。宿主机即使被攻破也无法读取受保护 VM 的内存内容。在 Kata Containers 中这意味着 kata 沙箱即轻量级 VM本身成为一个可信执行环境工作负载的隔离不再只依赖内核虚拟化边界而是叠加了硬件级机密计算保护适合承载需要可信环境authorized, authenticated, attested才能安全使用的工件与密钥的负载。文档假设你已经拥有一个按 Developer-Guide.md 搭建好的、可正常运行的 kata 环境本文只补充 SE 专属的镜像构建与部署步骤。测试环境规格官方文档给出的已验证环境可作复现参考并非硬性要求项目规格机器IBM z16 LPAR操作系统Ubuntu 22.04.1 LTSCPU16 vCPU内存16 GiB手动配置流程前置条件 1确认宿主机支持 Secure Execution首先确认宿主机硬件与内核具备受保护虚拟化能力# 从内核查看受保护虚拟化支持情况 $ cat /sys/firmware/uv/prot_virt_host 1 # 确认 Ultravisor 为本轮启动预留了内存 $ sudo dmesg | grep -i ultravisor [ 0.063630] prot_virt.f9efb6: Reserving 98MB as ultravisor base storage # 检查 CPU facility 位Secure Execution 对应位号 158 $ cat /proc/cpuinfo | grep 158 facilities : ... numbers ... 158 ... numbers ...如果以上任一结果不满足请联系云服务商开启 Secure Execution 能力。若你拥有管理员权限且 facility 位已置位可自行在内核参数中加入prot_virt1并重启开启$ sudo sed -i s/^\(parameters.*\)/\1 prot_virt1/g /etc/zipl.conf $ sudo zipl -V $ sudo systemctl reboot注意不同发行版启用 Secure Execution 的方式可能不同例如 RHEL/SUSE 系列可能通过其他引导配置请以发行版文档为准。前置条件 2准备 Kata Containers 构件SE 安全镜像由两个构件组成裸内核raw kernelvmlinux-6.1.62-121/vmlinuz-6.1.62-121等初始 RAM 磁盘initrdkata-ubuntu-20.04-confidential.initrd、kata-containers-initrd-confidential.img等最省事的获取方式是从已安装的 kata 运行时安装目录直接复用$ export PATH$PATH:/opt/kata/bin $ ls -1 $(dirname $(kata-runtime env --json | jq -r .Kernel.Path)) config-6.1.62-121 kata-containers.img kata-containers-confidential.img kata-containers-initrd.img kata-containers-initrd-confidential.img kata-ubuntu-20.04.initrd kata-ubuntu-20.04-confidential.initrd kata-ubuntu-latest.image kata-ubuntu-latest-confidential.image vmlinux-6.1.62-121 vmlinux.container vmlinuz-6.1.62-121 vmlinuz.container输出显示了内核vmlinux-6.1.62-121具体版本号可能因构建时间而异、rootfs 镜像kata-ubuntu-latest-confidential.image与 rootfs-initrdkata-ubuntu-20.04-confidential.initrd的部署情况。若缺构件则需要从项目源码自行构建# 假设项目已克隆到 $GOPATH/src/github.com/kata-containers $ cd $GOPATH/src/github.com/kata-containers/kata-containers $ make rootfs-initrd-confidential-tarball $ tar --zstd -tf build/kata-static-kernel.tar.zst | grep vmlinuz ./opt/kata/share/kata-containers/vmlinuz.container ./opt/kata/share/kata-containers/vmlinuz-6.7-136 $ kernel_version6.7-136 $ tar --zstd -tf build/kata-static-rootfs-initrd-confidential.tar.zst | grep initrd ./opt/kata/share/kata-containers/kata-containers-initrd-confidential.img ./opt/kata/share/kata-containers/kata-ubuntu-20.04-confidential.initrd $ mkdir artifacts $ tar --zstd -xvf build/kata-static-kernel.tar.zst -C artifacts ./opt/kata/share/kata-containers/vmlinuz-${kernel_version} $ tar --zstd -xvf build/kata-static-rootfs-initrd-confidential.tar.zst -C artifacts ./opt/kata/share/kata-containers/kata-ubuntu-20.04-confidential.initrd $ ls artifacts/opt/kata/share/kata-containers/ kata-ubuntu-20.04-confidential.initrd vmlinuz-${kernel_version}从仓库源码可以印证这些 tar 目标的依赖关系tools/packaging/kata-deploy/local-build/Makefile 中rootfs-initrd-confidential-tarball依赖agent-tarball pause-image-tarball coco-guest-components-tarball kernel-tarball即该 initrd 会打包 kata-agent、pause 镜像与 CoCo 客户机组件的完整集合这正是单体内核 机密 initrd方案的内涵。前置条件 3安装安全镜像生成工具 genprotimggenprotimg用于生成 IBM Secure Execution 镜像包含在s390-tools软件包中要求版本≥ 2.17.0低于该版本时必须追加参数--x-pcf 0xe0。源码原生构建示例$ sudo apt-get install gcc libglib2.0-dev libssl-dev libcurl4-openssl-dev $ tool_versionv2.34.0 $ git clone -b $tool_version https://github.com/ibm-s390-linux/s390-tools.git $ pushd s390-tools/genprotimg make sudo make install popd $ rm -rf s390-tools版本门槛逻辑同样体现在仓库构建脚本 tools/packaging/guest-image/lib_se.sh 中genprotimg --version低于2.17.0时脚本会自动补上--x-pcf 0xe0。前置条件 4获取主机密钥文档Host Key Document主机密钥文档是用于加密安全镜像的公钥VM 启动引导时由 Ultravisor 用对应私钥解密。获取途径二选一IBM 官方的 Resource Link需登录向负责你运行环境的 IBM Z / LinuxONE 云服务商索取为确保安全必须验证主机密钥文档的真实性与完整性请一并获取以下文件IBM Z 签名密钥证书IBM Z signing key certificateIBM Z 主机密钥证书吊销列表host key certificate revocation listDigiCert中间 CA 证书intermediate CA certificate构建安全镜像假设目录布局如下$HOME/host-key-document/HKD-0000-0000000.crt—— 主机密钥文档$HOME/certificates/ibm-z-host-key-signing-gen2.crt—— IBM Z 签名密钥证书$HOME/certificates/DigiCertCA.crt—— DigiCert 中间 CA 证书$HOME/certificates/ibm-z-host-key-gen2.crl—— IBM Z 主机密钥证书吊销列表两种镜像变体与两种运行时构建镜像前先明确运行时类runtime class运行时类运行时实现镜像形态说明qemu-seGo 运行时单体机密 initrd将所有 CoCo 客户机组件打包进一个 initrdqemu-se-runtime-rsRust 运行时可组合精简 base initrd 独立挂载的 CoCo 扩展镜像扩展镜像按 composable-vm-images.md 设计以附加 virtio-blk 冷插拔方式挂载以下命令对两种变体通用除非显式标注变体。手工方式genprotimg 直接调用$ # 切换到项目根目录 $ cd $GOPATH/src/github.com/kata-containers/kata-containers $ host_key_document$HOME/host-key-document/HKD-0000-0000000.crt $ kernel_imageartifacts/opt/kata/share/kata-containers/vmlinuz-${kernel_version} $ initrd_imageartifacts/opt/kata/share/kata-containers/kata-ubuntu-20.04-confidential.initrd $ echo panic1 scsi_mod.scannone swiotlb262144 agent.logdebug parmfile $ genprotimg --host-key-document${host_key_document} \ --outputkata-containers-se.img --image${kernel_image} --ramdisk${initrd_image} \ --parmfileparmfile --no-verify WARNING: host-key document verification is disabled. Your workload is not secured. $ file kata-containers-se.img kata-containers-se.img: data $ sudo cp kata-containers-se.img /opt/kata/share/kata-containers/--no-verify跳过了密钥验证流程仅限开发/测试环境使用。生产环境必须按如下方式携带证书与吊销列表做完整验证$ signcert$HOME/certificates/ibm-z-host-key-signing-gen2.crt $ cacert$HOME/certificates/DigiCertCA.crt $ crl$HOME/certificates/ibm-z-host-key-gen2.crl $ genprotimg --host-key-document${host_key_document} \ --outputkata-containers-se.img --image${kernel_image} --ramdisk${initrd_image} \ --cert${cacert} --cert${signcert} --crl${crl} --parmfileparmfileparmfile 中的内核参数panic1 scsi_mod.scannone swiotlb262144与仓库脚本 lib_se.sh 中自动拼接的命令行一致脚本还会额外追加agent.debug_console agent.debug_console_vport1026其中swiotlb262144为 SE 场景下保证 DMA 缓冲充足的关键参数。Make 目标方式推荐自动处理依赖不启用密钥验证的构建含内核与 initrd 依赖可一条命令完成。qemu-seGo 运行时单体$ cd $GOPATH/src/github.com/kata-containers/kata-containers $ mkdir hkd_dir cp $host_key_document hkd_dir $ HKD_PATHhkd_dir SE_KERNEL_PARAMSagent.logdebug make boot-image-se-tarball $ ls build/kata-static-boot-image-se.tar.zst build/kata-static-boot-image-se.tar.zstqemu-se-runtime-rsRust 运行时可组合$ cd $GOPATH/src/github.com/kata-containers/kata-containers $ mkdir hkd_dir cp $host_key_document hkd_dir $ HKD_PATHhkd_dir SE_KERNEL_PARAMSagent.logdebug make boot-image-se-runtime-rs-tarball $ ls build/kata-static-boot-image-se-runtime-rs.tar.zst build/kata-static-rootfs-image-coco-extension.tar.zst build/kata-static-boot-image-se-runtime-rs.tar.zst build/kata-static-rootfs-image-coco-extension.tar.zstSE_KERNEL_PARAMS可向两种变体注入额外内核参数无额外配置时也可省略。boot-image-se-runtime-rs-tarball会自动把rootfs-image-coco-extension-tarball作为前置依赖构建见 Makefile。CoCo 扩展镜像锁定在 versions.yaml 的.externals.coco-guest-components.version提交上其dm-verity 根哈希root_hash_coco-extension.txt由 guest-components 项目随扩展 tarball 一同发布构建时该哈希被提取出来并通过genprotimg以kata.extension.coco.verity_paramsroot_hash...,salt...,data_blocks...,...的形式封入 SE 内核命令行。因此运行时若替换扩展镜像封入的哈希必然失配启动阶段即被检测。这一密封机制在 composable-vm-images.md 中有精确定义genprotimg把完整的含 verity 参数的内核命令行在构建时用主机密钥加密封入 SE 镜像头部内容受完整性保护、无法在不重建镜像的前提下篡改而 build_se_image.sh 负责从扩展 tarball 中提取root_hash_coco-extension.txt并导出为COCO_VERITY_PARAMS供lib_se.sh拼装进命令行。对应地客户机内挂载脚本会交叉核对命令行与磁盘上的分区布局防止测量扩展被静默降级为未测量挂载。生产环境构建时通过环境变量开启密钥验证三者的关系在 lib_se.sh 中强制要么全部指定要么都不指定否则报错$ export SIGNING_KEY_CERT_PATH$HOME/certificates/ibm-z-host-key-signing-gen2.crt $ export INTERMEDIATE_CA_CERT_PATH$HOME/certificates/DigiCertCA.crt $ export HOST_KEY_CRL_PATH$HOME/certificates/ibm-z-host-key-gen2.crl若不需要真实 SE 环境做流水线联调仓库还提供了FAKE_SE_IMAGEtrue模式脚本用touch生成占位镜像并跳过内核/initrd/parmfile/主机密钥文档检查见 build_se_image.sh 与 Makefile 中相应依赖清空逻辑。调整运行时配置生成kata-containers-se.img并拷贝到/opt/kata/share/kata-containers/后还需修改运行时配置$ export PATH$PATH:/opt/kata/bin $ runtime_config_path$(kata-runtime kata-env --json | jq -r .Runtime.Config.Path) $ sudo cp ${runtime_config_path} ${runtime_config_path}.old $ # 对原配置文件做如下调整 $ diff ${runtime_config_path}.old ${runtime_config_path} 16,17c16,17 kernel /opt/kata/share/kata-containers/vmlinux.container image /opt/kata/share/kata-containers/kata-containers.img --- kernel /opt/kata/share/kata-containers/kata-containers-se.img # image /opt/kata/share/kata-containers/kata-containers.img 41c41 # confidential_guest true --- confidential_guest true 544c544 dial_timeout 45 --- dial_timeout 90要点说明kernel 指向 SE 镜像kernel /opt/kata/share/kata-containers/kata-containers-se.img原image项注释掉SE 场景下根文件系统已内嵌于镜像不再需要独立 rootfs 镜像开启机密访客confidential_guest true这是 QEMU 启用confidential-guest-support与s390-pv-guest对象的开关对应默认 SE 配置模板 configuration-qemu-se.toml.in 中恒为true的设定拉长 dial_timeout从默认 45 秒调至 90 秒。SE 镜像解密、Ultravisor 初始化等流程耗时更长需要更大的超时余量配置模板中该值同样是 90见 configuration-qemu-se.toml.in。验证QEMU 直启 测试容器先直接用 QEMU 启动 SE 镜像验证 Ultravisor 能成功解密并加载$ cd $GOPATH/src/github.com/kata-containers/kata-containers $ hypervisor_command$(kata-runtime kata-env --json | jq -r .Hypervisor.Path) $ secure_kernelkata-containers-se.img $ sudo $hypervisor_command -machine confidential-guest-supportpv0 \ -object s390-pv-guest,idpv0 -accel kvm -smp 2 --m 4096 -serial mon:stdio \ --nographic --nodefaults --kernel ${secure_kernel} [ 0.110277] Linux version 5.19.2 (root637f067c5f7d) (gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP Wed May 31 09:06:49 UTC 2023 [ 0.110279] setup: Linux is running under KVM in 64-bit mode ... log skipped ... [ 1.467228] Run /init as init process {msg:baremount source\proc\, dest\/proc\, fs_type\proc\, options\\, flagsMS_NOSUID | MS_NODEV | MS_NOEXEC,level:INFO,ts:2023-06-07T10:17:23.537542429Z,pid:1,subsystem:baremount,name:kata-agent,source:agent,version:0.1.0} ... log skipped ... $ # 按 ctrl a x 退出关键点-machine confidential-guest-supportpv0与-object s390-pv-guest,idpv0是 SE 虚拟机启动的必要 QEMU 参数kata 运行时在confidential_guest true时自动注入同样的参数。若主机密钥文档不合法你会遇到如下报错qemu-system-s390x: KVM PV command 2 (KVM_PV_SET_SEC_PARMS) failed: header rc 108 rrc 5 IOCTL rc: -22 Protected boot has failed: 0xa02反之若 hypervisor 日志无报错即表明镜像加载成功kata 运行时发起的 VM 将正常工作。最后在 Kubernetes 集群中跑一个测试容器做端到端验证假设已有运行中的集群$ kubectl get node NAME STATUS ROLES AGE VERSION test-cluster Ready control-plane,master 7m28s v1.23.1$ cat EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: nginx-kata spec: runtimeClassName: kata-qemu containers: - name: nginx image: nginx EOF pod/nginx-kata created $ kubectl get po NAME READY STATUS RESTARTS AGE nginx-kata 1/1 Running 0 29s $ kubectl get po -oyaml | grep runtimeClassName: runtimeClassName: kata-qemu $ # 请确认 confidential-guest-support 已设置且使用了安全镜像 $ ps -ef | grep qemu | grep -v grep root 76972 76959 0 13:40 ? 00:00:02 /opt/kata/bin/qemu-system-s390x ... qemu arguments ... -machine s390-ccw-virtio,accelkvm,confidential-guest-supportpv0 ... qemu arguments ... -kernel /opt/kata/share/kata-containers/kata-containers-se.img ... qemu arguments ...从 QEMU 进程命令行可以看到机器类型为s390-ccw-virtio且confidential-guest-supportpv0已生效、-kernel指向的正是安全镜像kata-containers-se.img。至此一个运行在 IBM Secure Execution 之上的 kata 容器即宣告就绪。通过 Kata-Deploy 与 Confidential Containers Operator 部署手动步骤虽然可行但在生产/集群化场景下更推荐自动化路径。通常你可以用 kata-deploy 在 Kubernetes 集群安装 Kata Containers但使用 IBM Secure Execution 时需要改用Confidential Containers Operatorconfidential-containers/operatorkata-deploy 容器镜像作为**载荷镜像payload image**出现在自定义资源ccruntime中由 Operator 负责把 kernel、shim-v2 等 Kata 二进制构件安装到节点。本节只讲载荷镜像即 kata-deploy的构建其余步骤请遵循 Confidential Containers 官方文档confidential-containers 项目的 ibm-se 指南。构建载荷镜像qemu-seGo 运行时单体$ cd $GOPATH/src/github.com/kata-containers/kata-containers $ host_key_document$HOME/host-key-document/HKD-0000-0000000.crt $ mkdir hkd_dir cp $host_key_document hkd_dir $ # 下面的命令会自动构建 kernel 与 rootfs-initrd-confidential $ HKD_PATHhkd_dir SE_KERNEL_PARAMSagent.logdebug make boot-image-se-tarball $ make qemu-tarball $ make virtiofsd-tarball $ make shim-v2-go-tarball $ mkdir kata-artifacts $ build_dir$(readlink -f build) $ cp -r $build_dir/*.tar.zst kata-artifacts $ ls -1 kata-artifacts kata-static-agent.tar.zst kata-static-boot-image-se.tar.zst kata-static-coco-guest-components.tar.zst kata-static-kernel.tar.zst kata-static-pause-image.tar.zst kata-static-qemu.tar.zst kata-static-rootfs-initrd-confidential.tar.zst kata-static-shim-v2-go.tar.zst kata-static-virtiofsd.tar.zst $ ./tools/packaging/kata-deploy/local-build/kata-deploy-merge-builds.sh kata-artifacts构建载荷镜像qemu-se-runtime-rsRust 运行时可组合boot-image-se-runtime-rs-tarball自动构建 CoCo 扩展 tarball 作为前置依赖因此kata-static-rootfs-image-coco-extension.tar.zst会随 SE 镜像一并产出且必须包含在载荷中$ cd $GOPATH/src/github.com/kata-containers/kata-containers $ host_key_document$HOME/host-key-document/HKD-0000-0000000.crt $ mkdir hkd_dir cp $host_key_document hkd_dir $ # 下面的命令会自动构建 kernel 与 rootfs-initrd $ HKD_PATHhkd_dir SE_KERNEL_PARAMSagent.logdebug make boot-image-se-runtime-rs-tarball $ make qemu-tarball $ make virtiofsd-tarball $ make shim-v2-rust-tarball $ mkdir kata-artifacts $ build_dir$(readlink -f build) $ cp -r $build_dir/*.tar.zst kata-artifacts $ ls -1 kata-artifacts kata-static-boot-image-se-runtime-rs.tar.zst kata-static-kernel.tar.zst kata-static-qemu.tar.zst kata-static-rootfs-image-coco-extension.tar.zst kata-static-rootfs-initrd.tar.zst kata-static-shim-v2-rust.tar.zst kata-static-virtiofsd.tar.zst $ ./tools/packaging/kata-deploy/local-build/kata-deploy-merge-builds.sh kata-artifacts两段流程的构建目标在仓库中有明确对应shim 组件清单 shim-components.json 将 s390x 架构分别映射为qemu-se所需的shim-v2-go, qemu, virtiofsd, kernel, rootfs-initrd-confidential, boot-image-se与qemu-se-runtime-rs所需的shim-v2-rust, qemu, virtiofsd, kernel, rootfs-initrd, rootfs-image-coco-extension, boot-image-se-runtime-rskata-deploy-binaries.sh 中的install_se_image/install_se_image_runtime_rs分别以--destdir与--composable --destdir调用 SE 镜像构建器。生产环境中与手动配置一样需先导出SIGNING_KEY_CERT_PATH、INTERMEDIATE_CA_CERT_PATH、HOST_KEY_CRL_PATH三个环境变量。若还需要为不带Secure Execution 功能的其他运行时类如kata、kata-qemu提供 rootfs 镜像请在运行kata-deploy-merge-builds.sh之前补执行$ make rootfs-image-tarball执行完毕后项目根目录会生成归档文件kata-static.tar.zst用于构建载荷镜像。若使用本地容器仓库localhost:5000$ docker run -d -p 5000:5000 --name local-registry registry:2.8.1构建并推送名为localhost:5000/build-kata-deploy、标签为latest的载荷镜像$ ./tools/packaging/kata-deploy/local-build/kata-deploy-build-and-upload-payload.sh kata-static.tar.zst localhost:5000/build-kata-deploy latest ... logs ... Pushing the image localhost:5000/build-kata-deploy:latest to the registry The push refers to repository [localhost:5000/build-kata-deploy] 76c6644d9790: Layer already exists 2413aff53bb1: Layer already exists 91462f44bb06: Layer already exists 2ad49fac591a: Layer already exists 5c75aa64ef7a: Layer already exists test: digest: sha256:25825c7a4352f75403ee59a683eb122d5518e8ed6a244aacd869e41e2cafd385 size: 1369随后即可在ccruntime自定义资源中引用该镜像交由 Confidential Containers Operator 完成节点侧部署。CI 集成注意事项若要把上述流程接入 CI 系统建议配置以下环境变量——它们通过缓存构建期间使用的容器镜像来加速 CI 任务$ export BUILDER_REGISTRY$YOUR_PRIVATE_REGISTRY_FOR_CI $ export PUSH_TO_REGISTRYyes其中BUILDER_REGISTRY指向你自己的私有镜像仓库供构建阶段拉取/缓存基础镜像PUSH_TO_REGISTRYyes指示构建产物如载荷镜像推送到该仓库避免每次 CI 运行重复从公共源拉取显著缩短流水线耗时。小结与排障速查完整链路回顾确认宿主机 SE 能力facility 158 prot_virt_host→ 准备内核/initrd 构件 → 获取并验证主机密钥文档 → 用genprotimg或make boot-image-se-tarball/boot-image-se-runtime-rs-tarball构建 SE 镜像 → 修改运行时配置kernel 指向 SE 镜像、confidential_guest true、调大dial_timeout→ QEMU 直启验证 → Kubernetes 测试容器验证 →可选通过 kata-deploy 载荷镜像 CoCo Operator 自动化交付。常见问题Protected boot has failed: 0xa02—— 主机密钥文档与当前机器不匹配或不合法检查 HKD 来源与证书验证链路genprotimg版本过低 —— 需 ≥ 2.17.0否则补--x-pcf 0xe0镜像加载成功但 kata 容器超时 —— 检查dial_timeout是否已从 45 调至 90生产环境误用--no-verify—— 务必改为证书 CRL 验证方式否则镜像安全性无法保证。深入阅读可组合 VM 镜像的完整设计扩展镜像、dm-verity、kata.extension.*.verity_params密封机制参见 composable-vm-images.mdSE 镜像构建脚本的完整参数与环境变量说明参见 build_se_image.sh 与 lib_se.shs390x 的 kata-deploy 构件清单见 shim-components.json。赞分享云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载相关推荐Kata Containers 在 IBM Z 上直通 CEX 硬件Secure Execution 机密容器中的关联密钥配置实战Kata Containers 在 IBM Z 上直通 CEX 硬件Secure Execution 机密容器中的关联密钥配置实战 在 IBM Zs390x云原生容器运行时bert-mini-finetuned-mnli在工业场景中的应用智能客服与内容审核案例bert mini finetuned mnli在工业场景中的应用智能客服与内容审核案例 bert mini finetuned mnli是一款基于MNLI云原生容器运行时Kubespray 部署 Kata Containers基于轻量级虚拟机的安全容器运行时实战指南Kubespray 部署 Kata Containers基于轻量级虚拟机的安全容器运行时实战指南 本文基于 Kubespray 官方文档 docs/CRI/k云原生容器编排DevOps运维上一篇如何使用GitLab CI构建自动化测试与部署流程新手必备教程下一篇Nixpkgs 中的 Geant4 粒子模拟工具包包配置、Setup Hook 与数据集管理实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
