Sharing a machine is cheap and efficient, right up to the moment everyone wants the same thing at once.

The problem of sharing

A Kubernetes cluster is a pool of machines called nodes, and each node runs many pods side by side. Running many programs on one machine is the whole point, because it saves money and keeps hardware busy. But a machine has only so much CPU time and so much memory. When the programs on it collectively ask for more than exists, something must give.

Two very different things can happen. If the shortage is about CPU, programs simply run more slowly because they take turns on the processor. If the shortage is about memory, there is no polite way to share. Memory is either available or it is not, and when it runs out, the machine must stop some program to free it. Without a plan, the system would choose a victim by chance, and the unlucky one might be your payment service while a harmless test job survives.

What QoS actually is

A Quality of Service class is a label that Kubernetes attaches to every pod, summarising how firmly that pod has reserved the resources it uses. There are exactly three labels: Guaranteed, Burstable and BestEffort. The label is not decorative. The kubelet, which is the agent running on each node, and the Linux kernel underneath both consult it when deciding how to arrange control groups, which process to stop first when memory runs out, and which pods to remove when the node is under pressure.

The most surprising thing for newcomers is that you never write the class yourself. There is no field called “qosClass” that you set. Instead, Kubernetes works it out from the way you described your pod’s resource needs. Change those descriptions, and the class changes with them. This design is clever, because it ties the safety level directly to the promises you were willing to make.

A story of a bad night

You cannot understand QoS without first understanding the two numbers every container can carry.

Each container in a pod may declare how much CPU and memory it needs. Kubernetes gives you two knobs for each resource. The request is the amount you are asking Kubernetes to set aside for you, and it is what the scheduler uses to decide where a pod fits. The limit is the ceiling that the container is not allowed to exceed. Between those two numbers lies a range where the container can use extra if it is available.

How CPU and memory behave differently

The node’s real budget

A node with sixteen gigabytes of memory does not offer all sixteen to pods. The operating system needs some, the kubelet and container runtime need some, and Kubernetes keeps a safety buffer so that it can react before memory truly runs out. What remains is the allocatable amount, and that is the budget the scheduler works against. Understanding this budget explains why a node that looks half empty can still refuse a new pod.

Guaranteed, Burstable and BestEffort: three promises of increasing flexibility and decreasing protection.

flowchart TD
    A["Look at every container in the pod"] --> B{"Does any container have any CPU or memory request or limit?"}
    B -->|"No"| C["BestEffort"]
    B -->|"Yes"| D{"Does every container have CPU and memory limits, with requests equal to limits?"}
    D -->|"Yes"| E["Guaranteed"]
    D -->|"No"| F["Burstable"]
        

The diagram shows the order of the questions. First Kubernetes asks whether the pod mentioned resources at all. If it said nothing anywhere, the pod is BestEffort. If it said something, the next question is whether it said everything and said it strictly: all containers, both resources, request equal to limit. A perfect answer gives Guaranteed. Every other partial answer lands in the middle as Burstable.

A side-by-side view

Why not make everything Guaranteed?

It is tempting to ask for the strongest class everywhere. The catch is cost. A Guaranteed pod reserves its full ceiling at all times, even when it is idle, and the scheduler cannot hand that capacity to anyone else. Run enough Guaranteed pods and your nodes look full on paper while the machines sit mostly idle. Burstable and BestEffort exist because sharing unused capacity is where most of the savings in a cluster come from.

The rules look simple, but small details quietly change the outcome.

Every container counts, including the helpers

The class belongs to the whole pod, not to a single container, so Kubernetes inspects every container. That includes init containers, which run first to prepare the pod, and the long-running helper containers often called sidecars. For a pod to be Guaranteed, each of them must have both CPU and memory limits, with the requests matching. One forgotten helper is enough to push the whole pod down to Burstable.

Worked examples in words

A newer option: pod-level resources

Recent Kubernetes versions have been adding the ability to describe resources for the pod as a whole, not only per container. This can simplify pods with many small helpers, because a single pod-level budget can be set. The feature is newer and still maturing across versions, so check your cluster’s release notes to see whether it is available and how it influences the class on your version before relying on it.

Kubernetes does not enforce anything by itself. It writes your intentions into Linux control groups, and the kernel does the rest.

What is a control group?

A control group, usually shortened to cgroup, is a Linux feature for putting processes into a bucket and attaching rules to the bucket: how much CPU time it gets, how much memory it may hold, how many processes it may create. Buckets can sit inside other buckets, forming a tree, and rules at the top apply to everything below. Containers are, at the bottom, just processes placed in the right cgroup buckets.

The QoS-shaped tree

The kubelet builds a family of cgroups that mirror the QoS classes. All pods live under one top bucket for Kubernetes workloads. Inside it, Burstable pods and BestEffort pods each have their own sub-bucket, while Guaranteed pods sit directly under the top bucket, side by side with those sub-buckets. Each pod then has its own bucket, and each container its own below that.

flowchart TD
    A["All Kubernetes pods bucket"] --> B["Guaranteed pod buckets"]
    A --> C["Burstable parent bucket"]
    A --> D["BestEffort parent bucket"]
    C --> E["Burstable pod buckets"]
    D --> F["BestEffort pod buckets"]
    B --> G["Container buckets"]
    E --> G
    F --> G
        

This shape has a purpose. Putting BestEffort pods in a shared sub-bucket with a very small CPU weight means that, when the node is busy, all of them together can only take a tiny slice, while Guaranteed and Burstable pods keep their reserved shares. The tree makes the class a real property of the machine, not just a label.

How requests and limits become kernel settings

The surprising behaviour of CPU limits

A CPU limit does not mean “you may use at most this fraction of the machine at any moment.” It means a budget of CPU time per tiny period, commonly a tenth of a second. A container with a limit of one core that runs on four threads at once can burn through its whole period budget in a quarter of the period and then be paused for the rest. The result can be sudden pauses, called throttling, even when the node as a whole is nearly idle. This is why CPU limits are a hot topic in latency-sensitive systems, and we will return to it later.

When memory runs out, the Linux kernel plays judge. QoS classes quietly influence its verdict.

Two ways a container dies from memory

People often use “OOMKilled” and “evicted” as if they meant the same thing. They do not, and the difference is essential for debugging. A container is OOMKilled when the kernel’s out-of-memory killer ends its process, either because the container hit its own memory limit or because the whole node ran out of memory. A pod is evicted when the kubelet, acting earlier and more politely, decides to remove it to relieve pressure on the node.

How the kernel picks its victim

Every Linux process has an out-of-memory score. When memory is exhausted, the kernel tends to stop processes with the highest score first. Kubernetes adjusts these scores using a setting called the OOM score adjustment, and it chooses the number according to the pod’s QoS class. This is how the class becomes a direct instruction to the kernel.

Reading the Burstable formula without fear

The Burstable calculation sounds technical but behaves intuitively. Start from the maximum score of one thousand and subtract a portion proportional to how much memory the pod requested compared with the whole machine. A tiny request subtracts almost nothing and leaves the pod near the top, close to BestEffort. A large request subtracts a lot and moves the pod toward the protected end. The result is clamped so that Burstable pods always stay above the Guaranteed range and below the BestEffort range.

The practical message is simple: for Burstable pods, setting an honest memory request is not only a scheduling hint, it is also a protection setting. A pod that requests too little memory looks cheap to the kernel and is stopped sooner, even if it is a very important service.

The kubelet would rather remove a pod gently than wait for the kernel to start swinging.

Why the kubelet acts first

The kernel’s out-of-memory killer is a last resort. It acts only when memory is already gone, and it picks processes, not whole pods, which can leave half-broken applications behind. To avoid this, the kubelet watches the node’s health continuously and starts removing pods when certain signals cross configured thresholds, ideally before the kernel has to step in. This process is called node-pressure eviction.

Soft and hard thresholds

Each signal can have two kinds of threshold. A soft threshold gives the node a grace period: if the signal stays bad for the whole period, the kubelet begins evicting pods and gives them time to shut down cleanly. A hard threshold has no grace at all: the moment the signal is crossed, the kubelet evicts pods immediately, stopping them without waiting. Kubernetes ships with sensible hard defaults, for example evicting when available memory drops below roughly one hundred mebibytes, though the exact defaults vary by version and operating system.

Who gets chosen: the real ranking

Here is where many articles oversimplify. It is often said that BestEffort pods are evicted first, then Burstable, then Guaranteed. The reality is slightly different and more interesting. The kubelet ranks candidate pods using three questions, in this order.

Notice that the class itself is not a step in the ranking. It matters indirectly, because the class determines how likely a pod is to exceed its request. A Guaranteed pod, whose limit equals its request, can never use more than it requested, so it is almost never at the front of the queue. A Burstable pod that is quietly staying under its request is also safe, while a Burstable pod that has stretched far beyond its request is a prime target. BestEffort pods almost always exceed their zero request, so they land at the front.

flowchart TD
    A["Node signal crosses a threshold"] --> B["Kubelet reclaims node-level resources such as unused images"]
    B --> C{"Still under pressure?"}
    C -->|"No"| D["Done, no pods removed"]
    C -->|"Yes"| E["Rank pods: usage above request, then priority, then size of overuse"]
    E --> F["Evict the top-ranked pod"]
    F --> G{"Pressure relieved?"}
    G -->|"No"| E
    G -->|"Yes"| H["Stop evicting"]
        

What happens around an eviction

Evicted pods are marked as failed with a reason of Evicted, and a message that explains which resource was short. The node reports a pressure condition, such as memory pressure, for a period of time. While that condition is active, the kubelet refuses to start new BestEffort pods on that node, and the scheduler is discouraged from sending more. This protects the node from a pile-on while it recovers.

Two details surprise teams. First, node-pressure evictions do not consult PodDisruptionBudgets, the rules that limit voluntary disruptions, because the kubelet is acting to save the node, not to move workloads politely. Second, evicted pods are not restarted on the same node; a controller such as a deployment creates a replacement that the scheduler places elsewhere, so spare capacity in the cluster matters.

These three words are constantly confused. Pulling them apart will save you hours of debugging.

Quality of Service describes how firmly a pod has reserved CPU and memory. Priority is a separate number you attach to a pod through a PriorityClass to say how important it is compared with others. Preemption is an action the scheduler takes: when a high-priority pod cannot find room, it may remove lower-priority pods to make space. Each idea answers a different question, and each is controlled by different settings.

They really are independent

You can have a BestEffort pod with the highest priority, a Guaranteed pod with the lowest priority, and every combination between. The scheduler’s preemption logic looks at priority and at the pod’s requests, not at its QoS class. The kernel’s memory logic looks at QoS-derived scores, not at priority. The kubelet’s eviction ranking combines usage versus requests with priority. Only by understanding all three can you predict what happens in a crisis.

Built-in critical priorities

Kubernetes defines two special priority classes for essential components: one for cluster-level services and one for node-level services. Pods with these priorities are very hard to preempt and the kubelet tries hard to keep them running. They are meant for the system’s own parts, such as networking and DNS, and ordinary applications should not use them, since overuse defeats their purpose.

The scheduler is a bookkeeper. It adds up requests, ignores limits and never looks at the QoS class.

What the scheduler counts

When a new pod needs a home, the scheduler examines each node and asks whether the sum of requests of the pods already there, plus the new pod’s request, still fits within the node’s allocatable amount. If yes, the node is a candidate. Limits play no part in this arithmetic, and neither does the class. This single fact explains most “why is my node full when it looks idle?” mysteries: the node is full of promises, not of usage.

The gap between requests and limits is your overcommit

Because the scheduler counts only requests, the total of limits on a node can far exceed its capacity. This is overcommit, and it is deliberate. Most applications spend most of their time well below their limits, so allowing the gaps to overlap lets you pack more workloads on fewer machines. The risk is that if too many pods rise toward their limits together, the node runs short, and the QoS machinery we have studied decides who pays the price.

flowchart LR
    A["Pod asks for a home"] --> B["Scheduler adds up requests on each node"]
    B --> C{"Does the total fit within allocatable?"}
    C -->|"Yes"| D["Node is a candidate"]
    C -->|"No"| E["Node is skipped"]
    D --> F["Scoring picks the best candidate"]
    E --> F
    F --> G["Pod is bound to the chosen node"]
        

How classes shape your overcommit appetite

A cluster made only of Guaranteed pods has no overcommit and no surprises, but also no sharing, so it tends to be expensive. A cluster full of BestEffort pods packs tightly but is fragile. Most healthy clusters blend them: Guaranteed for the heart of the business, Burstable for the bulk, and BestEffort for work that can be lost without regret.

CPU is forgiving, but the way it is forgiving can create some of the most puzzling performance problems in Kubernetes.

Requests are weights, limits are ceilings

When the CPU is idle, every container may use as much as it wants, unless a limit says otherwise. When the CPU is contended, the kernel divides time among containers according to their weights, which Kubernetes derives from CPU requests. A container requesting twice the CPU of its neighbour gets roughly twice the time under pressure. This is why even a Burstable pod with a tiny CPU request can become sluggish on a crowded node: its small weight gives it a small slice.

Throttling and the limits debate

CPU limits are enforced with a quota per short period, and a container that uses up its quota is paused until the next period. For programs with many threads or with sudden bursts of work, this can add small but noticeable delays to individual requests, even when the node has plenty of idle CPU. Teams running latency-sensitive services have argued for years about whether to set CPU limits at all.

There is no single right answer. A common middle path is to set CPU requests carefully, leave CPU limits off for latency-sensitive Burstable services, and keep memory limits in place because memory, unlike CPU, is not compressible. The cost of that choice is that those pods cannot be Guaranteed, since the Guaranteed class demands limits for both resources. Whatever you choose, measure throttling directly and decide with data.

Exclusive cores for the most demanding workloads

Some workloads, such as high-frequency trading, telecom packet processing and machine learning, suffer when the operating system moves their threads between processor cores. Kubernetes offers a CPU manager with a static policy that can dedicate whole cores to a container. This only applies to Guaranteed pods whose CPU request is a whole number. Such containers receive exclusive cores that no other container on the node uses, which removes interference from neighbours and cache churn.

A companion component, the topology manager, can also try to keep a container’s CPU and memory on the same hardware region, called a NUMA node, which avoids slower cross-region memory access. These features show that the Guaranteed class is not only about protection. It is also the doorway to special hardware-aware placement.

Memory numbers can be confusing, because the machine uses memory for more than your program’s own data.

What counts toward the limit

A container’s memory use includes the data your program holds, but also file cache the kernel keeps to speed up disk reads, and memory used by in-memory temporary volumes. Cache is generally reclaimable, so the kernel can drop it when pressure rises, and it does not by itself push a container over its limit. The measurement the kubelet cares about most is the working set: the memory that is truly in active use and cannot easily be taken back. Eviction decisions are based on this number, not on the raw total.

Memory-backed temporary volumes

A common trap is a temporary volume stored in memory. It behaves like a small fast disk but its contents consume memory that counts against the container’s limit. A pod that writes large files into such a volume can be OOMKilled even though its program data is small. If your workload needs large scratch space, use disk-backed temporary storage instead.

Programs that know their limits

Language runtimes decide how much memory to claim based on what they think is available. Older runtimes read the whole machine’s memory instead of the container’s limit, and then happily grow past it. Modern versions of Java and Go can read container limits, and settings exist to cap the heap at a safe fraction of the limit. A good rule is to leave headroom between the runtime’s heap ceiling and the container’s limit, because runtimes also use memory for threads, buffers and code.

Newer memory features and swap

On nodes using the newer version of control groups, an optional feature called memory quality of service can use the memory request to protect that amount from being reclaimed and can apply soft throttling before the hard limit. It is an advanced option that has matured gradually across versions, so verify its status for your release.

Kubernetes also gained support for swap space on nodes. In the common limited mode, only Burstable pods are allowed to use swap, in proportion to their memory request. Guaranteed pods and BestEffort pods are kept out, and so are pods with high priority. The reasoning is that Guaranteed workloads want predictable performance, while BestEffort workloads have no reservation to justify a share. If you enable swap, QoS class suddenly decides who may use it.

QoS classes look only at CPU and memory. Other resources have their own rules, and mixing them up leads to nasty surprises.

The class does not care about disk

A pod can declare requests and limits for ephemeral storage, which is the temporary disk space used for the container’s writable layer, its logs and temporary volumes. These numbers matter for scheduling and for eviction, but they are not part of the QoS class calculation. A pod with perfect CPU and memory settings is Guaranteed even if it says nothing about storage, and a pod with careful storage settings but no CPU or memory settings is still BestEffort.

Disk pressure and evictions

When a node’s disk fills up, the kubelet first tries to reclaim space by removing unused images and dead containers. If that is not enough, it evicts pods, ranking them by how much they exceed their ephemeral storage requests and by priority. A noisy pod that writes endless logs or fills its temporary volume can bring down its neighbours’ ability to run, which is why setting limits on ephemeral storage is a good habit for any workload that writes data.

Process limits

Each node has a finite supply of process identifiers, and a buggy program that creates processes in a loop can exhaust them, breaking every pod on the node. Kubernetes lets operators set a limit on the number of processes per pod and monitors the node-wide supply as an eviction signal. This is a protection against a different kind of noisy neighbour, one that does not show up in CPU or memory charts until it is too late.

QoS only works as well as the node underneath it is set up. A few kubelet settings decide how much room workloads really get.

The allocatable formula

The amount of CPU and memory that pods may use on a node is not the machine’s full size. Kubernetes starts from the node’s capacity and subtracts three things: a reservation for Kubernetes’ own components such as the kubelet and container runtime, a reservation for the operating system’s essential services, and the hard eviction threshold, which is the safety buffer the kubelet wants to keep free. What is left is the allocatable amount, and it is the budget that the scheduler spends.

Why reservations are a stability feature

Without reservations, a burst of workload memory can push out the kubelet itself. When the kubelet is unhealthy, it cannot report on pods, cannot enforce eviction and may be marked unreachable by the control plane, causing a cascade of rescheduling. Setting honest reservations means the node’s own tools survive the storms that the QoS system is trying to manage. A common starting point is to reserve a small fixed amount plus a percentage that grows with node size, then adjust using measurements from your own machines.

Special kinds of pods and how they are counted

Relying on every developer to set resources correctly is hope, not a plan. Namespace rules turn good habits into defaults.

LimitRange: automatic defaults and boundaries

A LimitRange is a namespace-level rule that does two helpful things. It can fill in default requests and limits for containers that forgot to set them, and it can enforce minimum and maximum values, or a maximum ratio between a container’s limit and its request. Because it acts when the pod is created, it directly changes the QoS class the pod ends up with. A namespace with sensible defaults will almost never produce an accidental BestEffort pod.

ResourceQuota: a budget for the whole namespace

A ResourceQuota sets a total budget for a namespace: the sum of requests and limits for CPU and memory, the number of pods, and more. When a quota covers CPU or memory, every new pod in the namespace must declare those values or be rejected, unless a LimitRange supplies defaults. The pair works well together: the quota sets the total, and the LimitRange makes sure each pod arrives with numbers attached.

Quota scopes that understand QoS

Quotas can be scoped to apply only to certain kinds of pods. Two scopes relate directly to QoS: one matches BestEffort pods and the other matches all pods that are not BestEffort. The BestEffort scope can only limit the number of such pods, since they have no resource numbers to add up. This allows a platform team to say, for example, “this namespace may run at most five BestEffort pods, but may reserve up to forty cores for everything else.”

Autoscalers make decisions based on the numbers you wrote down. Wrong numbers lead to wrong scaling.

Horizontal scaling reads requests

The horizontal pod autoscaler adds or removes pod copies to keep a target level of utilization. When that target is a percentage of CPU or memory, the percentage is measured against the pod’s request. This has two consequences. A pod with no request, such as a BestEffort pod, cannot be scaled by utilization at all, because there is nothing to compare usage against. And a request that is far too large or too small distorts the scaling: a bloated request makes the pod look idle and prevents scaling up, while a tiny request makes it look overloaded and causes needless scale-outs.

Vertical scaling recommends better numbers

The vertical pod autoscaler studies real usage and recommends, or applies, new requests and limits. It is a valuable tool for finding honest numbers, especially for services whose needs drift over time. Applying new values usually means recreating pods, so plan for the brief disruption, and keep in mind that changing the numbers may change the pod’s QoS class. Use recommendation-only mode first, and review the results before letting it act automatically.

Resizing pods in place

Newer versions of Kubernetes allow certain resource changes on a running pod without restarting it. This is a big improvement for steady, stateful workloads, but it comes with an important rule: the QoS class must not change during a resize. A Guaranteed pod must remain Guaranteed, so you cannot resize it in a way that makes requests differ from limits. If the new shape would change the class, you need to replace the pod.

Node scaling follows requests too

The cluster autoscaler, and similar node provisioning tools, add machines when pods are stuck pending for lack of room. Their decisions are based on pod requests, exactly like the scheduler. They do not add nodes because pods are using a lot of memory, only because requests do not fit. If your pods ask for far more than they use, you will pay for nodes that sit mostly idle; if they ask for far less, nodes will feel crowded without any scale-out.

The right class is the cheapest one that still lets you sleep at night.

flowchart TD
    A["New workload"] --> B{"Would losing it for a few minutes hurt the business?"}
    B -->|"Yes, severely"| C{"Needs steady latency or exclusive cores?"}
    B -->|"Somewhat"| D["Burstable with honest requests and memory limits"]
    B -->|"No"| E{"Can it restart safely and run anywhere?"}
    C -->|"Yes"| F["Guaranteed with whole-number CPU requests"]
    C -->|"No"| G["Guaranteed or Burstable with high requests and priority"]
    E -->|"Yes"| H["BestEffort or Burstable with tiny requests and low priority"]
    E -->|"No"| D
        

The diagram is a starting point, not a law. Follow the questions: how bad is a short loss, does the workload need steady performance, and can it tolerate being restarted on another node. The answers point toward a class, and you can adjust from there based on cost and the experience of running it.

Typical workloads and their natural homes

You cannot protect what you cannot see. Make QoS visible on dashboards and in daily operations.

Finding a pod’s class

Every pod shows its class in its status. The standard description command prints it in a line labelled “QoS Class,” and a query on the pod’s status field can list classes across a whole namespace. Metrics exporters such as kube-state-metrics also publish the class as a metric, so you can group and filter dashboards by it. Make it a habit to check the class on a running pod, not just on the file you wrote, because injected containers and namespace defaults may have changed the result.

The signals worth watching

Useful alerts

When a pod disappears or crawls, a calm sequence of questions finds the cause faster than guessing.

Symptom to cause lookup

When many teams share nodes, resource settings stop being a private matter and become a question of fairness and safety.

The noisy neighbour

A noisy neighbour is a workload that consumes so much of a shared resource that others suffer. With CPU, the harm is slowness. With memory, the harm is kills and evictions. With disk and process counts, the harm is node-wide failures. QoS classes, requests, limits and quotas are the tools that keep one tenant’s problem from becoming everyone’s problem.

Resource settings as a security control

Unbounded workloads are an easy way to cause an outage, whether by accident or by attack. A compromised pod that spins the CPU, allocates memory without end or floods the disk with data can take down a node, and thereby harm neighbours. Memory and storage limits, process limits and quotas turn these attacks into contained incidents. Treat missing limits as a security gap, not only as an efficiency problem.

The teams that handle QoS well repeat a few good habits. The teams that suffer repeat a few famous mistakes.

Patterns that work

Anti-patterns to avoid

If you keep only one chapter for your next design review, keep this one.

A review checklist you can reuse

Classes are not only a safety tool. They are one of the strongest levers on your cloud bill.

Where the money goes

Cloud nodes are billed by the hour whether they are busy or idle. Because the scheduler fills nodes based on requests, every unit of request you declare becomes a unit of capacity you pay for. A request that is twice what a service needs doubles that service’s cost, even though the machine sits half empty. Guaranteed pods lock in the most capacity, since their ceiling is their reservation, while Burstable and BestEffort pods let you pack more work onto the same hardware.

Four levers for balanced capacity

A simple planning method

The same three classes appear in very different industries, always solving the same problem of sharing without chaos.

No. Kubernetes derives the class from the requests and limits of the containers. To change the class, change those settings and recreate the pod, because the class cannot be edited on an existing pod.

Every container, including init and sidecar containers, must have CPU and memory limits and requests, with each request equal to its limit. If a container sets only limits, the requests default to the same values.

It is a sensible default for most services. The risk depends on how far its usage rises above its request, because that gap decides how likely it is to be chosen during pressure. Honest requests keep that risk small.

They will not be evicted because of another pod’s consumption. They can still be removed if node agents exceed their reserved resources and nothing less important remains, and they can still be OOMKilled if they exceed their own memory limit.

No. The scheduler checks that the sum of requests fits the node’s allocatable resources. It does not use limits or classes for placement. Priority, however, does influence scheduling and preemption.

OOMKilled means the Linux kernel stopped a container’s process for lack of memory. Evicted means the kubelet removed a whole pod to relieve node pressure. They have different causes, different messages and different recovery behaviour.

Not necessarily. CPU limits protect neighbours and are required for Guaranteed, but they can cause throttling that hurts latency. Many teams set CPU requests and memory limits, and add CPU limits only where there is a clear reason. Measure throttling to decide.

Most often because a container added by a mesh, security or logging tool lacks matching limits and requests, or because a LimitRange changed a value. Inspect all containers on the running pod, not just your manifest.

No. The class is computed only from CPU and memory. Ephemeral storage has its own requests, limits and eviction rules, and devices such as GPUs are handled through extended resources.

They are independent. Priority says how important a pod is for scheduling, preemption and eviction ranking. QoS describes how firmly resources are reserved and influences kernel kill preference. Align them for important workloads.

No. In-place resizing, where available, must keep the same QoS class. If you want a different class, replace the pod with a new one that has the new settings.

The scheduler counts requests, not usage. A node whose pods have requested all its allocatable room is full on paper, even if real usage is low. Right-sizing requests frees that room.

Yes, for disposable and experimental work that can be stopped without harm, ideally with low priority and a quota on how many such pods a namespace may run. It is a poor choice for anything users depend on.

Horizontal scaling by utilization measures usage against requests, so pods without requests cannot use it. Node autoscalers add machines when requests cannot be placed. Honest requests make both work properly.

Combine a LimitRange for defaults, a ResourceQuota for budgets, and an admission policy that rejects production pods without memory limits. Add alerts for unexpected BestEffort pods and a regular review of usage against requests.

Kubernetes nodes are shared and deliberately overcommitted, so there will be moments when the promises made cannot all be kept. Quality of Service classes are the plan that decides what happens in those moments. Guaranteed pods have reserved exactly what they use and are protected most, Burstable pods have a reserved floor and room to stretch, and BestEffort pods have reserved nothing and give way first. The class is derived automatically from requests and limits, turned into control groups and kernel scores, and combined with priority and usage to guide the kubelet’s evictions. Treat the numbers you write as promises, keep them honest, and use classes to spend protection where an outage would hurt and to share capacity everywhere else.