我已经在名为main_pod的pod中设置了这些环境变量。
$ env
HTTP_PROXY=http://myproxy.com
http_proxy=http://myproxy.com我还有另一个模式为sub_pod-{number}的动态pod，它附加了一个名为sub_pod-{number}的服务。
因此，如果我在main_pod中添加NO_PROXY=sub_pod-1环境变量，URL为http://sub_pod-1:5000/health_check的请求将成功运行，因为它不会通过代理进行定向，这很好。
但是我希望这个过程是动态的。sub_pod_45可能会在运行时产生，sub_pod-1可能会被销毁。有没有比为每个pod的创建/销毁更新NO_PROXY更好的方法来处理这个问题？
是否有任何资源/网络策略/出口规则可以让我告诉pod，如果域名属于kubernetes服务，不要通过代理服务器路由它？
或者我可以简单地在NO_PROXY env变量中使用regex或glob模式，比如NO_PROXY=sub_pod-*？
编辑
nslookup的结果
root@tmp-shell:/# nslookup sub_pod-1
Server: 10.43.0.10
Address: 10.43.0.10#53
Name: sub_pod-1.default.svc.cluster.local
Address: 10.43.22.139当no_proxy=cluster.local，
使用FQDN请求时绕过代理
res = requests.get('http://sub_pod-1.default.svc.cluster.local:5000')
仅使用服务名请求时，代理未绕过
res = requests.get('http://sub_pod-1:5000') #我希望这能成功
我不想要求我的开发人员更改应用程序以使用FQDN。
集群是否有办法识别URL是否解析为网络中存在的服务，如果发生这种情况，是否不将请求路由到代理？
1条答案
按热度按时间aamkag611#
支持
http_proxy环境变量的库通常也支持一个匹配的no_proxy来命名那些不应该被代理的东西。确切的语法似乎在不同的语言和库中有所不同，但是设置no_proxy=example.com导致anything.example.com也不被代理似乎是普遍的。这是相关的，因为Kubernetes DNS系统根据集群名（默认情况下为
cluster.local）在域中创建其名称。例如，服务DNS名称的规范形式为service-name.namespace-name.svc.cluster.local.，其中service-name和namespace-name是相应Kubernetes对象的名称。我怀疑这意味着做两件事会起作用：
1.设置环境变量
no_proxy=cluster.local;以及1.调用其他服务时，请确保使用FQDN形式
service.namespace.svc.cluster.local。Pod具有类似的命名，但位于
pod.cluster.local子域中。cluster.local值可在群集级别配置，在您的环境中可能有所不同。