这是一个创建于 234 天前的主题，其中的信息可能已经有所发展或是发生改变。
先介绍下我们的项目
Rainbond 是一个不需要懂 K8s 的开源云原生容器平台（https://github.com/goodrain/rainbond，定位是让开发者无需关心 K8s 底层，通过图形化界面和声明式配置，就能快速构建、交付、管理云原生应用。
开源六年间，我们保持着高频更新（当前 v6.3 版本），文档也持续完善（https://www.rainbond.com/docs/），但社区数据一直不温不火：
- GitHub star 数：5.2k （感觉和同类项目比差不少）
- 日均 issue/PR：个位数级别
我们反思可能的原因，但想听听大家的真实看法
1.技术定位模糊？
- 我们既想做 “K8s 简化工具”，又想覆盖 “应用全生命周期管理”，是不是功能太杂反而没突出核心卖点？
- 对比 Argo 、Jenkins X 等垂直工具，Rainbond 的 “一站式” 是否不够聚焦？
2.市场需求伪命题？
- 现在开发者是不是更愿意学 K8s 原生能力，觉得 “简化工具” 反而限制灵活性？
- 中小企业可能更倾向用云厂商 PaaS ，开源方案的落地场景是否有限？
3.社区运营拉胯？
- 我们主要靠内部团队维护，外部贡献者很少，是不是缺少激励机制？
- 文档虽然全，但新手引导是否不够傻瓜化？
4.推广方式太传统？
- 一直靠技术文章、Meetup 传播，在 B 站 / 小红书等年轻人聚集的平台几乎没投入
- 没做过竞品对比话题，是不是太佛系了？
真心求大佬拍砖
我们团队一直坚信 “让云原生开发更简单” 是有价值的，但开源六年的不温不火让我们开始怀疑： 是方向错了？还是执行没到位？ 哪怕是尖锐的批评，我们也想听听真实的声音
PS：不是钓鱼贴，团队正在做复盘，希望借 v 站大佬的视角找到破局点。如果有类似开源项目运营经验，也欢迎分享避坑指南！
最后附上 Rainbond 在线体验地址： https://run.rainbond.com/#/user/login?link=v2ex
 |
1
bigtear 2025 年 5 月 26 日
Demo 需要登陆，没兴趣了
README 写的内容太少，没看出来是干啥的 K8s 本身就很小众，普通人更喜欢 Docker 之类的关键词 |
|
2
bigtear 2025 年 5 月 26 日
而且登陆居然是用手机号，README 主要语言又是英文，定位不太清呀
国内玩这些 SaaS 的主要人群都是白嫖的，属于小众的领域 国外接受度高，但要中国手机号，体验不了呀 |
|
3
bigtear 2025 年 5 月 26 日  2
如果做 ToB 的，要多宣传才行
没有刷到过你们项目宣传的消息 |
 |
4
democrazyx 2025 年 5 月 26 日
这个链接的页面槽点就很多
首先点进去之后就是登陆页面，左边只有几句话的介绍，没有进一步的使用说明，手册之类的链接让人去了解。 其次，首页是手机号+验证码登陆，这一步估计就劝退了很多打开链接的人，我输入手机号获取验证码之后提示我用户不存在需要先注册，都获取验证码了，正常逻辑不应该是注册或登陆吗？ 好吧，我注册，获取验证码，因为刚才登陆的时候获取验证码了，提示 1 分钟后再试，那我等一分钟吧，等着等着就忘了，新用户-1 |
 |
5
LanLiang 2025 年 5 月 26 日 1
推广太少？ 至少和 kubesphere 相比，我很少见到 Rainbond 出现
|
 |
6
beyondstars 2025 年 5 月 26 日 3
对接个 github 登录，google 登录什么的，没有想象中难
|
 |
7
v1 2025 年 5 月 26 日 7
要国内手机号才能注册的首先就 pass 了
|
 |
8
FabricPath 2025 年 5 月 26 日
这个在线体验地址，要手机验证码，直接劝退。
从部署层面来说，都是在解决“如何用起来”，但是现在上 k8s 或者容器化，我觉得不是难在 “Need full container/K8s stack skills ”，因为只是部署一个东西，问一下 chatgpt ，搓一下 yaml ，也能部署起来了。 反而是难在出现问题是如何排查，比如还是以“Need full container/K8s stack skills”为例，如果没有 container 的经验，那部署业务的时候，containerd 一直在启动失败，那如何排查？所以我认为无论上层如何封装，k8s 原始的 kubectl 和 crictl 都是必备的知识。 其次是内置了很多模板（比如 golang 、php 的标准流程），这种方式虽然容易上手，但是毕竟不够灵活，现实中的需求千奇百怪，随着屎山的堆砌，大概率你预设的模板不满足业务要求，从而退化成原始的 kubectl （举个例子，比如我需要远程 ceph 存储，或者对接我自家的 csi ，我应该如何操作？）；同时这些模板也引入了新的学习成本。 我觉得你上述提到的“Rainbond 的 “一站式” 是否不够聚焦”很对，可以看到其他“热门”产品，很少出现这种固定模式的大一统产品（也许是我用得少了，我即使在 homelab 里面玩玩，也是自己搓 yaml 、自己配 Prometheus 采集）；这种大一统的方案，容易在做方案选择的时候就因为“不清楚你能做什么，但是看上去用你的人不多的样子”而被毙掉。 |
 |
9
goodrain OP 统一回复一下，我们最近在尝试 SaaS 模式还不太成熟，所以类似在线体验，我们主推的还是 100%开源，私有化部署。
|
 |
10
StrangerA 2025 年 5 月 26 日
方向错了。
我之前用的 TrueNAS ，跑容器用的 k3s ，做了全套图形化，k3s 更简单了吧。 结果还是被喷很久后终于顶不住压力在去年换回 docker-compose 了。 很多情况下大部分只需要个"能跑起来，挂了自动重启"之类的场景，对 k3s/k8s 那些其他功能根本没多大兴趣。 或者换句话说，有这个需求的也会自己去学相关知识，而不是找一个"无需学习"的纯图形化界面。 |
|
11
goodrain OP @bigtear README 托管在 Github 还是要英文优先的。这个在线体验地址是我们正在尝试的 SaaS 模式还不太成熟，所以目前当做一个在线体验，主推还是开源私有化部署。
|
|
12
goodrain OP @FabricPath 感谢您的认真回复，我们其实想做的是类似平台工程的理念，你说的这些应该是由平台管理员去处理的，而开发者们不需要懂这些东西，现在的开发什么都得干，写前端、写后端、搞运维。。。。
|
|
13
goodrain OP 补充下官网地址： https://www.rainbond.com
|
 |
14
skiy 2025 年 5 月 26 日
登录界面，基本都是中文。但是
Get verification code Sign in Sign up 却是英文。这种感觉像是半成品。 |
|
15
skiy 2025 年 5 月 26 日
既然需要登录，不如录个视频引导出来。让大家看视频就知道它能解决什么问题。
|
|
16
goodrain OP @skiy 谢谢您的回复，上面我也说过了，目前在尝试 SaaS 模式还不太成熟，但我们的开源私有化部署是很成熟的，有时间您可以自己再服务器上部署试试
|
 |
17
anonydmer 2025 年 5 月 26 日
什么内容都有，但是 license 是 LGPL ，你想需要这种 k8s 管理平台的都是什么企业？ 为什么不用 KubeSphere ，至少 license 不更友好？
|
 |
18
zeroday 2025 年 5 月 26 日 via iPhone
用 k8s 的都是企业，企业有自己的一套内部运维系统的
|
 |
19
seers 2025 年 5 月 26 日 via Android
k8s 属于用起来 no need ，排查故障要 all need 。。。
|
 |
20
ctwss 2025 年 5 月 26 日
可以参考一下 https://sealos.run 这个竞品
|
 |
21
justdoit123 2025 年 5 月 26 日 1
@seers 很精辟了。我总觉得原因就是 OP 说的 第二点，这就是个伪需求。
k8s 所描述的层面偏“底层”了一点，真要用不太可能是 “让开发者无需关心 K8s 底层”。与其学习你们用 UI 封装后的平台工具，为什么不直接学习 k8s ？ |
 |
22
matrix1010 2025 年 5 月 26 日 1
对于企业来说最重要的一点是收益与风险。只有在高收益的情况下才会愿意承担高风险，理想的情况是高收益低风险。所以 Readme 里首先应该明确选择你这个项目对比其他竞品的收益是什么，最好能精确到具体数字。风险方面，star 数量勉强能算一个指标，忽悠一些水平比较有限的程序员。有一定水平的程序员在决策时肯定会综合考虑项目背景(比如大厂出品，CNCF 认证), 代码质量(CI/CD 完善程度，是否有完备的单元/集成/e2e 测试)，是否有大厂已经在用以及是否有商业支持(出了问题谁背锅)等各种方面。对于开源项目来说 Issue 和 PR 也很重要，比如改一堆文件，PR 就一行字甚至没有字，也没有任何测试，这样的 PR 如果挺多而且合并了就是个很危险的信号
|
 |
24
Charkey 2025 年 5 月 26 日
用的 Kuboard
|
 |
25
ragnaroks 2025 年 5 月 26 日
不清楚有没有多租户，如果有的话加上计费系统做成 CaaS 平台可能更有竞争力
|
|
26
ragnaroks 2025 年 5 月 26 日
国内 CaaS 平台普遍定价比 VPS 贵一倍甚至更多，考虑到国内很多小作坊卖 VPS 的，所以我写出上面的回复
|
 |
27
37Y37 2025 年 5 月 26 日
看了下介绍，产品似乎还挺好的，github star 也不少，但作为运维确实之前都没听说过这个产品，继续加油
|
 |
28
songray 2025 年 5 月 26 日
这就是典型的不做市场调研...
国内能用上 k8s 的公司普遍都是有自己的测开、运开、sre 的，打造平台就是 KPI 的一部分，怎么可能采用你们的产品。 |
 |
29
lnbiuc 2025 年 5 月 26 日 2
我没输手机号，直接点了获取验证码，你猜怎么着 等 1 分钟吧
没注册，直接手机号+验证码登录，你猜怎么着 滚去注册吧 |
 |
30
cominghome 2025 年 5 月 26 日
我一直不觉得个人或者小团队做 toB 项目是一个好主意，toB 项目通常会面临 2 个重大问题：
1 、你为客户解决了什么问题？客户是否愿意为此付费？ 2 、对比竞品你的优势是什么？ 搞到最后你会发现这个项目小公司付不起钱，大公司不需要 |
 |
31
fengxsong 2025 年 5 月 26 日
17 年前前前公司要做内部云平台的时候还调研过。。
|
 |
32
siweipancc 2025 年 5 月 26 日 via iPhone
你这是开源还是开合啊
|
|
34
goodrain OP @matrix1010 感谢认真回复，issue 的维护和 pr 的提交规范以及其他的质量问题确实很重要，后续我们会更加重视。另外 CNCF 我们近期也在跟相关人员沟通加入
|
|
35
goodrain OP @ragnaroks 目前重点是做 100%开源的私有化部署方面，SaaS 服务也在尝试，帖子中贴的体验地址就是我们 SaaS 的初步形态
|
|
37
goodrain OP @siweipancc 我们是 100%开源的，可以私有化部署，https://www.rainbond.com/docs/quick-start/quick-install ，可以找服务器部署试试。同时提供了在线的 SaaS 环境（还在进步阶段）
|
 |
38
ranaanna 2025 年 5 月 26 日
按照官网，梅赛德斯奔驰、京东方、中航信、国货航、五所、国防科大、北理工、中电科、联影等等，都是贵公司的客户，还做着信创生意，还追求自由开源，厉害厉害，佩服佩服
但相比之下，应用商店，似乎，有点，拉低档次 |
 |
39
whoisS 2025 年 5 月 26 日
咋说呢,我是你们产品的用户.但是我只有在 java 开发的或者说是 spring 的项目才会在你们的这个平台上部署。
|
 |
40
lower 2025 年 5 月 26 日
产品名字也不好听，rain bond 既长又不知道跟 k8s 有啥关系。。。
|
 |
41
ETiV 2025 年 5 月 26 日 via iPhone 1
目标受众有问题……
咱就是说，有没有可能，“不需要懂 k8s 的人”，他就没听说过 k8s😂 |
 |
42
viking602 2025 年 5 月 26 日
登录这块都拿到验证码了就直接注册好了还要提示我个用户不存在 参考一下就竞品？ sealos 和 kubesphere cloud 对比竞品其实就没什么优势了
|
 |
43
genesislive 2025 年 5 月 26 日
README 加张图片？
|
 |
44
irrigate2554 2025 年 5 月 26 日
看了半天连个截图也不知道，就要我手机号，不敢给
|
 |
45
flynaj 2025 年 5 月 26 日
所有容器最底层都是 lxc ,都是在 lxc 上添砖加瓦，我自己直接使用 lxc.
|
 |
46
yijiangchengming 2025 年 5 月 26 日
有一个细节，你这个体验地址如果使用手机号登录未注册应该要提示会进行自动注册，你可以看看现在的 APP 都是这种。云端体验还要手机号太麻烦了，建议使用一个随机域名生成，然后实例每隔 30 分钟或者 10 分钟就重置。参考 QNAP 的云端体验。要么直接放管理账号密码，然后服务器用国外的规避一些东西，但是也要定时重置。
|
 |
47
hefish 2025 年 5 月 26 日
总结一下：
大家提的意见都非常好，但是团队有自己的考虑。 就这么着吧。。。 爱用不用。 |
|
48
yijiangchengming 2025 年 5 月 26 日
体验就是一坨。应用商店居然还要新开选项卡跳转。可以看看其他开源产品是怎么做的，订阅链接！！！参考 truenas 和 kasm 。默认一个订阅仓库，如果用户需要自定义维护仓库也可以。还有我搞不明白这个金额是做什么用的，私有化部署似乎不需要这东西，如果是 SaaS,建议使用好看一点的前端框架，这像十年前的产品了。看看 dashboard 和 cloudstudio ，侧边栏用起来，功能要分组。返回首页居然要靠左上角的图标，面包屑导航栏呢？重新设计一个前端的，太丑陋了。。。。。。
|
 |
49
ovtfkw 2025 年 5 月 26 日
 为何开源产品还写着要付费啊,开源也能收费吗 |
 |
50
pigmen 2025 年 5 月 26 日
不是，宣城图形化，readme 也好 官网也好，竟然一张预览图都没有？我是毫无兴趣的
|
 |
51
JoeDH 2025 年 5 月 27 日
没听说过，应该是宣传太少了
|
 |
52
CivAx 2025 年 5 月 27 日
你们跟 Rancher 比优势是什么… 在 K8S 还需要 KubeAdmin 才能安装的年代，Rancher 连安装流程都能给整成一键全托管了，那么我作为一个没多少技术人员的小型公司，我为什么不用 Rancher 呢
|
 |
53
dayeye2006199 2025 年 5 月 27 日 via Android
额外的封装在问题出现的时候基本都是坑。
|
 |
54
julyclyde 2025 年 5 月 27 日
问为啥不火之前你应该先问一下：
为啥要火 即使你的产品好，难道就有什么必须火的理由吗？ |
 |
55
wm5d8b 2025 年 5 月 27 日 via Android
产品本身没啥问题，但是我为什么要用？
对于个人，直接 docker 多简单。对于公司，基础支撑的产品不关心开不开源，你能提供 7x24 的售后支持才是关键，至于源代码，买的时候给一份呗 |
 |
56
ericguo 2025 年 5 月 27 日
我说个高层一点的，UI 丑这种完全不是的，只要是刚需，丑你也能起飞的，最重要的是用 k8s 了，显然是铁了心要白嫖的，你这种简化的需求本来就不存在，用 k8s 的心理是这样想的，MP ，那么多人都用上 k8s 了，而且相比 vmware 啥的都省了大钱了，我自己怎么会搞不定？我智力也是正常的啊！！！
所以建议，要不你直接换个方向吧。。 |
 |
57
xiaomushen 2025 年 5 月 27 日
个人，中小团队，就别 K8S 了。docker ，podman 之类，简简单单用用就行了
|
 |
58
aino 2025 年 5 月 27 日
5.2k 感觉已经很高了，大佬真厉害
|
 |
59
kapr1k0rn 2025 年 5 月 27 日
上个月在 reddit 上也看到这个产品的类似帖子，我还回复了，目前看来 op 团队有接受意见在改进，有专门的英文文档了，还是不错的
|
 |
60
PaulSamuelson 2025 年 5 月 27 日
你这个感觉有点像 —— https://github.com/labring/sealos
你看看人家 怎么弄的，对你有帮助 |
|
63
goodrain OP @yijiangchengming 感谢认真回复，我们在尝试 SaaS 模式，刚好没有体验的地址，就把 SaaS 放上来了
|
 |
64
hack2012 2025 年 5 月 27 日
看到需要手机号登录就不想体验了。
|
 |
66
mightybruce 2025 年 5 月 27 日
看了一眼，对你项目没有任何兴趣，你说吧，用你这个项目解决了什么问题，属于自己闭门造车，还不知道外界早就变化的项目
要一键部署一堆公司比如 kubkey, sealos devops 平台工程 项目一堆 针对应用开发生命周期管理的 2022 年就有 OAM ， 这几年更是有了 kubevela, crossplane 东西。 |
|
67
mightybruce 2025 年 5 月 27 日
devops 麻烦多看看 terraform 和 argocd 相关的开发
针对开发者麻烦多看看 cncf 的 OAM (Open Application Model Specification)， 别再闭门造车了，OAM 2022 年就已经被提出来了。 |
 |
68
leokun 2025 年 5 月 27 日
试用了一下，操作挺简单的，比同类多了应用商店，
注册后理解了为什么非要手机号了，因为应用都真的在跑，并且需要给资源，估计是怕违规或者占用资源太多 |
 |
69
sampeng 2025 年 5 月 27 日
作为运维
定位是让开发者无需关心 K8s 底层，通过图形化界面和声明式配置，就能快速构建、交付、管理云原生应用。 这个定位我就不会去看这个产品，是 terraform ，argocd 不香了？还是 k8s 得原生 yaml 真得有不能用的问题？ 开发者本来就无需关心 k8s 底层，这是个伪命题，说实话，你们是在闭门造车。 有研发能力的，就自研平台了，这是开发运维的活 没研发能力的，ci/cd 还不够用？开发需要知道什么 k8s 底层？公司养运维是吃干饭的？你是认为一个容器平台就能让公司没运维了？ 研发的关注点就不在 k8s 或者说运行环境。 运维的关注点，90%是应付工作，你给我整个页面操作，出问题了还一把抓瞎。 另一方面，这类工具太多太多了，盘子就那么大，有平台意识的公司或者运维大佬我有几十 k 的开源项目不用，把线上环境放一个 5k 的半死不活的国产开源项目里？ |
|
70
goodrain OP @mightybruce 谢谢回复，看起来你了解的蛮多的，如果你能给我们一些实质性的建议那就太好啦。OAM 也有我们团队的功劳（被挖），同时有大厂背书自然很有信服力。
|
|
72
mightybruce 2025 年 5 月 27 日
此外宣传多向海外宣发，因为国外对于成熟的产品采纳度很高， 国内不少公司还是自研，
看看人家平台工程的开源项目 seal.io ，数澈软件 Seal 完成 5300 万元种子轮融资 国内目前这方面最前沿的公司是蚂蚁自研的 KusionStack + KCL 打造云原生时代开发者的自服务平台 https://www.kusionstack.io/ 再看看 megaease , 也是走开源和私有化部署 https://megaease.cn/ |
 |
73
littlewing 2025 年 5 月 27 日
都有这么多国企和大公司客户了，还不温不火
|
 |
75
alanying 2025 年 5 月 27 日
很想听听 OP 觉得 sealos.run 这样子的产品如何？ 他们也差不多好几年了，也属于不温不火，也你也是竞品关系
|
|
78
alanying 2025 年 5 月 27 日
@goodrain 我也很早就在 oschina 看到过 rainbond ，也自己部署过， 今天又体验了一下你们的 PaaS 模式， 我觉得你们不比 sealos 差，甚至有超越。 所以蛮想听听你对 sealos 的看法的。
|
 |
80
Martin123123 2025 年 5 月 27 日
其他问题大家都说过就不说了挑我个人的角度说吧
1 、进了 git 包括文档，说实话我第一眼看不出来是跟 k8s 有关的，甚至我一开始认为这是跟 dokploy 一样，可能是基于 Docker / Docker Swarm 运行的，大概看下来我觉得你们的产品对标的应该是类似 kubesphere kuboard 这种，-如果真要简化 k8s 好歹提供 k8s 部署相关的文档，甚至 k3s 也可以，上面这两家都这样做的 2 、有了租户的概念却还要手动添加用户，我认为这种功能对接一下 ldap 或者其他完全没什么问题 |
 |
81
satoru 2025 年 5 月 27 日
定位有点奇怪
谁会去搜 "No need to learn Kubernetes" 然后刚好发现了你们？ 对大部分人来说其实日常用到的 K8s 的知识一周内就能学完了 |
 |
82
FreeGuy 2025 年 5 月 27 日
V 站都是小屌丝，给不出什么意见的，本质还是需求和供给的问题，在畸形的经济模式下，就算小屌丝们再有需求，都会被拍下去，小屌丝是招来干活的，不是给公司花钱的，你标榜的受众用户从一开始就错了，除非你出海。
|
 |
83
tt0411 2025 年 5 月 27 日
其实就一个原因, 无大厂背书.
我所知道的开源 infra 没有一个是在无大厂背书的情况下"火"起来的. 越底层的东西越需要大厂背书. |
|
85
goodrain OP @Martin123123 感谢认真回复，非常有用的意见
|
 |
86
mykaii 2025 年 5 月 27 日
没输入手机号，点获取验证码就读秒了，这基础的功能都没做好啊，用这个的都是同行，专业度要够吧
|
 |
90
soul11201 2025 年 5 月 27 日
其实有点好奇，你们的目标用户是那些人，针对他们的价值主张是什么，没明白你们要解决什么痛点。举个不恰当的例子，Rust 也不灵活，但是很火，呵呵~是不是你们切入的利基市场有问题？
|
 |
91
mengdodo 2025 年 5 月 27 日
就那么渴望用户的手机号吗，拜拜
|
|
92
soul11201 2025 年 5 月 27 日
@soul11201 对于开发来说，部署很少是痛点吧，按照 DevOps 价值左移的思路，业务交付才是研发的核心痛点，CI/CD 一般都是研发效能团队、或者说运维团队的事情，按你说的用户好像又没有这些人~
|
 |
93
overstar 2025 年 5 月 27 日
之前没用过这类东西，看到上面说有 sealos 的竞品，一起看了下，直观的感受是我想试试 sealos ，人家仓库一打开就很直观的有个演示视频，一下我就能了解到这东西如果用到自家的环境里能够有什么作用了哈哈
|
|
94
soul11201 2025 年 5 月 27 日
@soul11201 #92 从个人的研发经验来说，痛点很多时候都是不靠谱、不清楚的需求，以及交付周期又很紧张。CI/CD 公司研发效能团队都已经搞的很易用了。
|
 |
95
wosuopu 2025 年 5 月 27 日
我们团队这些年对于各式各样的容器编排工具都体验过不少，我也来说说这些年的一些心得体会吧。
我们只是一个小作坊规模的团队，所有的技术人员总共才有几个人而已，既要负责前后端的开发工作，还要负责服务器的运维工作。 最开始使用 docker 容器来部署服务，图的就是方便。这个可以减少我们的运维工作量。 差不多是 2017 年的时候吧，我们开始尝试使用 rancher v1.x 来管理服务器，当时的 k8s 还没像这样流行起来。rancher v1 差不多就是把提供一个 web 的界面来管理 docker 容器，而且还能管理多台服务器集群，简单、方便；不像 k8s 那样需要理解一堆的概念。 过了两年，k8s 开始流行起来了，rancher 也从 v1 升级到了 v2 ；此时的 rancher v2 也全面切换到 k8s 了，一下了就变得复杂很多了。 我们生产环境的服务器总共都不到 3 台机器；如果使用 k8s 的话，结果你告诉我为了高可用，光是 master 结点就至少得 3 台机器，worker 结点机器另算，而且还需要运行一堆的相关服务。这样光服务器的成本就增加了一倍不止。 另外服务器运维还需要了解一堆 k8s 的概念，当时光是开发的任务时间都不够用，哪还有空来折腾这些。于是我们就选择不升级，继续使用 rancher v1 。 这些年也陆续出现过一些号称是可以简化 k8s 的管理工具，包括 Rainbond 在内，我们也体验也不少，结果都是不太满意。 对于规模较大的，有专门运维人员的团队来说，选择使用 k8s 也没什么问题。但是对于我们这样的小团队，简单、方便的工具要更加适合我们。 直到现在我们都还是用的 rancher v1 ，然而这个版本官方早已不再维护了。现在在新的机器上安装时，还得先把相关的依赖包降级为老的版本才行。最近我们也在寻找替代方案，以免哪天 rancher v1 不能用了吧。 目前看来官方的 docker swarm 还算不错，这个比较简单，都是一些 docker 的东西，没有其他额外的复杂概念；唯一不足的就是官方没有提供 web 管理界面，所有操作都需要命令来执行，这个有点不方便。 现在 k8s 简化工具不少，如果有人能做一个 docker swarm 的简化工具的话，那对我们这种小团队来说就是福音啊。 |
 |
96
wnay 2025 年 5 月 27 日
目标太远大，没有解决某个类型客户或者场景真正的需求，云原生发展到现在
小公司大部分就用 k8s 基础的功能，直接使用公有云，现成的管理平台和控制面， 大公司有自己的基础设施团队，参与开源，直接根据自己的业务需要深入某个子项目，轻松就能整合一个平台 证券金融政府这种大客户需要的供应商要么有关系，要么底子厚，小公司很难分一杯羹 小红书推广就很迷，可能我跟不上时代。。。正常的不是应该参加展会 kubecon ，高校合作，直播公开课这样的吗 |
|
97
mightybruce 2025 年 5 月 27 日
@wosuopu 你这个开历史倒车了， 不用 k8s, 可以用一些轻量级的 k8s 替代 比如 k3s, kind.
或者直接使用 hashicorp 的 nomad, |
|
98
wosuopu 2025 年 5 月 27 日
@mightybruce 工具并不是越先进就越好，只有适合自己的才是最好的。
k3s 、nomad 之前也有调研体验过，使用这些方案不仅不能减轻我们的运维负担，反而还增加了我们的工作量。 我们想要的其实很简单，现在我们本地的开发环境是用的 docker-compose 来配置的，所以也希望线上的环境可以直接使用 docker-compose 的配置文件，简单、方便、好用；不需要其他花哨的功能。 目前 rancher v1 跟 docker swarm 都是可以直接使用 docker-compose 配置的，只是 docker swarm 没有管理界面，不太方便。 |
|
99
Martin123123 2025 年 5 月 28 日
@wosuopu 可以参考一下 dokploy / sealos 相关的产品，但是站在我的角度的话，小团队我认为这些基础设施运维可以外包出去(不单指部署方案，SSL 证书之类的一并外包出去花不了几个钱，而且也可以根据你们的需要去做解决方案)
|
 |
100
nuII 2025 年 5 月 28 日
从个人角度来说，可能是定位不对造成的。这款产品的目标群体是谁？小公司的开发者或者个人开发者？那我接触到的可能都不太会用本地部署的 k8s 管理工具，因为核心需求是开发-测试-发布，gitlab+circleCI 这种 saas 的更快，都不用关心是不是 k8s ，直接用就完事了。需要找第三方产品的，基本都是有强本地部署需求的，也就是更看重数据安全，这类就复杂了，直接使用开源工具反而是个更好的选择。
如果是有一定规模的公司或团队，选 saas 为什么不选择更知名的产品呢？在产品没有区别于同类的非买不可的痛点功能时，大厂产品或者知名产品肯定是更易被选择。如果要本地部署，那么几乎都会有至少运维和开发两个以上团队来共同使用，这种情况下不同角色的侧重点是不同的，运维更侧重服务器、服务和权限管理等，对于应用本身并不关心。而开发的角色对于这类产品的决策权并不大，只要能满足他们的需求就行。 所以本身定位就不对，当时我们也调研过，后面还是选择了 kubesphere ，后面又切回了 rancher 。 |
Select Language