Kube-rs: Talk to k8s API via http(s) proxy

[edio]

First of all, thanks a lot for this work. Using k8s via a generic API powered by Rust type system is a pure pleasure!

I just started using this library for a pet project, and I could not find how to make _kube-rs_ talk to k8s API via a http(s) server. And judging from the code, it doesn't seem possible
https://github.com/clux/kube-rs/blob/master/kube/src/client/mod.rs#L320-L338

Adding support for http(s) proxy (and for the fact, any kind of proxy, _reqwest_ supports many more) seems pretty simple implementation-wise, we just need to set proxies vector in the ClientBuilder.

However, I've no idea how exactly we can expose this on _kube-rs_ API level.

If I understand the codebase correctly,Config struct seems to be a one-stop entity to configure _kube-rs_, it addresses mixed concerns: we have namespace for kubernetes and headers for the http transport. Would you say, that adding another field proxy to the Config struct is a viable option? Or do you see a better way for configuring proxy server?

[clux]

Hey there, thanks for digging into this.

Hey there, yeah our Config is basically there to translate the underlying kubernetes config information (be it the local file, or the evars), into something that we can use to build a reqwest::Client with.

As this is a reqwest::ClientBuilder option, it should sit inside our Config, probably as a pub proxy: Option<reqwest::Proxy> (if Proxy satisfies all the derived traits we need), don't see a better way short term.

Long term, we were hoping to be able to lift the Client outside this module (maybe via #100), so that we didn't have to duplicate client options just to pass them on to the thing that really handled it (as well as forcing reqwest on everyone). But doing that change is probably a more difficult piece of work, so if you have a need for proxy, am happy to take a PR that just plants this into Config :-)

[clux]

This is now released in kube 0.35.0.

[lfrancke]

For anyone stumbling across this: This has been removed again in version 0.49 due to the move from reqwest to Tower.

[kazk]

It should be still _possible_ by implementing a custom service, but it's too painful at the moment because all the layers are private (you'll need to recreate the entire stack manually and use that to create kube::Serivce). I'd like to eventually make the layers public, so users can compose them easily.

We should be able to add an optional proxy layer using hyper-proxy, but I'm waiting for it to update to Tokio v1 first. Also, if I remember correctly, it didn't provide a way to fully customize the TLS stack, so we might need to open a PR there.

[kazk]

@lfrancke @edio hyper-proxy merged Tokio v1. Can you try #438?

In examples/ run:

PROXY_URL=https://your-proxy cargo run --example proxy --no-default-features --features=proxy-native-tls
# or
PROXY_URL=https://your-proxy cargo run --example proxy --no-default-features --features=proxy-rustls-tls

[lfrancke]

Thank you @kazk - I don't really need this feature. I just tried to put a mitmproxy in between so I can debug some issues I've seen. I really just commented here so others don't sumble across the same thing I did. This was the first issue that poppepd up for me when searching on Google for kube-rs and proxy and it wasn't obvious that this has been removed again.

I can try your PR but I can only get to it next week.
Thanks for your work on this!