Sealos 公众号已接入了 GPT-4，完全免费！欢迎前来调戏👇
Sealos 是什么
以 kubernetes 为内核的云操作系统，这是最精准的一句话描述。
理解起来非常简单，windows 用过吧，sealos 和 windows 产品形态很像但是有两个区别：
Sealos 不是运行在一台服务器上，而是运行在整个数据中心或者多台服务器上；
Sealos 上面运行的就不再是 QQ 微信了，而是各种开发者需要用的分布式应用。
如此用户用云就能像用个人电脑一样简单了
很多人一看 Sealos 就会说：这不是宝塔嘛，确实也可以这样类比，只是宝塔更关注到单机应用，Sealos 可以狭义的理解为“分布式应用的宝塔”，这样各种分布式应用可以很快运行起来。用宝塔首先你得搞台服务器，而 Sealos 本身就是一台超级计算机，打开网页直接用。
理解 Sealos 需要有个核心思想：
整个集群是一个整体，不是零散的服务器；
整个集群是一个整体，不是零散的服务器；
整个集群是一个整体，不是零散的服务器。
重要事情说三遍，记住这个，理解什么都容易了。
所以在 Sealos 上你可以：
一键运行 nginx；
一键运行你的各种编程语言程序；
一键运行各种低代码平台，各种数据库；
云开发，函数计算像写博客一样写代码；
。。。
需要什么就装什么，不需要什么就卸载掉。
Sealos 解决了什么问题
用云体验 - 让用云变得像用个人电脑一样；
用云成本 - 不是把成本抹个零头，而是把成本抹的只剩零头；
一键构建私有云，公有云私有云一致体验。
用云体验 —— User Interface
我对 User Interface 非常的重视，其实单机操作系统已经给了标准答案，但是今天很多云平台都变成了一个庞然大物，让用户迷失在了产品中，甚至诞生了一些专门用云的培训岗位，这就是产品上的失败。很少有人去上苹果手机的培训课，因为产品足够优秀。
产品理念上首先要理解不同的角色关注点不一样，云的用户群体里有开发者 DBA 运维，懂 k8s 的，小白，专家 等等，如果用一个产品想做让这些角色都能有好的体验几乎不可能，同样一个 CI/CD 工具都有人喜欢 jenkins 有人喜欢 drone。
很多 PaaS 平台就是这样，以 CI/CD 为例，集成了某一款工具如 jenkins，这就陷入一个尴尬境地，一旦这个工具不再流行，或者有更优秀的出来，几乎这个平台就得写代码来重构部分核心能力。也无法同时满足不同人的喜好。
这里我们看单机操作系统是怎么做的？系统本身啥也不管，只负责把应用管理好，那用户就可以挑选自己喜欢的应用，办公软件有人挑钉钉，有人挑飞书，不关 windows 什么事。这就具备了极大的自由度。很多人可能觉得各种 PaaS 平台也有应用市场啊，但是其实他们并没有把应用当成一等公民，反而大部分把 k8s 当成了一等公民，不说有什么大错，只能说这样做只能定位在云原生这个用户群体，无法做到高度的抽象。
Sealos 就完全遵循了操作系统的理念，用什么就聚焦在什么功能上，比如 DBA 创建数据库关心 k8s 干啥，k8s 单词不会拼都没关系，比如用函数计算的跑不跑在容器里关我什么事，比如一个 k8s 技术专家那就装个 lens 或者命令行咔咔敲就完了。
用云体验 —— API > CLI > GUI
很多人狭义的理解产品就是 GUI，其实一个没有 API 的云和废物差不多，企业想高效的运作肯定会打通和对接各种系统，API 就尤为重要，很多时候云的设计不一定是给“人”用的，而是给别的“程序或系统”用的，这样企业才能实现高度的自动化。
Sealos 的 API 完全兼容 kubernetes CRD 设计，给每个租户都分配了权限受限的 kubeconfig 认证文件，这样自由的对接各种系统。
用云体验 —— 所有操作不要超过 3min
我们希望 sealos 上绝大多数操作都在 30s 内可以完成，最长的不能超过 3min，如果超过那这个功能一定是有问题的需要重新思考。
用云体验 —— 行政都会用
Sealos 虽然是给开发者用的，但是我们开发功能时会直接让没有任何技术背景的行政同学体验，她能跑能流程说明门槛降到足够低了，如果不行那就还需要进一步降低门槛。如果云还需要别人教才会用那就太失败了。
用云体验 —— 精品应用
先要追求应用的质量而不是数量，对于绝大多数应用都需要一个运行环境和后端依赖数据库，把这两个应用做精致再去拓展其他应用。官方应用支持常用软件并集成各个方向和领域的顶尖应用。
用云体验 —— 保证扩展性
Sealos 并不自己去搞标准，而是 follow 成熟体系和事实标准，这样与整个生态兼容性都会非常好，这意味着现在所有的云原生应用都可以安全的运行在 sealos 上，即便没有产品化的一些应用也可以通过 sealos 的 terminal 来运行，它完全安全的兼容 kubernetes。
为什么加个 “安全的兼容”，因为企业级的云操作系统一定不是一个裸 kubernetes，试想一下你企业里面的每个员工都能操作主机，都有管理员级别的权限是一键多恐怖的事，而 sealos 里面的每个用户权限都是受限在自己 namespace 中，不用担心某个用户下载了一下不合适的镜像对整个集群造成灾难性损害。
用云成本
我们并不是只想帮你降低 30% 成本，这个太没挑战，太枯燥，我们希望把云的边际成本降到白菜价。至少降低到原来的 1/10，这是追求！怎么做到？
第一：抛弃 IaaS PaaS SaaS 三层架构
为什么要抛弃？因为你看一看 IaaS 都做了什么而你到底需要不需要它，IaaS 相当于把数据中心里面的路由器交换机虚拟机这些硬件全用软件模拟了一遍，调度是变得灵活了，可软件成本也变得极高无比，就像 openstack 没个几十人想搞稳定它不太可能，这就导致单纯软件成本就极高了。以前似乎是必须这样干才能灵活调度提升资源利用，而现在从应用视角来看我的应用跑起来就完了并不用关心它是否跑在独立的 VPC 中。
以上是我五年前画的一张图，现在逐渐变成了现实，这就和单机操作系统早期也是分层后面才变成内核架构一摸一样，云计算分层架构是有历史包袱的。企业一旦抛弃了 IaaS 就可以节省大量的成本，还能顺便享受更高的性能。
从这个视角去看，你真的不需要 IaaS，而 PaaS 和 SaaS 从技术视角上都是一个东西，所以也没必要区分，都是应用。
对于云内核架构而言，只需要做好多租户的隔离，根本不需要用那么重的方式去实现，比如 Sealos 能提供在公网不可信的环境中实现多租户共享一个 kubernetes 集群，我们使用强隔离容器(firecracker)，网络策略(cilium)以及存储块设备隔离(openebs)做到，成本更低效果更好。
第二：夸张级别提升应用密度与调度效率
除非是非常重型计算密集型的应用，不然一台服务器上不跑个 100多个应用你出门都不好意思和别人打招呼，而在 Sealos 上 我们一台服务器跑 800 个应用！还能保证应用的稳定。
这对企业意味着可以减少大量硬件资源的采购，如果你是企业高管，看看整个公司整体资源利用率，大部分都在 20% 以下，这就有很多倍的提升空间。
到了这一步企业节省一半成本比较简单。
第三：充分弹性
夜间企业的不活跃应用应该都去睡觉休息，把资源留给离线计算或者训练任务，这点其实用公有云更有优势，因为可以直接释放资源，节省大量成本。
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 选择一条非常有挑战的场景：在公网不可信的环境中让多租户共享一个 kubernetes 集群。
这样做的好处是巨大的：
用户进来直接用，不需要构建集群，也只需要为容器付费，成本大大降低。
随着规模增大就会产生飞轮效应，让边际成本大量降低。（Sealos 摩尔定律：Sealos 集群规模每翻一倍用户用云成本会降低 30%）
同时带来了一个巨大的技术挑战：隔离性，安全性和超大规模。
我们解决了这个技术挑战，那不仅在公有云上为客户提供很大价值，在私有云场景就更轻松拿捏了。
从这张图中拆解 Sealos 的技术体系：
到处运行
这块比较著名的开源项目可能是 terraform 了，不过很遗憾在对接某个云时启动速度很慢（某些 driver 写的不够好，不能怪 terraform），而且很容易触发云厂商的 API 调用 limit（也是 driver 乱请求），无法满足我们的需求。
而且我们希望的标准是 kubernetes 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 镜像的格式把整个集群打包，到了客户环境一键交付。
在集群镜像能力面前可能(用词严谨)其它所有交付工具我只能说：都是弟弟。
租户管理
任何一个企业级用户，多租户都是刚需，在设计租户权限的时候既要灵活又不能复杂，这些部门或者开发者之间既要相互隔离，又需要能相互协作，而原生的 kubernetes 是不帮你做这些的，只提供一个最粗略的 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个左右
差异化&技术对比
对比 Rancher kubesphere 这些云原生 PaaS 平台
这是问的最多的，最大的区别是设计理念，Sealos 不会去做一个大而全的 PaaS 平台，云操作系统本身是高度抽象的，是 nothing，Sealos 上应用是一等公民，通过各种不同的应用来满足用户的需求，比如 Sealos 上 Database 应用，你在使用它时完全不用关心其他任何概念，kubernetes 单词怎么拼都不知道。
Rancher kubesphere 是非常优秀的 PaaS 平台。Sealos 不会把 kubernetes 当成目的，就像是你用 linux 不会太关心 kernel 的 systemcall 一样，更重要的是 kubernetes 上跑了什么应用，所以 Sealos 的用户画像是全体开发者，试图做一个通用性操作系统，而不仅仅只是满足云原生圈内的人，甚至 Sealos 不太想强调云原生这个今天都没有明确被定义的概念。
所以思考点不是“更好用的 kubernetes”，而是 “利用 kubernetes 提供给用户想要的应用”
❝
用户真正需要的是什么？
操作系统的特点是用户需要什么它就是什么，极其灵活，不会给用户带来额外负担。
如 windows 对于一个游戏玩家来说就是个游戏机, 对于程序员来说就是用来写代码的工具，对于美工来说就是用来修图的。操作系统的形态取决于使用者是谁，装了什么应用。同理 Sealos 也是这样的设计理念，所以用户用户感受会完全不一样。
对比各种安装 kubernetes 的工具
安装只是整个操作系统的一个 boot 功能，不过 sealos 在集群生命周期管理和应用打包交付上也有极大的特色。
首先就是一条命令搞定，其次就是借助集群镜像可以把整个集群打包，到处交付。最后就是可以通过像写 Dockerfile 一样灵活的定制你想要的集群，自由组装镜像替换要的组件，上百款组件任你选。
总结
Sealos 社区现在拥有庞大的社区用户基础，发展了很多年，久经沙场，稳定性在各种极端场景下久经考验，稳如老狗。
我们云服务注册用户和应用数量也在夸张级别的增长，上线两周超 6k 在线开发者，近万应用数量。
我们会为用户提供一个公有云私有云体验完全一致，简单，便宜，开放，强大的云操作系统。
关于 Sealos
Sealos 是一款以 Kubernetes 为内核的云操作系统发行版。它以云原生的方式，抛弃了传统的云计算架构，转向以 Kubernetes 为云内核的新架构，使企业能够像使用个人电脑一样简单地使用云。
🌟GitHub：https://github.com/labring/sealos
🏠官网：https://sealos.io
💻开发者论坛：https://forum.laf.run
关注 Sealos 公众号与我们一同成长👇👇👇