关于云计算:sealos-与其它流行产品的差异与联系

sealos 与其它风行产品的差别与分割

sealos 与 helm

• helm 并不关怀 kubernetes 集群生命周期的治理，然而 sealos 关怀，sealos boot 模块整个云操作系统启动伸缩降级清理都会解决.
• helm 关怀编排不关怀打包，helm 外面依赖的 docker 镜像如何交付 helm 不关怀，sealos 是把分布式应用的所有依赖打包.
• helm 不会内嵌一个 kuberentes, 然而 sealos 会，这样保障整个集群整体的一致性.
• helm 如果你的分布式应用外面依赖一些非容器化的二进制，helm 不会打包这些依赖而 sealos 会.
• sealos 内嵌一个公有镜像仓库来寄存集群中所有须要用到的 docker 镜像，helm 并没有.

Best Practise: 最佳实际是配合 helm 与 sealos 应用，用 helm 编排 用 sealos 打包整个集群, 和利用所有的依赖.
Example: Building an ingress cluster images

sealos 与 kubeadm

严格来说应该是 sealos 的 boot 模块与 kubeadm, boot 模块和 kubedam 都是用户治理集群生命周期的.

boot 的底层调用了 kubeadm 的能力，两者是相互配合的关系，sealos boot 也能够扩大其它的形式装置集群，如 二进制实现，boot 还

能够扩大其它运行时的能力，如反对 k3s k0s 这样的其它 kubernetes 轻量级发行版。

kubeadm 的能力：

• 装置 kubernetes 集群
• 增删节点、降级、清理集群等

为什么在此基础之上还须要封装一层 sealos boot:

1. kubeadm 没有给默认的 LB 计划解决 HA 问题，所以 sealos 实现了 lvscare 让集群高可用
2. kubeadm 更适宜在线装置，没有解决好依赖，特地是二进制和依赖镜像，而 sealos 所有货色都放到集群镜像中了
3. kubeadm 整个装置步骤是面向过程的，根本是 环境预设 -> 装置二进制和 kubelet->kubeadm init->kubeadm join 这个过程，而 sealos 一条命令面向后果
4. kubeadm 的证书写死在源码中，还是须要额定组件续期等，sealos 重写这部分逻辑彻底解决这个问题
5. sealos 封装了 ssh scp 等操作，不再须要登录到各机器上
6. sealos 适宜超大规模集群的疾速装置，kubeadm 间接应用会不太不便，有过多手工操作

所以 sealos boot 是在 kubeadm 根底上让装置体验做到极致.

sealos 与 rancher kubesphere

rancher 和 kubesphere 是十分优良的基于 kubernetes 的 PaaS 平台，或者 kubernetes 的管理器，

这类产品的次要个性：

• kubernetes 的可视化治理，裸露原生大量的 kubernetes 的概念，如 service deployment pod 等
• 集成 CI/CD 能力，如 kubesphere 继承 jenkins
• 集成微服务能力，如 rancher 继承 istio
• 集成监控零碎能力
• 也有利用市场，是一些生态中其它的云原生化组件

特点是大而全，一站式服务，对应用人员的专业性要求比拟高，根本定位给相熟云原生的开发与运维人员应用。

是把 kubernetes 当成目标设计思路，产品性能与能力十分具体。

sealos 的设计理念是 “ 化整为零，自在组装，大道至简 ”，利用 kubernetes 的能力应用非常简单的形式提供给用户真正想要的货色。

如何了解这句话：

可大可小，可简略可弱小

• sealos 能够非常简单，能够简略到只装置最洁净的 kubernetes, 其它什么也不带，十分洁净。
• sealos 简略不意味着性能弱，能够通过 sealos run 几十款利用来组装一个能力十分强的云。
• sealos 能够在小到 2C4G 的机器上跑测试，也能够在大到数千台的数据中心中运行。

用户真正须要的是什么？

操作系统的特点是用户须要什么它就是什么，极其灵便，不会给用户带来额外负担。

如 windows 对于一个游戏玩家来说就是个游戏机, 对于程序员来说就是用来写代码的工具，对于美工来说就是用来修图的。
操作系统的状态取决于使用者是谁，装了什么利用。

那 sealos 云操作系统也一样，sealos 自身通过 sealos core, sealos hub, sealos desktop 把分布式应用治理好即可，
剩下所有能力让应用层去扩大。

• sealos core: 实现一个多租户的内核，相当于给 kubernetes patch 治理好租户和利用
• sealos hub: 利用的提供者和使用者相互协作的中央，提供者公布利用，使用者应用利用
• sealos CLI API desktop: 一些利用应用入口，如图形界面入口

再看用户群体：

公众用户

轻易做个开发者考察，你会发现懂 kubernetes 的不会超过 5%，即使是在大厂撑死也不会超过 10%，所以能够认为公众用户是不懂 kubernetes 的

然而他们又特地须要云原生的能力，比方绝大多数利用开发者都绕不开一个需要：提供一个高可用的数据库给他们。

此时：sealos run mysql-HA:v8.0 搞定了，再通知用户拜访地址和明码，整个过程齐全感知不到 kubernetes 内核的存在，这才是敌对体验。

有 sealos desktop 就更简略了，像装置微信一样装置 mysql 集群.

云原生用户

很多人就会问了，sealos 屏蔽了 kubernetes 细节是不是就对 kubernetes 专业人士不敌对了，其实一样的情理，专业人士只须要

装置一个 kuberentes dashboard 或者装置一个 cloud terminal 利用所有原生的体验都一点问题没有，kubectl 这样的命令也

能够间接用。他们用起来一样会很难受，甚至 rancher 和 kubesphere 也能够是 sealos 上的一款云管利用。

将来 sealos 的用户群体

你发现一个有意思的点，寰球 70 亿人，手机操作系统却只须要两款支流的，为什么，就是因为零碎是形象的，零碎之上的利用是具体的，

生产关系肯定要是 n 对 n 能力满足 70 亿人的需要，rancher kubesphere 的生产关系显然是 1 对 n.

sealos 零碎上分布式应用是一等公民，将来有十万级利用满足企业方方面面对云和数字化的诉求。

以后 B 端企业都有定制化需要，因为云操作系统标准化与生产力没有达到安卓这样的级别，导致生产关系没被扭转。

所以 sealos 上会跑各种利用，数据库 / 音讯 /AI 能力 / 甚至 SaaS 软件

sealos 以后利用笼罩 (20+ 款)：

• 函数计算 laf (自研)
• 数据库 mysql clickhouse redis
• 音讯队列 kafka
• GPU
• 监控 prometheus

更多利用

sealos 自身要做的最外围的事件就是治理好这些利用，这些分布式应用自身也是 sealos 的一部分，不过都能够自在的装置卸载.

sealos 的利用与 rancher kubesphere 利用市场利用的差别

• sealos 规范齐全兼容 OCI, 能齐全和 docker hub 兼容
• sealos 利用所有依赖基于集群镜像形式打包
• sealos desktop 重视利用自身 ” 自治理 ”，而其它利用市场装置完会以 kubernetes 原生对象透出
• sealos 的产品体验，所有皆利用，而其它工具是 kubernetes 治理界面中嵌套利用市场应用上会有很多烦扰
• 不懂 kubernetes 也能很不便的应用 sealos 分布式应用，而其它工具都是须要懂能力应用
  sealos 以 kubernetes 为内核的云操作系统发行版，让云原生简略遍及

laf 写代码像写博客一样简略，什么 docker kubernetes 通通不关怀，我只关怀写业务！