k8s容器和虚拟机负载均衡方案分析
负载均衡方案
先说结论：直接使用k8s的service
原因：我们的项目较为轻量，并且实现的是容器级别的负载均衡，这点k8s默认支持的ipvs策略就实现很好。其他更多负载均衡策略着重于node级别或service级别。我们的项目并不需要。
内部负载均衡（k8s自带）
k8s的内部服务发现是基于dns解析完成的
默认解析到一个稳定虚拟 IP （Service），该虚拟 IP 再通过 kube_proxy 将流量均衡到后端 Pods 上。 （ Pod 的 IP 可能会随着 Pod 的重建而变动，但 Service 的 IP 是稳定的 ）
四层负载均衡 （容器级别的负载均衡）
负载均衡器用 ip+port 接收请求，再直接转发到后端对应服务上；
工作在传输层 ；
客户端和服务器之间建立一次TCP连接，而负载均衡设备只是起到一个类似路由器的转发动作。
基本原理都是：维护一个端口映射表，将对service请求按照策略分配给不同pod。
官方提供三种模式：
userspace模式：性能差，维护一个iptables映射表，在用户态查询，需要来回切换用户态和内核态，消耗大。
iptables模式：性能适中，将对于iptables映射表的查询全部放在内核态，减少了用户态和内核态切换的时间消耗，但是当添加大量的iptables rules的时候，性能依然会变差。
ipvs模式：性能好，维护一个哈希表作为映射。1.9版本之后的k8s默认使用该策略
七层负载均衡（service 级别的负载均衡）
七层负载均衡需要建立两次 TCP 连接，
client 到 LB（loadBalancer），LB根据消息中的内容( 比如 URL 或者 cookie 中的信息 )来做出负载均衡的决定；
然后，建立 LB 到 server 的连接。
ingress
这是ingress的工作流程。通过不同域名来分配不同service
外部负载均衡（使用第三方组件）
根据chatgpt的回答，有大量开源插件能够实现负载均衡。但是大多数专注于七层负载均衡（service级别）。
HAProxy：很多大型网站都在使用的组件，很好支持七层和四层负载。可以说是免费LB的最优选择。但是对于我们的项目（负载较小）有些“杀鸡用牛刀”。
持久化策略
通过导出历史命令文件，在下次启动时执行这个文件。
想法：导出history文件，下次开启容器时执行。
history可以加密后导出给用户，可以存储在主机。
开放两种容器，一种支持持久化存储，一种不支持。
开放两种容器，一种支持持久化存储，一种支持导出历史文件。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。也可以邮件至 2738430398@qq.com
未找到相关的 Issues 进行评论
请联系 @Gohoy 初始化创建