web实时显示k8s集群信息解决方案

可尝试解决方案

例：前端实时显示k8s集群workload状态信息

方案1：（反应慢，后端+k8s集群压力大）

前端http请求轮询后端接口，

后端接口收到前端请求后通过k8s list接口去查询，将查询结果返回

方案2：（反应快，后端有压力，k8s集群接口压力小）

前端http请求轮询后端接口，

后端：服务启动时list接口拉取集群信息并存往redis，后端开启线程调用k8s watch相关接口监听k8s资源变化，相应资源发生变化则update  redis相应的表。前端请求到后端时，后端直接返回redis数据

方案3：（反应快，后端压力大，k8s集群接口压力大）

前端打开页面时将k8s数据存储于前端，页面打开直接取前端数据，与后端建立websocket连接，

同时后端开启watch监听k8s资源，资源变化时通过websoket将变化资源传递给前端。

方案4：（反应快，后端+k8s接口 压力小）

前端：http请求获取后端数据

后端：同方案2一样，数据存入redis,watch接口监听资源，并更新redis；后端收到请求后从redis拿数据给前端，

前后端建立websocket，当后端数据发声变化时，通知前端那种资源需要update；前端根据当前路由信息判断变化资源是否涉及当前页面显示资源，涉及则http请求获取后端最新数据

技术点：websocket,apscheduler,redis,k8sapi

方案4弊端：

根据资源种类判断是否更新，会存在很多无效更新请求。

 

方案5：前端一次拉取redis中所有资源数据并存储，与后端建立websocket连接时建立watch任务，监听k8s资源变化

watch的变化直接通过websocket推给前端，前端更具资源变化改变当前页的显示数据

备注：

1.与方案4不同的是，5中每个用户打开的页面后台websocket程序都会建立watch任务，而4中只有一个watch任务与websocket是分开的

2.前端会增加一些数据处理的工作

 

*有其他方案欢迎留言一起讨论学习--