应用容器化改造难点之：如何选择对外发布服务的方式，Nodeport、Ingress和LoadBalance如何选择？

也可以直接与负载均衡厂商（如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
• 应用系统和用户不用改变现有的访问方式

一般不使用NodePort，NodePort会将端口扩散到整个集群节点。

Ingress与LoadBalancer是配合关系，如果需要发布7层协议，通过Ingress+LB方式，如果是4层协议，则直接使用ClusterIP+LB即可。