K8s NodePort Service丢失Authorization请求头致401问题

这是MacOS环境下以Docker为默认驱动运行minikube时的已知行为，和业务服务逻辑、K8s Service配置无关。
触发原因很明确：执行minikube service <servicename> --url时启动的本地访问隧道内置了一层透明代理，这层代理会默认拦截、剥离所有经过它转发的HTTP请求里的Authorization请求头，根本不会把这个头传给后端Pod，所以所有依赖Bearer Token做鉴权的接口都会直接返回401。
3010端口的接口本身不校验Authorization头，哪怕头被剥了也能正常返回，才会让人误以为只有3000端口的链路有问题，实际上两个端口走的转发链路完全一致，所有经过这个隧道、需要校验Authorization头的服务都会复现这个问题。

直接进minikube节点内部，绕过外层隧道代理请求Service的ClusterIP，带正确鉴权头就能拿到正常响应，一步排除业务侧问题：

# 进入minikube节点shell
minikube ssh
# 替换成你自己的Service ClusterIP，节点内直接发起请求
curl http://<service-cluster-ip>:3000/info/ping --header 'Authorization: Bearer blah'

如果上面的请求能返回正常的ping响应，就可以完全确认是minikube隧道代理剥头导致的故障。

• 临时测试场景：直接用kubectl port-forward绕过minikube的service隧道，不需要改任何集群配置：

  # 把本地3000端口映射到目标Service的3000端口
  kubectl port-forward svc/<3000端口对应的Service名> 3000:3000
  # 本地直接请求localhost地址就行，Authorization头不会被篡改或剥离
  curl http://127.0.0.1:3000/info/ping --header 'Authorization: Bearer blah'
  

• 长期本地调试场景：重建minikube集群的时候把驱动从默认Docker换成MacOS原生的HyperKit驱动，这个驱动下的service转发逻辑没有内置拦截Authorization头的代理层，直接用minikube service生成的地址就能正常测试带鉴权的接口。
• 不想调整集群配置的场景：测试的时候临时把鉴权头换成自定义头（比如X-Dev-Authorization），在服务侧加一行兼容逻辑：如果没读到标准Authorization头，就读这个自定义头的值做鉴权，测试完删掉这段兼容逻辑就行。

内容的提问来源于stack exchange，提问作者Josh Klein