2.2k Star 的 Piko：为生产流量设计的开源隧道工具

做后端或运维，大概都遇到过这类需求：本地服务要临时给测试同事访问，客户内网中的应用需要从公网回连，或者 Kubernetes 里的服务要在不开放入站端口的前提下对外提供能力。

ngrok 很适合临时调试，但如果流量必须留在自己的基础设施里，团队通常会转向 frp、Cloudflare Tunnel 或自建反向隧道。Piko 切入的正是这个位置：它不强调”一条命令拿到公网域名”，而是把重点放在自托管、集群容错和 Kubernetes 部署上。

Piko 是什么

Piko 是一个用 Go 编写的开源反向代理，采用 MIT 许可证。官方对它的定位很直接：一个为生产流量设计、便于自行托管，尤其适合部署在 Kubernetes 上的 ngrok 替代方案。

Piko 的核心交付形态是自托管服务。你可以把它部署在自己的服务器或 Kubernetes 集群里，让流量和运行数据留在受控环境中。协议层面，它支持 HTTP(S) 透明反向代理和 TCP 转发：HTTP 请求可以通过 Host 或 x-piko-endpoint 标识目标端点；TCP 本身不携带这类路由信息，因此需要通过 piko forward 或 Go SDK 映射目标端点。

除了 CLI，Piko 还提供 Go SDK。应用可以直接创建标准 net.Listener，把隧道能力嵌进自身进程。对 BYOC（Bring Your Own Cloud）、客户内网回连或设备接入这类产品来说，这比额外维护一个独立 Agent 进程更容易集成。

工作原理：由内网服务主动建立连接

传统反向代理会主动连接上游服务，因此上游至少要能被代理所在网络访问。Piko 把连接方向反了过来：内网中的 upstream 主动向 Piko Server 建立出站连接，并注册自己监听的端点；外部请求到达后，Piko 再沿着已经建立的连接把流量转回 upstream。

这样一来，上游服务不需要公网 IP，也不必开放入站端口，只要能够访问 Piko Server 即可。它很适合客户内网服务、边缘设备，以及不希望通过 NodePort 暴露的 Kubernetes 工作负载。需要注意的是，“只建立出站连接”只是缩小了网络暴露面，生产环境仍要配置 TLS、认证、端点授权和日志审计。

传输层上，upstream 通过 WebSocket 连接 Server，并使用 yamux 在一条连接中复用多条双向数据流。对外，这仍是标准 HTTP 流量，可以放在 HTTP(S) 负载均衡器后面；对内，每个请求又能像独立连接一样转发，WebSocket 等长连接也可以透传。

集群中的 Piko 节点会同步端点路由信息。upstream 和外部客户端可以连接任意节点；如果入口节点没有目标 upstream，它会把请求转发到持有该端点连接的节点。同一端点注册多个 upstream 时，Piko 会在它们之间分配流量；节点失效后，upstream 会重连到其他节点。这套机制对应了项目强调的容错、横向扩展和滚动升级能力。

从本地 Demo 到 Kubernetes

仓库自带了 Docker Compose Demo，会启动多节点 Piko、NGINX 负载均衡以及 Prometheus、Grafana。默认会区分三类端口：代理入口、upstream 连接入口和管理接口，便于观察完整链路。

启动本地 HTTP 服务后，可以用下面几条命令注册和访问端点：

# 把本地 4000 端口注册为 HTTP 端点 my-endpoint
piko agent http my-endpoint 4000

# 把本地 4000 端口注册为 TCP 端点 my-endpoint
piko agent tcp my-endpoint 4000

# 在本地 3000 端口访问远端 TCP 端点
piko forward 3000 my-endpoint

HTTP 模式下，可以通过域名的第一个子域或 x-piko-endpoint 请求头选择端点。TCP 模式无法在原始连接中声明端点，所以要先让 piko forward 建立映射。

Kubernetes 更能体现 Piko 的设计取向。官方方案通常用 StatefulSet 运行多个 Server 副本，通过 Service 或 Kubernetes Gateway 接入流量，并借助 Headless Service 做节点发现。仓库还提供 Helm Chart，适合把部署方式纳入现有的集群管理流程。

可观测性也不是事后补上的：Piko 暴露 Prometheus 指标，支持访问日志和状态 API，Demo 中还包含预置的 Grafana 面板。对长期运行的隧道服务而言，这些能力比”能把请求转进去”本身更重要。

和 ngrok、frp 的区别

Piko 与 ngrok 服务的重点不同。ngrok 的优势是托管体验：不用维护入口服务器，临时调试很快就能获得可访问地址。Piko 则把控制权交给使用者，适合流量不能经过第三方、需要自行定义认证策略，或者希望隧道服务与现有 Kubernetes 基础设施统一运维的团队。代价也很明确：域名、证书、容量、升级和故障处理都要自己负责。

与 frp 相比，Piko 更强调多节点集群和 HTTP 负载均衡后的部署方式；frp 的生态和使用场景更广，单机部署也更轻。两者并非简单的替代关系：个人或小规模端口映射可以优先考虑 frp，生产级多节点入口则更值得评估 Piko。

Cloudflare Tunnel 同样能解决”内网只发起出站连接”的问题，但它是托管服务。是否采用，主要取决于团队能否接受第三方承载入口流量，以及是否愿意自行承担 Piko 的运维成本。

什么时候值得选 Piko

Piko 比较适合三类场景：

• BYOC 或私有化部署：产品运行在客户网络中，需要从控制面回连做管理、监控或诊断。
• 设备与边缘节点接入：设备分散在不同网络中，通过端点名向中心服务暴露受控能力。
• Kubernetes 服务临时或长期对外暴露：希望避免为每个服务单独调整 NodePort 或 Ingress，同时保留统一的入口和可观测性。

它不太适合只想临时分享本地页面的个人用户。Piko 需要先部署 Server，也没有现成的公网域名和完整管理后台；没有运维能力的团队，还要把高可用、证书和监控成本算进去。

总体来看，Piko 的位置不宽，却很清晰：当团队已经决定自托管隧道服务，又希望获得多节点、Kubernetes 友好和可观测能力时，它提供了一套相对完整的开源实现。最稳妥的评估方式不是直接替换现有入口，而是先跑通官方 Demo，再用真实的长连接、故障切换和认证策略做一轮压力与安全测试。