Enable HTTP/2 support in kube-client #1823
Conversation
Add http2 feature to hyper, hyper-util, and hyper-rustls to enable HTTP/2 ALPN support in the kube-client. This complements the enable_http2() API call to provide full HTTP/2 multiplexing capability for Kubernetes API connections. Signed-off-by: Andrew McDermott <[email protected]>
This change adds HTTP/2 ALPN support to the rustls HTTPS connector by calling enable_http2() in addition to enable_http1(). This enables HTTP/2 multiplexing for Kubernetes API connections, reducing the number of TCP connections from potentially hundreds to a single multiplexed connection per API server. Previously, kube-rs only supported HTTP/1.1 connections, resulting in a new TCP connection for each concurrent API request. With HTTP/2 enabled, multiple requests can be multiplexed over a single connection, improving performance and reducing resource usage. Signed-off-by: Andrew McDermott <[email protected]>
frobware
force-pushed
the
enable-http2
branch
from
719aab8 to
0b5cdf2
Compare
|
wow, really?! i wasn't aware that the apiserver supported http2 for this, but sure enough, there are flags for it. I do see it gives us some |
I'll take a look over the regressions, but it won't be immediately. |
|
Appreciated. No rush. From a quick googling around, this comment in client-go possibly implies some mutual exclusivity in usage, and perhaps we need to set Request::version_mut to override back to 1.1 for websocket stuff in kube-core's |
2 participants
This change enables HTTP/2 support in the client, allowing multiple requests to multiplex over a single connection. The implementation simply adds the http2 feature flag to hyper and its related dependencies, then enables HTTP/2 alongside HTTP/1 in the rustls connector configuration.
I noticed that I had 400+ open connections to the API server when streaming logs from all pods in my cluster, each requiring its own TCP handshake and TLS negotiation. With HTTP/2 enabled, I now only have a single connection handling all those streams, eliminating the overhead and avoiding potential resource exhaustion from hitting connection limits.