公司用 Kubernetes 搭了套容器平台，服务跑得稳，但问题来了：测试环境部署在内网，外部合作方没法直接访问接口，每次调试都得靠开发打包日志、转发请求，效率低还容易出错。
容器平台本身不缺能力，缺的是通路
企业级容器管理平台比如 OpenShift 或 Rancher，能把应用编排、扩缩容、健康检查全管起来。可一旦这些服务部署在私有网络里，外部网络就像隔着一堵墙。这时候，光有强大的调度能力也没法让接口被调用。
有个做法是把服务暴露到公网 IP，但安全风险大，防火墙规则复杂，运维稍不留神就可能开错端口。而且很多企业内网根本就没有固定公网出口，动态 IP 加 NAT，外部连接几乎不可能稳定建立。
内网穿透不是小工具，而是关键链路
我们给一个客户搭过方案：他们在内网部署了基于 K8s 的微服务集群，前端、后端、中间件全在容器里跑。为了让第三方支付回调能打进来，又不想开放整个节点端口，就用内网穿透工具把特定的 service 映射出去。
比如用 frp 配置一条 route：
<code>[web-payment]</code>
<code>type = http</code>
<code>local_port = 8080</code>
<code>custom_domains = pay.example-corp.com</code>这条配置就把容器组里处理支付回调的服务通过加密隧道暴露出去，外网访问 pay.example-corp.com，请求就被精准导流进内网的 Pod。整个过程不需要改动 K8s Ingress，也不用动防火墙策略。
更实用的是调试场景。产品上线前，产品经理想看下最新版本的界面，开发不用再发截图或临时部署测试服，直接生成一个穿透链接发过去，点开就能看真实数据下的效果。
和 CI/CD 流水线串起来才够省心
我们在 Jenkins 的构建任务末尾加了一步：每次部署到预发环境后，自动触发 frpc 配置更新，注册当前 deployment 的访问路径。这样一来，每个版本都有独立的可访问地址，配合短链服务，连邮件通知都可以自动生成。
这种模式特别适合多租户场景。不同客户对接同一套平台，各自环境隔离在不同的命名空间，通过独立的穿透通道对外提供 API，彼此不受影响。
企业级容器平台解决的是“怎么把服务管好”，而内网穿透解决的是“怎么让服务被找到”。两者一结合，既保留了内网安全，又实现了灵活接入，尤其适合那些还在混合网络环境下过渡的企业。