阿里slb做为k8s的负载均衡的限制

如果在本地搭建，我们可以使用haproxy+keepalived方式轻松实现k8s中的负载均衡，但是阿里的ecs不能使用keepalived,所以我们被迫只能使用阿里的 slb了。

既然keepalived的方式不能使用，那我们就使用阿里的slb进行负载均衡呗，由于该负载均衡不需要被外部访问，只提供对k8s集群节点之间的访问,所以我们就使用私网的slb。

[图片上传失败...(image-b02d7-1604545387128)]

我们保证该slb和k8s集群节点的node属于同一个局域网内，具体配置如下

第一步就是监听该slb的6443端口，该端口后端的服务器组分别是3台ecs的6443端口(apiserver服务)。接着我们可以 在master1节点 上执行如下命令

由于后端服务器组的 apiserver 都尚未运行，预期会出现一个连接拒绝错误。然而超时意味着负载均衡器不能和控制平面节点通信。 如果发生超时，请重新配置负载均衡器与控制平面节点进行通信。

我们在master1节点上创建kubeadm-config.yaml文件，用于初始化控制平面节点，如下。

接着我们在master1节点上执行如下命令初始化

最后结果如下

看上面的日志好像是kubelet的问题。我们先确认kubelet是否运行,发现处于running状态。

接着查看kubelet的日志

发现一个奇怪的问题，https://192.168.4.11:6443提示timeout。

接着我们在master1节点上首先测试本地的6443端口是否已经启用

看到master1节点的6443端口已经被占用，接着我们在 master1 节点测试slb的6443端口服务，按理说master1节点的6443服务已经启用，那么slb的6443服务也应该是可用可连通的。

遗憾的是slb的6443端口并没有连通，我们在master2,master3节点上分别连接slb的6443端口，发现都timeout。 我们又找了同一局域网内的另一台ecs，该ecs不属于slb的后端服务器，在该ecs上却能连接slb的6443端口 ，现在问题找到了：

带着这个疑问我们提了阿里工单，客服最后给出结论。

私网的slb是不可以使用了，我们换成公网slb之后重新按照上述流传执行一遍，最后初始化控制平面节点成功。

初始化之前slb的6443端口负载的后端服务器组的6443服务肯定都没有启动。

初始化开始后先在本地拉取相关镜像，随后apiserver等服务启动起来，也就是本地的6443服务已经启动。

接着验证slb的6443的连通性，由于master1节点的6443服务已经启动，那么slb的后端组在健康检查中就会发现有master1节点6443端口一起启动，所以slb的6443端口服务也就正常启动了。

通过上面的描述，在 控制平面节点 上大致需要满足以下俩点才能初始化成功

优点：可以将kubeconfig文件复制到你笔记本电脑上，进而可以在你本地访问集群，也正是由于这种方式可能造成安全泄漏的问题。

缺点：apiserver暴露的ip是公网ip，一是各个节点之间沟通的效率变低，二是具有安全性问题。

如果公司非得使用私网的话，我们可以采取这种方式，大概拓扑图如下

最上层是一个私网的slb,该slb的后端服务器组为俩个haproxy,使用俩台haproxy可以避免haproxy的单点故障，haproxy的后端服务器为3台k8s的master节点。

估计看到这里有人会有疑问，上面介绍的私网slb方式会导致四层监听的后端服务器无法访问私网SLB问题，那么该种方式就不会有这个问题吗？我们带着疑问进行测试。

我们准备6台ecs,配置如下

slb监听6443端口，该端口的后端服务器组为俩台haproxy并监听8888端口。

haproxy监听8888端口，该端口的后端服务器组为3台控制平面节点并监听6443端口,haproxy.cfg文件如下。

我们使用haproxy:1.7镜像，在俩台haproxy所在节点分别执行如下 *** 作：

kubeadm-config文件中controlPlaneEndpoint参数应为私网slb+6443端口，配置文件如下

执行初始化，发现可以初始化成功

以下所有测试在 master1 节点上测试

我们首先测试master1节点的apserver服务，6443端口是否已经被占用

master1节点的6443端口显示已经被占用，接着我们测试haproxy节点的8888端口是否连通

显示haproxy的8888端口已经连通，接着测试slb的6443端口是否被占用,发现可以连通

到此说明我们的3层架构都已经连通,说明此方案是可以执行的。

之前提的那个疑问我们现在得到了答案。 但有一点是需要特别注意的

优点：由于中间多了一层haproxy，所以巧妙的解决了私网slb四层监听的后端服务器无法访问私网SLB问题。

缺点：很显而易见了，中间多了一层haproxy的转发代理，而且也增加了成本。

现在大概有俩中方式可以实现k8s的高可用，一种是使用公网slb的方式，另一种是使用私网+haproxy+node的方式，这俩中方式各有优缺点，结合自己的实际情况选择适合的方案。

最近由于公司年会活动要使用一套抽奖程序，人数比较多，再加上比较重要，所以搞了一下容灾和分布式

假设现在有三台服务器A，B，C，我们的方案是A只用来做Register服务器，B，C开启Business和Gateway服务，1239作为注册端口，1240，1241等作为服务端口，这三台服务器在选择区域的时候，都要和SLB开通区域相同

SLB需要开启所有端口的监听，包括http80和https443，而后分发到几台服务器就好，需要注意云服务器安全组也需要开放对应服务的端口

Workerman直接进行端口监听不需要nginx进行转接

composer安装workerman

composer require workerman/workerman

查看workerman文件中注册文件start_start_register.php中注册端口

业务服务器中修改start_businessworker.php和start_gateway.php中的registerAddress（注册地址）和 lanIp（本机IP），如果使用的是云服务器的话，IP都要填写内网IP

然后回到项目根目录，运行命令

php start.php -d

注册服务器

之后使用工具测试对应服务器websoket是否畅通，成功即部署完成

另建议按照workerman手册优化Linux内核

手册地址

以及优化PHP无用扩展

阿里巴巴2019年到2021年的资产负债率为36.38%。根据相关信息显示，截至2021年12月31日，阿里巴巴总资产17605.67亿元，总负债6404.13亿元，资产负债率36.38%，处于比较健康的水平。

---