Proposed Changes

Proxy starts one pipe goroutine per direction and returns the first error it receives on errc. errc was unbuffered, and the done flag that kept a second sender away was a plain bool written by both goroutines. When both directions failed at about the same time (the usual case on a TCP reset), both goroutines could pass the done check; the second one then blocked forever on the send, holding its 32 KiB buffer and both connections.

errc now has room for both errors, so each pipe goroutine sends once and returns. The done flag and the err method are gone, which also removes the data race. Proxy still returns the first error and logs it unless it is io.EOF. It now logs once per connection; with the race, both goroutines could log. The second goroutine exits as soon as its Read or Write fails, which Proxy triggers by closing both connections on return.

I kept "return on the first error" rather than the wait-for-both-directions pattern in remotedialer's client_dialer.go, so Proxy cannot hang on a connection whose Close does not unblock a pending Read. Following @bheemareddy's review suggestion, which matches the classification in #14810, connection resets and broken pipes (syscall.ECONNRESET, syscall.EPIPE, matched with errors.As) are now logged at debug level instead of as Proxy error: warnings. Other errors are still logged as warnings, and io.EOF is still not logged.

Types of Changes

Bugfix

Verification

1. Run a server with the default egress selector mode (agent) and an aggregated APIService backed by an in-cluster Service, as in Goroutine leak in pkg/daemons/control/proxy: second pipe goroutine blocks forever on unbuffered errc when both directions fail (data race on done) #14787.
2. After some tunnel connections have ended with Proxy error: ... connection reset by peer, dump goroutines through the kubelet: kubectl get --raw "/api/v1/nodes/$N/proxy/debug/pprof/goroutine?debug=2".
3. No goroutine is left blocked in pkg/daemons/control/proxy. Before this change, the count of proxy.(*proxy).err goroutines only grows.

Testing

Added Test_UnitProxyBothDirectionsFail in pkg/daemons/control/proxy. It runs Proxy 10000 times on connections whose reads and writes always fail, then waits for the goroutine count to return to where it started. On the old code it fails (1029 goroutines left over) and -race reports the race on done; with this change it passes 20 of 20 runs of go test -race -count=20 ./pkg/daemons/control/proxy/. It catches the bug on multi-core runners; with GOMAXPROCS=1 the old code can pass. A blocked goroutine is not visible to an e2e test, so this is a unit test; I can drop it if you prefer.

Added Test_UnitProxyLogLevel, which checks the level for io.EOF, a TCP reset, a broken pipe and an unrelated error.

Linked Issues

Fixes #14787

User-Facing Change

Fixed a goroutine leak in the egress selector tunnel proxy when both directions of a proxied connection fail. Connection resets and broken pipes on proxied connections are now logged at debug level.