理解 KubeSphere 的“转身”,但遗憾它没有好好告别

欢迎大家关注「几米宋」的微信公众号,公众号聚焦于云原生、AI、服务网格、工具教程、技术观察以及日常感悟等内容,更多精彩内容请访问个人网站 jimmysong.io。


📄 文章摘要
青云宣布 KubeSphere 暂停开源版支持,引发社区强烈反响。这篇文章从开源参与者的视角出发,理性分析其背后的动因与影响,并呼吁以更成熟的方式应对企业开源项目的生命周期变化。

🔗 在 jimmysong.io 上 阅读原文 体验更佳。

说实话,看到青云宣布 KubeSphere 暂停开源版下载和支持的消息(见 Announcement on the Adjustment of the KubeSphere Open Source Project #6550),我挺感慨的。

这让我想起 2023 年 Docker 公司清理未付费的“开源账户”的事件。当时很多项目的 CI/CD pipeline 一夜之间崩了。你会意识到,这不是单纯的技术问题,而是“信任危机”——当你以为可以依赖某个开源项目的长期可用性时,突然间你成了局外人。

KuberSphere 提供全栈的 Kubernetes 容器云 PaaS 解决方案
KuberSphere 提供全栈的 Kubernetes 容器云 PaaS 解决方案

KubeSphere 自 2018 年开始活跃,是我见证成长的国产开源项目之一。从早期的容器平台可视化起步,到后来支持 DevOps、微服务治理、多租户等功能,它在中国云原生社区积累了不少真实用户,也吸引了很多布道者和贡献者。如今,它选择暂停开源版产品的发行,或许是正式走上了 COSS(Commercial Open Source Software)的道路:将过去的核心能力商业化运营,以支撑团队发展。

这件事本身并不难理解,毕竟开源从来不是慈善。我们都知道,真正持续维护一个项目的成本是极高的,尤其在 GenAI 浪潮之下,基础设施公司的生存压力也确实在加剧。转型商业化无可厚非,问题在于——缺乏提前沟通与过渡期的安排

社区不是不能理解商业化,但不能接受“突然断供”

在 GitHub 的公告发出之前,没有任何预警;镜像仓库直接下线、安装链接清空,用户反馈拉不动镜像、节点无法更新、生产环境受影响——这是“断供”,不是“转型”。

更让人心凉的是,社区用户在 Issue #6550 下面提出种种担忧、请求延长支持、寻求镜像备份,有的理性、有的情绪化,而官方不到 24 小时便关闭了评论区,仿佛把门一关就能关掉一切讨论。这不是社区治理的方式,而是企业控制产品的方式。

如何更成熟地看待这种变化?

作为开源社区的参与者,我更倾向于用一种建设性的视角来看待这种事件。

1. 别慌,先看清动机

从公告内容看,KubeSphere 的核心代码依旧保留在 GitHub,并继续以 Apache License 2.0 + 附加条款发布,这意味着项目并没有闭源,而是暂停了“发行版”的发布和免费支持。

这有点像 Kubernetes 当年从 Docker runtime 切换到 containerd,虽然引起不小争议,但生态可以演进,用户可以迁移。问题不在变化,而在沟通方式。

2. 拥抱替代方案,保持技术多样性

云原生的精神就是“组件化”和“可替换性”。无论是 Rancher、OpenShift,其实都有能力替代 KubeSphere 提供的功能,只不过部署与运维方式不同。

别把所有的基础设施绑定在一个项目上,才是云原生真正的思维方式。

3. 与其抱怨,不如参与共建

如果你依旧想使用 KubeSphere,其实完全可以组织社区维护 fork,搭建自己的镜像仓库、构建 CI/CD pipeline。这次事件也许能促成更真实意义上的“去中心化社区治理”。

你用,你也得负责——这就是开源的本质。

写在最后

我并不想苛责青云的决定。作为一家基础设施公司,它们可能在长时间的业务探索中,发现完全免费提供复杂系统的方式难以为继,开始探索稳定的商业路径是情理之中。但作为一个影响深远的开源项目,KubeSphere 本可以有一个更平稳的告别方式。

它本可以提前三个月发预告,留下旧版本镜像、搭建文档存档站点、设立社区转交机制。它本可以告诉每一位曾经为之 PR、提 issue、分享部署经验的人:“谢谢你们参与了这段旅程,我们要换一种方式走下去了。”

可惜,它没有。

开源不是免费午餐,而是一段长期的伙伴关系。信任比技术更难建立,也更容易崩塌。但我仍愿意相信,中国的开源生态会从每一次波折中学会更成熟地构建未来。

我期待下一个真正社区驱动的云原生平台,也希望今天离开的用户,能找到新的归属,而不是在寒心中默默放弃。


🔗 更多精彩内容

  • • 🌐 个人网站:jimmysong.io

  • • 🏠 云原生社区:cloudnativecn.com

  • • 🎥 Bilibili:space.bilibili.com/206214

💫 如果这篇文章对你有帮助,欢迎点赞、分享给更多朋友!

版权声明

本文首发于 jimmysong.io,遵循 CC BY-NC-SA 4.0 协议。转载请注明出处并保留作者信息。

### KubeSphere 应用商店未启用的配置教程及解决方案 在 KubeSphere 中,应用商店功能需要显式启用才能正常使用。以下是关于如何解决应用商店未启用问题的具体方法: #### 1. 检查应用商店是否已启用 确保在安装 KubeSphere 时启用了应用商店功能。如果是在安装后才发现应用商店未启用,则可以通过以下步骤进行配置[^2]: - 登录 KubeSphere 控制台,使用管理员账号(如 `admin`)。 - 进入 **集群管理** 页面,检查是否已经启用了应用商店扩展。 - 如果未启用,可以在 **平台管理 > 扩展管理** 中找到应用商店扩展并手动启用。 #### 2. 配置应用商店访问端口 KubeSphere 的应用商店默认可以通过 `30880/apps` 端口直接访问。如果无法通过该地址访问应用商店,请检查以下内容: - 确保 KubeSphere 的负载均衡器或反向代理配置正确。 - 验证节点的防火墙规则是否允许 `30880` 端口的流量通过。 - 如果使用的是自定义域名,请确保 DNS 解析和反向代理配置正确[^2]。 #### 3. 在多集群架构中启用应用商店 在多集群环境中,应用商店需要在 Host 集群(H 集群)上启用。启用后,Member 集群(M 集群)可以直接使用应用商店的功能,而无需单独启用: - 确保 Host 集群已经正确配置了应用商店。 - 检查 Member 集群与 Host 集群之间的网络连接是否正常。 - 如果仍然无法访问,可以尝试重启 Host 集群中的相关服务组件。 #### 4. 配置全局应用可见性(KubeSphere v4) 在 KubeSphere v4 中,上传的应用 Chart 包默认仅在当前企业空间可见。如果需要全局可见,必须进行额外的配置[^4]: - 进入 **平台管理 > 全局配置**。 - 启用全局应用仓库,并将需要全局可见的应用 Chart 包添加到全局仓库中。 - 确保所有用户都有权限访问全局应用仓库。 #### 5. 验证 OpenPitrix 集成 KubeSphere 的应用商店基于 OpenPitrix 构建,因此需要确保 OpenPitrix 正常运行。如果 OpenPitrix 出现问题,可能会导致应用商店功能不可用[^1]: - 检查 OpenPitrix 相关 Pod 的状态,确保它们都在运行。 - 查看 OpenPitrix 的日志文件,定位可能的错误。 - 如果 OpenPitrix 配置不正确,可以参考官方文档重新配置。 #### 6. 测试应用商店功能 完成上述配置后,建议测试应用商店的基本功能以确保其正常工作: - 使用管理员账号登录 KubeSphere 控制台。 - 进入 **应用商店** 页面,尝试上传一个 Helm Chart 包。 - 验证是否可以成功部署该应用。 ```python # 示例:验证 Helm Chart 包是否可以正常上传 helm package redis-10.5.6.tgz ``` ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值