Kubectl: sort-by not sorting as expected

[skuxy]

What happened: When using sort-by on certain fields, output is sorted unexpectedly

What you expected to happen: Proper numerical sort on resource request fields

How to reproduce it (as minimally and precisely as possible):

On kubectl get pods -A -o=custom-columns='CPU:.spec.containers[*].resources.requests.cpu,MEM:.spec.containers[*].resources.requests.memory,NAME:.metadata.name' --sort-by='.spec.containers[0].resources.requests.cpu'

Following output is returned (cropped massively):

<none> <none> some-pod 2 8Gi some-pod <none> <none> some-pod <none> <none> some-pod <none> <none> some-pod 2 8Gi some-pod 1 6Gi some-pod 1 6Gi some-pod 1 6Gi some-pod 10m <none> some-pod 10m <none> some-pod 10m <none> some-pod 10m <none> some-pod 10m <none> some-pod 10m <none> some-pod 10m <none> some-pod 10m <none> some-pod 10m <none> some-pod 50m 100Mi some-pod 50m 32Mi some-pod 50m 32Mi some-pod

Expected behaviour was to show larger requests (2 and 1 full vCPU) below 10 and 50 milicpus.
Also, pods without requests are just randomly thrown around at the beginning of the output.

Anything else we need to know?:

Environment:

• Kubernetes client and server versions (use kubectl version):
  Also on server version 19.
  Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.4", GitCommit:"d360454c9bcd1634cf4cc52d1867af5491dc9c5f", GitTreeState:"archive", BuildDate:"2020-11-25T13:19:56Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.12-eks-7684af", GitCommit:"7684af4ac41370dd109ac13817023cb8063e3d45", GitTreeState:"clean", BuildDate:"2020-10-20T22:57:40Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}
• Cloud provider or hardware configuration:
• OS (e.g: cat /etc/os-release): Arch Linux

[skuxy]

Please note: I am quite aware this is same behaviour I'd get by using sort on a particular column, but that is exactly why I didn't want to use that command in this case :)

[eddiezane]

There might be a bug with custom columns. Could even be a TODO somewhere in there to fix it.

/triage accepted
/help
/priority backlog

[k8s-ci-robot]

@eddiezane:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

There might be a bug with custom columns. Could even be a TODO somewhere in there to fix it.

/triage accepted
/help
/priority backlog

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/test-infra repository.

[lauchokyip]

I was able to reproduce the bug, will take a look 😃

[lauchokyip]

/assign

[lauchokyip]

@eddiezane @soltysh @dougsland
I have digged into it and found the issue lies inside here https://github.com/kubernetes/kubectl/blob/0223f3fef06550cd3783f8044f0bd7f96d8dd954/pkg/cmd/get/sorter.go#L265-L268

.spec.containers[*].resources.requests.cpu are detected as string, and because the package is using natural sort package (https://github.com/fvbommel/sortorder/blob/master/natsort.go). I tried to add a test case to compare 100m and 1 over here (https://github.com/fvbommel/sortorder/blob/26fad50c6b32a3064c09ed089865c16f2f3615f6/natsort_test.go#L28) the expected output is 1 < 100m.

The same goes for memory because memory（https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory） because memory is using (E, P, T, G, M, K), so MiB will go before GiB.

How should we go for that? Should I use a regex and check if it's a memory or CPU, then convert them into float. Other strings just use the natural sort?

[eddiezane]

Synced up with @lauchokyip. They're going to take a look at parsing into a Quantity and sorting off of that.