Reflector should not request the whole meta

[SOF3]

Would you like to work on this feature?

yes

What problem are you trying to solve?

I want to reduce controller memory usage by only storing the raw JSON of dynamic objects in memory instead of allocating the entire serde_json::Value. Currently the reflector store expects a type parameter with bound K: Resource, where Resource has to provide (mutable) access to an ObjectMeta it caches internally. This makes it impossible to implement Resource on a JSON string wrapper.

I do not want to extract out the entire metadata because the unused fields like annotations and labels may allocate a lot of heap memory and waste even more on pointers.

Describe the solution you'd like

Not all fields in ObjectMeta are required for the reflector. In fact, a quick git grep 'meta(' kube-runtime/src/reflector reveals that the all fields used from the ObjectMeta is the namespace, resourceVersion and uid (and read-only).

I am proposing that we change the bound of K: 'static + Resource in reflector::Store to this:

pub trait ReflectorResource : 'static {
    type Object: Send + Sync + 'static;
    fn namespace(object: &Self::Object) -> &str;
    fn name(object: &Self::Object) -> &str;
    fn resource_version(object: &Self::Object) -> Option<&str>;
    fn uid(object: &Self::Object) -> Option<&str>;
}

impl<K: Resource + 'static> ReflectorResource for K {
    type Object = K::DynamicObject;
    // other functions delegate to K::meta()
}

Describe alternatives you've considered

In the equivalent Go informer implementation, I implemented metav1.Object methods by returning zero values in unused getters and no-op in unused setters (which is obviously an undocumented hack), but the same trick is not possible to implement soundly due to meta_mut().

Documentation, Adoption, Migration Strategy

This is possibly a BC break since the bounds of reflector::Store are widened, but should cause no impact to most users since all existing Resource implementors are blanket-impled for.

Target crate for feature

kube-runtime

[clux]

There might be some good points in here about making the bounds of the relfector's operation explicit, but from a purely memory optimisation POV, it feels a little unnecessary at the moment because of existing optimisations laid out in: https://kube.rs/controllers/optimization/#pruning-fields - have you seen this?

The default behaviour of the reflector is to store everything it sees, and personally i think is a sensible default, because everything you see is ultimately going on the wire anyway.

[clux]

(this might not work for you if you absolutely need to implement Resource yourself on a json wrapper - but maybe it's worth asking if that is necessary first)

[SOF3]

Yep, pruning managedFields would probably help reduce half of the memory used, but I actually wanted to cache the entire generic object to execute some user-defined query operations, which still requires the entire object. Not sure how much this costs in Rust, but my experience in Go was that the unstructured object memory footprint is around four times as large as the raw JSON list.

[clux]

If you still need to cache the entire object, then the memory cost should be the cost of storing the full thing + the cost of getting a (possibly smaller) copy, no? In fact, if you are using Store::get you're getting a shared reference to the same object through an Arc so you don't even have to pay for it twice.

We don't really do unstructured objects the same way as Go, so you should not see any particular memory gains by working on serialised data - rust is pretty efficient with its memory layout in general.

The things we generally use instead of unstructured is DynamicObject (if we care at all about the spec) or PartialObjectMeta (if we only care about labels/annots/name/kind so we can use metadata watch api).

[SOF3]

Why would there be the cost of storing a copy? I assume I could deserialize the JSON into something like a struct { name: Cow<'data, str> }, which could be converted into an Either<ArcStr, Range<usize>> (or Range<NonZeroU32> if we want to optimize further, since etcd cannot store objects larger than a few megabytes anyway and string literals never start at the first byte). And since the required extra fields are typically alphanumeric/hyphen, this generally means I just need 8*4 bytes additional bytes for each object, plus a usize to store the ArcStr at which the object is cloned into.

As for the part of getting the object, most objects are only retrieved once or twice in practice for many applications, so we're just deferring the cost of deserialization from list/watch time to processing time.

Could you elaborate further on "not doing unstructured objects the same way"? In the particular case I am trying to use right now, I need to pass the JSON to another library across an FFI boundary anyway, so getting the raw JSON is actually my intention, not just for memory optimization but also to avoid needing to reserialize it to pass the FFI. But I admit that FFI is a bit niche in the kube case so let's not focus on that.

[nightkr]

FWIW, the overhead cost of a blank ObjectIdentity is 344 bytes, compared to 96 bytes for a bare minimum impl of your ReflectorResource:

use std::mem::size_of;

use kube::core::ObjectMeta;

struct ObjectIdentity {
    namespace: Option<String>,
    name: String,
    resource_version: String,
    uid: String,
}

fn main() {
    dbg!(size_of::<ObjectMeta>()); // => 344
    dbg!(size_of::<ObjectIdentity>()); // => 96
}

That is... surprisingly non-neglegible, actually.

[nightkr]

We can always add the stricter bound to ::erase().