摘要：近日发现一个问题应用程序在返回的时候丢失了原先访问的端口。于是怀疑问题出在这几个上。在中，在描述的时候提到，其返回的必须是。修改的端口为靠谱这个方法比较靠谱，只要将的端口改成就没有问题了。使用靠谱使用提供的，将的值做文本替换。
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解决办法 请求时带上x-forwarded-port(不靠谱)-- cat /etc/nginx/nginx.conf
查看Nginx Ingress配置文件发现如果最初请求的时候带上x-forwarded-port的话，就能够改变它传递到后面的值，但是这有两个问题：
通过浏览器访问时，你没有办法加上这个header
这个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的值做文本替换。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/32668.html
摘要：近日发现一个问题应用程序在返回的时候丢失了原先访问的端口。于是怀疑问题出在这几个上。在中，在描述的时候提到，其返回的必须是。修改的端口为靠谱这个方法比较靠谱，只要将的端口改成就没有问题了。使用靠谱使用提供的，将的值做文本替换。 github 近日发现一个问题：应用程序在返回Http Redirect的时候丢失了原先访问的端口。比如，我们这样访问http://IP-A:Port-A/ap...
摘要：参与者流量来自于内部系统和外部流量，其中大部分来自于外部流量。水平扩容服务的水平扩容重要性不言而喻。 背景 目前微店中台团队为了满足公司大部分产品、运营以及部分后端开发人员的尝鲜和试错的需求，提供了一套基于图形化搭建的服务端接口交付方案，利用该方案及提供的系统可生成一副包含运行时环境定义可立即运行的工程代码，最后，通过 某种serverless平台 实现生成后代码的部署、CI、运行、反...
摘要：中暴露服务访问自己实现了一个，它本质上是包装了，在真正创建负载均衡器上它会调用来创建自身的。 Kubernetes概述 最近的一年，kubernetes的发展如此闪耀，正被越来越多的公司采纳用于生产环境的实践。同时，我们可以在最著名的开发者问答社区StackOverflow上看到k8s的问题数量的增长曲线（2015.5-2016.5），开发者是用脚投票的，从这一点看也无疑证明了k8s的...
摘要：中暴露服务访问自己实现了一个，它本质上是包装了，在真正创建负载均衡器上它会调用来创建自身的。 Kubernetes概述 最近的一年，kubernetes的发展如此闪耀，正被越来越多的公司采纳用于生产环境的实践。同时，我们可以在最著名的开发者问答社区StackOverflow上看到k8s的问题数量的增长曲线（2015.5-2016.5），开发者是用脚投票的，从这一点看也无疑证明了k8s的...
摘要：，托管于腾讯云容器平台容器编排工具。适配我们目前的服务部署在腾讯云托管，节点使用核的网络增强型机器，所有的后端服务都以部署，集群外部署高可用支持集群内服务发现，数据库以为主，消息队列采用。 距离2017年的见闻技术架构调整接近2年，随着业务线的发展，见闻技术部的项目数量、项目架构类型、基础设施规模、服务变更频率都在不断地增长，带给SRE的挑战是如何能更快地助力于开发人员更快更稳定地部署...
阅读 873·2021-10-19 11:42
阅读 2743·2021-10-11 10:58
阅读 2743·2021-09-10 10:51
阅读 484·2021-09-09 09:33
阅读 2006·2021-09-04 16:46
阅读 1573·2021-09-01 10:43
阅读 2618·2019-08-30 12:43
阅读 3410·2019-08-30 11:24
