Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Plain kubectl top tells you how much CPU and memory a pod is using right now. It does not tell you what that pod asked for or how much it is allowed to use, so you cannot judge whether a number is high. ferctl top, a small Go command-line tool described by its author Fer Rios, puts usage, requests, limits, and percent-of-limit in one pod-level table. This article explains what each column means in Kubernetes terms, how to read the percentage correctly, and where the approach has limits of its own.
Usage, requests, and limits are three different things
Most confusion about pod resources comes from treating these three values as one. They answer different questions.
- Usage is what the pod consumes at the moment you measure it. Kubernetes exposes this through the Metrics API, which is populated by Metrics Server.
- Request is the amount the scheduler reserves for the pod when it decides which node can take it. It is a placement input, not a measurement.
- Limit is the ceiling set in the pod spec that the kubelet and container runtime enforce.
A pod can use more than its request and still be well below its limit. That is normal and often healthy. The useful question is how far current usage sits from the limit, because that gap determines how much headroom the pod has before enforcement kicks in.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What Kubernetes actually enforces
Requests and limits are declared per container in the container’s resources block. Kubernetes also supports pod-level requests and limits when the relevant feature is enabled on your cluster version. For a given resource, the pod-level values are generally described as the sum across the pod’s containers, so check your version’s behavior before relying on pod-level fields in a report.
#1 Best Overall
Enforcement differs by resource, and the difference matters when you read a percentage:
- Memory above the limit leads to the container being terminated, typically reported as an out-of-memory kill.
- CPU above the limit leads to throttling. The container keeps running but gets less CPU time. A CPU limit does not kill the pod.
- Memory above the request does not affect scheduling. The scheduler only counts requests when it decides whether another pod fits on a node.
So a memory percentage near 100% is a warning sign of a kill risk, while a CPU percentage near 100% usually means slower responses rather than a crash.
What ferctl top shows
According to the write-up, the command adds requests and limits to the table that kubectl top already produces. Compare the two invocations:
Recommended Free Tools
- Run
kubectl top pods -n productionto see current CPU and memory per pod. The output contains usage columns only. - Run
ferctl top -n productionto see the same usage beside each pod’s CPU and memory requests and limits, plus a percent-of-limit value and a status indicator. - Add
--warning-percentto set the percentage at which a row is flagged. The threshold is your own setting; it is not a Kubernetes standard. - Use all-namespace mode to scan the same view across the cluster, if your kubeconfig permits it.
The write-up describes a Go implementation with a command layer, Kubernetes clients, and a runner that matches listed pods with their metrics. Flag names and output columns here are as the write-up describes them. They have not been checked against the source repository, so confirm them against the version you install.
Reading the percent-of-limit column
The write-up’s worked example is a pod using 490 MiB of memory against a 512 MiB limit. It shows that as 95% and marks it critical. The arithmetic is 490 ÷ 512 ≈ 95.7%, so the displayed figure is truncated rather than rounded. Whether that is intended is a detail to confirm in the code.
The example is illustrative. It is not a measured incident, and it does not show that a 95% reading always leads to a restart. A pod at that level has little room for a spike, which is why it deserves a look, but whether it actually fails depends on the workload’s real memory behavior over time.
Rank #3
When a limit is not set
If a pod has no memory limit, the write-up says ferctl top displays 0Mi and 0%. Read those zeros as “no configured limit.” They are a display convention, not a report that the pod uses no memory. A percentage column is only meaningful for rows that have a limit, so filter or sort on the limit column first when you audit a namespace with mixed configuration.
Where the status flag comes from
The flag reflects the threshold you pass in. A row that crosses your chosen percentage is marked, but the flag does not tell you whether the threshold is appropriate for that workload. Pick values based on your own history and on the restart and throttling behavior you have seen.
When metrics are missing or stale
Both views depend on Metrics Server. The official kubectl reference states: “This command requires Metrics Server to be correctly configured and working on the server.” If the table is empty or shows no usage, work through these checks in order:
- Confirm Metrics Server is running in the
kube-systemnamespace and its pods are ready. - Run
kubectl top nodes. If that fails, the problem is the metrics pipeline, not the pod. - Wait a few minutes after creating a new pod. The kubectl reference notes that pod metrics can be unavailable for a short time after creation because of pipeline delay.
- Check that the pod is actually running. Metrics are not available for pods that are not running.
The write-up does not describe how ferctl displays rows when metrics are missing for some pods but not others, so do not assume a blank value means zero usage.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Where the approach has gaps
A pod-level view is only as complete as its aggregation. The write-up does not establish how ferctl handles init containers, pod-level resource fields, or every container edge case. Init containers run to completion before the main containers start, so their requests and limits can differ from what a steady-state table suggests. Ask whether a given version accounts for them before using the totals in a capacity decision.
Free tools Windows power users keep installed
One-click scans. No signup required.
The separate howardjohn/kubectl-resources plugin is an existing alternative with configurable aggregation levels. Its README states that it does not account for init containers. That limitation belongs to that plugin and is not established for ferctl.
Best Value
| Aspect | kubectl top |
ferctl top (as described in the write-up) |
kubectl-resources (per its README) |
|---|---|---|---|
| Current CPU and memory usage | Yes | Yes | Not stated |
| Requests and limits beside usage | No | Yes, per pod | Yes, with configurable aggregation |
| Percent of limit | No | Yes, when a limit exists | Not stated |
| Display when no memory limit is set | Not applicable | 0Mi and 0% |
Not stated |
| Init containers | Not stated | Not stated | Not accounted for |
| Metrics prerequisite | Metrics Server must be working | Relies on the same metrics path (not separately stated) | Not stated |
The verdict
Use ferctl top when your question is “how close is this pod to its configured limit?” and you want the answer in one table rather than by running kubectl describe and kubectl top side by side. Treat the percentage as a prompt to investigate, not a diagnosis. Confirm the command’s behavior on your Kubernetes version, check init-container handling before using totals for capacity planning, and remember that a zero limit display means no limit is configured.
For an official reference on the underlying data, see the Kubernetes documentation on resource management for pods and containers and the generated kubectl reference for the top command.
Quick Recap
The Bottom Line
“”
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →
