Display units - memory and CPU

Kubius lets you choose how CPU and memory values are displayed in resource-usage charts, container request / limit cells, and node tables. Open Settings ▸ Display to pick the format that suits you.

The setting only affects how values are formatted for display. It never changes the YAML or the data the cluster reports - when you open a YAML viewer or copy a resource, you’ll see whatever the cluster actually stores (which is usually whatever the original author wrote).

Memory

Memory in Kubernetes is most often expressed in either decimal (powers of 10) or binary (powers of 2) units. They look similar but they’re different sizes.

Megabytes (MB) - decimal

• 1 MB = 1,000,000 bytes (10⁶)
• The convention you’ll see in marketing copy, disk drives, network bandwidth, and the SI standard.
• Use this when you want round, human-friendly numbers and aren’t comparing against memory hardware directly.

Mebibytes (Mi) - binary, the K8s convention

• 1 Mi = 1,048,576 bytes (2²⁰)
• Labelled Mi in the Display settings panel because that’s exactly how Kubernetes writes it in YAML - resources.requests.memory: 256Mi. Same value as the formal SI symbol MiB (mebibyte).
• This is the convention you’ll see across nearly every production manifest - official K8s docs, Helm charts (bitnami, prometheus-community, cert-manager, ArgoCD, nginx-ingress, etc.), kustomize bases, kubelet eviction thresholds.
• Matches what RAM hardware physically is - DIMMs are sized in powers of 2, and the Linux kernel reports memory in KiB / MiB / GiB.
• Use this when you want display values to match what you’ll find in most YAML and what the kernel actually sees.
• 256 Mi and 256 MB are not the same - Mi is about 4.86% larger.

K8s shorthand (M) - decimal SI, no space

• Same value as MB (decimal, 10⁶) but written compactly with no space: 512M, 2G, 4T.
• Kubernetes YAML accepts this form too - resources.requests.memory: 256M is valid and means 256,000,000 bytes (not 268,435,456).
• Less common in practice than Mi - most Helm charts and official examples lean binary. Pick this if you specifically want decimal sizing in YAML, or if your team has standardised on M.

Why the difference matters

If you wrote memory: 256M in your YAML, that’s 256,000,000 bytes. If Kubius displayed that as Mi, you’d see 244 Mi - which is the same number of bytes but written using the binary unit. Same memory, two correct labels. Pick the one that matches how you think about your workloads.

The Right-Sizing recommendation YAML follows your choice too. Pick Mi and recommendations come out as memory: 97Mi; pick M and they come out as memory: 97M. Both are valid K8s; the rounding is granular enough that the actual byte count is within a unit either way.

CPU

CPU in Kubernetes is always fractions of a CPU core. Every display option in Kubius is the same underlying number - just formatted four different ways.

Format	Looks like	What it is
%	50%	Percentage of one CPU core. 100% = one whole core.
Decimal	2.5	Raw fraction of cores, no label.
Cores	2.5 cores	Same as Decimal, with the unit spelled out.
m	500m	Millicores - 1000m equals one core. This is what K8s YAML uses for requests / limits.

Pick m if you want display values to match what you write in YAML. Pick % or Cores if you want a more human-readable picture of usage relative to capacity.

CPU has no decimal-vs-binary ambiguity, so there’s nothing equivalent to the memory MB/MiB distinction here.

Where these preferences apply

• Resource usage charts - Y-axis ticks, hover tooltip, and the live values row beneath each chart
• Pod / Deployment / StatefulSet / DaemonSet detail views - gauge values, requested / limit cells
• Node detail - Resources table (used / requested / allocatable / capacity)
• Node Diagnostics - memory consumers table, CPU pressure tile, top consumers

YAML viewers always show the raw cluster-stored value (256M, 512Mi, 1500m, etc.). The display preference doesn’t rewrite YAML.

See also

• Metrics - how Kubius collects and stores the values being formatted here
• Right-Sizing - when applying recommendations, the format you’ve chosen affects how the gauges read but the patch sent to the cluster still uses the canonical K8s units