Sealos

Sealos以 Kubernetes 为底层，把开发环境、应用部署、数据库、对象存储和项目资源放进统一工作区。它能减少直接编写底层清单的步骤，但不会消除镜像安全、密钥管理、容量、备份和故障恢复。最合适的试点是一个可随时重建的非关键应用。

部署前先固定可重建的发布物

明确 OCI 镜像版本、启动命令、容器端口、健康检查、环境变量和配置文件，密钥单独存放，不写进镜像。使用 DevBox 时，可先创建发布版本再交给 App Launchpad；使用现有镜像时，也应记录源码提交和构建过程，避免只能从运行容器反推配置。

在 Launchpad 配齐计算、网络与卷

官方部署流程要求分配 CPU、内存和存储，并配置端口与必要的持久卷。先用内部访问验证服务，再开放域名和公网入口；为无状态副本设置资源上下限，确认滚动更新期间旧新版本如何共存。应用详情显示“运行中”后，还要从外部完成一次真实业务请求。

数据库与对象存储分别管理状态

数据库服务可选择 PostgreSQL 等类型、版本、资源、副本与存储容量，并在创建前显示预计费用。对象存储提供 S3 兼容接口和内外网端点；含敏感数据的 Bucket 从 private 起步，生产环境避免公开读写。凭据只交给需要的应用，备份文件再做跨故障域保存。

用三层应用验收平台边界

选择一个前端、API 和 PostgreSQL 组成的样例：前端只访问 API，API 通过内部地址连接数据库，并把上传文件写入 private 对象存储。为每层记录镜像、CPU、内存、端口、域名、环境变量和存储依赖。部署后创建一条带附件的数据，再重启 API 实例，确认数据库记录和对象文件都还存在。

更新、扩容和观测必须一起验收

发布新镜像前先备份状态数据，观察启动探针、日志、CPU、内存、磁盘和请求错误，再逐步切换流量。扩副本只能缓解可水平伸缩的组件；数据库连接、队列和共享卷可能成为新瓶颈。平台界面解释不了异常时，团队仍需具备查看 Kubernetes 资源和事件的能力。

离开平台时要带走完整退出包

• 镜像、启动参数和配置模板；
• 数据库逻辑备份及恢复说明；
• 对象文件、Bucket 权限与域名控制权；
• 资源规格、依赖版本和最近一次恢复结果。

Sealos 的开源部署与在线托管在责任、地域、计费和支持上不同。正式采用前，以当前区域和实际工作负载核算持续运行、存储与网络费用，并在另一环境恢复一次退出包。