可尝试解决方案

例:前端实时显示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.前端会增加一些数据处理的工作

 

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

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐