前言
Kubernetes 的负载均衡，和 Istio（服务网格）流量分配，对使用的网络协议/客户端都是有些要求的，不是说随便一个网络协议、随便一个客户端都能直接通过 Kubernetes 实现负载均衡/流量分配。
Kubernetes 集群的服务发现与内部负载均衡
Kubernetes 的内部服务发现是基于 DNS 解析实现的，默认情况下解析到的是一个稳定的虚拟 IP 地址（Service），该虚拟 IP 再通过 kube_proxy 将流量均衡到后端的 Pods 上。
Pod 的 Ip 可能会随着 Pod 的重建而变动，但 Service 的 IP 是稳定的。
上面讲到的这个稳定 IP 地址，就是一个 ClusterIP 类型的 Service，这个 Service 根据 kube-proxy 的代理模式的不同，有不同的表现：
- userspace 模式（最老，性能差）
- iptables 模式（性能适中，当前默认）：通过 Iptables 实现的一个四层（TCP）NAT，kube_proxy 只负责创建 iptables 的 nat 规则，不负责流量转发。
- 这种模式下流量的负载均衡很差劲。往往造成多个副本时“一 Pod 有难，多 Pod 围观”。。。
- ipvs 模式（最新、性能与负载均衡兼得）：可通过
--ipvs-scheduler指定负载均衡算法，有多种算法可选，详见 ipvs-based-in-cluster-load-balancing
这个代理模式是通过 kube-proxy 参数 --proxy-mode 指定的，
另外也可以使用 Headless Service，通过 DNS 的 SRV 记录将 Pod IPs 直接暴露给应用，由应用自己进行负载均衡。这种方式直接绕过了 Service 的虚拟 IP 与负载均衡功能。
Istio 流量切分
Istio 的流量切分有三种方法：
- 使用 http headers 中的 host 作为元信息进行流量切分（http/grpc/websocket）
- 使用 tcp 的 ip 和 port 进行流量分配
- 使用 tls 协议的 SNI 值进行流量分配
因此支持得最好的显然只有 http/tls，其他协议基本只能在第四层应用层进行流量分配，比较鸡肋了。