[2.5.11] Added typer to store

[paynejacob]

rancher/rancher#34721
rancher/rancher#30718
rancher/rancher#25487

Problem

For a deep dive on this problem see here. TLDR; Norman is slow listing large resources because the Kubernetes dynamic client parses the response from the Kubernetes API multiple times when the type is unstructured.Unstructured. This can lead to high memory consumption and excessive processing time deseralizing responses.

Solution

Stores can be optionally passed a typer. If the typer recognizes the resource associated with the given store it will return the Golang stuct for the given resource. This allows the client to deseralize the response more efficiently.

Testing

For a testing environment I used a k3d cluster with rancher running locally. All requests were done with curl piping the output to /dev/null. To test this I generated 200 configmaps with 8KB of data each. I then listed them with the application/json content type three times and averaged the response time. With no changes it took an average of 13,341 ms to list configmaps. Applying these changes but not registering ConfigMapList with the typer the response time averaged 12,719 ms. Registering the ConfigMapList with the typer brought it down to 7,764 ms.

Notes:

• The time to first byte from the Kubernetes API averaged ~700 ms. This was not measured with every test but the request to the API is not affected.
• All these test are done with all components talking over the local network. The real world performance gains main be greater when network transfers are factored in.
• The 8KB data size was selected because response times were noticeably slower after 8KB. This threshold is dependent on a multitude of factors including CPU clockspeed, memory speed, memory size, etc. Clusters provisioned with more resources may not realize performance gains with these changes as quickly as smaller clusters. The performance will always be at a minimum the same as before these changes.
• These tests do not account for how list transformers are interacting with the data, the performance gains here may not be consistent across all resources.
• In testing I added Accept: application/protobuf, combined with these changes I was able to get responses as low as 2,000 ms. Protobuf is only available if the typer recognizes the resources and significantly limits our ability to debug calls between Rancher and Kubernetes. With these limitations I don't think it is worth adding but could be worth exploring in the future as a further optimization.

[paynejacob]

marking as draft until 2.5.11

[snasovich]

@paynejacob , did we decide to drop _drop part? If that's the case, we want the description updated to reflect that. Let me know if I'm missing where this is implemented.

[paynejacob]

@snasovich yes we removed that functionality because it wasn't going to benefit the UI. ill update the description.

[snasovich]

LGTM, kudos for adding a unit test for this

[cbron]

lgtm, not a norman expert but the approach seems correct.

[snasovich]

Note that this PR is actually for 2.6 release. The name is confusing due to how Norman was versioned and timeline of Rancher releases. The one for 2.5.x is this one: #405