Incus 脚本审阅与验收 · 第 1 / 8 篇
一台服务器能启动六个 Debian，看起来像一次简单的数量扩容。真正值得记录的，是六个环境能否单独管理、网络是否互相影响、重装一台会不会伤到其他实例，以及资源用完时系统会怎样表现。这个系列围绕这些问题，拆解一套 Debian 12 与 Incus 管理脚本。
先说明这份记录能证明什么
本系列依据六份现存脚本、对应操作手册及官方资料编写。我们重新完成了 Bash 语法检查、内嵌 Python 语法检查和若干离线逻辑复现。原部署与重装手册明确写着：尚未在用户服务器完成端到端部署或破坏性重装验证。因此，本文中的架构是代码设计，验收表是需要实机填写的标准，不是已经获得的六台全绿报告。文件名里的 verified 不能代替测试证据。
这是系统容器，不是六台独立虚拟机
Incus 同时管理系统容器和虚拟机。这套脚本执行的是不带 --vm 的 incus launch images:debian/12，目标是系统容器。它适合获得完整的 Debian 用户空间、运行 systemd、安装 SSH 和普通 Linux 服务。容器共享宿主机内核；不能因此声称每台都有独立内核，或者拥有与独立 KVM 实例相同的隔离边界。Incus 官方容器与虚拟机说明
这里的“小鸡”是便于交流的昵称。对外说明环境时，应写“Incus Debian 系统容器”，这样读者不会误以为获得了六个独立公网 IP、独立硬盘或六份独占算力。
方案中的四个部件分别解决什么问题
例如，连接宿主机的 2203 端口，预期进入 vps3 的 22 端口。这是端口分流，不是给 vps3 分配了新公网地址。业务端口由另一份管理脚本按需添加，部署脚本本身没有预先开放一整段业务端口。
六台的成本不能只看实例数量
单实例配置是 limits.cpu=1、limits.memory=256MiB、根盘上限 3GiB。CPU 参数不能被宣传成“独占一个物理核”。六台内存上限相加是 1536MiB，这个算式还没有算宿主系统、Incus、缓存、Docker、监控等开销。它既不表示启动后立即消耗这么多，也不能证明一台约 2GB 内存的宿主机可以稳定承载所有容器同时满载。
同样，六份 3GiB 上限相加是 18GiB，而存储池只有 12GiB。上限不是预留，池容量也不是从空气中增加的磁盘。升级软件、写日志、保留镜像和快照都会参与容量竞争。这个方案可以用于轻量实验，但扩容前必须观察实际工作负载，不能只把 COUNT=3 改成 COUNT=6 就宣称容量验证完成。
三台版到六台版，代码到底变化了什么
对现存两个部署脚本逐行比较，唯一差异是 COUNT=3 与 COUNT=6。这能证明它们采用同一套部署逻辑，不能证明六台版经过了新增的压力测试，也不能推断旧版曾有怎样的性能问题。
合理的扩展顺序是：先让一台容器完成完整验收，再扩到三台，观察并发更新、内存峰值与磁盘增长；最后增加到六台，重复同样测试。每一步保留版本、配置和结果，扩容才是可复查的演进过程。
本篇希望达到的效果
读完这一篇，应能画出“公网入口—宿主机代理—容器 SSH”和“容器—网桥—出口”的两条路径，算清共享资源，并知道哪些承诺不能从配置数字推出来。下一篇开始拆解部署顺序和根盘配额，重点回答：为什么创建成功还不等于部署完成。
依据与范围：本地 3 台、6 台部署脚本；Incus 实例配置选项。官方在线文档反映当前版本；本套脚本目标为 Debian 12 amd64 与 Incus 6.0 系列，实际执行前还应核对本机帮助与版本。