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

Posted 2023-05-06

参考技术A

如果在本地搭建，我们可以使用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的方式，这俩中方式各有优缺点，结合自己的实际情况选择适合的方案。

阿里云SLB最佳实践

一、SLB概念

负载均衡（Server Load Balancer）是将访问流量根据转发策略分发到后端多台云服务器（Elastic Compute Service，简称 ECS）的流量分发控制服务。

负载均衡服务通过设置虚拟服务地址，将位于同一地域的多台ECS实例虚拟成一个高性能、高可用的应用服务池；再根据应用指定的方式，将来自客户端的网络请求分发到云服务器池中。负载均衡服务是ECS面向多机方案的一个配套服务，需要同ECS结合使用。

负载均衡服务会检查云服务器池中ECS实例的健康状态，自动隔离异常状态的ECS实例，从而解决了单台ECS实例的单点问题，提高了应用的整体服务能力。在标准的负载均衡功能之外，负载均衡服务还具备TCP与HTTP抗DDoS攻击的特性，增强了应用服务的防护能力。

组成部分

负载均衡服务由负载均衡实例、监听和后端服务器三个部分组成。
负载均衡实例 （Server Load Balancer Instance）
如果您想使用负载均衡服务，必须先创建一个负载均衡实例。一个负载均衡实例可以添加多个监听和后端服务器。
监听 （Listener）
在使用负载均衡服务前，您必须为负载均衡实例添加一个监听，指定监听规则和转发策略，并配置健康检查。
针对不同的需求，您可以单独配置四层（TCP/UDP）或七层（HTTP/HTTPS）监听。
后端服务器（Backend Server）
一组接收前端请求的ECS实例。您可以单独添加ECS实例到服务器池，也可以通过虚拟服务器组或主备服务器组来批量添加和管理。
默认后端服务器是在实例维度上维护的，即负载均衡实例下的所有监听都只能够将请求转发到相同ECS实例的相同端口上。虚拟服务器组功能实现了监听维度的转发。您可以针对不同的监听创建不同的虚拟服务器组，即负载均衡实例中的不同监听可以将请求转发到不同端口的后端服务器上。
此外，七层负载均衡服务支持域名、URL转发策略，可以将来自不同域名或者URL的请求转发给不同的后端服务器处理。

二、使用限制

2.1 在 4 层（TCP 协议）服务中，不支持添加进后端云服务器池的 ECS 既作为 Real Server，又作为客户端向所在的 SLB 实例发送请求。因为，返回的数据包只在云服务器内部转发，不经过负载均衡，所以通过配置在 SLB 后端的 ECS 去访问其 VIP 是不通的。
2.2 仅支持 TCP/UDP（4 层） 和 HTTP/HTTPS（7 层） 这 4 种协议。
2.3 后端服务器仅支持 ECS，不支持第三方云服务器。
2.4 仅支持轮询（RR）、加权轮询（WRR）和最小加权连接数（WLC）这 3 中调度算法。
2.5 不支持 7 层 SSL Session 超时时间的调整。当前全局统一为 300s。
2.6 不支持 7 层 HTTP Keep-alive 超时时间的调整。当前配置为 15s。

说明：如果客户端访问 SLB HTTP 监听时使用长连接, 那么这条连接最长的空闲时间为 15 秒, 即如果超过 15 秒没有发送任何 HTTP 请求, 这条连接将会被 SLB 主动断开。如果您的业务可能会出现超过 15 秒的空闲, 需要从业务层面检测连接的断开并重新发起连接。

2.7 不支持转发超时时间的调整：

当前配置： TCP 900s，UDP 300s，HTTP 60s，HTTPS 60s
上述配置是指 SLB 服务端从后端接收数据并进行转发的超时时间，并非健康检查超时时间间隔。如果超时，通常会向客户端返回 504 错误码。

2.8 金融云 SLB 基于安全性考虑，仅允许开放特定的端口：80，443，2800-3300，6000-10000，13000-14000

三、SLB使用误区

3.1 SLB后端只添加一台ECS

用户在 SLB 后端只添加一台服务器时，虽然链路能跑通，客户端也能正常访问。但却失去了 SLB 消除 ECS 单点的基本能力。如果这台仅有的 ECS 出现异常，那边整个业务访问也会出现异常。

建议：至少在 SLB 后端加入两台以上 ECS。以便单一服务器出现异常时，业务还能持续正常访问。

3.2 后端 ECS 能正常访问，但 SLB 无法访问，则说明 SLB 出现了异常

用户通过 SLB 访问业务出现异常。但 hosts 绑定后端 ECS 的公网 IP 能正常访问。用户据此推断后端业务是正常的，是 SLB 服务端出现异常导致业务访问异常。

其实，由于负载均衡的数据转发和健康检查都是通过内网进行的。所以，从后端 ECS 的公网 IP 进行对比访问测试，并没有可比性，并不能反应真实访问情况。

建议：出现异常时，在后端 ECS 之间，通过内网 IP 做对比访问测试。

3.3 SLB 的 VIP 能 ping 通就说明配置是正常的

用户通过 ping SLB 的 VIP 地址来判断 SLB 服务的有效性。

其实，这种测试非常不可靠。因为 ping 响应是由 SLB 服务端直接完成的，与后端 ECS 无关。所以，正常情况下：

只要配置了任意监听，即便相应监听处于异常状态，SLB VIP ping 也是正常的。
相反，如果 SLB 没有配置任何监听，其 VIP 是 ping 不通的。

建议：对于 4 层服务，通过 telnet 监听端口进行业务可用性测试；
对于 7 层服务，通过实际的业务访问进行可用性测试。

3.4 已经调整了健康检查间隔，结果还会出现访问超时

用户反馈已经调大了健康检查的最大间隔时间，但客户端访还是由于访问超时收到 504 错误。

其实，虽然健康检查及业务转发都是由 SLB 服务端相同的服务器承载，但却是完全不同维度的处理逻辑。来自客户端的请求，经由 SLB 转发给后端 ECS 后，SLB 服务端会有接收数据的超时窗口。而另一方面，SLB 服务端持续的对后端 ECS 根据检查间隔配置进行健康检查。这两者之间没有直接关系，唯一的影响是在后端 ECS 健康检查失败后，SLB 不会再对其进行数据转发。

建议：客户端访问超时时，结合业务与 SLB 默认超时时间进行比对分析；健康检查超时时，结合健康检查与业务超时时间进行比对分析。

3.5 从后端日志看，健康检查间隔与监听配置的间隔时间不一致

用户反馈通过 SLB 后端 ECS 的业务日志进行统计分析，发现健康检查的间隔非常短，与之前在创建监听时配置的健康检查间隔时间不一致。

这个问题在文档 负载均衡健康检查原理浅析 有相关说明：LVS 集群内所有节点，都会独立、并行的遵循该属性去对后端 ECS 进行定期健康检查。由于各 LVS 节点的检查时间并不同步，所以，如果从后端某一 ECS 上进行单独统计，会发现来自负载均衡的健康检查请求在时间上并不会遵循上述时间间隔。

建议：如果健康检查频率过高对业务造成影响，可以参阅知识点 健康检查导致大量日志的处理 进行处理。

3.6 大量健康检查形成 DDoS 攻击，导致服务器性能下降

用户认为 SLB 服务端使用上百台机器进行健康检查，大量健康检查请求会形成 DDoS 攻击，造成后端 ECS 性能降低。

实际上，无论何种模式的健康检查，其规模均不足以达到类似于 DDoS 攻击的量级：SLB 集群会利用多台机器（假定为 M 个，个位数级别），对后端 ECS 的每个服务监听端口 （假定为 N 个） ，按照配置的健康检查间隔（假定为 O 秒，一般建议最少 2 秒）进行健康检查。以 TCP 协议健康检查为例，那么每秒由健康检查产生的 TCP 连接建立数为：M*N/O。

从该公式可以看出，M 和 N 都是固定的，而且值很小。所以，最终健康检查带来的每秒 TCP 并发请求数，主要取决于创建的监听端口数量。所以，除非有巨量的监听端口，否则由健康检查产生的连接请求，根本无法达到 SYN Flood 的攻击级别，实际对后端 ECS 的网络压力也极低。

建议： 如果健康检查频率过高对业务造成影响，可以参阅知识点 健康检查导致大量日志的处理 进行处理。

3.7 用户为了降低健康检查的影响，将健康检查间隔设置得很长

这样配置会导致当后端 ECS 出现异常时，负载均衡需要经过较长时间才能侦测到后端 ECS 出现不可用。尤其是当后端 ECS 间歇性不可用时，由于需要【连续多次】检测失败时才会移除异常 ECS。所以，检查间隔过长，会导致负载均衡集群可能根本无法发现后端 ECS 不可用。

3.8 移除服务器与权重置零的效果是一样的

移除服务器：已经建立的连接会一并中断，新建连接也不会再转发到该 ECS。
权重置零：已经建立的连接不会中断，直至超时或主动断开。新连接不会转到该 ECS。

建议：在业务调整或服务器维护时，提前将相应服务器的权重置零，直至连接持续衰减至零。操作完成后，再恢复权重配置，以降低对业务的影响。

3.9 单个连接就能达到监听配置的带宽峰值

SLB 在创建监听时可以指定带宽峰值。但用户通过单一客户端进行测试时，发现始终无法达到该峰值。

由于 SLB 是基于集群方式部署和提供服务的。所以，所有前端请求会被均分到集群内不同的 SLB 服务器上进行转发。相应的，在监听上设定的带宽峰值也会被平分后设定到各服务器。因此，单个连接下载的流量上限公式为：

单个连接下载峰值=设置的负载均衡总带宽/(N-1) 
*注：N 为流量转发分组个数，当前值一般为 4

假设在控制台上设置的带宽峰值为 10Mb，那么单个客户端可下载的最大流量为： 10/(4-1)≈3.33Mb

建议：建议在配置单个监听的带宽峰值时，根据实际的业务情况并结合上述实现方式设定一个较为合理的值，从而确保业务的正常对外服务不会受到影响和限制。

3.10 阿里云web应用防火墙（WAF）+SLB回话保持不生效

在流量入口为防护网址添加waf，waf作为反向代理在slb如果配置四层tcp/udp端口监听，可能存在后端web应用回话保持不生效，七层使用cookie可以解决，但是由于业务可能存在限制必须使用四层端口，此时可以在阿里后台提交工单申请开启waf回话保持缓存解决。

四、SLB最佳实践

4.1 业务架构

SLB 在公网环境下的典型业务架构如上图所示。基于多可用区特性，当主可用区出现异常时，SLB 会自动将流量切换到备可用区。但在实际的业务架构设计过程中，建议关注如下要点：

为了降低延迟，建议选择离您客户最近的地域进行 SLB 部署。
并非所有区域都支持多可用区特性（具体支持情况以您在控制台所见为准），请您结合业务情况选择合适的可用区。
在配合使用多可用区特性时，后端 ECS 也必须同时在相应的主备可用区部署，才能保障出现异常时，相应可用区有 ECS 能进行业务承载。

4.2 监听配置

如上图所示，SLB 支持创建多种协议监听，然后按转发策略，将前端业务请求转发到后端多种逻辑服务器集。在 SLB 服务配置的各主要步骤中，请关注如下要点。

选择监听协议

并非只要 Web 网站就必须使用 HTTP 协议。大部分没有特殊 HTTP 要求的 Web 网站，使用 TCP 监听 80 端口就可以满足业务需求。
SLB 集群采用 LVS 和 Tengine 实现。其中 4 层监听（TCP/UDP）经过 LVS 后直接到达后端服务器，而 7 层监听（HTTP/HTTPS）经过 LVS 后，还需要再经过 Tengine 转发，最后达到后端服务器，由于比 4 层多了一个处理环节。因此，7 层监听的性能相对要差一些。

集合模式	配置权重	指定服务端口	服务器数量限制	其它特性
后端服务器	支持	不支持	无限制	创建监听时的默认映射服务器集
虚拟服务器组	支持	支持	无限制	有更大的灵活性
主备服务器组	支持	支持	2 台	只能在 TCP/UDP 监听上使用

按业务逻辑创建不同的虚拟服务器组，然后创建相应的监听与之对应。
无论创建何种服务器集合，均结合 SLB 多可用区特性，同时加入位于不同可用区的服务器，以实现跨可用区容灾。
设置过多转发规则会增加业务维护的复杂度，建议尽量精简策略条目。

选择转发策略

权重代表相应服务器所承载的业务的相对占比，而非绝对值。当前 SLB 支持 3 种转发策略，其使用场景及要点如下：

转发策略	算法说明	使用要点
加权轮询（WRR）	按比重轮流分配新增连接	根据后端 ECS 规格的不同，配置相应的权重。如果是长连接业务，可能会导致老服务器的连接数持续增加，而新加入服务器的连接数相对非常低，造成负载不均的假象。
加权最小连接数（WLC）	●在 SLB 服务端，实时统计与后端 ECS 已建立的 ESTABLISHED 状态连接数，来评估相应服务器的负载情况。按权重比例，将新增连接分配给活动连接数少的服务器，最终尽可能使服务器的已建立连接数与其权重成正例。	当前暂未实现新增服务器的过载保护或缓冲机制。所以，如果业务并发非常高，可能会导致新增服务器连接数陡增，对业务造成影响。建议新增服务器时，逐步调高权重。
轮询（RR）	按顺序逐一分发新增连接。	必须手工确保后端 ECS 的业务承载能力一致。

五、建议

• 在同一个服务器集中，同时加入不同可用区的服务器，以实现同城容灾
• 根据服务器规格的差异，配置与之成正比的权重
• SLB 后端最少配置两台以上 ECS，以避免单台 ECS 出现异常导致整个业务也出现异常
• 后端 ECS 建议无状态部署：即只用于计算，而数据调用与存储后连至后端的 OSS、RDS 等公共服务。这样可以无需为 ECS 之间的数据同步问题而困扰。
• 建议基于相同的镜像或自定义镜像创建后端 ECS 服务器，以保障配置的一致性。
• 后端 ECS 归属安全组及系统内部防火墙必须对 SLB 服务端地址段进行访问放行。