也可以直接与负载均衡厂商(如F5)进行集成,不需要另外开发。既能满足容器对灵活性的要求,也能保留F5的传统优势。
F5的解决方案包含2个组件,VE(Virtual Edition)和CC(Container Connector)。VE是F5LTM的软件化产品,可以安装在虚拟机上,其功能与硬件设备完全一致。CC是F5的一个开源组件,它以容器的形式部署在Kubernetes集群中,通过读取Kubernetes API获取集群内的服务资源并将其转化为VE上的配置。管理员可以为每一个租户部署一组CC,每组CC独立控制VE上的一个对象配置隔离区域(partition),该partition下的资源完全由该组CC独立控制。兼顾了稳定性、灵活性与安全性。该方案中,负载均衡策略的定义提供多种方式,可以使用Ingress,也可以使用ConfigMap。
采用CC+VE技术,利用CC与Kubernetes通过API进行联动,完全适应容器平台对灵活性的要求;另外,配置上采用ConfigMap定义负载均衡策略,架构上采用VE直接对集群中的POD进行负载分发,减少网络层次,提升负载均衡性能;同时,通过将Kubernetes的Namespace与VE的partition一一对应,实现不同容器租户服务资源的隔离。
K8s发布服务有4种方式,ClusterIp, Nodeport, loadbalancer, externalName
ClusterIp是对容器内部服务调用
Nodeport是提供对外的调用方式,但Ip:port的方式通常不够友好。
Loadbalancer是需要k8s 外部负载均衡工具的支持。
基于Ingress机制可以实现负载均衡,比如用Nginx实现Ingress负载均衡。通常可以使用Ingress机制,辅以DNS实现域名访问。不过需要优化的工作不少。
ExternalName没有详细研究
nodeport 四层协议的适用 中小规模的时候可以使用(ipvs目前不是特别的稳定,个人认为还没到生产可用,我们经常遇见服务没有及时更新的问题,但是是未来的方向)
ingress 七层http和https协议适用 有多种ingress类型
loadbalance 需要自己去开发对接了
Nodeport方式在某些场景上还是存在一些问题的,NodePort的实现方式是通过直接访问计算节点的端口,通过计算节点的iptables来转发请求至pod,而iptables只能基于源IP地址做会话保持,不能基于cookie等信息。另外,如果F5在没有开启X-Forwarded-For的情况下,由于计算节点接收到请求的源IP都为F5的地址,所以基于iptables的源地址会话保持机制,会将访问的所有流量都转发到一个pod中,导致在有多个pod的情况,只有一个pod有业务访问流量,其他pod没有负载(实际情况下,其他pod也有流量,但是流量非常少),不能做到流量负载均衡;
Ingress方式适合的场景会更多,可以通过Nginx或者HAProxy实现负载均衡,不过这种方式可能会带来一些额外的工作。如果现有环境中,系统间的接口调用方式不是域名方式的话,就需要接口调用方及提供方更改接口地址为域名地址,同时还需要引入DNS配合。
从我们实际使用情况看,三种方式适用于不同场景。Nodeport适用于需要将服务端口注册到服务注册中心,不需要负载均衡的应用,典型的如使用了Spring Cloud服务治理架构的应用,应用和应用之间通过注册到服务中心的IP+端口通信。Ingress适合于对外的微服务较多,需要收敛到统一对外服务入口的应用,比如有20个微服务,都通过NodePort或者Loadbalance对外服务并不现实,通过Ingress对外提供统一服务入口就变得很有必要了。LoadBalance适用于除上述两种类型应用的其它场景。
收起• Openshift产品推荐通过NodePort类型的Service为某个应用对外暴露一个服务端口。NodePort类型的Service会在集群中的所有节点上监听一个特定的端口,访问任意一个计算机节点的端口,即可访问内部容器中的服务。在集群的所有节点的这个端口都会预留给该应用所用。
• 在F5 VS的Pool Member中配置所有节点,通过Keepalived来实现HA
• 应用系统和用户不用改变现有的访问方式