之前记录过k8s中ingress以及nginx获取客户端真实IP的文章,我司这个项目架构和这个环境一样,因为遗留问题,导致这个架构比较乱,为了更清晰的记录,还是画个图吧。
可以看到以上配置跳来跳去,这也是历史遗留原因,首先比如www.baidu.com/lizexiong/test到达lb,lb根据判断后把请求转给ingress,ingress根据lizexiong/test,然后反向定量用户输入的,最后转给pod nginx,转了2次。
为什么要先强调一下拓扑。是因为突然间多了一个需求。环境原因,部分url不能提前公开对外,但是我司这部分业务需要在线上环境测试然后对外。但是如果发布肯定就对外了,所以这里想到了白名单或者安全组或者防火墙。只开放予许访问的IP。所以有了以下思路。
1.LB不能做安全组,因为安全组上面有很多项目,会受到影响,除非用7层防火墙有可能,但是要钱,此方案pass。
2.Ingress上设置,百度看了一下设置方式,怕会影响所有项目,偷懒,不想准备测试环境,pass了
3.Pod的nginx上设置allow ip,此方案可行,最后引出一个超级麻烦的事情。(见下节)
4.使用小域名(在正式域名外设置一个其他专门测试的域名),但是被运营否认了。
那就选方案3吧,看着最简单,还不影响,还不需要准备环境,于是就在location里配置了allow 1.1.1.1,予许我司IP访问,自己简单测试了2次,以为解决了。
结果测试人员去测试的时候说,一会正常,一会403,结果自己去看,果然如此。
查看了ingress日志,是正常的。也获取到了客户端的真实IP,怎么会不对呢。
于是查看pod nginx的日志,结果发现,访问的时候有k8s node主机的IP。
只要日志出现k8s node主机ip的时候,访问就403,因为这个IP我没有加入到allow白名单里面。
后面排查了很久,新建了一个集群,所有环境相同(这里说的是配置,版本,容器),但是新建的这套集群却一点没问题。
后面仔细检查版本,配置一些内容,最后突然想到,唯一不同的就是出问题的集群有三个node节点,没有出问题的只有一个k8snode节点。
最后仔细想想,仔细看看之前配置,到ingress之后,ingress还会做一次跳转,会剥离lizexiong/test的url,到pod nginx上只剩下 /了,如果ingress和pod nginx不在同一台node上,跳转的时候出去请求的IP那不就是k8s nodeIP吗?找到原因。
后面就准备设置亲和性和pod local模式。
但是又要各种测试,不是要了老命嘛,而且,每次取消白名单对外的时候都会很麻烦。
所以使用方案2,ingress上配置,20分钟解决。差点吐了,还是不能太偷懒。