如果在本地搭建，我们可以使用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的日志
发现一个奇怪的问题，提示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的方式，这俩中方式各有优缺点，结合自己的实际情况选择适合的方案。
四层负责均衡：主要是指通过判断报文的IP地址和端口并通过一定的负载均衡算法来决定转发到哪个指定目标，主要工作在OSI模型的第四层。四层负载均衡对数据包只是起一个数据转发的作用，并不会干预客户端与服务器之间应用层的通信（如：三次握手等）。所以能对数据所进行的操作也就很少，但相对于七层负载均衡来讲效率会高上很多
七层负载均衡：也被称为“内容交换”，指的是负载均衡设备通过报文中的应用层信息(URL、HTTP头部等信息)和负载均衡算法，选择到达目的的内部服务器。七层负载均衡可以“智能化”地筛选报文中 应用层信息，然后根据不同的信息进行特定的负载均衡调度。这种方式提升了应用系统在网络层上的灵活性，另外也在一定程度上提升了后端系统的安全性。因为像网络常见的DoS攻击，这些攻击在七层负载均衡的环境下通常都在负载均衡设备上就截止了，不会影响到后台服务器的正常运行。
前网络中常见的负载均衡主要分为硬件负载均衡和软件负载均衡。硬件负载均衡比较知名的产品有F5 Big-IP、Cirtix Netscaler等等。而软件负载均衡就有着众多的开源项目，常见的有Haproxy、nginx、lvs等。
Haproxy：
lvs:
nginx:
Haproxy可以做代理服务相对于nginx而言有很多相同之处，统一可以基于mode tcp进行四层代理也可以基于mode http进行七层代理，但不同的是其无法使用location和if等进行匹配判断。突出优势在于有会话绑定，web管理界面，状态统计非常详细。官方推荐只启用一个进程，相对于nginx多进程架构工作并不理想，更多的线程可能会受到系统内存的一些限制。
程序环境：
主程序：/usr/sbin/haproxy
主配置文件：/etc/haproxy/haproxy.cfg
Unit file：/usr/lib/systemd/system/haproxy.service
查看配置文件
重要的几个参数，及性能调优，多数无需修改
发现日志发送给本机rsyslog的local2的facility，而本机的rsyslog里并没有定义，需要我们自己去配置
所以vim /etc/rsyslog.conf添加一段将local2的所有信息记录在对应日志文件中
由于HAProxy可以工作在七层模型下，因此，要实现HAProxy的强大功能，一定要使用强大灵活的ACL规则，通过ACL规则可以实现基于HAProxy的智能负载均衡系统。HAProxy通过ACL规则完成两种主要的功能，分别是：
1）通过设置的ACL规则检查客户端请求是否合法。如果符合ACL规则要求，那么将放行；如果不符合规则，则直接中断请求。
2）符合ACL规则要求的请求将被提交到后端的backend服务器集群，进而实现基于ACL规则的负载均衡。HAProxy中的ACL规则经常使用在frontend段中，使用方法如下：
acl 自定义的acl 名称 acl 方法 -i [ 匹配的路径或文件] 其中：
·acl：是一个关键字，表示定义ACL规则的开始。后面需要跟上自定义的ACL名称。
·acl方法：这个字段用来定义实现ACL的方法，HAProxy定义了很多ACL方法，经常使用的方法有hdr_reg（host）、hdr_dom（host）、hdr_beg（host）、url_sub、url_dir、path_beg、path_end等。
·-i：表示不区分大小写，后面需要跟上匹配的路径或文件或正则表达式。与ACL规则一起使用的HAProxy参数还有use_backend，use_backend后面需要跟上一个backend实例名，表示在满足ACL规则后去请求哪个backend实例，与use_backend对应的还有default_backend参数，它表示在没有满足ACL条件的时候默认使用哪个后端
这些例子定义了www_policy、bbs_policy、url_policy三个ACL规则，第一条规则表示如果客户端以 或 z点吸烟 开头的域名发送请求时，则此规则返回true，同理第二条规则表示如果客户端通过 bbs.z点吸烟 域名发送请求时，则此规则返回true，而第三条规则表示如果客户端在请求的URL中包含“buy_sid=”字符串时，则此规则返回true。
第四、第五、第六条规则定义了当www_policy、bbs_policy、url_policy三个ACL规则返回true时要调度到哪个后端backend，例如，当用户的请求满足www_policy规则时，那么HAProxy会将用户的请求直接发往名为server_www的后端backend，其他以此类推。而当用户的请求不满足任何一个ACL规则时，HAProxy就会把请求发往由default_backend选项指定的server_cache这个后端backend。
与上面的例子类似，本例中也定义了url_static、host_www和host_static三个ACL规则，其中，第一条规则通过path_end参数定义了如果客户端在请求的URL中以.gif、.png、.jpg、.css或.js结尾时返回true，第二条规则通过hdr_beg（host）参数定义了如果客户端以www开头的域名发送请求时则返回true，同理，第三条规则也是通过hdr_beg（host）参数定义了如果客户端以img.、video.、download.或ftp.开头的域名发送请求时则返回true。
第四、第五条规则定义了当满足ACL规则后要调度到哪个后端backend，例如，当用户的请求同时满足host_static规则与url_static规则，或同时满足host_www和url_static规则时，那么会将用户请求直接发往名为static的后端backend，如果用户请求满足host_www规则，那么请求将被调度到名为www的后端backend，如果不满足所有规则，那么将用户请求默认调度到名为server_cache的这个后端backend。
log：全局的日志配置，local0是日志设备，info表示日志级别。其中日志级别有err、warning、info、debug4种可选。这个配置表示使用127.0.0.1上的rsyslog服务中的local0日志设备，记录日志等级为info。
maxconn：设定每个HAProxy进程可接受的最大并发连接数，此选项等同于Linux命令行选项“ulimit -n”。
user/group：设置运行HAProxy进程的用户和组，也可使用用户和组的uid和gid值来替代。
daemon：设置HAProxy进程进入后台运行。这是推荐的运行模式。
nbproc：设置HAProxy启动时可创建的进程数，此参数要求将HAProxy运行模式设置为daemon，默认只启动一个进程。该值的设置应该小于服务器的CPU核数。创建多个进程，能够减少每个进程的任务队列，但是过多的进程可能会导致进程崩溃。
pidfile：指定HAProxy进程的pid文件。启动进程的用户必须有访问此文件的权限。
mode：设置HAProxy实例默认的运行模式，有tcp、http、health三个可选值。
retries：设置连接后端服务器的失败重试次数，如果连接失败的次数超过这里设置的值，HAProxy会将对应的后端服务器标记为不可用。此参数也可在后面部分进行设置。
timeout connect：设置成功连接到一台服务器的最长等待时间，默认单位是毫秒，但也可以使用其他的时间单位后缀。
timeout client：设置连接客户端发送数据时最长等待时间，默认单位是毫秒，也可以使用其他的时间单位后缀。
timeout server：设置服务器端回应客户端数据发送的最长等待时间，默认单位是毫秒，也可以使用其他的时间单位后缀。
timeout check：设置对后端服务器的检测超时时间，默认单位是毫秒，也可以使用其他的时间单位后缀。
bind：此选项只能在frontend和listen部分进行定义，用于定义一个或几个监听的套接字。bind的使用格式为： bind [address:port_range] interface interface其可以为主机名或IP地址，如果将其设置为“*”或“0.0.0.0”，将监听当前系统的所有IPv4地址。port_range可以是一个特定的TCP端口，也可是一个端口范围，小于1024的端口需要有特定权限的用户才能使用。interface为可选选项，用来指定网络接口的名称，只能在Linux系统上使用。
option httplog：在默认情况下，HAProxy日志是不记录HTTP请求的，这样很不方便HAProxy问题的排查与监控。通过此选项可以启用日志记录HTTP请求。
option forwardfor：如果后端服务器需要获得客户端的真实IP，就需要配置此参数。由于HAProxy工作于反向代理模式，因此发往后端真实服务器的请求中的客户端IP均为HAProxy主机的IP，而非真正访问客户端的地址，这就导致真实服务器端无法记录客户端真正请求来源的IP，而X-Forwarded-For则可用于解决此问题。通过使用forwardfor选项，HAProxy就可以向每个发往后端真实服务器的请求添加X-Forwarded-For记录，这样后端真实服务器日志可以通过“X-Forwarded-For”信息来记录客户端来源IP。
option httpclose：此选项表示在客户端和服务器端完成一次连接请求后，HAProxy将主动关闭此TCP连接。这是对性能非常有帮助的一个参数。
log global：表示使用全局的日志配置，这里的global表示引用在HAProxy配置文件global部分中定义的log选项配置格式。
default_backend：指定默认的后端服务器池，也就是指定一组后端真实服务器，而这些真实服务器组将在backend段进行定义。这里的htmpool就是一个后端服务器组。
option redispatch：此参数用于cookie保持的环境中。在默认情况下，HAProxy会将其请求的后端服务器的serverID插入cookie中，以保证会话的session持久性。而如果后端的服务器出现故障，客户端的cookie是不会刷新的，这就会出现问题。此时，如果设置此参数，就会将客户的请求强制定向到另外一台健康的后端服务器上，以保证服务正常。
option abortonclose：如果设置了此参数，可以在服务器负载很高的情况下，自动结束当前队列中处理时间比较长的连接。
-balance：此关键字用来定义负载均衡算法。目前HAProxy支持多种负载均衡算法，常用的有如下几种：
cookie：表示允许向cookie插入SERVERID，每台服务器的SERVERID可在下面的server关键字中使用cookie关键字定义。
option httpchk：此选项表示启用HTTP的服务状态检测功能。HAProxy作为一个专业的负载均衡器，它支持对backend部分指定的后端服务节点的健康检查，以保证在后端backend中某个节点不能服务时，把从frotend端进来的客户端请求分配至backend中其他健康节点上，从而保证整体服务的可用性。
option httpchk的用法如下： option httpchk method uri version 其中，各个参数的含义如下：
check：表示启用对此后端服务器执行健康状态检查。
inter：设置健康状态检查的时间间隔，单位为毫秒。
rise：设置从故障状态转换至正常状态需要成功检查的次数，例如，“rise 2”表示2次检查正确就认为此服务器可用。
fall：设置后端服务器从正常状态转换为不可用状态需要检查的次数，例如，“fall 3”表示3次检查失败就认为此服务器不可用。
cookie：为指定的后端服务器设定cookie值，此处指定的值将在请求入站时被检查，第一次为此值挑选的后端服务器将在后续的请求中一直被选中，其目的在于实现持久连接的功能。上面的“cookie server1”表示web1的serverid为server1。同理，“cookie server2”表示web2的serverid为server2。
weight：设置后端真实服务器的权重，默认为1，最大值为256。设置为0表示不参与负载均衡。
backup：设置后端真实服务器的备份服务器，仅仅在后端所有真实服务器均不可用的情况下才启用。
用nginx反代后端的两台tomcat主机，做动静分离，如果是jsp结尾的就发往后端，否则就交给nginx处理。
在两台tomcat主机上创建应用
nginx配置
则动静分离就实现了，并且我们还基于uri实现了会话粘性
随着网站、应用访问量的增加，一台服务器租用已经不能满足应用的需求，而需要多台服务器集群，这时就会用到负载均衡，那么负载均衡优点是什么呢呢，今天南昌壹基比小小喻下面为大家讲解一下：
服务器负载均衡有哪些优点：
• 负载均衡优化了访问请求在服务器组之间的分配，消除了服务器之间的负载不平衡，从而提高了系统的反应速度与总体性能；
• 负载均衡可以对服务器的运行状况进行监控，及时发现运行异常的服务器，并将访问请求转移到其它可以正常工作的服务器上，从而提高服务器组的可靠性采用了负均衡器器以后，可以根据业务量的发展情况灵活增加服务器，系统的扩展能力得到提高，同时简化了管理。
负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。
一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。当Web服务器为图像服务、SSL（安全套接层）会话或数据库事务而进行优化时，负载均衡器可以体现特别的价值。
当需要进行服务器升级或系统维护时，保证稳定的服务器退出服务以避免服务中断。当选定某台服务器要退出服务后，将不会将任何新的用户分配到该服务器。但是，它可以要该服务器完成对当前用户的服务。从而保证了无中断的优质服务，并且简化了服务器群的管理。
智能的服务器服务恢复：
将重新启动的服务器应用到服务中时，避免新服务器因突然出现的流量冲击导致系统故障是非常重要的。所以，在将新服务器引入服务器群时，将逐渐地增加分配到该服务器的流量，直至达到其完全的处理能力。从而不仅保证用户在服务器退出服务时，同时还保证服务器在启动期间以及应用程序开始时，均能获得不间断服务。
