Sealos 应用商店简单说是云环境里的应用安装入口。它解决的核心问题不是“多了一个下载软件的页面”而是把数据库、中间件、Web 服务这类云上应用从一个人折腾半天的部署过程变成一套可视化、模板化、可复现的安装流程。第一次接触的人很容易拿手机应用商店或 Linux 桌面应用商店来类比但它和这两种完全不同——在 Sealos 应用商店里点“安装”得到的是运行在 Kubernetes 集群里的一组服务而不是一个本机安装包。这个主题适合三类人看刚开始接触云原生想找一个能快速部署应用的环境做开发、测试不想每次手动写 Kubernetes YAML以及准备用 Sealos 自建低配云平台或者学习公有云应用商店模式的运维人员。最值得关注的点不是它能安装多少应用而是你能不能把存储、访问入口、日志和资源限制这几个关键条件搞清楚。下面我从定位、环境、流程、参数、运维和排查几个角度拆一遍。1. 先分清 Sealos 应用商店和普通应用商店的边界1.1 它不是一个“下载软件”的页面很多人第一次打开 Sealos 应用商店会习惯性把它想成手机里的应用市场或 Linux 发行版里自带的软件中心。比如你在 Linux 桌面环境的应用商店里会有办公软件、浏览器、输入法点安装之后系统会把安装包下载到本机然后装进系统目录里。Sealos 应用商店的工作方式不是这样。在 Sealos 应用商店里你选择的应用本质上是一个部署模板。点击部署之后平台会调用 Kubernetes 集群的接口创建对应的 Deployment、Service、PVC、ConfigMap 等资源然后从镜像仓库拉取镜像在集群节点上启动容器。整个过程只有一个界面入口但实际执行的是一个完整的云原生部署流程。这意味着两件事。第一你不需要在服务器上手动安装 MySQL、Redis、Nginx也不需要自己维护安装脚本和版本依赖第二应用安装后的“位置”不是某个本地目录而是集群中的资源对象。如果你后续想迁移、备份或扩展副本操作方式也和本地安装完全不同。1.2 这个商店里的应用是服务而不是工具继续用桌面应用商店对比。桌面商店里的软件通常解决“人机交互”的问题比如浏览器、编辑器、聊天工具。Sealos 应用商店里的应用则更多以服务形态存在比如数据库、对象存储、消息队列、API 网关、博客系统、低代码平台等。它们提供给用户的不是一个可以双击打开的本地程序而是一个供业务调用的地址、端口或管理后台。这不是说应用商店里没有带界面的应用。像博客、CMS、低代码平台等等也会有网页管理界面但核心仍然是服务化运行。你把一个带 Web 界面的应用部署上去得到的不是本地的一整套运行环境而是一组运行中的服务组合包括 Web 服务、数据库服务以及它们之间的网络连接。容易出现的一个误判是应用商店里那么多应用是不是所有都适合我不一定。Sealos 应用商店更适合已经有业务目标的场景比如我确实需要一套博客、需要一套团队的 API 文档平台、需要给开发环境搭一套 MySQL。如果你只是想找一个能装到本机的软件集合那它并不适用。1.3 为什么这个入口值得关注应用部署最大的痛点从来不是“安装按钮不好找”而是流程太长准备服务器、安装依赖、配置网络、处理存储、维护环境变量。Sealos 应用商店把这些拆成了模板和参数把重复的部分交给 Kubernetes 处理。对刚接触云原生的开发人员来说比较友好的地方在于你不需要理解每个底层对象的含义也能先把应用跑起来。不过有经验之后你会发现它并不是一个“无脑点安装”的黑盒。真正用好应用商店依然要了解集群资源、持久化存储、网络映射和日志排查。这也是后面会反复提这些基础概念的原因。2. 上手前的环境准备服务器、账号和网络条件2.1 先确定你要用公有云版本还是自己部署开源版Sealos 有两种常见使用方式。一种是直接使用官方提供的公有云服务打开网页、注册账号、进入工作台另一种是使用社区版或开源版本在自己的服务器上部署一套完整环境。这两条路径的前置条件不同。如果你走公有云版本前置条件相对简单注册账号确认实名认证方式按平台引导开通工作空间一般会涉及资源配额或计费提醒。费用结构、具体资源单价在不同区域、不同时间段可能都不一样建议以实际开通页面为准。不要一次性把配额开满先用最小的资源验证流程。如果自己部署开源版你需要准备一台 Linux 服务器。这里建议先做单节点测试不要一上来就搞多节点集群。单节点能跑通再去扩展节点。内存和磁盘是最容易出问题的地方如果机器内存很小集群基础组件可能只占用一小部分但应用商店里部署数据库或中间件后内存会迅速被占满。磁盘也一样很多应用需要持久化存储节点磁盘空间不足会导致调度失败或 Pod 无法启动。2.2 网络、域名和端口条件无论哪种方式网络条件都需要重点确认。应用商店里部署应用会拉取各种镜像如果你的服务器或运行环境无法正常访问镜像仓库很多应用会卡在镜像拉取失败的状态。这个问题在初次使用时出现频率很高但往往不是 Sealos 本身的问题而是网络达不到镜像仓库或者仓库响应过慢。访问入口通常也需要提前规划。公有云版本一般会提供默认域名或自定义域名的配置入口自建版本则需要你准备一个可以解析到服务器 IP 的域名或者先用 IP 加端口的方式做验证。HTTPS 证书不是必须从一开始就配置但如果涉及登录页面和密码明文传输我建议在最开始就保留证书配置位置否则后面更换会比较麻烦。2.3 需要准备哪些命令行工具在浏览器里使用 Dashboard 已经能完成大部分操作但做问题排查时建议准备 kubectl 命令行工具。原因很简单应用商店给你看的是结果很多报错细节必须进入 Pod 事件或日志才能看到。如果你是运维或有一定基础也可以关注 Sealos 自带的命令行工具用于集群节点管理、镜像打包、集群安装等场景。具体命令参数每个版本可能不同落地时先运行帮助命令确认当前版本用法。这里不展开具体命令避免和你实际安装的版本不匹配。2.4 资源配额和费用预期和手机应用商店不同Sealos 应用商店里的部署会持续占用服务器资源。应用跑起来会占 CPU 和内存持久化存储会占磁盘对外访问还涉及网络流量。学习环境可以使用很小的工作空间但生产任务需要单独规划。最稳妥的方式是先给每个应用设置资源规格不要全部默认。我一般会建议一个简单的资源预算法先明确你想部署应用的类型。一个带 Web 界面的应用比如博客、CMS、低代码平台至少需要给 1 核 CPU 和 1G 内存左右的保底资源如果再加上数据库资源会更高。低配机器能跑起来但不建议同时部署大量应用。这个判断不是某一套固定的官方标准而是实测时最容易遇到的资源边界。3. 第一次部署完整流程从打开商店到确认服务可用3.1 最小验证目标先把一个简单应用跑通第一次使用不要一上来就部署 MySQL、Redis、Kafka 这类有状态基础设施。建议先从简单的 Web 应用开始例如博客类、CMS 类或者静态站点工具。这样你可以在一两个小时内把整条链路跑通包括浏览应用商店、填写参数、执行部署、拿到访问地址、确认页面可打开、查看日志。这个顺序是按“排错面积”来设计的。简单 Web 应用只有一个服务实例不涉及复杂存储和密码初始化即使失败排查量也很小。数据库类应用会引入 PVC、启动脚本、账号初始化、数据卷权限等变量任何一个环节出问题你都会分不清是应用商店的问题还是应用本身的问题。3.2 完整的部署步骤参考以下流程以 Web 应用为例登录 Sealos Dashboard进入工作空间或命名空间。打开应用商店入口先浏览首页的应用分类。搜索或选择一个简单的 Web 应用点击进入详情页。查看应用简介、版本号、所需资源描述和默认端口。填写应用名称选择命名空间设置资源规格。按页面要求填写环境变量或初始化配置比如管理员账号、数据库连接信息。确认配置无误后点击部署进入部署状态页。等待资源创建完成观察状态从 Pending 变为 Running。找到访问入口可能是服务地址、域名或外部端口。打开浏览器访问确认首页或登录页能正常显示。回到应用详情页查看运行日志确认没有循环报错。每一步都不复杂但要注意第 5、6、7 步不是“只点一下确认”的过程。应用商店给你的参数大多有默认值但不一定适合你的集群环境。比如使用哪个命名空间、多少个副本、什么资源限制这些直接决定应用能否正常调度。3.3 怎么确认部署“真的成功”不要只看 Deployment 状态变成 Running 就结束。Running 只能说明容器进程在运行不代表业务可用。一个 Web 应用可能在 10 秒内启动完成也可能因为数据库连接失败反复重启但状态仍然显示 Running。我建议用三个条件判断成功Pod 处于 Running 或 Completed且没有反复重启。最近的日志中没有 fatal、connection refused、permission denied 这类关键错误。通过浏览器或 curl 请求访问入口时返回的是正常业务页面而不是 502、504 或空白页。如果你不熟悉命令行也要在 Dashboard 的日志和事件面板里确认这两个地方。很多“我部署了但访问不了”的问题早期会在日志里留下很明显的线索。3.4 如果第一步失败不要反复点“重新部署”重新部署会重建一组资源但不会自动解决根本问题。我更建议先记录当前 Pod 的状态和日志回到第 6 章按顺序排查。没有明确原因就反复重试既浪费时间也可能因为积压太多资源导致新的问题。4. 选应用和配参数时最容易忽略的四个细节4.1 有状态、无状态两类应用的判断方法完全不同应用商店里的应用可以粗略分成两大类。无状态应用比如 Nginx、静态站点、大部分 Web 服务重启后不需要保留上一份数据。有状态应用比如 MySQL、PostgreSQL、Redis、MongoDB它们需要把数据写到持久化存储里重启后数据不能丢。如果你部署的是无状态应用挂载卷、节点亲和性、数据恢复这些问题可以先放一放。如果你部署的是数据库或消息队列存储就成为第一优先级。在应用商店里这类应用通常会自动绑定一个存储声明但你需要确认存储类是什么、容量多大、创建后的 PVC 被调度到哪台节点。很多人在这一步偷懒只看应用能安装就点下去。等重启节点或 Pod 迁移后才发现数据丢了或者磁盘满了这个时候再来补存储策略代价比一开始确认要高很多。4.2 默认密码、版本和资源三个最容易漏的参数第一个容易漏的是默认账号密码。数据库、CMS、低代码平台通常在部署时会生成初始化密码或 token有的应用会直接显示在部署结果页有的需要到 Secret 里查看。建议拿到后第一时间保存到安全位置因为很多平台只展示一次。第二个是版本。应用商店一般提供多个版本可供选择。不要一味选最新版尤其在生产环境。新版本可能依赖更新的镜像仓库、新的数据格式或更高的系统资源。更稳妥的做法是选择你之前用过或社区建议的稳定版本。第三个是资源限制。部署时很多应用默认不设资源上限或者设置得比较保守。不设上限一个内存泄漏的应用可能把节点吃满设得太小应用可能频繁被系统杀掉。标准做法是先给一个合理值观察一段时间日志和监控再调整。4.3 访问路径没配置好应用跑起来也白搭应用部署成功但访问不了是应用商店使用中出现频率很高的情况。原因通常不是应用坏了而是访问路径没有配置完整。比如 Service 端口没有暴露Ingress 规则没有指向正确的服务域名没有解析或者防火墙没有放行端口。在不同环境里这个问题的表现也不同。公有云版本一般自带网关和域名相对省心自建版本需要你自行处理域名、端口和证书。我的建议是在点部署之前先确认当前环境是否有可直接使用的访问域名如果没有先准备好 IP 和端口然后再去选应用。4.4 不要低估日志和监控的作用应用商店解决了部署入口但没有解决运维观察。部署完应用后你应该至少知道两个信息应用日志在哪里看资源占用去哪里看。Dashboard 的日志入口可以满足大部分需求如果长期使用建议进一步接监控面板观察 Pod 的内存和 CPU 趋势。这样应用突然变慢时你能判断是资源不足、数据量增大还是应用本身有问题。5. 部署后的存储、备份、升级和卸载要注意什么5.1 存储不能只靠“默认”应用商店里有状态应用在部署时通常会创建 PVC但不同存储类保证的数据可靠性不一样。有些环境使用本地磁盘有些使用网络存储。网络存储通常支持多节点挂载和迁移本地存储则要关注节点绑定关系。你需要知道自己所在集群用的是哪一类。如果某些目录没有挂到持久化卷应用重启后数据会丢失。比如数据库的数据目录如果没有挂载独立存储容器重建后数据就没了。部署完成后可以通过控制台或 kubectl 查看 PVC 状态和存储容量确认没有 Pending 或容量为 0。5.2 备份的正确姿势先看数据类型再选备份方式备份不是等到出问题才做。数据库类应用可以用数据库自带工具定期导出无状态应用更简单只要保存好配置和镜像版本随时可以重新部署。如果集群支持 PVC 快照也可以做定期快照。备份节奏取决于应用的业务等级。开发环境可以每天备份生产环境建议至少做到每天备份并保留多份。很多人在部署完当天很开心一个月后不小心删了数据库才发现备份策略没有建立。这个坑完全可以在第一次部署时提前规避。5.3 升级前先看变更说明不要直接点最新版应用商店给升级提供了入口但升级不一定都是安全的。小版本升级通常风险较低大版本升级比如 MySQL 5.7 升到 8.0往往涉及数据迁移和配置变化。点击升级前先看一下应用详情里的版本变更说明再确认当前实例是否做过备份。如果只是学习环境可以随时升级试错。如果是生产环境我更建议先把升级验证放到测试集群里确认兼容性后再操作。不要因为页面显示“有可用更新”就立刻更新。这个提示通常意味着有新版本不一定代表当前版本已经不安全。5.4 卸载应用不等于清理数据在应用商店里点卸载或删除通常会把 Deployment、Service 等资源一并删除但 PVC 不一定会被自动删除。原因很好理解平台担心误删用户数据。所以如果你确认一个应用不再需要除了删除应用还要检查是否有残留的 PVC、ConfigMap、Secret再决定是否清理。反过来如果你只是临时停用不是彻底删除就不要清理 PVC否则下一次部署时数据已经没了。很多人以为“卸载”就是“清理干净”实际上需要你手动确认存储资源是否释放。这个步骤容易被忽略但直接影响数据安全和资源占用。6. 部署失败或访问不了按这个顺序排查6.1 先看状态再查日志不要盲改配置遇到部署失败第一步不是去改配置或者重新部署而是先看当前 Pod 的状态。能用一句话描述的现象往往能快速缩小排查范围Pending资源不足、存储类不存在、节点无法调度。ContainerCreating镜像拉取中、存储卷挂载失败、权限问题。CrashLoopBackOff容器启动后立即崩溃进程反复拉起。ImagePullBackOff镜像拉取失败多数是仓库地址、凭证或网络问题。Running 但访问不了服务端口、Ingress、域名、防火墙或应用自身配置问题。把现象记下来再去对应日志和事件效率会高很多。6.2 查看 Pod 事件和日志的命令如果你会使用 kubectl这是最直接的排查路径# 查看命名空间下的 Pod 状态 kubectl get pods -n namespace # 查看某个 Pod 的详细事件 kubectl describe pod pod-name -n namespace # 查看某个 Pod 的实时日志 kubectl logs pod-name -n namespace # 查看上一次崩溃的日志 kubectl logs pod-name -n namespace --previous如果你不会命令行在 Dashboard 里一般也能找到事件和日志入口。重点看三处当前 Pod 状态、最近的事件、容器启动日志。大部分问题在这三处都有明确提示。6.3 按问题类型逐个排查镜像拉取失败先确认网络能否访问镜像仓库再看镜像名称和 tag 是否正确最后看是否配置了私有仓库凭证。如果换一个镜像源能解决那问题大概率不是应用商店而是仓库网络访问能力。存储卷挂载失败查看 PVC 的状态如果一直是 Pending多半是存储类没有匹配或磁盘资源不足。如果创建成功但挂载失败需要检查节点目录权限、格式和磁盘空间。不要在这里反复重建应用。访问不了先确认应用端口是否已经暴露成 Service再确认实际端口号然后检查 Ingress 或外部网关是否指向正确服务。如果浏览器里能看到 404、502、504说明请求已经到达某个入口问题往往在路由或后端服务健康状态上而不是端口没开。应用反复重启查看日志里是否有数据库连接失败、配置项缺失、文件权限不足、依赖模块不存在等错误。这类问题通常和应用模板的默认参数有关而不是集群故障。6.4 如果实在排查不清用“最小复现”的方式逐步验证不要同时部署多个应用来测试。我一般会这样验证只留一个最简单的无状态应用排除其他因素看它能不能正常启动。如果最简单的应用也不行说明集群环境或平台本身有问题如果最简单应用可以再逐步加数据库、加存储、加资源配额。这样能把问题定位到具体环节而不是在一个被多种变量污染的集群里猜原因。7. 给第一次试用的几个建议7.1 把“能跑”和“能生产使用”分开应用商店降低了部署门槛但这不代表它消除了所有运维问题。作为第一轮的验证目标可以把“能跑”定义为一个简单应用能够在默认配置下顺利完成部署、访问、删除这一整套流程。只要这个目标达成应用商店本身的可操作性就算掌握了。需要生产使用的时候就要再加上存储可靠性、备份策略、资源监控、版本升级和故障恢复这些条件。很多人在试用阶段就把生产资源堆进去出了问题反而分不清是功能问题还是配置问题。7.2 先掌握核心概念再深入细节如果你不是专门做 Kubernetes 运维也可以先记住几个核心概念Pod应用的运行单元Deployment管理应用副本Service提供稳定访问入口PVC持久化存储声明。这四个概念在应用商店的界面里经常出现。理解它们很多报错和配置项就不会显得陌生。7.3 从应用商店开始但不要停留在这里应用商店是快速部署的入口但它不会帮你判断某个应用适不适合业务。真正落地的时候你还是要理解应用本身的配置数据库的账号体系、中间件的连接池、Web 服务的安全配置。把应用商店当作起点而不是终局这是少走弯路的关键。7.4 我个人的推荐顺序我更建议先把单应用跑稳再考虑多应用联动。比如先部署一个博客系统确认存储、访问、日志都清楚然后再给它接一个数据库或对象存储观察两个应用之间的网络依赖最后再考虑多副本和升级。这个顺序看起来慢但能让你在问题出现时明确知道是哪一部分出了错。踩过几次之后你会发现应用商店里最容易出问题的点往往不是“点不下去”而是前置环境和应用参数没有处理干净。