Inconsistent deserialization behaviour when using KubernetesObjectApi.list vs KubernetesObjectApi.get

[LFrobeen]

Describe the bug
The data returned by KubernetesObjectApi.list() does not deserialize timestamps in the items[].metadata field which makes the results inconsistent with KubernetesObjectApi.get(). As a result, the returned manifests cannot directly be used with the KubernetesObjectApi.patch() method because the string-based timestamps will be rejected.

This issue might be related to the changes in #1695.

Client Version
0.22.1

Server Version
v1.30.5

Steps to Reproduce & Example Code

The following code snippet reproduces the problem. The code tries to list VirtualServices and thus requires istio to be installed. However, the problem can be reproduced with any other resource kind that is not known to the kubernetes/client-node package.

import { KubeConfig, KubernetesObjectApi } from '@kubernetes/client-node';

const TEST_RESOURCES = {
  VirtualService: {
    apiVersion: 'networking.istio.io/v1',
    kind: 'VirtualService',
    namespace: 'default',
    name: 'my-service',
  },
  Pod: {
    apiVersion: 'v1',
    kind: 'Pod',
    namespace: 'default',
    name: 'my-pod',
  },
};

(async () => {
  const kc = new KubeConfig();
  kc.loadFromDefault();

  const client = KubernetesObjectApi.makeApiClient(kc);

  // const { apiVersion, kind, name, namespace } = TEST_RESOURCES.Pod; // known resource kinds work as expected
  const { apiVersion, kind, name, namespace } = TEST_RESOURCES.VirtualService; // "unknown" resource kinds have inconsistent timestamp types

  await client.list(apiVersion, kind, namespace);

  const pod1 = await client
    .list(apiVersion, kind, namespace)
    .then((response) => response.body.items.find((p) => p.metadata?.name === name)!);

  const pod2 = await client
    .read({ apiVersion, kind, metadata: { namespace, name } })
    .then((response) => response.body);

  // Types of timestamps will be different when listing VirtualServices
  console.log(pod1.metadata?.creationTimestamp, pod1.metadata?.creationTimestamp?.constructor.name);
  console.log(pod2.metadata?.creationTimestamp, pod2.metadata?.creationTimestamp?.constructor.name);

  console.log();
})();

Expected behavior
The above code should print the same line twice, e.g.:

2023-07-19T12:59:47.000Z Date
2023-07-19T12:59:47.000Z Date

However, when listing VirtualServices (or any other resource that isn't known to this package) the timestamp types in the metadata are different, e.g.:

2023-07-19T12:59:47Z String
2023-07-19T12:59:47.000Z Date

Environment:
Probably happens on any environment. For completeness, this is my test environment:

• OS: MacOS
• NodeJS Version: 18
• Cloud runtime: GKE

[brendandburns]

I think that this is because we aren't passing type information down here:

https://github.com/kubernetes-client/javascript/blob/master/src/object.ts#L478

requestPromise takes an optional type parameter, but we're not passing it.

If you want to investigate further, we'd be happy to take PRs to fix this.

[LFrobeen]

Hi @brendandburns I might try to tackle this in the coming days.

In my project, I've fixed the issue by checking whether the package's list implementation returns deserialized objects or just plain objects. In the latter case I'm running the KubernetesObject deserialization logic on the elements of the items array manually.

I think the problem is basically that the KubernetesObjectSerializer has a fallback for unknown response types which handles read responses just fine, but does not have special logic for list responses.

I have noticed that the implementation is aware of some list response types, e.g. there is V1PodList.

My approach would be to define a generic list type, e.g. V1KubernetesObjectList (like this KubernetesObject type) that specifies the type of items to be a KubernetesObject array.

If I understand correctly, passing an explicit / generic type parameter to requestPromise would override the deserialization behaviour for known resource types like V1Pod in a V1PodList. Would it make sense to add an additional parameter like typeFallback to requestPromise and potentially KubernetesObjectSerializer that would be used if there is no known type for a apiVersion/kind combination?

That way I'm hoping to keep backwards compatibility for the known list types, and ensure unknown response types are treated consistently in the list and get implementations.

[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