kubectl
kubectl copied to clipboard
kubernetes
The resources.limits.memory unit is automatically converted. Why cannot the unit be displayed as configured?
What happened?
When resources.limits.memory is set to 1237.3Mi, the actual pod is 1297403084800 m by running the kubectl command, which is difficult to understand.
What did you expect to happen?
Resources.limits.memory can be displayed based on the configured value and unit.
How can we reproduce it (as minimally and precisely as possible)?
Set resources.limits.memory to 1237.3Mi and run the kubectl command to check the value.
Anything else we need to know?
No response
Kubernetes version
$ kubectl version
# paste output here
1.31
Cloud provider
OS version
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here
# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
Install tools
Container runtime (CRI) and version (if applicable)
Related plugins (CNI, CSI, ...) and versions (if applicable)
This issue is currently awaiting triage.
If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
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.
I think this helps us to understand what is the actual limit , if it shows in mentioned unit , the value will only show till particular decimal places.
but there has been mention of why Mi value usage created some issue like : https://github.com/kubernetes/kubernetes/issues/128684
/sig api-machinery
/remove-sig storage node api-machinery /sig cli
/transfer kubectl
IMO, the choice of conversion function (for display) is one made by the kubectl tool
Can you provide a reproduction of what you are talking about? Do you mean on the pod definition if you create deployment using kubectl apply or create? Or possibly describe?
/remove-sig storage node api-machinery /sig cli
/transfer kubectl
IMO, the choice of conversion function (for display) is one made by the
kubectltool
I also want to know where the code for the conversion function is. Can you tell me
Can you provide a reproduction of what you are talking about? Do you mean on the pod definition if you create deployment using kubectl apply or create? Or possibly describe?
When kubectl is used to create a deployment, its resources.limits.memory is set to 1237.3Mi. However, when kubectl is used to view the deployment, 1297403084800m is displayed.
If I understand this correctly, you ran kubectl to create a pod and set the limit to said number.
So something like from example
kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=1237.3Mi
Then you did kubectl describe and the response came back as bytes and not as Mi?
Here is a somewhat related issue #1597
Looks like it comes back from the api-server that way.
Maybe it can be made into some sort of a preference to always show human readable.
Just to clarify, this isn't something that is set or handled by kubectl. kubectl sends the configuration to the api server, which then creates the object and stores it in the etcd database. When kubectl subsequently requests more details from the server about the resource it simply takes what the api server responds with and displays it without modification. kubectl doesn't keep track of the objects it stores, and the api server does it's best to display units in human readable formats, but it won't round numbers and will always respond with the most precision possible, and because you have created this object with a decimal value of a base 2 unit it causes some unfortunate conversions which results in a very human unfriendly number.
Anyway, let me ask everyone their opinion on a human readable flag for describe output. I don't think we would accept one for get but describe seems fine to me.
I had a WIP PR that introduced a function to convert computed values to a human-readable format. This is controlled by a hardcoded boolean for now. Once @mpuckett159-ias 's comment is addressed, we could implement a configurable command-line flag for in a follow-up PR.
Sorry that's my work account and I have a bad habit of not switching on my phone. It was discussed in the meeting and we decided that we could move forward. This is gonna be an annoying fix, because we'll need this function to do the conversion which is easy but we'll need to do it in a lot of different places. Also this won't address the core of this issue but there's no way for us to address it so having a human readable flag is the closest option we have.
@mpuckett159 thanks for the quick reply! If I understand the code correctly, the describe cmd takes values from HTTP response(?) and leverage this String() function to convert the value, especially the CanonicalizeBytes method. If we could make the String() to convert input to human readable string, then it will be applied to all places(within describe). I'm not entirely sure I've got that right, could you explain in more detail when you mentioned: we'll need this function to do the conversion which is easy but we'll need to do it in a lot of different places? Thanks a lot!
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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