Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

thingsboard ce 3.6.4 在高可用k8s 集群方案需要补充一些 #10

Open
ltanme opened this issue Aug 9, 2024 · 1 comment
Open

Comments

@ltanme
Copy link

ltanme commented Aug 9, 2024

针对高可用方案图,我有些问题不是很清楚 ,目前我就是要部署高可用方案,设备数就是奔着上千万台去的
1,haproxy proxy 代理可以部署k8s内部的
2,k8s 容器组本身具有 负载的功能,不管是mqtt,还是http协议都是可以的,好像和用zk,haproxy 有些冲突,就是说如果k8s自带能解决负载mqtt 的话,就不需要部署haproxy ,那什么时候要用haproxy ,除非是一个域名下,要对应多个服务,比如mqtt://a.com, http://a.com 这样子的才有可能需要用到haproxy,那如果每个微服务都有一个独立的域名就不需要部署 haproxy

3,在k8s里面可以补充哪些部署采用 k8s Deployment,还是 StatefulSet 部署方式,目前我还没有搞清楚
这个我目前想到部署时用到了TB_SERVICE_ID 这个环境变量,每个id不一样且唯一,目的是用于zk协调。
如果要TB_SERVICE_ID 唯一,则要用 StatefulSet 。

4,根据官方的k8s集群部署方案,ce版本的 3.6.4 这个连接
https://github.com/thingsboard/thingsboard-ce-k8s/blob/release-3.6.4/minikube/tb-node.yml
tb-node就是tb-core 依赖了zk, 那些服务需要依赖zk的,我现在还没有搞清楚,这些服务都是基于application maven 打包拆分出来的,很神奇的样子。

我不确定,还是不清楚 tb-http-transport, tb-mqtt-transport, tb-core, tb-rule-engine 那些要用TB_SERVICE_ID 这个id,
TB_SERVICE_ID 作为zk协调,要是唯一,

目前已知的:tb-rule-engine、tb-js-executor 是一个处理kafka消息的,不需要暴露端口
tb-http-transport 端口是8080,不是9090更不是 7070,用于给设备通过http上报遥测数据的
tb-core/tb-node 一样,暴露8080端口,我理解就是提供给web ui ,restclient 调用的
tb-mqtt/coap 设备连接mqtt,

@blackstar-baba
Copy link
Owner

感谢建议:

  1. 有做过这样的实践:在设备(网关)连接到云端时,需要有一个统一入口,使用vip+keepalive+haproxy,做整个集群的反向代理,如果有同等功能的k8s负载均衡器,也可以替代
  2. 目前了解,tb的节点都是同等地位,无状态,使用deployment即可,有状态的服务,比如zk、postgres通常是sts
  3. thingsboard有多种玩法,单体架构和微服务架构,通过工程结构+配置完成一套代码,支持两种架构,如果是高可用,高负载,通常使用

后续继续完善文档,再次感谢~

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants