Integrate @kubernetes/client-node types into Rancher code

[cnotv]

Description

In some extensions seems like we have a broad use of interfaces based on @kubernetes/client-node which has been proposed and postponed years ago #6724

As we have a long lasting proven use case, we should probably adopt as well into this repository.

Example PR: rancher/kubewarden-ui#1204

@nwmac @richard-cox

[richard-cox]

generally we should discourage users from fetching resources via @kubernetes/client-node and use the mechanisms we have in place instead (findAll, find, etc actions). resources fetched by steve/norman are supplemented with the required fields that make the generic components in rancher work.

then it comes down to users importing types that aren't quite matching with ours. if we have our models extending them then we've got to work out how to integrate resource versions (given rancher could talk to different k8s versions with different resource versions)

[cnotv]

In Kubewarden extension is used only for interface, which we do not have at all. I would say that rather have official interfaces updates periodically than have none. If necessary for some cases as you said, we could extend/union that.

The code we have in Rancher is regardless of the version, it's always current one. The sense of Typescript is on fact to ensure a common ground through it.

What should we do with the extension then?

[richard-cox]

The problem is that we use instances of classes, those would need to implement interfaces that extend extend kube types from client-node, and those kube types will be versioned and possibly different between downstream clusters. So there's quite a bit of work there and some unknowns

[cnotv]

We never cast the classes inside Vue or anywhere else, they stay there inside the type folder and forgotten by both us and code. The problem may arise when we add stuff keys or logic (never remove cos we would end in problems), then we could just extend the interface and use that without mix with classes.

[cnotv]

So let's make an example:

• A: it's a @kubernetes/client-node interface and has key bar: string
• B: it's a custom interface with different key foo: number
• C: it's the class extended from the union of A and B containing both the keys

[cnotv]

Changing milestone so we just take a decision and close this.