写在最前

KubeSphere 一直是我最喜欢的 Kubernetes 控制台，没有之一。
以前只要有朋友问，我几乎都会第一时间推荐它——不管是操作体验还是整体设计，都做得非常顺手，用起来也很舒服。再加上社区一直很活跃，遇到问题基本都能找到答案，用着很安心。

但在 2025 年 8 月前后，项目突然关闭了所有镜像和文档，这一下真的有点猝不及防。
我这边很多 Kubernetes 环境都已经部署了 KubeSphere，新的环境也在持续接入，当时第一反应就是后面要是出了问题怎么办？

现在最大的不安，其实不是不能用，而是出了问题没人兜底。
这种不确定性，对我们这种已经深度依赖它的人来说，压力还是挺大的。

不只是我，我身边不少朋友也都在用 KubeSphere，大家的感受其实都差不多——不是说产品不好，恰恰是因为它太好用了，才更难接受现在这种局面。

随着 AI 开发浪潮的到来，在这样的背景下，我尝试用 Codex 重新实现了一套类似 KubeSphere 的控制台。

整体思路是：参考 KubeSphere 的前端 UI 美学和交互设计，由 AI 生成核心代码逻辑，重点还原使用体验和操作路径。最终做出来的效果，在视觉和交互上会让人感觉“很像 KubeSphere”。

但需要强调的是，这个项目是纯 AI 生成实现，并没有复制或使用官方源码。虽然外观和使用方式相似，但在代码层面是完全独立的两套实现。

本质上，这更像是一种“设计借鉴 + AI 重构”，而不是源码层面的复刻。

1. 部署流程

https://github.com/tanqidi/kubespark-console

# 使用仓库内示例 YAML 创建 Namespace + RBAC + Deployment + Service
kubectl apply -f deployment/kubespark-rbac.yaml
kubectl apply -f deployment/kubespark-deployment.yaml
kubectl apply -f deployment/kubespark-console-deployment.yaml

# 卸载用kubectl原样删除即可

2. 架构设计

https://github.com/tanqidi/kubespark-console/blob/dev/docs/API-CONTRACT.md

2.1 后端

接口需要认证访问，采用 JWT Token 机制 POST /kapis/auth/v1/login

Kubespark 后端服务提供统一的 Kubernetes 资源访问入口，基于 GVR（Group / Version / Resource） 进行抽象，所有资源均通过同一套接口进行管理 /kapis/v1alpha1/resources/{group}/{version}/{resource} 所有 Kubernetes 资源均可通过统一接口进行 CRUD 操作。

# 列表查询
GET /kapis/v1alpha1/resources/{group}/{version}/{resource}?namespace=default

# 获取详情
GET /kapis/v1alpha1/resources/{group}/{version}/{resource}/{name}?namespace=default

# 创建资源
POST /kapis/v1alpha1/resources/{group}/{version}/{resource}?namespace=default

# 更新资源，请求体为标准 Kubernetes JSON/YAML（JSON 格式提交）
PUT /kapis/v1alpha1/resources/{group}/{version}/{resource}/{name}?namespace=default

# 删除资源
DELETE /kapis/v1alpha1/resources/{group}/{version}/{resource}/{name}?namespace=default

2.2 前端

前端基于 React + Next.js 架构实现，各功能模块均围绕 GVR（Group / Version / Resource）模型进行封装，在需要的时候对它 GVR 发起GET POST PUT DELETE 请求完成 Kubernetes 资源的增删改查操作，以下是使用到的GVR对照，也可以可以到源码里看看

在此之上，其余部分主要聚焦于 UI 交互与体验设计，整体界面采用 shadcn/ui 组件库构建，以保证一致性的美学设计

Pods：core/v1/pods
Services：core/v1/services
ConfigMaps：core/v1/configmaps
Secrets：core/v1/secrets
Namespaces：core/v1/namespaces
PersistentVolumeClaims：core/v1/persistentvolumeclaims
PersistentVolumes：core/v1/persistentvolumes
Nodes：core/v1/nodes
Deployments：apps/v1/deployments
StatefulSets：apps/v1/statefulsets
DaemonSets：apps/v1/daemonsets
Jobs：batch/v1/jobs
CronJobs：batch/v1/cronjobs
Ingresses：networking.k8s.io/v1/ingresses
StorageClasses：storage.k8s.io/v1/storageclasses

3. 交互设计

整个项目的核心设计是界面操作与 YAML 编辑的双向转换。

对于新手用户，可以通过图形界面逐步完成配置流程，系统会实时生成对应的 YAML 内容；在最后阶段切换到 YAML 编辑视图，即可清晰看到完整配置，方便理解资源结构。

对于有经验的用户，则可以直接进入 YAML 编辑模式，粘贴已有配置，系统会自动解析并映射为可视化界面，进一步完成调整或直接部署。

这种设计兼顾了易用性与灵活性，既降低了 Kubernetes 的使用门槛，也保留了原生 YAML 的控制能力。