This implementation depends on transports constructed from kubeconfig files conforming to the RoundTripperWrapper interface:

type RoundTripperWrapper interface {
    http.RoundTripper
    WrappedRoundTripper() http.RoundTripper
}

type DialFunc func(net, addr string) (net.Conn, error)

func Dialer(transport http.RoundTripper) (DialFunc, error) {
    if transport == nil {
        return nil, nil
    }

    switch transport := transport.(type) {
    case *http.Transport:
        return transport.Dial, nil
    case RoundTripperWrapper:
        return Dialer(transport.WrappedRoundTripper())
    default:
        return nil, fmt.Errorf("unknown transport type: %v", transport)
    }
}

Interesting. We can certainly add them back for now, but this seems like something that should be done another way. Why rely on a http.RoundTripper to supply a dialer and TLS config, especially when wrapping them is such a common idiom? Wouldn't it be better for the proxy/upgrade handlers to just know what Dialer and TLSConfig they should use instead of trying (and failing in this case) to discover from a naively wrapped http.RoundTripper?

The proxy code handles generically proxying/upgrading connections to node, pod, and service back ends. The transport to use is part of what is handed to the proxy code.

I'm fine with a refactor, but I'd like to unbreak this asap and work on a better solution at leisure. This is seen to have an effect when connecting to things with custom dialers like GKE and a tunneling dialer

Agreed whole-heartedly with quick fix + thinking about a better way. Are you doing this? Or should I?

FWIW this is a similar situation to http.Transport.CancelRequest(). People naively wrapped the round tripper, http.Client's Timeout would no longer worked. They ended up bypassing the need to type assert down to that method by adding a Cancel channel to the http.Request object.

Also, there are e2e tests that should have caught this, but they may have been conditionalized away in GKE :-/

If you can, I can do a quick review