How do I best handle execing into a Pod in a namespace when watching with an Api::all instance?

[chinatsu]

Hello!

First of all, I've had a great time with this library so far. Part of that is Rust being a great language to play with, but kube-rs has also contributed a lot to my enjoyment here, so thanks a lot!

I've been playing with making an operator that looks at Pods with a special label that we add to every Pod spawned by a Job, and then shuts off every container that isn't the main container once the main container has terminated; sidecars will usually not know what's going on with sibling containers and shut themselves down after all.

Ideally, this cluster-wide operator would look at every Pod matching that label regardless of namespace, so I'm doing the watching with Api::all(). Then, when I find a Pod (and some containers) that ends up being eligible for some special care I run into some problems:

The Pod is namespaced, but my Api instance isn't, so I can't use that to do stuff like exec to kill -s INT 1 a cloudsql-proxy, because exec doesn't seem to take any arguments to specify namespace. The way I've gone about this now is that I send in a clone of the Client that I initially used to create my Api::all()-instance, to create another Api instance specifically namespaced to the Pod, and then throw that away once I'm done shutting down all the sidecars. Here's where I do that in my current project: handleable.rs.

Is this particularly expensive, I wonder? And maybe if it is, have I overlooked a way to continue using my one Api instance in some way (or, at least a clone that lives longer than one round of handling a Pod)?

Now, I've only skimmed a few seemingly relevant issues and discussion threads, so I apologise if a similar thing has been brought up already!

[clux]

hey there! glad you're getting things to work well. Cool idea for a project (and great name).

Cloning the Client or the Api should not be an operation that has noteworthy cost. It's designed so that it can be done pretty frequently in controllers because (as you have seen) you need one Api instance per scope (and also type) - so you are doing things idiomatically in my book.

The reasoning behind why cloning is cheap, lies in what the Client contains and how they are wrapped. The main interface to the http client goes through the tower::Service (or BoxService in our case), and it's wrapped in a tower::Buffer designed to cheaply clone services.

(There are some prototype thoughts floating around on tuning the Api abstraction in the future to make less service cloning required between scopes, but that's more of an orthogonal safety concern plus ergonomic change, rather than overhead reduction.)

[chinatsu]

Cheers! I was kind of assuming/hoping that it was fairly cheap, but the consumerist approach of use and discard felt a little iffy to me so I figured I'd ask the authorities.

Either way, these events shouldn't come by too often on our platform, so I don't think it'd hurt even if there was some significant overhead. It was more a question about whether my solution was somewhat sane, and I think I've got my answer!