随着云计算的快速发展和广泛应用，企业和开发者越来越希望能够灵活、高效地管理和部署云资源。在这个背景下，Sealos 应运而生，它不仅是一个以 K8s 为内核的云操作系统，更是一个创新的解决方案，旨在简化和优化云计算的使用体验。
本文将深入探讨 Sealos 的核心功能、技术特点、设计理念，以及它如何革新云操作系统领域。我们也将探索 Sealos 在不同使用场景下的应用，并与市场上其他云服务平台进行比较，以展现其独特的市场优势和潜力。
Sealos 是什么？
Sealos 在概念上类似于如 Windows 这样的操作系统，但有两个关键的不同点。首先，Sealos 不是在单个服务器上运行，它的核心理念是将整个数据中心或跨多服务器的资源视为一个统一的整体。这种方法突破了传统操作系统只在单一机器上运行的局限，将资源和应用管理扩展到了更大规模，能够在整个数据中心范围内运行和管理应用，从而大幅提升云资源的利用效率和运维能力。
与普通操作系统支持的 QQ、微信等日常应用不同，Sealos 专注于为开发者提供所需的分布式应用环境。在 Sealos 的世界里，复杂的云计算任务变得像使用个人电脑一样简单直观。无论是运行常见的 Web 服务如 Nginx，还是部署和管理各种编程语言编写的分布式应用，Sealos 都能一键完成，极大地减少了配置和管理的复杂性。它的设计哲学强调用户友好性和简洁性，致力于消除使用云服务时的技术壁垒，让每个用户都能轻松享受到云计算的强大能力。
Sealos 解决的核心问题
Sealos 主要解决了以下几个核心问题：
优化用云体验
用户界面
用户界面 (User Interface) 的重要性不言而喻。传统的单机操作系统为我们提供了一个标准化的用户体验范例。然而，当今众多的云平台已经演变成庞大而复杂的系统，导致用户在产品中迷失方向。甚至催生了一些专门针对云服务的培训岗位，这在某种程度上反映了产品设计的失败。例如，很少有人需要参加苹果手机的使用培训，因为其产品设计已经足够优秀，非常易于理解和操作。
在产品设计理念上，我们首先需要认识到不同的用户角色关注点各异。在云服务的用户群体中，有开发者、数据库管理员 (DBA)、运维人员、熟悉 K8s (k8s) 的专家、技术新手和行业专家等。试图用一个产品满足所有这些角色的需求几乎是不可能的。例如，即使是同一个 CI/CD (持续集成/持续部署) 工具，也有人偏爱 Jenkins，而有人更喜欢 Drone。
许多 PaaS 平台以 CI/CD 为例，通常集成了特定工具如 Jenkins，这导致一旦该工具不再流行或有更优秀的替代品出现时，平台需重构核心功能。同时，这种设计无法满足不同用户的偏好。
单机操作系统的做法值得我们学习。操作系统本身并不过多干预，而是负责良好地管理应用程序。这样，用户就可以自由选择他们喜欢的应用，如办公软件钉钉或飞书，而这与 Windows 操作系统无关。这种方法赋予了用户极大的自由度。尽管许多 PaaS 平台也提供应用市场，但他们并没有将应用视为首要元素。相反，大多数平台将 K8s 视为核心，这不是说有什么大错，但这种做法只能定位于云原生用户群体，并不能实现高度的抽象。
Sealos 平台则完全遵循了操作系统的理念。它专注于用户所需的具体功能。例如，DBA 在创建数据库时无需关心 K8s 的具体细节；使用函数计算服务的用户不必关心其是否运行在容器中；而对于 K8s 技术专家，则可以通过 Lens 应用程序或命令行工具进行操作。Sealos 的这种设计理念，使得各类用户都能在其平台上找到合适的工具和服务，从而优化了整体的用户体验。
API > CLI > GUI
许多人对产品的理解仅限于其 GUI，但实际上，一个没有 API 的云服务产品对企业而言几乎无用。企业为了提高效率，需要打通和对接各种系统，这时 API 的重要性就显现出来了。云服务的设计往往不仅仅是为了人类用户，更多的是为了其他程序或系统，以实现企业操作的高度自动化。
具体来说，Sealos 提供的 API 与 K8s 的 CRD (Custom Resource Definitions，自定义资源定义) 设计完全兼容。用户可以通过 Sealos 的 API，以与操作 K8s 环境相同的方式来管理和控制他们的云资源。为了安全性，Sealos 为每个租户分配了权限受限的 kubeconfig 认证文件。这些文件允许租户在保证安全的前提下，灵活地对接和管理不同的系统和资源。
这种设计不仅使得 Sealos 的云服务更加强大和灵活，而且为企业提供了一种高效、自动化的方式来管理他们的云基础设施。通过 API 的广泛应用，企业可以轻松地整合 Sealos 云服务到他们现有的工作流程中，从而提高运营效率和灵活性。
快速、高效的操作体验
我们的目标是确保大多数操作能在 30 秒内完成，最长不超过 3 分钟。如果某项功能的操作时间超过这个标准，那一定是有问题的，需要重新评估和设计。
面向所有用户
尽管 Sealos 主要面向开发者，但在功能设计过程中，我们同样关注非技术背景用户的体验。为此，我们特意邀请无技术背景的行政人员亲身体验我们的服务，以此来验证产品的易用性。如果他们能够顺畅完成操作流程，便证明我们的产品操作简便、易于上手。产品的易用性是我们的核心追求，若用户需要他人指导才能使用服务，那就说明我们的设计尚有不足。
专注于高质量应用
在应用开发领域，Sealos 始终将质量置于数量之上。对绝大多数应用而言，稳定的运行环境及后端数据库支持是不可或缺的。我们致力于先对这些基础应用进行精细打磨，随后才拓展至其他应用领域，融合各个方向、领域的尖端应用，以便为用户提供全面且高效的解决方案。
保障扩展性和安全性
Sealos 并不自己去设定标准，而是严格遵循成熟的体系和事实标准，这一策略确保了我们的服务与整个云原生生态系统的高度兼容。所有云原生应用均可在 Sealos 上安全运行，即便没有产品化的一些应用也可以通过 Sealos 的终端来运行。我们的兼容性建立在全面支持 K8s 的基础上，同时在安全性方面进行了加强。
在 Sealos 中，为了避免不当操作或不适当的镜像下载对整个系统造成灾难性影响，每位用户的权限被限制在其自身的命名空间内。这种权限管理机制加强了企业级云操作系统的安全性与稳定性。
降低用云成本
我们的目标不仅是帮您降低 30% 的成本——这样的目标缺乏挑战性，过于枯燥。我们追求的是将云服务的边际成本降至极低，至少要达到原成本的十分之一。如何实现这一目标？这正是我们追求的方向。那么如何实现这个目标呢？
重定义云架构：摒弃传统模式
首先，我们要摒弃传统的 IaaS、PaaS 和 SaaS 三层架构模式。
为何选择放弃这一经典架构？原因在于，传统的分层模式已不再符合当前的技术发展和市场需求。以 IaaS 为例，它通过软件模拟数据中心中的路由器、交换机和虚拟机等硬件，虽然提高了调度的灵活性，但同时也导致软件成本急剧增加。以 OpenStack 为例，没有数十人的团队是难以维护其稳定性的，这直接导致了高昂的软件成本。过去，这种方式似乎是提高资源利用率的必要手段，但现在从应用的角度看，许多应用在运行时并不关心它们是否运行在独立的 VPC 中。
以上是我五年前画的一张图，现在逐渐变成了现实，这与单机操作系统的发展历程类似：最初是分层的，后来逐渐发展成为更高效的内核架构。云计算的分层架构同样携带着历史的包袱。一旦企业摒弃了 IaaS，它们就可以节省大量成本，并享受到更高的性能。
从这个新的视角出发，我们发现，实际上并不需要 IaaS。同时，从技术角度来看，PaaS 和 SaaS 本质上是相同的，它们都是应用层面的服务，因此也无需进行过度区分。在新的云内核架构中，我们只需要有效地实现多租户之间的隔离。这并不需要复杂重量级的解决方案。例如，Sealos 提供了一种在不可信公网环境中实现多租户共享一个 K8s 集群的方式。我们利用强隔离容器 (如 Firecracker)、网络策略 (如 Cilium) 以及存储块设备隔离 (如 OpenEBS) 来实现这一目标，不仅成本更低，效果也更好。
提高应用密度和调度效率
除非是非常重型计算密集型的应用，不然一台服务器上不跑个 100 多个应用你出门都不好意思和别人打招呼，而在 Sealos 上我们一台服务器跑 800 个应用！还能保证应用的稳定。
这对企业来说非常重要，企业可以显著减少对硬件资源的采购需求。如果你是企业高管，可以重新审视一下公司的整体资源利用率，你会发现大部分情况下这一比率都低于 20%。通过我们的方法，还有很多倍的提升空间。
通过 Sealos，企业能够以更简单的方式节省高达一半的成本。
充分弹性
夜间企业的不活跃应用应该都去睡觉休息，把资源留给离线计算或者训练任务，这点其实用公有云更有优势，因为可以直接释放资源，节省大量成本。
Sealos 直接把这一重要特性内置。如果企业所有应用都以这样的方式运行，可以节省巨量的成本。
干掉僵尸应用和僵尸服务器
企业里面有很多开发测试的程序，怎么知道哪些没人在用？甚至还有很多僵尸 “服务器”，有些企业只能靠一个 exel 表来维护谁用了啥，过一段时间把负责都问一遍，清退没人有的服务器，稍微高端点的会搞个老掉牙的 CMDB。。。
解决这个问题的釜底抽薪办法是：收钱。对，企业内部也得收钱，欠费的应用就直接干掉。
这样每个部门可以申请额度，开发者申请额度，额度用完就干掉应用，这样可以长期保证没有僵尸应用。而 Sealos 把所有服务器都统一纳管，整个集群变成一个大资源池，当然就不可能存在僵尸服务器了。同时还帮企业节省了一帮运维人力。
要想杜绝资源浪费就需要这样精细化运营，Sealos 以极低的成本达到这个目的，企业管理者唯一要做的事就是给每个子账户分钱即可。
这样你可以精细化的控制到每个部门每个人用多少钱，从而进一步分析 ROI。
最多半个人运维整个云
一帮运维？每个业务都有运维组？你见过微软把 PC 卖给你再给你配个运维？所以还是软件不够优秀，足够优秀足够稳定就不需要运维这个角色。或者这个角色做的事情会改变比如写编排文件写 operator。
Sealos 的开发者花了不到一半精力维护整个云，8000 个应用时半个人，8w 个也是 80w 个也是 800w 个也是半个人，这就是云操作系统，不会因为体量变大而增加运维复杂度。
我是一个比较中性的人但是我有个极端观点是云足够成熟的情况下不应该有运维这个角色，如果你的企业运维超过 3 个人 (搬服务器的除外)，那应该好好反思一下。
在给现在的运维人员指条明路：去开发云操作系统。
研发人力成本
我是一个研发，我至少 50% 以上的精力花在了研发之外的事上，那些杂事加起来可能有 20% 但是其影响可能是 80% 。它会割裂我正在做的事，比如你写完代码想着还要卖服务器，配置证书，打包，上线一想到这些我敢打赌没有哪个开发者喜欢做这些事，除非他是个变态。开发者是群懒人，为了偷懒开发出一大堆工具，这是偷懒者的胜利，sealos 也是一群偷懒者创造的，所以能自动绝不手动，能 AI 绝不人工。
自己分析问题多累，AI 比人还专业。
Sealos 上函数计算能力 Laf 就可以让写代码像写博客一样简单，点击保存，关机走人，要想下班早，Laf 得用好。
所有后端依赖如数据库这些都可以轻松 30s 之内解决。未来还有 AI 自动打包上线，自动编码调试等。
这无形中的研发效率提升可以节省的成本是难以想象的，我们客户例子中 2 个人干五个人活的比比皆是。
一键构建私有云，公有云私有云体验一致
Sealos 对云计算的理解是深刻的：
公有云和私有云是一回事，同一个抽象，同一套代码，同一种体验，装的应用不同尔而已
你会发现 linux 不管跑在你自己的数据中心还是跑在公有云上都是一种产品形态，这就是优秀软件的特点，能做到高度抽象。
Sealos 设计之初就考虑到这一点，其实公有云与私有云本质是一样的，都是链接计算资源。很多人可能觉得不一样啊，公有云还有充值计费什么的，其实只需要把这些功能放到一个单独的应用中即可，这样在不需要的场景直接不安装这个应用。
但其实大一点的企业即便做私有云它的形态也应该和公有云一样，计量计费是非常重要的一个功能，企业超过 10 个人都需要精细化运营云资源，就更别说成千上万人的企业用私有云了，各部门的成本分摊等。
一些非常小的差异比如微信支付第三方登录这些可能确实不太需要，这就是一些小的配置。
Sealos 技术分析
Sealos 选择一条非常有挑战的场景：在公网不可信的环境中让多租户共享一个 K8s 集群。
这样做的好处是巨大的：
- 用户进来直接用，不需要构建集群，也只需要为容器付费，成本大大降低。
- 随着规模增大就会产生飞轮效应，让边际成本大量降低。(Sealos 摩尔定律：Sealos 集群规模每翻一倍用户用云成本会降低 30%)
同时带来了一个巨大的技术挑战：隔离性，安全性和超大规模。
我们解决了这个技术挑战，那不仅在公有云上为客户提供很大价值，在私有云场景就更轻松拿捏了。
从这张图中拆解 Sealos 的技术体系：
到处运行
这块比较著名的开源项目可能是 terraform 了，不过很遗憾在对接某个云时启动速度很慢 (某些 driver 写的不够好，不能怪 terraform)，而且很容易触发云厂商的 API 调用 limit (也是 driver 乱请求)，无法满足我们的需求。
而且我们希望的标准是 K8s CRD 而非 terraform，这样配合上 helm 就可以，于是我们自研了一个对接基础设施的控制器。结果是本需要 10min 启动的基础设施我们优化到了 30s，这几乎是极限了，很难在有压榨空间了，除非云厂商自己服务器启动时间能再快些。优化点主要在一些并行的处理以及退避算法调优，而不是动不动就 sleep 10s。加上在这些虚拟机上启动 Sealos 集群也只需要 3min，这已经优于很多同类产品了，大家可以自行比较 (其它一般 15min)
同样在裸机上运行要考虑大量兼容性问题，所以 Sealos 底层几乎全部抛弃 rpm apt 这些与操作系统耦合的安装工具，这样几乎兼容了全部主流的 linux 发行版。windows 我们不支持，原因是因为单纯的讨厌不喜欢。
同时我们的集群镜像能力可以很好的同时支持 ARM x86 这些主流硬件体系架构。
云驱动层
这块挑战巨大，如果不考虑安全性隔离性，这块装一个 containerd calico openebs 可能就 OK 了，但是在公网不可信环境中这种弱隔离肯定是不行的，所以我们在一些新的技术上填坑，如 firecracker 来解决容器维度强隔离，而云厂商虚拟机里套虚拟机又是有问题的，这里后续我们会单独发一篇文章来介绍。
网络我们对计量和隔离的要求极高，而 calico 这些你懂的，隔离会使用大量的 iptables 规则，规模一大基本网络就不可用了，我们测试过 5000 条规则时压力测试一下就有 30% 的失败率。网络这块我们就引入了 cilium，通过 ebpf 来解决这这些问题，还有多租户的网络计量。
存储我们使用 openebs + lvm，为每个用户挂载独立隔离的卷，这样用户可以享受到本地磁盘的性能。而文件存储又变成一个大问题，nfs 这些几乎只是玩具，根本无法生产。所以我们世界冠军同学带队基于 rust 完全自研 sealfs 文件系统，架构超级精简，主打高性能，支持 RDMA。
生命周期管理与集群镜像
对于集群安装扩容 Sealos 老用户都知道，几乎已经被做到极致了，多复杂的集群一律一条命令搞定！
而集群镜像能力世界上可能 (为了不触犯广告法加上可能二字) 只有两款软件支持 Sealos 和 sealer，都是我主导开发的，sealer 在阿里时捐给了 CNCF。这种能力是交付之王！可以用完全兼容 Docker 镜像的格式把整个集群打包，到了客户环境一键交付。
在集群镜像能力面前可能 (用词严谨) 其它所有交付工具我只能说：都是弟弟。
租户管理
任何一个企业级用户，多租户都是刚需，在设计租户权限的时候既要灵活又不能复杂，这些部门或者开发者之间既要相互隔离，又需要能相互协作，而原生的 K8s 是不帮你做这些的，只提供一个最粗略的 namespace 管理肯定是不够的。
Sealos 会为每个登录的用户分配一个独立的 kubeconfig，其权限只会被限制到用户自己的 namespace 中，用户可以把自己的 namespace 共享给别人。用户想穿透到主机，或者使用特权，或者共享主机文件系统端口号这些危险操作统统禁止，这才是企业实践云原生的 (可能) 最佳姿势。
应用管理
应用是 Sealos 的一等公民，在云内核之上，一切皆应用。这里最难的地方是在多租户的情况下如何寻求一个统一的应用管理方式的抽象。
比如有些应用是需要一个管理员权限跑一个控制器的。
有些应用是需要跑一个单独的实例的。
有些应用是一个实例多个用户共享使用的。如一个 chatGPT API。
有些应用是不使用时就要被自动释放的。如 terminal 应用，没人用会自动被回收。
而系统还需要对这些应用进行权限的管控和计量，进一步增加了复杂度。
Sealos 把这些能力全部抽象成了应用，就像你 macOS 上跑的应用一样。
自研函数计算应用 Laf
真的让你体验什么是像写博客一样写代码
- 云端开发，码上生花
- Laf 用的好，天天下班早
- 行政都会用的云开发
- 函数计算有两种 30s 上线的和 30s 劝退的
Laf 的毫秒级发布几乎吊打一切，一般其他方案发布一次都得等个 3 到 5s，而 laf 能做到比发博客还快。
Laf 直接集成 GPT4，大部分代码就不用你自己写了，我们训练了几千份 Laf 的代码，现在 AI 写起来已经很绝绝子了。
数据库内置，对象存储内置，除了用 AI 写点代码几乎不用关心其它任何东西。
对 websocket 的支持几乎天下无敌 (有些 function 按调用时长收费，我就问你一个长链接你的钱包还够不够)
别的函数计算不是常驻模型，一个 chatGPT 的会话 ID 你都得存到数据库，而 Laf 完全不需要，用的是常驻自动伸缩容器。
自研 AI 知识库应用 fastGPT
Laf AI 写代码，sealos 故障自动诊断，AI 自动上线应用，自动构建 Docker 镜像，这些统统靠 fastGPT 这个项目，自动帮你构建知识库。
数据库/消息队列等应用
我们核心聚焦在操作系统和部分内置应用上，数据库消息队列这些是个非常专业的领域，我们选择的办法是与顶级天团团队合作，数据库我们选用 kubeblocks，是 polarDB 创始人曹伟主导的项目 (刚好就在我们隔壁，他们的咖啡好喝，数据库好用)。kubeblocks 统一编排了 mysql pgsql mongo redis，各种高可用数据备份恢复等，绝对的为数据保驾护航。数据库管控我们与 bytebase 合作，google 云数据库团队担任技术负责人陈天舟带队。
消息队列我们选择与 rocketmq 创始人王小瑞合作，统一解决 rocketmq kafka 等消息队列服务。
devops 我们与 gitea 合作，90% 兼容 github actions，gitea 作者亲自带队，github actions 几乎是一个完美 devops 方案，gitea 选择与其兼容是一个非常明智的选择。
计量计费
计量并不容易，首先需要有类似监控系统的采集机制，容器的 CPU 内存磁盘，采集到了之后需要与其 namespace 关联，最终关联到账户。除此之外还需要采集一些比较难采集到的东西，比如函数计算里面数据库的访问次数，对象存储每个租户用的大小等。最难的是在不影响网络性能的情况下对网络带宽的计量。
计量系统的挑战是他不像监控系统那样对精准度要求不高，一旦计量出错用户的钱就出错，是个非常敏感操作，我们需要有个对账的系统对计量进行校验，确保没有收错钱。
有了这个能力，企业就要以对部门和内部开发者做精细化的运营，应用欠费自动停机就会让整个公司几乎没有僵尸进程。
我们还实现了公有云模式与私有云模式计量的统一抽象。
Sealos 设计理念与原则
牛掰的东西从使用者视角来看一定是简单的，如苹果手机，安卓操作系统。云计算同样可以做到，但是如果简单功能不强，那叫简陋。牛逼的架构不会牺牲复杂度来增强功能。
Sealos 一旦违背这些原则，就会走向笨重，奔向死亡。
大道至简
Sealos 大道至简体现在两个方面：产品设计&系统架构。
产品上我们坚决不想给用户带来任何负担，就希望用户像用个人电脑一样用云，是什么样的角色关心什么样的应用，坚决不让额外你不需要用的功能对你产生干扰。这不意味着功能就弱，Sealos 可以通过扩展任何应用来增强系统的能力，也提供原生 API 来自由扩展。
系统架构层面抛弃 IaaS PaaS SaaS 三层架构是个明智之举，因为从应用视角来看其实压根就不需要复杂的三层架构去支撑，云内核+云驱动，系统之上皆为应用。
化整为零
Sealos 可以精简到只剩一个裸 kubernetes，也可以装成千上万个应用，可以跑在电视盒子上，也可以运行在数万台服务器的数据中心，想想优秀的 linux 是不是也是这样，可以运行在嵌入式设备上也可以运行在最大的数据中心，这就是一种化整为零的架构，可以做到恰好满足你的需求，而不是堆了一大堆你不需要的能力。
只有这种架构才能做到无限扩展。
自由组装
内聚精简的架构就可以根据自己的需求来做组装，让你的云多一分则嫌多，少一分则嫌少。这得益于高度抽象的能力，具体功能通过应用本身去实现，而云操作系统本身对下只需要池化资源，对上只需要管理好应用即可，这样即便整个生态几十万应用出现也不会增加你的云的复杂度。参考你是怎么用智能手机的，云也可以这样玩。
使用场景
直接使用 Sealos 提供的云服务
- 任何的业务组件能 build 成 docker 镜像的就能很轻松跑在 Sealos 上 (后面当然会有 AI 帮助完成镜像构建，什么 Docker 我不懂)，比如企业内部各种编程语言写的项目。
- 四大数据库高可用集群一键启动 pgsql/mysql/mongo/redis，备份/恢复/监控/管控应有仅有。
- 各种知名开源项目都可运行在 Sealos 上。
所以可以很好的在 Sealos 上运行你的业务系统，解决了业务运行时问题和所有后端依赖。
帮助你构建完整的私有云
大家可能越来越发现裸硬件不仅比虚拟机性能更好，而且价格还便宜，不过还是大量公司还不会考虑托管硬件，原因就在于很难搞得定软件部分，搭 openstack？搭 kubernetes？其实都差点意思。
Sealos 的云服务版本可以一模一样的 clone 到你自己的机房，Sealos 目前已经服务数万在线用户了，能支持的场景和复杂度已经超过绝大多数公司了，毕竟有几万开发者的公司还是不多的。
所以裸机+Sealos 软硬件都有了，自建私有云这个事就成立了。
自建成本有多高呢？
- 买好服务器
- 一条命令起集群，小白都会，管你多少台服务器都是一键
- 最多 0.5 人维护，我们基本实现了自运维，目前在线集群服务上万应用投入的维护人力 0.1 个左右
与其他平台的比较
对比其他云原生 PaaS 平台
这是问的最多的，最大的区别是设计理念，Sealos 不会去做一个大而全的 PaaS 平台，云操作系统本身是高度抽象的，是 nothing，Sealos 上应用是一等公民，通过各种不同的应用来满足用户的需求，比如 Sealos 上 Database 应用，你在使用它时完全不用关心其他任何概念，kubernetes 单词怎么拼都不知道。
与追求大而全的传统 PaaS 平台不同，Sealos 把云操作系统视为高度抽象化的 “nothing”，强调应用程序的重要性。在 Sealos 平台上，应用被视为第一等公民，通过多样化的应用来满足用户的各种需求。例如，使用 Sealos 的数据库应用时，用户无需关注任何其他概念，甚至不需要知道如何拼写 “Kubernetes”。
Rancher 和 KubeSphere 是非常优秀的 PaaS 平台。但 Sealos 并不将 K8s 作为其核心目的。它更注重于 K8s 上运行的应用，而非 K8s 本身。因此，Sealos 的目标用户是广泛的开发者群体，其意图是打造一个通用性操作系统，不局限于仅服务于云原生领域。Sealos 甚至都不太想强调 “云原生” 这一尚未明确定义的概念。
因此，Sealos 的核心思想并非是 “更好用的 Kubernetes”，而是 “利用 K8s 为用户提供所需的应用”。
用户真正需要的是什么？
在操作系统领域，用户的需求定义了系统的功能。操作系统的灵活性意味着它不会给用户带来额外负担。例如，Windows 对于游戏玩家而言是游戏平台，对程序员则是编程工具，对美工来说则是图像处理软件。操作系统的形态由使用者决定，取决于装载了哪些应用。Sealos 也秉承这样的设计理念，因此不同用户的体验将截然不同。
对比各种 K8s 安装工具
安装只是整个操作系统的一个 boot 功能，不过 Sealos 在集群生命周期管理和应用打包交付上也有极大的特色。
首先，Sealos 通过一条命令即可完成安装。其次，利用集群镜像，可以将整个集群打包并随处交付。最后，Sealos 允许用户像编写 Dockerfile 一样灵活地定制所需的集群，自由组装和替换镜像中的组件，提供了上百种组件供用户选择。
总结
Sealos 社区现在拥有庞大的社区用户基础，发展了很多年，久经沙场，稳定性在各种极端场景下久经考验，稳如老狗。
我们云服务注册用户和应用数量也在夸张级别的增长，上线两周超 6k 在线开发者，近万应用数量。
我们会为用户提供一个公有云私有云体验完全一致，简单，便宜，开放，强大的云操作系统。