之前帮团队搭建内部开发环境时最头疼的其实不是容器本身而是 Kubernetes 这套“操作系统”的安装、网络、存储、证书、插件配置。每次拉起来一套可用集群都要翻好几篇文档踩不少版本坑。后来接触到 Sealos发现它把“云原生操作系统”的思路做得挺彻底尤其是内置的应用商店让团队从“用 YAML 手搓应用”变成了“在商店里点几下完成部署”。这篇文章就来系统梳理 Sealos 应用商店的使用方法、设计思路和落地经验。1. 背景与核心概念1.1 什么是 SealosSealos 是一个以 Kubernetes 为核心的云操作系统。它通过一条命令就能完成 Kubernetes 集群的部署、升级和清理同时把常见的云原生能力例如数据库、对象存储、应用管理、开发工具以“软件包”的方式集成到系统里。你可以把 Sealos 理解成“云时代的操作系统内核 应用生态”传统操作系统的内核负责管理硬件资源Sealos 的内核形态是 Kubernetes负责管理服务器资源。传统操作系统的应用商店提供软件安装入口Sealos 的应用商店提供云原生应用的一键部署入口。传统操作系统有网络配置、用户权限、防火墙Sealos 也有对应的网络策略、RBAC 权限、安全隔离机制。这种设计最大的价值在于开发人员不再需要关心底层的容器编排细节而是像使用一台“超大电脑”一样使用整个集群。1.2 Sealos 应用商店是什么Sealos 应用商店是 Sealos 控制台内置的“云端应用市场”。它汇集了各类开源软件、开发工具、中间件和业务系统模板用户可以在图形化界面中浏览、配置、部署和运维这些应用。常见的应用类型包括数据库类MySQL、PostgreSQL、MongoDB、Redis 等中间件类Nginx、Kafka、MinIO、RabbitMQ 等开发工具类Jenkins、GitLab、Gitea、VS Code Server 等业务应用类WordPress、Wekan、Nextcloud 等AI 与大数据类Jupyter Notebook、TensorFlow 相关镜像等与直接在服务器上执行apt install或docker run相比应用商店更强调“云原生交付”每一个应用背后都是一套完整的 Kubernetes 资源定义包括工作负载、服务暴露方式、存储卷、环境变量、健康检查、自动扩缩容配置等。1.3 应用商店解决的核心痛点在没有应用商店之前团队部署一套中间件通常要经历这些步骤准备镜像。编写 Deployment、Service、ConfigMap、Ingress 等 YAML。考虑存储卷和持久化方案。配置健康检查、资源限制、环境变量。执行 kubectl apply。持续关注 Pod 状态、日志、事件。这套流程对于熟练的运维工程师来说问题不大但对业务开发人员、测试人员、刚接触云原生的新手来说门槛偏高。应用商店把上述工作封装成了一个“模板化”的产品体验使用者只需要关心应用配置项不需要关心底层对象细节。用白话来说应用商店是 Sealos 提供的最小化应用部署路径是“Kubernetes YAML 工程化封装”的产物。2. Sealos 应用商店整体架构与设计思路2.1 从“安装软件”到“部署应用”在传统 Linux 系统中安装软件发生在操作系统之上软件与操作系统共享内核、文件系统和用户体系。在 Sealos 中应用商店安装的是一个“云原生应用”它由一组 Kubernetes 资源组合而成--------------------------- | Sealos 应用商店控制台 | --------------------------- | 应用模板仓库 | | 镜像仓库 | | 配置参数 | --------------------------- | Kubernetes API Server | --------------------------- | Deployment / StatefulSet | | Service / Ingress | | PVC / ConfigMap / Secret | ---------------------------用户在应用商店点击部署时Sealos 会执行以下操作从模板仓库加载应用定义。将用户填写的配置参数注入模板。通过 Kubernetes API 创建或更新资源。等待应用可用并在控制台展示状态信息。用户通过暴露的访问地址使用应用。2.2 应用商店与 Docker 之间的对比这里容易产生一个认知混淆Sealos 应用商店里能装“容器应用”但它并不是简单执行docker run。对比项Docker 单机安装Sealos 应用商店部署运行环境单台服务器Kubernetes 集群副本数量通常 1 个容器可指定多个副本服务发现端口映射Service DNS流量入口宿主机端口Ingress / LoadBalancer持久化本地目录或 VolumePVC / 分布式存储故障恢复通常需要手动处理控制器自动重建 Pod配置管理环境变量ConfigMap / Secret / UI 表单所以应用商店更准确的定位是云原生应用编排的一站式入口。2.3 设计中的关键原则从使用体验倒推Sealos 应用商店在设计上有几个值得学习的原则最小化配置用户只需要关心端口、密码、副本数、存储大小等关键参数其他默认值已由模板维护。模板化交付不同应用共享同一套部署流程便于自动化扩展新应用。面向资源而非面向镜像商店里的应用部署结果是 Pod、Service、PVC 等 Kubernetes 资源而不是一个孤立的容器。控制台与 CLI 结合普通操作可以在网页完成高级排错依然可以通过 kubectl 或 sealos CLI 完成。3. 环境准备与部署前规划3.1 硬件与系统要求Sealos 本身运行在 Linux 服务器上客户端支持 Linux、macOS 和 WindowsWSL 环境更佳。在开始使用应用商店之前至少需要准备一套可用的 Sealos Kubernetes 集群。服务器建议CPU2 核以上单节点演示至少 2 核内存4 GB 以上生产环境按应用规模调整磁盘建议 SSD空间 20 GB 以上操作系统建议 Ubuntu 22.04 LTS、Debian 12、CentOS Stream 9 等主流发行版注意不同 Sealos 版本对 Kubernetes 版本的要求不同。请以你实际安装的 Sealos 版本为准不要照搬网上旧命令而不加验证。3.2 安装 Sealos CLI以下安装步骤以 Linux 环境为例使用官方安装脚本curl -fsSL https://mirrors.sealos.cn/install.sh | sh安装完成后验证命令是否可用sealos version如果网络受限可以从 GitHub Releases 页面下载对应架构的二进制包手动放入/usr/local/bin或自定义 Bin 目录并赋予执行权限chmod x sealos mv sealos /usr/local/bin/3.3 创建 Kubernetes 集群使用 Sealos 创建集群最直观的方式是执行sealos run。在多节点环境中需要准备一个集群配置文件Clusterfile。最小化单节点集群配置示例apiVersion: apps.sealos.io/v1beta1 kind: Cluster metadata: name: my-cluster spec: image: docker.io/labring/kubernetes:v1.28.0 ssh: host: 192.168.1.10 user: root passwd: your-password port: 22执行创建sealos apply -f Clusterfile命令执行完成后验证集群状态kubectl get nodes kubectl get pods -A如果是在已有 Kubernetes 集群上单独接入 Sealos 控制台也可以跳过集群创建步骤直接部署控制台组件。这里以 Sealos 自带完整能力为主。4. Sealos 应用商店使用流程全拆解4.1 进入应用商店集群启动后通过 Sealos 控制台访问应用商店。浏览器打开控制台地址通常为http://your-server-ip:console-port首次登录时需要创建管理员账号或在已有认证环境下使用默认账号。登录后左侧导航栏中能够看到“应用商店”或“App Store”入口点击进入。整个界面逻辑接近我们熟悉的软件市场左侧是分类中间是应用列表右上角是搜索框。你可以直接搜索应用名称也可以按分类筛选。4.2 浏览应用模板应用列表中的每一个卡片代表一个可部署的应用模板。卡片信息通常包含应用名称和图标简短描述版本号维护者或来源标签例如数据库、开发工具、CMS点击应用卡片后会进入应用详情页页面主要包括应用介绍部署所需资源预估可配置参数表“部署”按钮这里需要注意的是不同模板的成熟度并不一致。社区维护的模板可能需要自行验证官方或认证模板相对更稳定。生产环境建议优先选择有明确维护记录和更新频率的模板。4.3 配置并部署应用下面以部署一个常见 CMS 应用为例说明流程。假设我们要在应用商店中部署 WordPress。进入 WordPress 详情页后需要填写或调整以下配置应用名称用于区分同一应用的多个实例。命名空间默认会在当前项目或指定 Namespace 下创建资源。WordPress 端口如果模板暴露 HTTP 服务指定期望的访问端口。数据库密码WordPress 通常需要连接 MySQL部分模板会把数据库一并部署。存储大小数据持久化需要的磁盘容量。副本数生产环境建议 2 个及以上演示环境 1 个即可。填写完成后点击“部署”按钮。此时 Sealos 后台会创建一系列 Kubernetes 资源。等待进度条走完页面会展示应用状态、访问链接和基础运维入口。这一过程等价于执行了多份 YAML 的kubectl apply但全部交互发生在图形界面中日志和事件也会汇总展示。4.4 查看应用运行状态部署完成后可以关注以下维度的状态应用是否处于 Running 状态。相关 Pod 是否全部 Ready。服务是否已经暴露到预期端口。PVC 是否绑定成功。访问链接是否能够正常打开。如果应用启动失败最直接的方式是查看 Pod 日志kubectl get pods -n namespace kubectl logs -f pod-name -n namespaceSealos 控制台也提供了日志查看功能方便不熟悉命令行的用户排查问题。4.5 升级、回滚与卸载应用商店中部署的应用支持后续的版本升级和配置变更。升级时通常需要确认以下事项新版本是否有数据迁移脚本。镜像地址是否变化。是否涉及不兼容的配置项。升级前建议先备份 PVC 中的数据或使用数据库自带的备份工具导出数据。如果升级失败可以通过上一版本镜像重新部署并恢复数据。卸载操作需要在应用详情页执行。值得注意的是卸载应用通常会删除对应的 Deployment、Service、ConfigMap但 PVC 是否被删除取决于实现。如果数据重要建议在卸载前确认 PVC 保留策略或者手动备份到对象存储。5. 应用商店核心原理与常用操作5.1 应用模板的构成一个应用模板背后本质上是封装好的 Kubernetes 资源集合。以一个典型 Web 应用为例它可能需要创建Deployment管理应用容器副本。Service提供集群内稳定的访问入口。Ingress将外部流量路由到 Service。ConfigMap保存非敏感配置文件。Secret保存数据库密码等敏感信息。PVC持久化存储。这些资源打包在一起配合参数化变量就成了“应用模板”。5.2 使用命令行查看应用资源对于习惯了命令行操作的开发者建议在部署后使用 kubectl 检查实际生成的资源。例如kubectl get deploy,svc,pvc,ingress -n namespace这样可以清楚地看到应用商店到底创建了哪些对象也能帮助你理解“模板封装”到底封装了什么。5.3 修改已部署应用的配置部分配置可以再次编辑例如修改副本数或环境变量。修改副本数的方式kubectl scale deployment deployment-name --replicas3 -n namespace修改环境变量时建议通过控制台应用编辑功能完成这样模板会重新渲染对应资源避免手工改 YAML 导致模板配置与控制台状态不一致。5.4 在 Kubernetes 资源层面排查问题如果应用部署后无法访问优先按以下链路排查Pod 是否 Running检查镜像、资源配额、调度情况。Service 是否正确选择 Pod检查 selector 标签是否匹配。Ingress 是否指向正确 Service检查域名和路径配置。安全组或防火墙是否放通端口云服务器需额外确认安全组规则。这条链路和通用 Kubernetes 排错思路一致。应用商店只是帮你快速生成资源运行时的排错仍然需要掌握基础 K8s 知识。6. 应用商店适用的典型场景下面列举几类比较常见的应用场景方便你判断“要不要用应用商店”。6.1 开发环境快速搭建开发团队准备接入 Redis、MySQL、MinIO 时不需要找运维要 YAML直接在应用商店部署一套实例即可。开发环境对高可用要求不高配置参数可以保持默认重点是快速获得可用服务。6.2 测试环境仿真测试环境往往需要多套隔离的中间件。通过应用商店可以创建一个独立的 Namespace 并在其中部署全套依赖用完直接卸载不会污染其他环境。6.3 私有化交付面向客户交付时应用商店能够显著降低部署成本。交付人员只需要在客户环境中安装 Sealos然后从应用商店拉起业务组件比逐个手工发布容器快很多。6.4 学习云原生技术对于正在学习 Kubernetes 的读者应用商店是很好的观察窗口。通过部署一个复杂应用再查看它生成的 Deployment、Service、PVC 等资源可以理解一个“完整应用”到底需要哪些云原生对象。7. 常见问题与排查思路以下汇总了使用 Sealos 应用商店过程中可能遇到的高频问题供读者参考。问题现象常见原因解决思路应用一直处于 Pending资源不足或存储类不存在查看节点资源确认 StorageClassPod 频繁重启镜像启动命令或环境变量错误查看日志对比模板默认配置外部无法访问Ingress 未配置或安全组未放通检查 Ingress 事件、访问链路部署成功但页面 502后端服务启动慢或健康检查失败查看应用日志调大就绪探针时间升级后数据丢失升级流程未注意 PVC 保留策略升级前备份数据确认存储策略应用商店页面加载慢镜像仓库网络原因配置镜像加速或使用内网镜像仓库同一应用部署多套冲突未指定不同名称或端口给应用设置唯一名称和端口控制台显示异常前端与后端版本不一致统一 Sealos 组件版本更详细的排查思路如下确认集群状态是否正常kubectl get nodes。确认应用资源是否创建kubectl get all -n namespace。查看 Deployment 事件kubectl describe deployment name -n namespace。查看 Pod 日志kubectl logs pod-name -n namespace。查看 PVC 状态kubectl get pvc -n namespace。查看 Ingress 规则和事件。能够熟练执行以上步骤应用商店中的大多数部署问题都可以快速定位。8. 最佳实践与工程建议8.1 命名空间隔离不要把全部应用部署在同一个命名空间中。建议按环境或团队拆分namespace: dev-wordpress namespace: test-wordpress namespace: prod-wordpress这样既方便权限隔离也方便资源配额管理。8.2 资源配额与限制在应用商店部署应用时尽量填写合理的 CPU 和内存限制避免某个应用占满整个节点。对于生产环境还建议在命名空间级别设置 ResourceQuotaapiVersion: v1 kind: ResourceQuota metadata: name: prod-quota namespace: prod-wordpress spec: hard: requests.cpu: 8 requests.memory: 16Gi limits.cpu: 16 limits.memory: 32Gi8.3 数据安全与备份应用商店中部署的数据库类应用数据安全性要优先考虑启用 PVC 存储。定期备份数据库数据不要把备份文件放在同一份 PVC 上。设置合理的备份保留周期。生产环境的数据库账号密码通过 Secret 管理避免明文写入配置。8.4 镜像与版本管理应用模板可能默认使用外部镜像源。如果你的服务器无法直接拉取外部镜像建议搭建内网镜像仓库或使用 mirrors 加速。将常用镜像提前同步到内网仓库。在模板中统一替换镜像地址。8.5 权限与审计如果 Sealos 控制台被团队成员共用建议为不同成员设置不同权限普通开发人员只能部署和查看自己的命名空间。运维人员可以管理集群资源和全局配置。管理员拥有完整权限。同时建议开启操作审计记录谁在什么时间部署了什么应用方便问题回溯。8.6 生产环境变更规范应用商店在生产环境的任何变更都应遵循最小权限和风险控制原则变更前导出当前配置。在测试环境验证升级或配置修改流程。备份数据。选择低峰期执行变更。保留回滚方案。9. 总结与下一步学习建议这篇文章从 Sealos 应用商店的概念、架构、部署流程、核心操作、常见问题到工程实践做了完整梳理。通过应用商店个人开发者可以快速获得一套可用的云原生应用环境团队可以减少大量重复的 Kubernetes YAML 编写工作交付人员也能在客户环境中实现低成本的应用部署。需要注意的是应用商店虽然有“一键部署”的体验但底层依然是 Kubernetes。真正遇到生产环境问题时扎实的 K8s 基础仍然是排错的关键。建议读者掌握以下能力理解 Deployment、Service、Ingress、PVC、ConfigMap 的作用。熟悉 kubectl 常用命令和日志查看方式。理解应用容器化的基本原理包括镜像、端口、探针。学会数据库备份、恢复的基本方法。下一步可以尝试在 Sealos 应用商店中部署一套带数据库的完整应用例如 WordPress 或 GitLab观察它生成的资源对象然后模拟一次升级和回滚。这个练习做完你对云原生应用的部署模型会有更直观的理解。如果文章对你有帮助可以先收藏备用。也欢迎在评论区聊聊你使用 Sealos 应用商店时遇到的具体问题后续可以针对高频问题再做专题整理。