需求背景
- 服务 A 部署在 K8S 中，集群外的服务 B 需要调用服务 A，同时调用服务 A 的端口是指定了的，必须是 5000，无法修改。
- K8S 集群是客户的，我们只能部署服务，不能修改集群。
- 服务 A 需要得到真实的客户端 IP。
解决方案一
通过 Nodeport 的方式暴漏服务 A。
5000 端口不在 Nodeport 默认端口范围内（30000-32767）。 修改 Nodeport 的端口范围，需要修改 kube-apiserver 配置，行不通。
解决方案二
服务 A 的 Pod 配置hostNetwork: true。
服务 A 内部还有其他进程，监听了端口，容易和节点的其他进程冲突。同时还会暴漏服务 A 内部的其他服务。
解决方案三
新增一个 nginx Pod，并配置hostNetwork: true，dnsPolicy: ClusterFirstWithHostNet，通过七层代理来转发流量到服务 A 的 service。
服务 B 调用服务 A 时，原本是使用服务 A 的 ssl 证书。但是在七层代理下，会使用这个 nginx 的证书。而证书是服务 A 生成的，不太好自动配置给 nginx。
解决方案四
新增一个 nginx Pod，并配置hostNetwork: true，dnsPolicy: ClusterFirstWithHostNet，通过四层代理来转发流量到服务 A 的 service。nginx 启用 proxy protocol，用来传递真实的客户端 IP。
proxy protocol 需要后端应用支持，nginx、apache 这些都是支持了的，此方案可行。
解决方案五
新增一个 ubuntu Pod，并配置hostNetwork: true，通过 iptables 来转发流量。
- 如果客户的 K8S kube-proxy 是 IPVS 方案
- 将服务 A 通过 nodeport 暴漏到 30001，同时设置 iptables，将 5000 端口流量转发到 30001端口。
- 如果客户的 K8S kube-proxy 是 iptables 方案
- 由于在nat表里面对数据包进行dnat操作过后，数据包就不再执行nat表里面的其它规则，所以不能将流量转发到 service、nodeport，只能直接转发到服务 A 的 pod ip。
- 由于 pod ip 不固定，假如 pod 重新创建，就需要更新 iptables 规则里的 pod ip，所以需要当前服务去 watch pod。
针对方案四中，后端应用不支持 proxy protocol 协议的情况，可以用这个方案。实现较为复杂。
