树莓派服务器集群架设

树莓派服务器集群架设,第1张

实际上每个派都要装系统,但是装的不是完整系统而是核心,和必要软件,某个pi要被设置为中心机,上面带完整系统和 相关软件安装文件。

理想情况是,一个pi接入网络,中心机配置后就在该pi上部署相关软件,然后接入集群开始工作。但是要想完成这个集群需要做很多工作,比如部署,接入,运行,监控,分离,分类(存储类型pi,业务派)。

kubernetes用于大型集群管理,而k3s属于kubernetes的一个轻量级版本,常用于嵌入式设备使用。现把它安装到树莓派上使用。

这里用到树莓派的系统是:CentOS-Userland-7-armv7hl-RaspberryPI-Minimal-4-2009-sda.raw,型号是4B+,8g内存。

树莓派初次启动需要扩容,并且做一些基本调整:

cgroup是linux用来对进程分配cpu、内存资源的工具,需要在启动系统时开启他,k3s会用到。

在/boot/cmdline.txt后加入这个,然后reboot

k3s是一个轻量级的k8s,适用于树莓派这种嵌入式设备。

这个脚本跑完的时候,会把k3s添加到systemd里面,可以通过systemctl status k3s来查看运作状态。启动成功就可以使用啦

官方参考: https://rancher.com/docs/k3s/latest/en/installation/ha-embedded/

等它重启个好几次之后,基本就成功了。

如果一直失败,可以输入命令刷一下iptable缓冲

iptables --flush

iptables -tnat --flush

等第二个结点加入后,在任意结点执行命令,都能查看到已有的2个Server(Master)结点了

当Server结点数大于等于3个且为奇数时,集群才可以实现高可用。

大于等于3是因为k3s使用了Raft算法来实现一致性,而Raft算法的容崩率为1/3,也就是只要集群中有2/3台机器正常运作,集群就能正常运作,所以3台机器是最低要求;要奇数个结点是因为Raft算法过程中有一个很重要的随机投票选Leader的流程,结点们通过定期投票选举出一个Leader角色,然后其他结点在它的任期内就向他同步数据,这个时候如果结点数是偶数,那么容易出现平票问题,选不出leader,并且,崩溃后集群进行数据恢复过程中,实现一致的方法是多数服从少数,如果是偶数Master结点,且刚好被分割成2个结点规模一样的集团,就没办法恢复数据了[裂开],所以需要奇数个结点以避免权力平分问题。

以上为个人理解。

有兴趣的同学可以一起探讨这类共识算法,与此类似的还有联盟链的PBFT类算法,比特币PoW算法等等。

因为集群并非开放式集群,加入集群需要获取一个token作为校验。这个token可以从Master服务器上获取。(手动加入的话,仅需要使用相同的K3S_TOKEN参数启动即可。)

这样,结点就正常连接上啦:

关闭k3s进程后,后台还留存一些服务占用着端口,需要用官方脚本关闭他们

可以flush一下iptables,等他自己重启就行了。

有可能发生了一些冲突,可以试下重装k3s-agent

目前系统已经伴随k3s安装的一些软件:

crictl :类似与docker的命令行工具,比如:

k3s :封装了kubeneters基本工具在里面的集成,如使用kubectl:

这里示范部署一个最简单的web应用

--net host 代表与本机享受同一个网络命名空间

这里可以在docker容器内开启ssh服务: https://blog.csdn.net/Leo_csdn_/article/details/96150534

做好docker镜像后,就可以部署到集群上了。

等一会儿就能在pods列表里面看到了:

但这时候,这个pod并没有对外开放,只能在集群内部相互访问,通过get services命令查看集群的服务,发现并没有我们的hello-node服务。

expose命令其实是创建了一个service,用于给这个pod提供访问入口。

(如果使用--type=LoadBalancer,则代表一个deployment上管理的所有POD进行均衡负载,但这里还没用上deployment,第四章节会使用到)

等一会儿,pod上就有一个结点IP的对外端口,供外部访问了。

运行结束后,刚启动过的pod和service就不见了,服务也停止了。

docker容器,其实就是一个运行的轻量级系统,里面可以跑我们的业务应用。

而POD则是代表容器的集合,一个POD可以运行多个容器,一台机器上可以运行多个POD。

POD未必是一个对外开放的服务,他可能只是内部计算的程序,默认只能集群内部通信,所以还有Service的概念,用于让POD对外开放端口,供外部访问。这里的service本质上是个集群内部的负载均衡器,用来给同一个Deployment分流;对应的还有Ingress,外部负载均衡器,用于给多个Deployment分流。

而Deployment顾名思义,就是一次部署的抽象实例,比如说,现在需要部署一个3台机器均衡负载的nodejs业务应用,那么这个部署任务则代表一个deployment实例。

很快,我们可以看到POD和deployment的部署情况,都已经正常运作。

进入容器后可以使用基本linux命令,也可见8080端口已经被我们的node应用占用了。

但是此时service还没有他们,也就是正处于无法提供外部服务的状态。

这里对一个deployment里面的3个pod启动了个默认均衡负载服务,暴露出来的一个端口是30057,访问可通。

也能够通过logs命令查看控制台输出的日志。

因为deployment实例中包含了pod的部署配置,所以删除deployment时,k3s就会直接把pod也删除掉。

但service并不在deployment部署的范围内,所以需要同步删除它,在删除命令中通过","与deployment分割开来即可。

至此已经把刚起来的服务全部关闭掉了。

这里我们看到3个Server(Master)结点由于需要维护集群高可用,对CPU持续20%左右的消耗,内存也需要一个G左右。而Agent(Wroker)结点只需要执行部署任务,所以对内存与CPU的需求都相对低一些,仅维持在10%左右的CPU和半个G左右的内存消耗。

参考: https://zhuanlan.zhihu.com/p/120171512

参考: http://kubernetes.kansea.com/docs/hellonode/


欢迎分享,转载请注明来源:夏雨云

原文地址:https://www.xiayuyun.com/zonghe/315347.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-29
下一篇2023-04-29

发表评论

登录后才能评论

评论列表(0条)

    保存