关于KubeSphere应用管理的一些思考

[lxm]

首先来一个大的背景

以下是我们(红亚科技 & 青椒课堂) 的总体工具链的一些结构

代码仓库: Coding
CI: Coding
制品库: Coding
CD: Coding+开源FluxCD方案
多集群管理: KubeSphere + 阿里云集群注册(私有网络集群需要暴露kube-apiserver提供给CD)
日志告警: 阿里云SLS
应用监控: KubeSphere 自定义监控

关于应用管理的一些思考

当前面临的问题:

• 希望有一个全局统一的工具来管理应用的整个生命周期
• KubeSphere无论是应用市场(应用运营、运维阶段的管理能力不足)还是多集群应用(仅支持自制应用，无法使用helm、kustiomze等工具)都无法满足当前的现状
• 应用发布的工具如Coding Orbit、Zadig等，都在逐步右移进行集群内资源管理相关的功能跟进

[webup]

1. 所以 @lxm 你觉得给 ks 集成 FluxCD 后有可能成为一个破局点吗
2. 不光是一些竞品（再补充一个 Erda），另一个维度 Dev Portal，也有像 BackStage 这样 CNCF Incubting 阶段选手，也在右移加强自己 K8s 资源管理的能力，当大家都有基本可用的集群管理能力后 KS 的卖点又会在哪儿呢

[lxm]

关于CD工具，当前在ks-devops项目中，已经集成argocd，以及我们正在进行的FluxCD，我的看法是，不应该单单把一些开源工具进行集成就算拥有了某个能力，对于应用发布和管理来讲，是一个长生命周期的工作，涉及到的内容也会很多，例如制品库、集群、不同的namespace、监控、告警等等，应该有一个真正 以应用为中心 的视角在KubeSphere中。

[lxm]

关于第二点，从实际的角度出发，集群维度的管理并不是根本需求，根本需求在 “应用” 的全生命周期的运营、运维，如果有一个应用管理维度的产品能够把应用在集群内的资源也进行很好的呈现，那ks的卖点确实就不那么容易找到

[calvinyv]

个人觉得，单纯的从集成某个或者某几个工具的角度，并不能真正的解决上述问题，KubeSphere 项目从诞生到现在经历了几个阶段，第一个就是从无到有，第二个阶段是场景补齐，而且伴随着第二个阶段，KubeSphere 也获得了大量社区用户的支持，在这个过程中，大家会发现，云原生场景的多样性和客户需求的疾速变化，同时，KubeSphere 的客户也在成长（技术上、职位上……），KubeSphere 已有的能力也需要进化来应对客户的进化，单纯的通过产品、设计、需求迭代是没办法满足的，所以我们在推进的 4.0 就是为了解决这些所有的问题，让 KubeSphere 变成真正的云原生操作系统，没有人（大部分哈）会抱怨 windows、macos 满足不了自己的工作和家庭需求（蓝屏除外），只有真正像操作系统那样可插拔，才能随需而变。
同时，伴随着 4.0 的架构调整，产品功能和设计也正在进行调整，管理功能、数据会变得更集中，让管理力上升，另外的纵向，也会围绕着应用打通整个产品，通过 4.0 可以做到这一点，这是一个过程，也希望大家多多参与，多给 4.0 提出建议，欢迎 pr

[lxm]

hi，@calvinyv
坦率的讲，4.0目前的前期设计看起来更像是前端微应用的云原生玩法(个人观点，不带任何色彩)。而4.0从整体架构迁移到最终的形态，大概率是在4.x才能完整落地，这期间ks也不能止步不前。
对于ks的用户来说，能得到更多的能力是短期内的一个目标，否则使用KubeSphere的阻抗大，自然会被挤到其他的产品。包括我们首页的slogan，“面向云原生应用”，而当前急需对于应用相关的能力做更多的设计和落地，我们也迫切希望能参与到这个工作当中去。