Try to enable HTTP/2 support in the client

[clux]

What problem are you trying to solve?

The apiserver supports HTTP/2 as evidenced by the multiple http2 flags documented.

If the apiserver supports it, it would be good to try to support it also.

Enabling http2 can supposedly massively reduce open connections for certain calls, particularly around log streaming as reported in #1823 . That PR has a start, but is currently abandoned so raising an issue to open up if anyone is interested in experimenting.

Describe the solution you'd like

Unclear. This needs experimentation.

Enabling http2 is simple enough;

-        Ok(builder.enable_http1().wrap_connector(connector))
+        Ok(builder.enable_http1().enable_http2().wrap_connector(connector))

with extra htt2 features on dependencies hyper, hyper-util and hyper-rustls.

However, this leads to upgrade errors UpgradeConnection(ProtocolSwitch(500)) for websocket related calls.
So i am not sure if this is possible to do as is, i.e. globally setting http2 but then doing some calls as http1.

Exploration is welcome. I speculated a bit in #1823 (comment).

I'd rather not split clients up, but maybe it's possible to do some multiplexing internally in Client based on what types of calls if it came to it.

Documentation, Adoption, Migration Strategy

should be additive and non-breaking if it's done.

Target crate for feature

kube-client, kube-core

[uchiha-vivek]

@clux @doxxx93

Sir, I tried to do some initial research and study on this issue.
Initially i tried to find out how client-go (Go k8s client) is solving it.

In client-go HTTP/2 is implicitly allowed for normal REST API calls,but upgrade-based APIs are explicitly routed through a separate transport that forces HTTP/1.1. They have designed architecture for it.

Normal rest traffic is constructed via rest/transport.go which uses Go net/http behaviour.
Exec/attach/port-forward is implemented using spdy.RoundTripperFor(config).

client-go never attempts protocol upgrades over HTTP/2,

In kube-client, enabling HTTP/2 at the client builder level applies globally. Thus upgrade-based APIs are sent over HTTP/2 causing the issue

UpgradeConnection(ProtocolSwitch(500))

Three things we can do for rust k8s client

• Routing them through a dedicated HTTP/1.1 transport
• Allow HTTP/2 only for APIs where it is known to work(REST API's and Watch Logs)
• Treat upgrade-based APIs as fundamentally different transport requirements (inspiration from go)

From brute force i think this is a design issue , i need to make more edge cases and test it. Accordingly i will try to paste my results here.

[uchiha-vivek]

I will soon come up with the tests i have done

[lukasstockner]

Hi, we've also been looking into HTTP/2 support in order to enable keep-alive frames, since the usual HAProxy config for self-hosted clusters will terminate the connection after 35sec, which is not ideal for watch streams.
The official Go clients uses HTTP/2 with a 30sec keep-alive ping interval to avoid this.

We simply configured the client for HTTP/2-only:

-        hyper_util::client::legacy::Builder::new(TokioExecutor::new()).build(connector)
+        hyper_util::client::legacy::Builder::new(TokioExecutor::new())
+            .http2_only(true)
+            .http2_keep_alive_interval(Some(Duration::from_secs(30)))
+            .http2_keep_alive_while_idle(true)
+            .timer(TokioTimer::new())
+            .build(connector)

-        Ok(builder.enable_http1().wrap_connector(connector))
+        Ok(builder.enable_http2().wrap_connector(connector))

and so far it works just fine, though we don't use Websocket calls so I can't speak for that.

[uchiha-vivek]

Hi, we've also been looking into HTTP/2 support in order to enable keep-alive frames, since the usual HAProxy config for self-hosted clusters will terminate the connection after 35sec, which is not ideal for watch streams. The official Go clients uses HTTP/2 with a 30sec keep-alive ping interval to avoid this.

We simply configured the client for HTTP/2-only:

•    hyper_util::client::legacy::Builder::new(TokioExecutor::new()).build(connector)
  

•    hyper_util::client::legacy::Builder::new(TokioExecutor::new())
  

•        .http2_only(true)
  

•        .http2_keep_alive_interval(Some(Duration::from_secs(30)))
  

•        .http2_keep_alive_while_idle(true)
  

•        .timer(TokioTimer::new())
  

•        .build(connector)
  

•    Ok(builder.enable_http1().wrap_connector(connector))
  

•    Ok(builder.enable_http2().wrap_connector(connector))
  

and so far it works just fine, though we don't use Websocket calls so I can't speak for that.

@lukasstockner I tested it myself and it works fine, well i will come up with some more cases

[frobware]

I took another look at HTTP/2 support for kube-client and tried splitting the connection path so WebSocket upgrades stay on HTTP/1.1: #1823 (comment)

This is still very much exploratory.