在实际 Kubernetes 项目里把一个应用真正跑起来需要处理的细节远比大多数人想象中多Deployment、Service、Ingress、StorageClass、PVC、Secret、ConfigMap 全部要写对还要考虑版本升级、故障重启、资源限制和访问入口。Sealos 应用商店正是为了降低这条链路的门槛而存在。它把 Kubernetes 上的复杂部署过程封装成可视化、可复用的应用模板让使用者通过表单就能完成原本需要编写多份 YAML 的工作。这篇文章不打算只介绍界面截图而是从“为什么需要应用商店、底层做了什么、如何自己部署一个应用、出问题时怎么排查”这条主线展开适合刚开始接触 Sealos、Kubernetes 部署经验不足、或者想在自己团队里做统一应用交付平台的开发者阅读。1. Sealos 应用商店是什么解决什么问题1.1 从 Kubernetes 手动部署的痛点说起在原生 Kubernetes 里部署一个带状态的中间件比如 MySQL通常要准备这么一批资源Deployment 或 StatefulSet描述容器镜像、启动参数、探针和副本数。Service提供稳定的集群内访问地址。Ingress 或 NodePort把服务暴露给集群外部。PVC 和 StorageClass为数据库提供持久化磁盘。Secret保存数据库密码、证书等敏感信息。ConfigMap保存非敏感配置。这些资源相互依赖任何一个字段写错都可能出现“Pod 没起来”“数据没持久化”“外网访问不通”的问题。更麻烦的是不同应用的部署形态差异很大Redis 可以是单节点也可以是集群Nginx 需要挂载配置文件GitLab 需要大量资源。如果每个应用都靠手动复制 YAML 来部署维护成本会随应用数量线性增长。Sealos 应用商店要解决的正是这个“部署标准化”的问题。它不让用户直接面对一堆 YAML而是把常见应用的部署方式整理成模板用户在界面上填写参数系统自动生成底层资源并完成部署。1.2 应用商店的核心定位应用商店可以理解成“Kubernetes 应用的上架与下发入口”。它做的事情如下把应用部署过程模板化。为模板提供表单化配置界面。部署时自动创建 Deployment、Service、PVC、Secret 等资源。部署后统一展示应用状态、访问地址和运行日志。支持应用的升级、删除和重新配置。它和 Linux 软件仓库、移动端应用商店的体验类似但底层运行在 Kubernetes 之上。使用者不需要知道某个中间件在 Kubernetes 里的完整资源定义只需要关心“我要部署什么、需要多大存储、密码是什么”。这里的“为什么”值得强调应用商店不是在 Kubernetes 之上又做了一层黑盒而是把 Kubernetes 的资源模型封装成了更适合人操作的界面。底层仍然是标准的 Deployment、Service、PVC只是由平台统一生成和管理。这也意味着你在应用商店里部署出的东西依然可以用 kubectl 查看和控制。1.3 与 Docker Hub、Helm 的关系把 Sealos 应用商店和 Docker Hub、Helm 放在一起对比能更快理解它的定位。对比维度Docker HubHelmSealos 应用商店主要面向对象镜像生产者与使用者熟悉命令行和模板语法的开发者平台使用者和应用管理者解决的核心问题镜像的存储、分发、拉取应用资源编排的版本化和复用应用部署的可视化和自动化使用方式docker pull / pushhelm install / upgrade网页表单填写并提交底层产物镜像Chart 渲染出的 Kubernetes 资源模板渲染出的 Kubernetes 资源学习门槛低中高低从技术上来说Sealos 应用商店完全可以借助 Helm Chart 作为模板来源也可以直接使用 Kubernetes 资源模板。实际项目中这三者并不是互斥关系而是一条链路镜像负责“程序是什么”Helm 或应用商店模板负责“程序怎么部署”Sealos 应用商店负责把“怎么部署”的复杂度对用户隐藏起来。2. 核心概念先弄懂模板、应用实例、持久化和访问入口2.1 模板与模板版本模板是应用商店的核心资产。一个模板描述了一个应用应该如何被部署包括需要哪些容器镜像。需要创建哪些 Kubernetes 资源。需要暴露哪些可配置参数。每个参数的默认值和校验规则。模板像软件一样有版本。发布新版本可以升级镜像、调整参数、修复配置问题。使用者在部署应用时可以选择模板版本。这里容易产生误解模板版本不等于应用镜像版本。模板版本决定“部署编排方式”镜像版本决定“实际运行的程序版本”两者可以独立升级。2.2 应用实例与部署生命周期当用户填写完表单并点击部署系统会基于模板生成一份部署参数并在指定命名空间下创建一批 Kubernetes 资源。这一整套运行中的资源被称为“应用实例”。应用实例的生命周期一般包括部署中资源正在创建Pod 尚未全部就绪。运行中Pod 处于 Running 或 Ready 状态服务可访问。升级中正在替换镜像或调整配置。异常部分 Pod 处于 CrashLoopBackOff、ImagePullBackOff 等状态。已删除实例被销毁但数据卷可能保留。理解生命周期很重要因为在 Kubernetes 中Pod 的重启和替换是正常现象。只要最终状态满足实例定义应用就处于健康状态。2.3 持久化与存储卷状态型应用比如数据库、消息队列、对象存储必须依赖持久化存储。应用商店模板通常会为这类应用声明 PVC。PVC 依赖 StorageClass。不同云厂商、不同 Kubernetes 环境的 StorageClass 名称和能力不一样。如果集群里没有可用的 StorageClass或者模板指定的存储类型与实际环境不匹配应用就会一直处于 Pending 状态这是新手最容易踩的坑之一。在部署表单里用户通常只需要填“存储容量”和“存储类型”。底层创建的是 PVC实际挂载到哪个存储后端由 StorageClass 决定。2.4 访问入口与域名应用部署完成后需要让用户访问。常见的入口方式有三种ClusterIP只能在集群内部访问适合后端服务。NodePort通过节点 IP 端口访问适合测试环境。Ingress通过域名 路径访问适合生产环境。Sealos 应用商店在部署表单里通常会提供“是否开放公网访问”的选项。选择开放后平台会创建 Ingress 规则并分配一个可访问的域名或路径。生产环境中还要考虑 TLS 证书、HTTPS 跳转和跨域配置这些能力一般由平台本身的网关层统一处理。3. 准备环境学习环境和自建集群分别怎么搭3.1 快速体验先在低风险环境里跑通流程如果是第一次接触 Sealos不要直接在生产集群上操作。推荐先用以下几种方式之一体验官方提供的在线体验环境。本地虚拟机安装一个 Linux 系统资源不少于 4 核 8GB。一台临时云服务器用完即删。学习环境的目标只有一个尽快跑通“登录控制台 - 打开应用商店 - 部署一个应用 - 验证访问”这条流程。环境越简单越好不要一开始就追求高可用和复杂网络配置。3.2 自建集群使用 sealos 命令行完成初始化Sealos 本身提供了一键安装 Kubernetes 集群的能力。整体思路是先准备若干台 Linux 服务器再在首台机器上用 sealos 命令完成集群初始化。前置检查项服务器之间网络互通。SSH 免密登录正常。系统时间同步建议配置 NTP。内核和系统版本满足 Kubernetes 要求。磁盘有足够空间尤其是 etcd 所在节点。下面是最小示例。实际 IP、版本号和 sealos 二进制下载地址请以官方 Release 页面为准。# 下载 sealos 二进制这里以 amd64 平台为例 wget https://github.com/labring/sealos/releases/latest/download/sealos_amd64.tar.gz tar zxvf sealos_amd64.tar.gz chmod x sealos sudo mv sealos /usr/local/bin/ # 查看版本确认安装成功 sealos version集群初始化命令示例如下# 示例一个 master 加一个 node sealos run labring/kubernetes:v1.25.0 \ --masters 192.168.1.10 \ --nodes 192.168.1.11需要注意不同版本的 sealos 命令参数有差异。有的版本使用-m和-n简写有的版本要求先安装运行时再安装 Kubernetes。落地上手前先阅读目标版本对应的文档避免因为命令格式不一致导致初始化失败。集群就绪后再安装 Sealos Cloud 相关模块。这里的模块名、依赖组件和支持的 Kubernetes 版本会随版本更新而变化不要直接照搬旧命令。原则是先确认当前版本对应的安装命令再一次性把所需模块装齐。3.3 登录控制台并完成初始配置平台模块装好后会暴露一个控制台访问地址。首次登录时通常需要设置管理员账号和密码。确认集群可用资源。检查是否存在可用的 StorageClass。检查域名解析和网关是否正常。登录成功后进入主界面找到“应用商店”或“应用市场”入口。到这里环境准备完成可以进入实际部署环节。4. 从应用商店部署第一个应用4.1 案例选择用 MySQL 讲清楚完整流程数据库是最适合作为应用商店示例的应用类型它包含状态存储、密码配置、资源配额、持久化卷、外部访问几乎覆盖了应用商店的所有核心能力。下面以在测试环境部署一个 MySQL 实例为例说明完整操作流程。实际界面上的字段名称以版本为准但逻辑一致。4.2 浏览应用商店并打开应用详情进入应用商店后可以看到应用列表通常包含应用图标和名称。简短功能说明。支持的模板版本。资源要求或适用场景标签。使用搜索框输入 MySQL进入应用详情页。详情页会展示应用介绍。模板版本列表。部署必填参数。默认端口和访问方式。可能的注意事项。这一步的检查点确认当前环境支持的模板版本避免选择与 Kubernetes 版本不兼容的旧模板。4.3 填写部署表单点击“部署”或“安装”后进入表单填写页面。典型字段如下字段示例值说明应用名称mysql-test应用实例名称也用于标识资源命名空间test部署到哪个命名空间不存在时自动创建数据库用户名root初始化账号数据库密码自定义强密码会写入 Secret不要明文写在配置文件里数据库名称mydb初始创建的数据库镜像版本8.0指定 MySQL 镜像版本存储容量20GiPVC 请求的存储大小CPU 限制1000m容器最多可使用的 CPU 配额内存限制2Gi容器最多可使用的内存配额是否开放外网访问是/否决定是否创建 Ingress 规则填写完成后提交。如果某些字段校验失败表单会给出提示比如密码太短、存储容量非法等。4.4 提交后观察部署过程提交后应用列表会出现新实例状态可能是“部署中”。此时平台正在做的工作包括在目标命名空间创建 Secret保存数据库密码。创建 PVC申请持久化存储。创建 StatefulSet 或 Deployment调度 Pod。创建 Service提供内部访问地址。如果开启外网访问创建 Ingress 规则。部署过程快则几十秒慢则几分钟取决于镜像拉取速度、存储卷创建速度和节点资源情况。观察点有两个一是实例状态是否从“部署中”变为“运行中”二是如果很久未就绪要立刻查看事件和日志而不是继续等待。4.5 验证应用可用性部署成功后需要做可用性验证而不是只看状态变绿。验证步骤包括# 查看 Pod 状态 kubectl get pods -n test -l appmysql-test # 查看 Service 地址 kubectl get svc -n test # 查看 PVC 是否 Bound kubectl get pvc -n test # 查看 Ingress kubectl get ingress -n test如果开放了 NodePort可以直接用节点 IP 加端口连接mysql -h 192.168.1.10 -P nodePort -u root -p在应用商店界面里通常也能直接看到访问地址或连接信息。推荐至少做一次真实业务连接测试比如创建一张表并写入数据再查询一次确认数据库服务完整可用。5. 部署参数背后的原理为什么这些配置会影响应用行为5.1 命名空间是隔离边界命名空间决定了应用运行在哪个资源隔离范围内。测试环境和生产环境建议使用不同命名空间避免资源冲突和误操作。命名空间还影响 DNS 名称服务之间通过服务名.命名空间.svc.cluster.local互访。5.2 镜像版本要显式指定表单里的镜像版本最终会体现在 Deployment 的 image 字段上。显式指定版本很重要因为latest标签会导致每次重建时拉取到不可预测的镜像生产中几乎不应该使用。更好的做法是记录实际部署的版本号方便回滚和审计。5.3 CPU 和内存限制不是越大越好资源配额用于限制容器能使用的资源。设置过小会导致 OOMKilled设置过大则会浪费集群资源并影响调度。推荐先从合理默认值开始再根据监控数据调整。对于数据库类应用内存限制通常要考虑连接数、缓存池大小等因素。5.4 存储容量与动态扩容策略存储容量决定 PVC 申请的空间。云原生环境中多数 StorageClass 支持动态扩容但扩容方向一般是单向的缩小容量通常不被允许。因此容量设置要比当前需求略大同时保留监控和告警能力。5.5 密码和敏感信息进入 Secret 而不是明文表单中填写的密码在部署时应该写入 Secret由 Pod 通过环境变量或配置文件读取。不要把这些信息写死在镜像或 Deployment 的明文环境变量中否则任何能看到 YAML 的人都能拿到凭据。这也是应用商店模板设计中的一个常见安全要求。6. 部署完成后的日常运维日志、升级、删除与数据保护6.1 查看运行状态和日志应用运行过程中需要经常查看状态和日志。常用命令如下# 查看命名空间下所有资源 kubectl get all -n test # 查看 Pod 详细信息 kubectl describe pod pod-name -n test # 查看最近 200 行日志 kubectl logs pod-name -n test --tail200 # 动态跟随日志输出 kubectl logs -f pod-name -n test日志中的 Warning 和 Error 不一定要立刻处理但要能判断优先级。比如磁盘空间告警、连接数超限、主从同步中断都是需要及时响应的信号。6.2 升级应用时的注意事项应用商店提供升级能力。升级模板版本或镜像版本前建议确认新版本是否兼容现有数据。是否需要备份后再升级。是否有停机时间要求。是否已记录当前版本便于回滚。对于数据库类应用升级前必须做数据备份并且建议先在测试环境验证升级流程。不要直接在唯一的生产实例上执行升级实验。6.3 删除实例不等于删除数据删除应用实例时平台通常只删除工作负载和 ServicePVC 可能被保留。这是为了防止误删数据。理解这个行为很重要如果只是想临时停服可以缩容副本或暂停应用而不是删除实例。如果确定不再需要数据需要手动清理 PVC。删除实例前先确认为什么删、数据是否需要保留、是否有其他服务依赖它。6.4 应用商店运维的最小命令集即使应用商店提供了图形界面运维人员也应该掌握基础 kubectl 命令因为很多问题只有通过命令行才能定位。把下面这些命令作为日常检查基础kubectl get nodes kubectl get ns kubectl get pods -A kubectl get events -n test --sort-by.lastTimestamp kubectl get pvc -A kubectl get storageclass7. 常见问题排查从现象到根因7.1 应用一直处于 Pending现象部署提交后实例长时间处于部署中Pod 没有变成 Running。排查顺序kubectl get pods -n test kubectl describe pod pod-name -n test可能原因和对应处理可能原因检查方式处理建议节点 CPU 或内存不足kubectl describe node查看 Allocated 和 Available增加资源或减少应用副本数StorageClass 不存在或不可用kubectl get storageclass创建对应 StorageClass或修改模板存储类型PVC 一直 Pendingkubectl get pvc -n test、kubectl describe pvc检查存储后端配置和配额镜像拉取失败kubectl describe pod查看 ImagePullBackOff 事件检查镜像名、版本和仓库权限7.2 Pod 反复重启状态为 CrashLoopBackOff现象Pod 能启动但持续退出重启。排查入口是日志kubectl logs pod-name -n test --tail200 kubectl logs --previoustrue pod-name -n test --tail200常见原因数据库密码或环境变量配置错误。初始化脚本执行失败。依赖的另一个服务未就绪。存储卷权限或挂载路径不正确。镜像入口命令与模板参数不匹配。7.3 外网访问不通现象应用状态正常但从浏览器或客户端无法访问。检查顺序kubectl get ingress -n test kubectl get svc -n test kubectl get endpoints -n test可能原因没有开启外网访问Service 是 ClusterIP。Ingress 控制器未安装或未运行。域名解析未生效或访问路径配错。云厂商安全组没有放行对应端口。服务端口与容器端口不匹配。7.4 数据在 Pod 重建后丢失现象Pod 重启或删除后数据库中的数据消失。检查kubectl get pvc -n test kubectl get pv如果 PVC 不存在或者 PVC 的 reclaimPolicy 是 Delete数据就可能丢失。这是最需要预防的问题。解决方案是部署前确认使用了持久化存储并且定期备份数据。生产环境还应该为关键数据配置跨节点或跨地域备份。8. 最佳实践与扩展方向8.1 环境检查清单部署任何应用前建议用这份清单做一次环境检查[ ] Kubernetes 集群版本与 Sealos 版本是否兼容。[ ] 是否有可用 StorageClass默认存储类型是什么。[ ] 节点资源是否满足应用最低要求。[ ] Ingress 控制器是否安装并运行。[ ] 域名解析是否指向正确地址。[ ] 镜像仓库是否可达拉取是否有限制。[ ] 是否已设置命名空间级别的资源配额。[ ] 密码等敏感信息是否计划写入 Secret。[ ] 是否明确数据备份和回滚方案。8.2 学习环境与生产环境的差异学习环境的核心目标是跑通流程可以适当简化比如使用默认存储、不配置域名。生产环境则要补齐以下内容配置外置化不要在模板里写死环境相关参数。日志和监控接入 Prometheus、告警和集中日志平台。权限控制限制谁能部署、谁能删除、谁能访问生产命名空间。备份与恢复至少覆盖数据备份、配置备份和恢复演练。回滚方案记录版本号支持一键回退到上一个可用版本。资源限制为每个应用设置 CPU、内存、存储配额防止互相影响。8.3 扩展方向从使用者变成发布者用好应用商店之后可以往三个方向深入第一研究模板结构。搞清楚一个应用模板由哪些文件组成参数如何在模板中生效这样遇到不符合需求的应用时可以自己修改和调试。第二发布自己的应用。团队内部的工具、中间件和业务服务可以制作成应用商店模板统一团队部署方式。这比每个人都复制一份 YAML 要可靠得多。第三与 CI/CD 集成。镜像构建完成后自动发布到内部仓库再触发应用商店中的模板升级把“构建、发布、部署”串成一条自动化链路。8.4 对新手最实用的练习建议如果只想做一件事来加深理解建议部署同一个应用两次第一次完全用应用商店界面操作第二次在命令行里观察部署前后 Kubernetes 资源的变化。重点看 Secret、PVC、StatefulSet、Service、Ingress 各自被创建成了什么参数和资源字段是如何对应的。这样的对照练习既能掌握应用商店的使用方式也能补上 Kubernetes 资源模型的基础后续无论用哪种工具部署应用都会有更清晰的判断力。Sealos 应用商店本质上是一个把 Kubernetes 操作复杂度收进来的入口。理解它最好的方式不是只看介绍而是亲手部署一个带存储、带密码、带访问入口的应用然后从命令行一侧观察它生成的资源。把“界面操作”和“底层资源”对应起来应用商店就不再是一个黑盒而是 Kubernetes 学习与生产交付之间的一座桥。
架构全景、安全固件工程审计与平台移植落地指南)
