`read` returns wrong struct for custom k8s objects, if name matches core API object

[gnarlex]

Describe the bug When read()ing a custom k8s object, whose kind matches one of the core API object kinds, it constructs an object matching the core v1 type.

Example: monitoring.coreos.com/v1:Probe matches core/v1:Probe

Client Version 0.21.0

Server Version v1.28.4

To Reproduce Steps to reproduce the behavior:

• Keep a custom k8s object in your cluster, with apiVersion monitoring.coreos.com/v1, and kind Probe, metadata.name="foo".
• read probe "foo".

Expected behavior The correct, entire monitoring../v1:Probe object is returned.

Example Code

const k8s = require('@kubernetes/client-node');

const kc = new k8s.KubeConfig();
kc.loadFromDefault();

const client = kc.makeApiClient(k8s.KubernetesObjectApi);

const main = async () => {
    let {body: listRes} = await client
        .list('monitoring.coreos.com/v1', 'Probe', 'default');
    console.log(Object.entries(listRes.items[0]));
    /* monitoring.coreos.com/v1:Probe ✅
    [
      [ 'apiVersion', 'monitoring.coreos.com/v1' ],
      [ 'kind', 'Probe' ],
      [ 'metadata', {...} ],
      [ 'spec', {...} ],
    ]
    */

    let {body: readRes} = await client.read({
        apiVersion: 'monitoring.coreos.com/v1',
        kind: 'Probe',
        metadata: {
            name: 'foo',
            namespace: 'default'
        },
    });
    console.log(Object.entries(readRes));
    /* core/v1:Probe ❌
    [
      [ 'exec', undefined ],
      [ 'failureThreshold', undefined ],
      [ 'grpc', undefined ],
      [ 'httpGet', undefined ],
      [ 'initialDelaySeconds', undefined ],
      [ 'periodSeconds', undefined ],
      [ 'successThreshold', undefined ],
      [ 'tcpSocket', undefined ],
      [ 'terminationGracePeriodSeconds', undefined ],
      [ 'timeoutSeconds', undefined ]
    ]
    */
}

main();

Environment (please complete the following information):

• OS: MacOs
• NodeJS Version: 18.5.0

Additional context list() correctly returns the object as-is for custom object types. I suppose it matches the full version string, instead of just the v1 part.

[brendandburns]

I'll see if I can reproduce this. I suspect that there is some special casing for v1 APIs which is messing this up.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.