树莓派服务器集群架设

实际上每个派都要装系统，但是装的不是完整系统而是核心，和必要软件，某个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/

---