尧图网站建设 
CubeSandbox K8s升级完全指南集群升级路径与高频问题FAQ【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox对于在 Kubernetes 集群上部署 CubeSandbox 的运维者来说「怎么升级才不中断沙箱」「升级后连不上 MySQL 怎么办」是最常遇到的两个问题。CubeSandbox 是一款面向 AI Agent 的轻量安全沙箱支持单机与多节点集群部署并可通过 Helm Chart 原生部署到 K8s 集群。本文结合官方文档梳理CubeSandbox K8s 升级路径与高频问题 FAQ帮助新手安全完成集群升级与故障排查。先搞懂架构为什么控制面与计算面升级方式不同在升级之前先理解 CubeSandbox 在 K8s 中的分层这是理解一切升级规则的前提控制面DeploymentCubeMaster调度与元数据、CubeAPIE2B 兼容 API、CubeOps运维后台、WebUI、CubeProxy 等。它们以标准 Deployment 形式滚动更新升级不影响沙箱。计算面四个原生 DaemonSetcube-nodeBig Pod运行 cubelet 与内嵌网络运行时沙箱的网络 TAP 设备就挂在它的 netns 里cube-node-installer向宿主机安装 shim / 内核 / 镜像制品cube-node-bootstrap节点预检并写入node-prep-ready标记cube-node-pvmPVM 宿主机内核切换可能导致节点重启。详细分层与启动顺序可阅读 docs/guide/kubernetes/architecture.md。一句话总结控制面可以优雅滚动升级而计算面升级会重建cube-nodeBig Pod该节点上的存量沙箱网络会被中断。集群升级路径控制面滚动 计算面按节点维护官方升级文档的核心目标是一句话控制面按序滚动计算面升级重建 Big Pod 并中断该节点存量沙箱。1. 日常升级的正确姿势升级时只改对应组件的镜像 tag不要随意改动 Big Pod 的 env、volumeMount、容器列表——这些同样会触发 Pod 重建。生产环境请按节点逐台灰度全量一起升级风险极高。升级前调用 CubeMaster 的隔离 API 隔离节点至少 60 秒并销毁该节点上的沙箱之后再升级。2. 组件与镜像的对应关系你想升级什么改哪个 values 键是否重建 Big Podcubelet 等运行时images.cubelet等✅ 会中断沙箱shim / 内核 / guest 制品images.cubeShim等❌ 不会节点预检逻辑images.nodeInit❌ 不会PVM 内核切换脚本images.pvmHostBootstrap❌ 不会但节点可能重启3. 组件升级顺序v0.7 迁移期必读在 cube-master → cube-ops 的迁移过程中升级顺序必须严格遵守先让 CubeOps 起来并可访问新版 cubelet 指向它地址不可达会 fail-fast再起 CubeMaster它依赖 cube-ops 可达迁移期间不要新旧 cubelet 混跑上报端点不同节点状态会不一致最后再滚动cube-master、cube-api与计算节点。4. 想让升级不中断两个方案部署cube-node时启用hostNetwork: truePod 重建后沙箱网络设备仍存活在宿主 netns 中使用熟悉的 K8s 原地升级in-place upgrade插件只换镜像不重建 Pod。红线操作这些动作同样会重建 Big Pod以下操作都会导致 PodIP / netns 变化、存量沙箱中断请只在计划内维护窗口执行红线操作原因增删 Big Pod 容器含改 slot 数量变更 Pod 模板DaemonSet 重建 Pod直接改 volumeMount / securityContext / 容器名 / env同上改wait-node-prepinit 容器配置init 容器任何变更都会重建手动删除 Big Pod等同重建数据面把制品安装塞进 Big Pod破坏职责划分制品必须走 Installer另外cubeNode.env、cubeNode.podAnnotations、global.timezone、cubeEgress.enabled等也会改变 Pod 模板不是可随手改的日常升级项。完整红线清单见 docs/guide/kubernetes/upgrade.md。FAQK8s 部署高频问题解答以下问题整理自官方 FAQdocs/guide/kubernetes/faq.md按场景分组。安装与验证类Q1helm install报错要求配置placement.*.nodeSelectorChart 通过templates/validate.yaml禁止通配部署避免误调度到任意节点。必须为控制面 / 计算面显式打上节点标签例如cube.tencent.com/cube-control: true、cube-nodetrue并配合角色污点。Q2helm test卡在 CubeAPI/health通常是 MySQL 迁移未完成——CubeMaster 内置 schema 迁移首次启动可能耗时数分钟安装时请使用--timeout 90m。Helm 3.13 的--timeout才对 test hooks 生效可加--logs查看。节点与调度类Q3计算节点 DaemonSet 的 Ready 数量不足按DESIRED / CURRENT / READY三段排查DESIRED0是没节点匹配placement.compute缺标签CURRENT DESIRED是污点挡住了调度READY CURRENT则先看 bootstrap 与wait-node-prep是否就绪。Q4控制面节点能兼任计算节点吗单节点试验可以同时打cube-control与cube-node两个标签但生产环境不推荐——资源争抢且升级策略不同。Q5临时把一台计算节点下线维护先销毁节点上的沙箱再kubectl drain加--ignore-daemonsets维护完kubectl uncordoncube-node会自动恢复注册。控制面与数据库类Q6cube-master 连不上 MySQL依次检查内置 MySQL 是否 Running → Secret 密码是否被误改 → 容器内连通性。使用外部 MySQL 时注意环境变量是CUBE_SANDBOX_MYSQL_*而 CubeMaster 侧的地址来自 Chart 渲染的conf.yaml。Q7升级后 schema 迁移卡住CubeMaster 启动时运行内置 goose 迁移可 grep 日志中的migrat关键字或连库查看goose_db_version异常退出留下的锁需按数据库状态谨慎手工处理。Q8CLM 故障切换后沙箱多 pause/resume 了一次属预期行为且只发生一次新 leader 接管后会复核各沙箱状态记录不一致时按安全方向记为paused不会真的对 VM 下发 pause下次请求自动唤醒即可。计算面 / PVM / 沙箱类Q9pvm-host-bootstrap反复重启多数情况是换内核后的正常重启而非 CrashLoop。先看三个日志pvm-host-bootstrap、wait-pvm-host、wait-node-prep。若节点换内核后始终不重启多半是缺少重启权限或 GRUB 未更新需登节点手动reboot并用uname -r自检。Q10节点 Ready 了但没有沙箱 / 节点未注册用cubeopscli node list查看healthy状态不在列表则 grep cubelet 注册日志常见原因是连不通 CubeMaster网络 / DNS。Q11某节点所有沙箱同时断网大概率是该节点的cube-nodePod 被重建了手动删除、模板变更或 drain——沙箱 TAP 设备在 Pod netns 中Pod 重建即销毁不会自愈。恢复方式是销毁并重建受影响沙箱预防方式是部署时启用hostNetwork: true。Q12单节点大约能跑多少沙箱受三方面约束内存每沙箱数百 MB 到数 GB、/data/cubelet磁盘容量默认 loopback 仅 25G建议改挂大容量 XFS 盘、KVM 数量单机通常数百上限。配合Pause可让空闲沙箱 CPU/RSS 趋近 0。CubeProxy / TLS / DNS 类Q13沙箱域名解析不到集群内先确认 CoreDNS 中注入了# BEGIN cube-sandbox-dns片段解析结果应为cube-proxy的 ClusterIP集群外则把*.cube.app指向 Ingress / LB。Q14selfSigned 证书浏览器告警试验环境属预期生产环境改用cubeProxy.tls.mode: existingSecret或certManager挂载正式证书。升级、回滚与卸载类Q15helm upgrade会中断沙箱吗只升 Installer / Bootstrap / PVM 镜像时不会一旦动了 Big Pod 模板含运行时镜像、容器、env、挂载会中断该节点存量沙箱PodIP 也会变化。Q16helm rollback会回滚宿主机内核吗不会。Helm 只管理 K8s 对象内核 / GRUB / fstab / XFS 属于宿主状态需要单独的宿主回滚 runbook。Q17helm uninstall后节点上还有数据这是设计行为——卸载只删 Chart 管理的对象。可用 Chart 自带的 deploy/kubernetes/chart/scripts/cleanup-node-host.sh 清理/data/cubelet、/data/cube-shim等残留PVC/PV 是否删除取决于 StorageClass 的reclaimPolicy。镜像构建类Q18如何构建 arm64 镜像 / 只重建单个镜像构建脚本支持按组件重建例如只传cubelet即只构建该镜像arm64 需要 arm64 机器或 buildx 多架构环境完整用法见脚本--help。报障模板高效提 Issue 的格式遇到问题时官方建议附上以下信息可显著加快定位速度Chart 版本 / K8s 版本 / 环境TKE / 自建 / k3s / 单节点 相关 values 片段脱敏 故障组件Pod 名 kubectl describe kubectl logs kubectl -n cube-system get pods -o wide小结控制面升级标准滚动按 CubeOps → CubeMaster → 其余的顺序执行计算面升级默认中断该节点沙箱升级前先隔离节点并清理沙箱想做到平滑升级安装时启用hostNetwork: true或使用原地升级插件遇到问题优先对照官方 K8s 部署总览、安装指南 与 FAQ按「DaemonSet 状态 → 日志 → 网络/DNS」的顺序排查。掌握以上升级路径与 FAQ你就能在 CubeSandbox 集群日常迭代中做到心中有数、操作有度。【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CubeSandbox K8s升级完全指南：集群升级路径与高频问题FAQ
CubeSandbox K8s升级完全指南集群升级路径与高频问题FAQ【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox对于在 Kubernetes 集群上部署 CubeSandbox 的运维者来说「怎么升级才不中断沙箱」「升级后连不上 MySQL 怎么办」是最常遇到的两个问题。CubeSandbox 是一款面向 AI Agent 的轻量安全沙箱支持单机与多节点集群部署并可通过 Helm Chart 原生部署到 K8s 集群。本文结合官方文档梳理CubeSandbox K8s 升级路径与高频问题 FAQ帮助新手安全完成集群升级与故障排查。先搞懂架构为什么控制面与计算面升级方式不同在升级之前先理解 CubeSandbox 在 K8s 中的分层这是理解一切升级规则的前提控制面DeploymentCubeMaster调度与元数据、CubeAPIE2B 兼容 API、CubeOps运维后台、WebUI、CubeProxy 等。它们以标准 Deployment 形式滚动更新升级不影响沙箱。计算面四个原生 DaemonSetcube-nodeBig Pod运行 cubelet 与内嵌网络运行时沙箱的网络 TAP 设备就挂在它的 netns 里cube-node-installer向宿主机安装 shim / 内核 / 镜像制品cube-node-bootstrap节点预检并写入node-prep-ready标记cube-node-pvmPVM 宿主机内核切换可能导致节点重启。详细分层与启动顺序可阅读 docs/guide/kubernetes/architecture.md。一句话总结控制面可以优雅滚动升级而计算面升级会重建cube-nodeBig Pod该节点上的存量沙箱网络会被中断。集群升级路径控制面滚动 计算面按节点维护官方升级文档的核心目标是一句话控制面按序滚动计算面升级重建 Big Pod 并中断该节点存量沙箱。1. 日常升级的正确姿势升级时只改对应组件的镜像 tag不要随意改动 Big Pod 的 env、volumeMount、容器列表——这些同样会触发 Pod 重建。生产环境请按节点逐台灰度全量一起升级风险极高。升级前调用 CubeMaster 的隔离 API 隔离节点至少 60 秒并销毁该节点上的沙箱之后再升级。2. 组件与镜像的对应关系你想升级什么改哪个 values 键是否重建 Big Podcubelet 等运行时images.cubelet等✅ 会中断沙箱shim / 内核 / guest 制品images.cubeShim等❌ 不会节点预检逻辑images.nodeInit❌ 不会PVM 内核切换脚本images.pvmHostBootstrap❌ 不会但节点可能重启3. 组件升级顺序v0.7 迁移期必读在 cube-master → cube-ops 的迁移过程中升级顺序必须严格遵守先让 CubeOps 起来并可访问新版 cubelet 指向它地址不可达会 fail-fast再起 CubeMaster它依赖 cube-ops 可达迁移期间不要新旧 cubelet 混跑上报端点不同节点状态会不一致最后再滚动cube-master、cube-api与计算节点。4. 想让升级不中断两个方案部署cube-node时启用hostNetwork: truePod 重建后沙箱网络设备仍存活在宿主 netns 中使用熟悉的 K8s 原地升级in-place upgrade插件只换镜像不重建 Pod。红线操作这些动作同样会重建 Big Pod以下操作都会导致 PodIP / netns 变化、存量沙箱中断请只在计划内维护窗口执行红线操作原因增删 Big Pod 容器含改 slot 数量变更 Pod 模板DaemonSet 重建 Pod直接改 volumeMount / securityContext / 容器名 / env同上改wait-node-prepinit 容器配置init 容器任何变更都会重建手动删除 Big Pod等同重建数据面把制品安装塞进 Big Pod破坏职责划分制品必须走 Installer另外cubeNode.env、cubeNode.podAnnotations、global.timezone、cubeEgress.enabled等也会改变 Pod 模板不是可随手改的日常升级项。完整红线清单见 docs/guide/kubernetes/upgrade.md。FAQK8s 部署高频问题解答以下问题整理自官方 FAQdocs/guide/kubernetes/faq.md按场景分组。安装与验证类Q1helm install报错要求配置placement.*.nodeSelectorChart 通过templates/validate.yaml禁止通配部署避免误调度到任意节点。必须为控制面 / 计算面显式打上节点标签例如cube.tencent.com/cube-control: true、cube-nodetrue并配合角色污点。Q2helm test卡在 CubeAPI/health通常是 MySQL 迁移未完成——CubeMaster 内置 schema 迁移首次启动可能耗时数分钟安装时请使用--timeout 90m。Helm 3.13 的--timeout才对 test hooks 生效可加--logs查看。节点与调度类Q3计算节点 DaemonSet 的 Ready 数量不足按DESIRED / CURRENT / READY三段排查DESIRED0是没节点匹配placement.compute缺标签CURRENT DESIRED是污点挡住了调度READY CURRENT则先看 bootstrap 与wait-node-prep是否就绪。Q4控制面节点能兼任计算节点吗单节点试验可以同时打cube-control与cube-node两个标签但生产环境不推荐——资源争抢且升级策略不同。Q5临时把一台计算节点下线维护先销毁节点上的沙箱再kubectl drain加--ignore-daemonsets维护完kubectl uncordoncube-node会自动恢复注册。控制面与数据库类Q6cube-master 连不上 MySQL依次检查内置 MySQL 是否 Running → Secret 密码是否被误改 → 容器内连通性。使用外部 MySQL 时注意环境变量是CUBE_SANDBOX_MYSQL_*而 CubeMaster 侧的地址来自 Chart 渲染的conf.yaml。Q7升级后 schema 迁移卡住CubeMaster 启动时运行内置 goose 迁移可 grep 日志中的migrat关键字或连库查看goose_db_version异常退出留下的锁需按数据库状态谨慎手工处理。Q8CLM 故障切换后沙箱多 pause/resume 了一次属预期行为且只发生一次新 leader 接管后会复核各沙箱状态记录不一致时按安全方向记为paused不会真的对 VM 下发 pause下次请求自动唤醒即可。计算面 / PVM / 沙箱类Q9pvm-host-bootstrap反复重启多数情况是换内核后的正常重启而非 CrashLoop。先看三个日志pvm-host-bootstrap、wait-pvm-host、wait-node-prep。若节点换内核后始终不重启多半是缺少重启权限或 GRUB 未更新需登节点手动reboot并用uname -r自检。Q10节点 Ready 了但没有沙箱 / 节点未注册用cubeopscli node list查看healthy状态不在列表则 grep cubelet 注册日志常见原因是连不通 CubeMaster网络 / DNS。Q11某节点所有沙箱同时断网大概率是该节点的cube-nodePod 被重建了手动删除、模板变更或 drain——沙箱 TAP 设备在 Pod netns 中Pod 重建即销毁不会自愈。恢复方式是销毁并重建受影响沙箱预防方式是部署时启用hostNetwork: true。Q12单节点大约能跑多少沙箱受三方面约束内存每沙箱数百 MB 到数 GB、/data/cubelet磁盘容量默认 loopback 仅 25G建议改挂大容量 XFS 盘、KVM 数量单机通常数百上限。配合Pause可让空闲沙箱 CPU/RSS 趋近 0。CubeProxy / TLS / DNS 类Q13沙箱域名解析不到集群内先确认 CoreDNS 中注入了# BEGIN cube-sandbox-dns片段解析结果应为cube-proxy的 ClusterIP集群外则把*.cube.app指向 Ingress / LB。Q14selfSigned 证书浏览器告警试验环境属预期生产环境改用cubeProxy.tls.mode: existingSecret或certManager挂载正式证书。升级、回滚与卸载类Q15helm upgrade会中断沙箱吗只升 Installer / Bootstrap / PVM 镜像时不会一旦动了 Big Pod 模板含运行时镜像、容器、env、挂载会中断该节点存量沙箱PodIP 也会变化。Q16helm rollback会回滚宿主机内核吗不会。Helm 只管理 K8s 对象内核 / GRUB / fstab / XFS 属于宿主状态需要单独的宿主回滚 runbook。Q17helm uninstall后节点上还有数据这是设计行为——卸载只删 Chart 管理的对象。可用 Chart 自带的 deploy/kubernetes/chart/scripts/cleanup-node-host.sh 清理/data/cubelet、/data/cube-shim等残留PVC/PV 是否删除取决于 StorageClass 的reclaimPolicy。镜像构建类Q18如何构建 arm64 镜像 / 只重建单个镜像构建脚本支持按组件重建例如只传cubelet即只构建该镜像arm64 需要 arm64 机器或 buildx 多架构环境完整用法见脚本--help。报障模板高效提 Issue 的格式遇到问题时官方建议附上以下信息可显著加快定位速度Chart 版本 / K8s 版本 / 环境TKE / 自建 / k3s / 单节点 相关 values 片段脱敏 故障组件Pod 名 kubectl describe kubectl logs kubectl -n cube-system get pods -o wide小结控制面升级标准滚动按 CubeOps → CubeMaster → 其余的顺序执行计算面升级默认中断该节点沙箱升级前先隔离节点并清理沙箱想做到平滑升级安装时启用hostNetwork: true或使用原地升级插件遇到问题优先对照官方 K8s 部署总览、安装指南 与 FAQ按「DaemonSet 状态 → 日志 → 网络/DNS」的顺序排查。掌握以上升级路径与 FAQ你就能在 CubeSandbox 集群日常迭代中做到心中有数、操作有度。【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考