Proxy Subresource

[clux]

With #127 nearing completion, there's actually only one special subresource left; proxy (which has its own verb).

Described in kubernetes.io/../proxies it describes a method to connect to services from outside the cluster using the proxy verb. See also a TL;DR stackoverflow answer.

The allowed http methods are the same for Pod, Service and Node. See e.g. Node methods):

• POST /api/v1/nodes/{name}/proxy
• POST /api/v1/nodes/{name}/proxy/{path}
• DELETE /api/v1/nodes/{name}/proxy
• DELETE /api/v1/nodes/{name}/proxy/{path}
• GET /api/v1/nodes/{name}/proxy
• GET /api/v1/nodes/{name}/proxy/{path}
• HEAD /api/v1/nodes/{name}/proxy
• HEAD /api/v1/nodes/{name}/proxy/{path}
• PUT /api/v1/nodes/{name}/proxy
• PUT /api/v1/nodes/{name}/proxy/{path}

e.g. we, at the very least, need some Api methods protected by a Proxy trait and implemented by:

impl Proxy for k8s_openapi::api::core::v1::Pod {}
impl Proxy for k8s_openapi::api::core::v1::Service {}
impl Proxy for k8s_openapi::api::core::v1::Node {}

impl<K> Api<K>
where
    K: DeserializeOwned + Proxy
{
    //todo!("methods from above list")
}

in kube-client.

Prior Art

OpenEBS Mayastor control plane has a forwarding crate using the /proxy verb:

• https://github.com/openebs/mayastor-control-plane/blob/92af9014102beeb2996f43ef1f0e3ba182ebe0f9/k8s/forward/src/http_forward.rs#L253-L255
• original upstream PR: https://github.com/openebs/mayastor-control-plane/pull/288

Previous proxy-like work; how to setup kube-client with a custom proxy connector, but that's more for supporting config.proxy_url.

Discussion

Not sure how to approach this in kube. My gut feel is something similar to portforward.rs, but we have also left client proxying up to custom clients (via user-supplied connectors).

There's ultimately no discussion about it currently so putting in an issue to gauge interest (plus i want to stash some tabs). If people have thoughts or ideas about this, comments are welcome.

[aryan9600]

i was trying to figure out how to tackle this issue and as you said portforward seemed to be the closest thing, so i took a look there. i think we might need to go about this in two ways (note that this is very high level):

• introduce a trait Proxy and implement it for Pod, Service and Node. then have something like pods.proxy(req) where req will be the HTTP request to forward to the pod. this will be helpful for consumers who just want to access a single resource on-demand.
• to aid users who want to build a full blown proxying service similar to kubectl proxy, we should introduce a HTTPForwarder, which would accept a request, and using the URL figure out the target. it'd then forward the request to the intended target. this way consumers won't have to fetch the actual pods/services/nodes (as is required in the first way), avoiding unnecessary API calls.