企业官网建设流程全解析

之前帮团队搭建内部开发环境时，最头疼的其实不是容器本身，而是 Kubernetes 这套“操作系统”的安装、网络、存储、证书、插件配置。每次拉起来一套可用集群，都要翻好几篇文档，踩不少版本坑。后来接触到 Sealos，发现它把“云原生操作系统”的思路做得挺彻底，尤其是内置的应用商店，让团队从“用 YAML 手搓应用”变成了“在商店里点几下完成部署”。这篇文章就来系统梳理 Sealos 应用商店的使用方法、设计思路和落地经验。

1. 背景与核心概念

1.1 什么是 Sealos

Sealos 是一个以 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 应用商店解决的核心痛点

在没有应用商店之前，团队部署一套中间件通常要经历这些步骤：

1. 准备镜像。
2. 编写 Deployment、Service、ConfigMap、Ingress 等 YAML。
3. 考虑存储卷和持久化方案。
4. 配置健康检查、资源限制、环境变量。
5. 执行 kubectl apply。
6. 持续关注 Pod 状态、日志、事件。

这套流程对于熟练的运维工程师来说问题不大，但对业务开发人员、测试人员、刚接触云原生的新手来说，门槛偏高。应用商店把上述工作封装成了一个“模板化”的产品体验，使用者只需要关心应用配置项，不需要关心底层对象细节。

用白话来说：应用商店是 Sealos 提供的最小化应用部署路径，是“Kubernetes YAML 工程化封装”的产物。

2. Sealos 应用商店整体架构与设计思路

2.1 从“安装软件”到“部署应用”

在传统 Linux 系统中，安装软件发生在操作系统之上，软件与操作系统共享内核、文件系统和用户体系。在 Sealos 中，应用商店安装的是一个“云原生应用”，它由一组 Kubernetes 资源组合而成：

+---------------------------+ | Sealos 应用商店控制台 | +---------------------------+ | 应用模板仓库 | | 镜像仓库 | | 配置参数 | +---------------------------+ | Kubernetes API Server | +---------------------------+ | Deployment / StatefulSet | | Service / Ingress | | PVC / ConfigMap / Secret | +---------------------------+

用户在应用商店点击部署时，Sealos 会执行以下操作：

1. 从模板仓库加载应用定义。
2. 将用户填写的配置参数注入模板。
3. 通过 Kubernetes API 创建或更新资源。
4. 等待应用可用，并在控制台展示状态信息。
5. 用户通过暴露的访问地址使用应用。

2.2 应用商店与 Docker 之间的对比

这里容易产生一个认知混淆：Sealos 应用商店里能装“容器应用”，但它并不是简单执行docker run。

所以，应用商店更准确的定位是云原生应用编排的一站式入口。

2.3 设计中的关键原则

从使用体验倒推，Sealos 应用商店在设计上有几个值得学习的原则：

• 最小化配置：用户只需要关心端口、密码、副本数、存储大小等关键参数，其他默认值已由模板维护。
• 模板化交付：不同应用共享同一套部署流程，便于自动化扩展新应用。
• 面向资源而非面向镜像：商店里的应用，部署结果是 Pod、Service、PVC 等 Kubernetes 资源，而不是一个孤立的容器。
• 控制台与 CLI 结合：普通操作可以在网页完成，高级排错依然可以通过 kubectl 或 sealos CLI 完成。

3. 环境准备与部署前规划

3.1 硬件与系统要求

Sealos 本身运行在 Linux 服务器上，客户端支持 Linux、macOS 和 Windows（WSL 环境更佳）。在开始使用应用商店之前，至少需要准备一套可用的 Sealos Kubernetes 集群。

服务器建议：

• CPU：2 核以上（单节点演示至少 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 <namespace>

Sealos 控制台也提供了日志查看功能，方便不熟悉命令行的用户排查问题。

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> --replicas=3 -n <namespace>

修改环境变量时，建议通过控制台应用编辑功能完成，这样模板会重新渲染对应资源，避免手工改 YAML 导致模板配置与控制台状态不一致。

5.4 在 Kubernetes 资源层面排查问题

如果应用部署后无法访问，优先按以下链路排查：

1. Pod 是否 Running：检查镜像、资源配额、调度情况。
2. Service 是否正确选择 Pod：检查 selector 标签是否匹配。
3. Ingress 是否指向正确 Service：检查域名和路径配置。
4. 安全组或防火墙是否放通端口：云服务器需额外确认安全组规则。

这条链路和通用 Kubernetes 排错思路一致。应用商店只是帮你快速生成资源，运行时的排错仍然需要掌握基础 K8s 知识。

6. 应用商店适用的典型场景

下面列举几类比较常见的应用场景，方便你判断“要不要用应用商店”。

6.1 开发环境快速搭建

开发团队准备接入 Redis、MySQL、MinIO 时，不需要找运维要 YAML，直接在应用商店部署一套实例即可。开发环境对高可用要求不高，配置参数可以保持默认，重点是快速获得可用服务。

6.2 测试环境仿真

测试环境往往需要多套隔离的中间件。通过应用商店，可以创建一个独立的 Namespace 并在其中部署全套依赖，用完直接卸载，不会污染其他环境。

6.3 私有化交付

面向客户交付时，应用商店能够显著降低部署成本。交付人员只需要在客户环境中安装 Sealos，然后从应用商店拉起业务组件，比逐个手工发布容器快很多。

6.4 学习云原生技术

对于正在学习 Kubernetes 的读者，应用商店是很好的观察窗口。通过部署一个复杂应用，再查看它生成的 Deployment、Service、PVC 等资源，可以理解一个“完整应用”到底需要哪些云原生对象。

7. 常见问题与排查思路

以下汇总了使用 Sealos 应用商店过程中可能遇到的高频问题，供读者参考。

更详细的排查思路如下：

1. 确认集群状态是否正常：kubectl get nodes。
2. 确认应用资源是否创建：kubectl get all -n <namespace>。
3. 查看 Deployment 事件：kubectl describe deployment <name> -n <namespace>。
4. 查看 Pod 日志：kubectl logs <pod-name> -n <namespace>。
5. 查看 PVC 状态：kubectl get pvc -n <namespace>。
6. 查看 Ingress 规则和事件。

能够熟练执行以上步骤，应用商店中的大多数部署问题都可以快速定位。

8. 最佳实践与工程建议

8.1 命名空间隔离

不要把全部应用部署在同一个命名空间中。建议按环境或团队拆分：

namespace: dev-wordpress namespace: test-wordpress namespace: prod-wordpress

这样既方便权限隔离，也方便资源配额管理。

8.2 资源配额与限制

在应用商店部署应用时，尽量填写合理的 CPU 和内存限制，避免某个应用占满整个节点。对于生产环境，还建议在命名空间级别设置 ResourceQuota：

apiVersion: v1 kind: ResourceQuota metadata: name: prod-quota namespace: prod-wordpress spec: hard: requests.cpu: "8" requests.memory: "16Gi" limits.cpu: "16" limits.memory: "32Gi"

8.3 数据安全与备份

应用商店中部署的数据库类应用，数据安全性要优先考虑：

• 启用 PVC 存储。
• 定期备份数据库数据，不要把备份文件放在同一份 PVC 上。
• 设置合理的备份保留周期。
• 生产环境的数据库账号密码通过 Secret 管理，避免明文写入配置。

8.4 镜像与版本管理

应用模板可能默认使用外部镜像源。如果你的服务器无法直接拉取外部镜像，建议：

• 搭建内网镜像仓库或使用 mirrors 加速。
• 将常用镜像提前同步到内网仓库。
• 在模板中统一替换镜像地址。

8.5 权限与审计

如果 Sealos 控制台被团队成员共用，建议为不同成员设置不同权限：

• 普通开发人员：只能部署和查看自己的命名空间。
• 运维人员：可以管理集群资源和全局配置。
• 管理员：拥有完整权限。

同时建议开启操作审计，记录谁在什么时间部署了什么应用，方便问题回溯。

8.6 生产环境变更规范

应用商店在生产环境的任何变更，都应遵循最小权限和风险控制原则：

1. 变更前导出当前配置。
2. 在测试环境验证升级或配置修改流程。
3. 备份数据。
4. 选择低峰期执行变更。
5. 保留回滚方案。

9. 总结与下一步学习建议

这篇文章从 Sealos 应用商店的概念、架构、部署流程、核心操作、常见问题到工程实践做了完整梳理。通过应用商店，个人开发者可以快速获得一套可用的云原生应用环境，团队可以减少大量重复的 Kubernetes YAML 编写工作，交付人员也能在客户环境中实现低成本的应用部署。

需要注意的是，应用商店虽然有“一键部署”的体验，但底层依然是 Kubernetes。真正遇到生产环境问题时，扎实的 K8s 基础仍然是排错的关键。建议读者掌握以下能力：

• 理解 Deployment、Service、Ingress、PVC、ConfigMap 的作用。
• 熟悉 kubectl 常用命令和日志查看方式。
• 理解应用容器化的基本原理，包括镜像、端口、探针。
• 学会数据库备份、恢复的基本方法。

下一步可以尝试在 Sealos 应用商店中部署一套带数据库的完整应用，例如 WordPress 或 GitLab，观察它生成的资源对象，然后模拟一次升级和回滚。这个练习做完，你对云原生应用的部署模型会有更直观的理解。

如果文章对你有帮助，可以先收藏备用。也欢迎在评论区聊聊你使用 Sealos 应用商店时遇到的具体问题，后续可以针对高频问题再做专题整理。