https://github.com/authzed/spicedb-operator/pull/320 switched from using a fork of client-go with SMP metadata included on the ApplyConfiguration types to pulling the OpenAPI schema and using that to for structured merge patch metadata. That PR also updated kube deps to 1.30.2.
One (or both) of those changes resulted in significantly higher memory usage - in a stage environment, the steady state went from ~25MB to ~90MB. Looking at profiles, the majority of the memory is held by the OpenAPI kube machinery.
Long term this issue might go away - we don't actually want to be using Structured Merge Patch, it would be much nicer to send multiple FieldManagers in the same API request to support the patches feature, but in the meantime it's worth seeing if there's a way to reduce the footprint.
https://github.com/authzed/spicedb-operator/pull/320 switched from using a fork of client-go with SMP metadata included on the ApplyConfiguration types to pulling the OpenAPI schema and using that to for structured merge patch metadata. That PR also updated kube deps to 1.30.2.
One (or both) of those changes resulted in significantly higher memory usage - in a stage environment, the steady state went from ~25MB to ~90MB. Looking at profiles, the majority of the memory is held by the OpenAPI kube machinery.
Long term this issue might go away - we don't actually want to be using Structured Merge Patch, it would be much nicer to send multiple FieldManagers in the same API request to support the
patchesfeature, but in the meantime it's worth seeing if there's a way to reduce the footprint.