最近降本增效各家玩的都很火,就连汽车企业不去好好造车,却一贯喜欢各种花里胡哨的互联网玩法,最典型的就是这个云厂商买过来玩一段时间,然后打着降本的口号又玩新花样---“迁移降本”,这不各种迁移诱发出各种问题,其中目前最疑惑的就是不同云helm部署出现以下问题。
简述
Jfrog制品库服务从百度专有云迁移到新的阿里专有云上,原本一切进行正常,各种helm配置中的value.yaml配置修改完成,然后helm install 一把完成,然后服务其中正常,页面访问正常,登陆授权看起来没有问题。原本以为可以快速降本增效,却遇见棘手问题,变成了降本增“笑”。
1.页面无任何问题,到jfrog制品库真正用到的是与devops中代码构建时的依赖引用和代码构建过程中使用到的基础资源代理及资源下载中心,如:覆盖面最多的maven,pypi,go proxy,docker,yum,apt等各种资源本地资源,代理资源,聚合资源等。在无需认证的客户端下载资源时候一切正常。
2.当验证docker pull xxx.xxx.com/docker/image:tag -u admin 带有auth认证信息时候,一直提示404 not find,一开始尝试docker login xxx.xxx.com发现输入任意错误认证,返回永远200 OK,然后第一件事情想起来开启了匿名访问,然后关闭后,返回的状态更加明显了。
3.关闭匿名访问后,docker login 此时提示 :authentication is required. 然后测试旧云上的服务输入错误提示:bad 认证,从而表面证明了传入到jfrog后端服务是缺少authentication信息的。这时候马上打开jfrog 服务日志进行验证。
4.通过查看jfrog artifact-request.log日志中发现确实通过客户端GET访问过来的header头信息中没有传递过来授权信息。为何页面能正常访问,因为是POST请求,认证信息放到body里面的,所有没问题。
5.然后接着梳理流量转发过程图如下:
6.然后各种从内部开始抓包tcpdump,服务本身有日志直接看见GET请求头信息中缺少authentication信息。kube-system ingress lb抓包发现头信息中确实缺少authentication信息。
7.到目前位置感觉似乎云SLB缺少转发7层http头信息授权信息。接来下接着抓包查,如果果真如此,那增“笑”成真,大伙见笑了!
结论
果然是阿里云容器集群ingress nginx lb转发的时候出现了问题,将原地址信息及信息头给丢失了。如下如抓包分析得出:
解决方法如下:
ingress configmap配置调整后完成。
apiVersion: v1
kind: ConfigMap
......
data:
compute-full-forwarded-for: "true"
use-forwarded-headers: "true"
参考文档:www.cpweb.top/2306