K8S Ingress环境下，Http Redirect端口丢失问题

github

近日发现一个问题：应用程序在返回Http Redirect的时候丢失了原先访问的端口。好比，咱们这样访问http://IP-A:Port-A/app/delete，这个url会响应302，可是它返回的Response header Location里丢失了端口，正确的结果应该是这样：http://IP-A:Port-A/app/index，但返回的倒是：http://IP-A/app/index，把端口丢失了。

基本状况

咱们的部署状况是这样的：

• 部署了Nginx Ingress，并使用NodePort的方式把Nginx Ingress Service暴露出来
• 配置了App的Ingress

服务器信息：

Server Name	NAT Server	K8S Node	Nginx Ingress Svc	Nginx Ingress Pod	App Svc	App Pod
IP	IP-A	IP-B	IP-C(Cluster IP/VIP)	IP-D(Cluster IP)	IP-E(Cluster IP/VIP)	IP-F(ClusterIP)
Port	Port-A	Port-B(Nginx Ingress Svc's NodePort)	Port-C	80(Container Port)	Port-E	Port-F

其实以上也不全是服务器，其中有两个K8S Service不是服务器，它们是VIP，关于这个请看K8S - Using Source IP一文，当访问http://IP-A:Port-A/app/delete的时候，这个请求从左到右贯穿了这些服务器。

顺便一提上面的NAT Server是一台普通的服务器，咱们用它作了PAT使咱们的Nginx Ingress可以被外网访问到。

观察

咱们使用以前提到过的Echo Server来观察透过Ingress访问Echo Server时传递给Echo Server的Request header：http://IP-A:Port-A/echo-server，获得了这些有趣的Request header：

host=IP-A:Port-A
x-original-uri=/echo-server
x-forwarded-for=IP-B
x-forwarded-host=IP-A:Port-A
x-forwarded-port=80
x-forwarded-proto=http

而后直接访问Echo Server Svc，发现是没有上面提到的x-*Request header的。因而怀疑问题出在这几个header上。

名词解释

来说一下这些头各自表明什么意思。

• x-forwarded-for，client访问proxy的时候，client的ip。
  在这里之因此是K8S Node的IP，是由于在Nginx Ingress看来请求是来自K8S Node的（好好看看以前提到的K8S - Using Source IP一文），在这以前的NAT它是不知道的。
• x-forwarded-host，client访问proxy的时候，访问的原始host。
• x-forwarded-proto，client访问proxy的时候，访问的原始http scheme。
• x-forwarded-port，client访问proxy的时候，访问的port。
• x-original-uri，查不到权威资料。

注意，前三个是事实标准，MDN有收录，x-forwarded-port和x-original-uri彷佛是私有扩展。

实验

找一个趁手的Http Request工具（我用的是Postman），记得把Follow redirect关掉，而后模拟Nginx请求的方式（就是把上面提到的x-* header带上/去掉/修改值）直接请求App Svc。

结果发现x-forwarded-port是Response header Location的关键，即若是x-forwarded-port=Port-A的话，Location就会带上正确的端口。

分析

Redirect url是如何构造的

能够推测，App利用了host和x-forwarded-*这些header来构造redirect url。

在Java Servlet API中，在描述HttpServletResponse#sendRedirect的时候提到，其返回的URL必须是Absolute URL。

Tomcat的org.apache.catalina.connector.Response的toAbsolute方法负责构造Absolute URL。

那么它又是如何知道选用什么Port的呢？这个和RemoteIPValve有关，有兴趣的话你能够查阅相关文档。

上面只是讲了Tomcat是如何构造redirect url的，但这个方法不是标准的，不一样的容器有各自的实现，毕竟Java Servlet API也没有规定如何构造Absolute URL。

我以前也写过一篇相关话题的文章《反向代理使用https协议，后台tomcat使用http，redirect时使用错误协议的解决办法》，你能够看一看。

为什么x-forwarded-port是80

那么问题来了，我明明访问的是IP-A:Port-A，为什么Nginx取到的值是80？

这是由于在整个请求链路的前段：NAT Server > K8S Node > Nginx Ingress Svc 都是在第4层工做的，能够认为它们干的事情都是NAT，Nginx Ingress Pod是不知道这些服务器/网络节点的端口，所以它只能把本身的端口80（容器内Port）给x-forwarded-port。

关于这个逻辑你能够查看Nginx Ingress的配置文件就可以知道了：

kubectl -n kube-system exec -it <nginx-ingress-controller-pod-name> -- cat /etc/nginx/nginx.conf

解决办法

请求时带上x-forwarded-port(不靠谱)

查看Nginx Ingress配置文件发现若是最初请求的时候带上x-forwarded-port的话，就可以改变它传递到后面的值，可是这有两个问题：

1. 经过浏览器访问时，你没有办法加上这个header
2. 这个header通常都是反向代理加的，也就是在咱们的Nginx Ingress以前还得有一个反向代理

因此这个方法很差。

修改tomcat的代码(不靠谱)

虽然能够经过修改tomcat的代码，让它从x-forward-host/host header来取port，可是这个不现实。

修改NAT Server的端口为80(靠谱)

这个方法比较靠谱，只要将NAT Server的端口改为80就没有问题了。

事实上，若是你直接访问K8S Node的话（NodePort方式），也是要将NodePort设置为80，记得前面说的吗？Nginx Ingress没法知道上层NAT的端口。

总而言之，就是你最初请求的URL不能是80以外的端口，必须是http://some-ip/app才能够。

使用Nginx Ingress Annotations(靠谱)

使用Nginx Ingress提供的Proxy redirect annotations，将Location的值作文本替换。