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

0次阅读

共计 3070 个字符，预计需要花费 8 分钟才能阅读完成。

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 的 boot 模块与 kubeadm, boot 模块和 kubedam 都是用户治理集群生命周期的.

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

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

kubeadm 的能力：

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

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

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

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

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

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

正文完