Long-Term Fix for Pod Eviction on GKE

A monitoring alert fires at 3 AM — the team's GKE Pods are being evicted. Investigation shows node memory is at 98%. Pods without resource requests are being evicted first. What is the long-term fix to prevent evictions?

Quick Answer

The answer is to add explicit memory requests and optionally limits to all Pod specs. This is the correct long-term fix for GKE pod eviction under memory pressure because without resource requests, Pods are classified as BestEffort or Burstable under Kubernetes’ Quality of Service (QoS) classes, making them the first to be evicted by the kubelet when node memory hits 98%. By defining memory requests, you give the scheduler the data it needs to place Pods only on nodes with sufficient available memory, preventing overcommitment at the scheduling level rather than just reacting to evictions. On the Google Associate Cloud Engineer exam, this scenario tests your understanding of Kubernetes resource management and QoS tiers—a common trap is choosing a short-term fix like increasing node size or adding more replicas, which doesn’t address the root cause of missing requests. Memory tip: “No request means no rest”—Pods without requests are always first to be evicted under pressure.

⚠ Common exam trap

Google Cloud often tests the misconception that raising limits or adding capacity is the fix, but the real issue is the absence of requests, which prevents the scheduler from making informed placement decisions and leaves Pods in the lowest QoS class.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Add explicit memory requests (and optionally limits) to all Pod specs

B is correct because setting explicit memory requests ensures the Kubernetes scheduler can accurately place Pods on nodes with sufficient resources, preventing the node from being overcommitted. Without requests, Pods are treated as burstable or best-effort, making them the first candidates for eviction under the kubelet's Quality of Service (QoS) classes when node memory pressure hits 98%. This is a long-term fix because it enforces proper resource governance at the scheduling level, not just a reactive measure.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Set higher memory limits on the Pods being evicted
Why it's wrong here
Memory limits cap consumption but do not reserve memory, so the scheduler still treats these Pods as requesting zero and evicts them first under node pressure. Limits suit containing runaway workloads; requests are what guarantee schedulable memory and determine eviction priority.
✓
Add explicit memory requests (and optionally limits) to all Pod specs
Why this is correct
Without memory requests, Pods are classified BestEffort, so the kubelet evicts them first under node memory pressure. Declaring explicit memory requests makes each Pod Burstable or Guaranteed, giving the scheduler accurate placement data and the kubelet a defined eviction ranking.
✗
Disable node-level eviction by modifying kubelet configuration
Why it's wrong here
Disabling kubelet eviction removes the safety mechanism that reclaims memory before the node becomes unstable, risking kernel OOM kills of critical processes. Kubelet eviction thresholds exist to protect node stability; tuning them is valid only alongside proper resource requests and limits.
✗
Add more nodes to the cluster to increase available memory
Why it's wrong here
Adding nodes increases cluster capacity but leaves Pods without resource requests, so the scheduler still cannot reserve memory and kubelet continues evicting them under pressure. Extra nodes suit genuine capacity shortfalls, not the missing requests causing this eviction pattern.

Go deeper

1 more way this is tested on ACE

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. Your GKE application's pods are being evicted frequently during periods of high traffic. You notice that pods without resource requests are being evicted first. The nodes are running at ~85% memory utilization. What should you do to reduce pod eviction?

medium

✓ A.Set memory requests and limits for all pods to match their actual memory usage.
B.Increase the node machine type to have more memory.
C.Configure pod disruption budgets (PDBs) to prevent eviction.
D.Enable cluster autoscaler to add nodes before memory pressure occurs.

Why A: Setting memory requests and limits for all pods to match their actual memory usage ensures that the Kubernetes scheduler can accurately allocate resources and make informed scheduling decisions. Without requests, pods are treated as BestEffort QoS class, making them the first candidates for eviction under memory pressure (when nodes exceed ~85% utilization). By defining requests, pods are classified as Burstable or Guaranteed, which gives them higher priority during eviction and prevents unnecessary disruptions.

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.

Long-Term Fix for Pod Eviction on GKE

Why each option matters

Option-by-option breakdown

Related to this question

1 more way this is tested on ACE