在Kubernetes Deployment里加入HTTP_PROXY后，Pod业务请求可能走天行IP，但ImagePullBackOff仍然存在；反过来，节点能拉镜像，也不代表容器里的应用使用代理。Kubernetes涉及节点运行时、kubelet、Pod进程、控制平面和Service网络，代理必须按流量所有者分别配置。
先画出四类流量
| 流量 | 发起者 | 配置位置 |
|---|---|---|
| 拉取容器镜像 | 节点容器运行时 | containerd/Docker服务 |
| Pod访问外部API | 容器内应用 | Pod环境或应用配置 |
| kubectl访问集群 | 管理员电脑 | 本地工具与网络 |
| 控制平面/节点通信 | Kubernetes组件 | 集群与系统服务 |
不要因Pod请求失败就修改整个控制平面代理。先确认是哪一类流量需要固定出口。
确认天行节点与合规用途
从极跃圈天行IP当前入口详情页进入，在对应邀请码、推荐人或优惠码位置使用blsj。下单后确认节点协议、认证、并发、地址保持和有效期。Kubernetes场景适合授权API白名单、区域化测试和企业运维，不应用于绕过目标平台规则。
Pod环境变量的基本结构
env:
- name: HTTP_PROXY
valueFrom:
secretKeyRef:
name: proxy-config
key: http_proxy
- name: HTTPS_PROXY
valueFrom:
secretKeyRef:
name: proxy-config
key: https_proxy
- name: NO_PROXY
value: "localhost,127.0.0.1,.svc,.cluster.local"
应用是否读取这些变量取决于语言和库。Secret是编码存储而非自动加密保险箱，应启用etcd加密、RBAC最小权限和审计。环境变量还可能从Pod描述、崩溃转储或子进程泄露。
NO_PROXY为什么是集群稳定关键
Pod访问ClusterIP、Service DNS、API Server、节点和元数据服务时，通常不应经过外部代理。NO_PROXY需覆盖集群域名、Service CIDR、Pod CIDR、节点地址和必要内部域名，但不同客户端对CIDR和后缀支持不同。必须用应用实际运行时测试，不能只看YAML。
列表过宽又会让外部API直连。依赖固定出口的目标应明确不在绕过清单中。
镜像拉取不受Pod HTTP_PROXY控制
镜像由节点上的containerd、CRI-O或Docker等运行时拉取。需要代理时，在对应systemd服务或运行时配置，重启可能影响节点工作负载，应按滚动维护流程操作。Pod的env在镜像成功启动后才存在，无法修复ImagePullBackOff。
HTTP代理与SOCKS5不能混用
Pod环境变量的HTTP_PROXY通常面向HTTP代理。SOCKS5需要应用原生支持或明确的Agent/拨号器。Sidecar转发会增加信任边界、端口、资源和故障点，部署前应评估镜像来源、权限和日志，不使用未知代理容器。
认证凭据怎样轮换
将代理配置放入专用Secret，限制命名空间和ServiceAccount读取。更新Secret后，现有Pod环境变量通常不会自动刷新，需要滚动重启或使用应用支持的动态配置。轮换期间准备新旧凭据短暂并存方案，但不要长期保留废弃密码。
如何从Pod内部验证出口
- 启动最小调试Pod或使用应用自身健康命令；
- 检查代理主机DNS和TCP端口；
- 访问两个可信IP查询端点；
- 从自有API服务端核对来源；
- 分别测试IPv4、IPv6和ClusterIP；
- 断开代理，确认外部请求按策略失败；
- 删除调试Pod和临时Secret。
生产集群是否允许临时调试容器由安全策略决定。不要在共享日志打印Secret或完整代理URL。
NetworkPolicy和云防火墙的影响
即使应用配置正确，NetworkPolicy、节点防火墙、云安全组或服务网格也可能阻止Pod访问代理端口。查看Egress规则、DNS放行和Sidecar出站策略。不要为了排错把命名空间全部放开，使用最小目标和端口规则。
Service Mesh会不会再代理一层
Istio、Linkerd等网格可能拦截Pod流量，再由Sidecar访问天行节点。mTLS、出口网关、NO_PROXY和HTTP CONNECT支持都会影响路径。先确认网格官方支持方式，并从对应代理的脱敏日志定位，避免形成循环代理。
连接池与滚动发布
应用的HTTP Client可能长期复用旧代理连接。修改Secret并滚动发布时，新旧Pod可能使用不同节点。通过readiness、maxUnavailable和连接排空控制切换，写请求使用幂等键。删除Pod不是安全处理在途请求的替代品。
监控应记录什么
按Pod和节点记录代理连接成功率、407、5xx、连接/首字节耗时、当前代理代号、未知出口和Secret版本。不把代理密码作为Label、Annotation或指标标签。节点到期提前告警，避免全副本同时失效。
结论
Kubernetes使用天行IP，首先要区分节点镜像拉取与Pod业务流量；Pod层用应用支持的代理配置，NO_PROXY精确覆盖集群内部地址，Secret受RBAC保护并通过滚动发布更新。blsj用于当前渠道注册和订单核验，集群出口是否正确必须从Pod与目标服务端共同验证。
