容器是运行在操作系统上的单个进程,应用需要通过多个容器提供服务,这样就组建成了集群,那么对外仍然需要通过统一接口提供服务,从而屏蔽集群内部的相关容器变化,这样就需要负载均衡进行相关操作。现在企业产品以HAproxy实现负载路由和均衡的功能,比如PCF、openshift和阿里飞天、华为产品等。
当容器启动时,将相关信息注册到一个统一的管理中心比如etcd中,在HAProxy中需要有进程监听etcd中的集群信息变化,当有集群变化时,监听进程会自动修改HAproxy的backend相关信息,这样就能够实现负载均衡的自动监控和修改。
在集群对外提供服务时,在负载均衡之前,一般还会使用域名形式来访问,当按照域名发送请求到PaaS平台的某个router所在的节点时,router记录有域名和IP:port 的映射关系,于是将请求转发到平台内部对应的 IP:port 上面,然后通过haproxy再路由到某个容器进行服务。
F5 是硬负载,nginx和haproxy是软负载。PaaS平台的负载均衡需要感知PaaS平台的基础设施的变化,硬负载相对封闭,这里不做考虑。nginx功能较多,可以做web服务器也做lb,而haproxy专注于做lb,在转发性能上更优。
首先,PaaS平台均会有个注册中心(etcd,zookeeper,consul),每个容器的创建和销毁,均会在注册中心里记录。注册中心中会有容器的ip地址,对应的服务,对应的应用以及所在宿主机的位置。Paas平台会把注册中心的相关信息机如dns记录同步到各个计算节点的metadata中。haproxy的监听进程监听metada里的相应的服务变化,根据用户需求做tcp或者http或者udp的转发。
同意楼总的意见。
paas的负载均衡这个范畴有点大,可以是传统paas也可以是以容器为代表的新一代paas,情况不一样。
f5属于硬件方案,一般在物理机X86和虚拟化时代用于LB比较多,性能好,价格高;nginx一般用户web场景,反向代理等,haproxy倒是专业的软LP。
需要看具体场景。
像f5 也有k8s等这些容器编排平台等集成方案,实现服务的自动发现等。,甚至还有service mesh方案。从简单规模的负载均衡看 无论是软还是硬都可以满足基本要求。例如k8s中的ingress 实际上变成了多node节点入口问题,要么dns简单轮询,要么再加一层f5这样的设备解决多人口本身的健康性或复杂lb以及安全策略等。放大到企业的复杂业务场景,更多复杂adc需求以及更多安全性 可视化等角度,反而类似f5这样的方案更灵活。见过很多用nginx的外面又放一个f5。
收起这里主要补充一下nginx,haproxy之间的选择问题。
nginx:
haproxy
所以,还是要结合自身业务使用场景来选择。
收起