负载均衡设备哪家好？最好是能适用于金融业的

在金融行业的传统IT基础架构中，专有硬件负载均衡设备（如F5、Radware等）普遍具备功能强、性能高、运行稳定等特点，成为解决应用系统对外提供统一服务的首选方案。近年来，随着OpenStack、Kubernetes等云技术的兴起，应用系统的微服务化、快速迭代对资源的弹性伸缩能力提出了更高的要求，这就要求负载均衡有更好的灵活性和开放性。开源负载均衡软件因其开放的设计，完善的API接口以及对应用灵活部署需求的满足，在金融行业的云环境中逐步推广使用。民生银行在Kubernetes容器平台建设中，探索使用了一种灵活的软件F5解决方案，在利用F5传统优势的同时，也满足了容器应用的高灵活性要求。

Kubernetes服务发布方式及局限性

Service是Kubernetes最核心的资源对象之一，通过它可以为一组具备相同功能的容器应用提供一个统一的访问入口地址，并将请求负载分发到后端的各个容器应用上。这一点与传统IT基础架构中F5等负载均衡设备将访问请求负载分发到后端功能相同的应用上类似，Kubernetes集群中每个节点上运行的kube-proxy其实就是一个智能的软件负载均衡器，它负责把对Service的请求转发到后端的某个pod实例上，并在内部实现服务的负载均衡与会话保持机制。Service被分配了一个全局唯一的虚拟IP地址，称为ClusterIP。但ClusterIP只能实现集群内部的访问（即东西向服务），对于需要通过外部IP对外提供访问（即南北向服务）的场景，Kubernetes提供了三种主要方案，分别是NodePort 、LoadBalancer 、Ingress。

1 NodePort

NodePort 的实现方式是在每个节点上为需要外部访问的Service开启一个对应的TCP监听端口，外部系统用:可以从集群外部访问一个NodePort服务，NodePort 服务会路由到 ClusterIP ，通过kube-proxy转发至后端的容器，完成对服务的访问。NodePort的方式是解决服务暴露问题最直接的做法，其配置和维护都很简单，但它依赖于kube-proxy，目前仅支持轮询算法以及源地址会话保持。在负载均衡的其他特性方面还有一定缺陷。另外，NodePort占用node节点一个独立的端口，限制了集群中暴露服务的数量。且在实际使用过程中定义一个NodePort，需要在Kubernetes集群中的所有节点上开通此端口的入访能力，因此一般会结合集群外的负载均衡设备，与kube-proxy形成两级负载均衡的架构，对性能会产生一定影响，同时增加成本。

2 LoadBalancer

LoadBalancer 是Kubernetes深度结合云平台的一个组件，使用它构建服务时，实际上是向底层IaaS申请创建一个负载均衡来实现。Ia