This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

/cc @mborsz @wojtek-t @jpbetz @deads2k @p0lyn0mial

/sig api-machinery

cc @mengqiy @hakuna-matatah

Great observation Marek!

I think there are two main unknowns with the proposal:

• The potential impact on the other resource types --- IIUC the current experiments were for configmaps for which this approach is clearly beneficial (as nearly all the data is in strings). The next step would be probably to benchmark different scenarios to understand potential gain. Having similar benchmarks for e.g. pods which may have a lot of nested structs and not that much data in strings may help us understand a potential impact in other scenarios. Note that https://github.com/mborsz/kubernetes/blob/b49532753b4077a6edb6b5e6407ae8738e41ac90/staging/src/k8s.io/apimachinery/pkg/runtime/serializer/protobuf/streaming.go contains some experimental implementation of streaming protobuf encoder from my previous exploration in this area -- I hope it will be useful for further experiements here.
• Complexity to deliver some production version of this logic -- availability of a good serialization libraries, whether we can deliver all fancy features like "as=Table" https://kubernetes.io/docs/reference/using-api/api-concepts/#receiving-resources-as-tables or at least skip them for now in a clean way

Having better visibility for both will be helpful to understand the tradeoff we are making.

The potential impact on the other resource types --- IIUC the current experiments were for configmaps for which this approach is clearly beneficial (as nearly all the data is in strings). The next step would be probably to benchmark different scenarios to understand potential gain. Having similar benchmarks for e.g. pods which may have a lot of nested structs and not that much data in strings may help us understand a potential impact in other scenarios.

Tested pods, spread data in 1KB chunks around containers, initcontainers volumes and condition fields to create a large structure. The test results showed smaller, but still substential benefits. Memory usage went down from 27GB to 9GB. With pods the base memory is around 7GB, so it means we reduce allocations from 20GB to 2GB. I can accept that :P

Complexity to deliver some production version of this logic -- availability of a good serialization libraries, whether we can deliver all fancy features like "as=Table"

I think we can skip them for now. Our main focus should on default client behavior. Which is base JSON. One sad thing is that we don't really have any JSON performance. Scalability tests run everything in proto based on fact that K8s would not hit 5k nodes if we used JSON at all. Still would like to have Proto implemented just to see the impact in scalability tests.

I imagine we'd like to triage this as accepted. What are the downsides?