Nanos – 一个 Unikernel

原文 ↗ Hacker News 讨论 ↗

感知到的收益和用例

  • Nanos 被认为很适合：
    • 高性能、低波动的云工作负载和 HPC。
    • 教学、操作系统/系统/CPU 架构研究。
    • 需要类似 Linux 进程模型的嵌入式系统。
  • 提到的主要优势：
    • 非常小的、单一用途的 OS 镜像，攻击面更小。
    • 更高的吞吐量（基准测试显示静态内容相比 Linux 约高 1.6 倍）。
    • 心智模型：“你的应用 + 最小内核 + hypervisor”，别无其他。

架构、裸机和文件系统

  • Nanos 明确设计为运行在 hypervisor 之上的 VM，而不是运行在任意裸机上。
  • 它面向半虚拟化环境（例如 KVM 设备），避免支持多样化的硬件驱动。
  • 它确实有文件系统；缺少的是交互式的多用户 userland。

调试、日志和运维问题

  • 多位评论者都对镜像内缺少 shell 和传统工具感到困扰。
  • 日志通常通过 syslog 或云日志（例如 CloudWatch）导出，类似 Kubernetes 的做法。
  • 有些人担心在出问题时环境会显得“贫血”；也有人认为远程日志 + 可附加调试器就足够了。
  • 文档因对 Nanos 本身的细节描述详尽而受到好评，但在管理、部署和测试方面的指导较薄弱而受到批评。

部署、编排和云集成

  • ops CLI 可以构建镜像并在 AWS 上启动 VM；也有 Terraform provider 和示例。
  • 策略是依赖云原语（ELB、ASG、存储服务）而不是复制 Kubernetes 风格的编排。
  • ops 不是一个编排系统；对于更大的部署，建议使用 Terraform 或云工具链。
  • 关于运行时配置（例如环境变量）与把配置烘焙进镜像之间存在困惑。

与容器、Alpine 和 Kubernetes 的比较

  • 许多人指出 Alpine + 容器之所以“胜出”，是因为生态成熟、熟悉度高，以及编排能力（Kubernetes）。
  • 容器被认为在隔离性和性能上“足够好”，而且更易调试（shell、可安装包）。
  • 有些人认为 unikernel 去掉了完整的多用户 OS 和不必要的内核功能；另一些人则认为这牺牲了便利性和技能迁移。

安全讨论

  • 支持者强调 VM 提供强隔离边界；容器则不是，反复出现的容器逃逸就是例证。
  • 据说在 Kubernetes 下运行 unikernel 会削弱安全收益，因为 Linux/容器层又回来了。
  • 使用 curl | sh 安装并依赖 MD5 校验被批评为不负责任；批评者呼吁签名的、可复现的构建以及多方验证。项目代表提到了其他下载方式，但疑虑仍然存在。

语言、研究和验证

  • 有人表达了对基于 Rust 的 unikernel 的需求；也有人为 C 辩护，认为如果谨慎编写，它在稳定性和简单性方面更好。
  • Nanos 与语言无关，据报道也被用于 Rust 应用。
  • 更广泛的 unikernel 生态：提到了 MirageOS 及其部分形式化推导的组件。
  • 有些人认为操作系统研究已经放缓，但仍然认为在分发、安全以及重新思考“云之下的栈”方面存在重大开放问题。

生态系统和工具

  • 三个主要组件常常造成混淆：
    • nanos.org：内核/技术。
    • nanovms.com：公司/产品。
    • ops.city：包和 ops CLI。
  • 打包模型被比作 Docker：基础包（例如 nginx）可通过配置（文件/目录/映射）进行扩展；用户已经在发布自己的包。
  • 社区空间策略存在争论（没有官方聊天 vs 希望有一个中心化、可搜索、尊重隐私的场所）。