Lesson 08 — Resource Limits

Learning Objectives

By the end of this lesson, you will be able to:

Understand Kubernetes Resource Requests and Limits
Learn how CPU and Memory resources are managed
Prevent resource exhaustion attacks
Protect Kubernetes clusters from noisy neighbour workloads
Understand Quality of Service (QoS) classes
Implement Resource Limits in Amazon EKS
Apply enterprise workload governance best practices

Why This Matters

Kubernetes clusters often host hundreds or even thousands of applications.

Every application competes for shared resources such as:

CPU
Memory (RAM)
Storage
Network bandwidth

Without proper resource controls, a single container can consume excessive resources and negatively impact the entire cluster.

This may result in:

Slow applications
Pod crashes
Node failures
Denial-of-Service (DoS)
Unstable production environments

Resource Requests and Limits help ensure workloads receive the resources they need while preventing individual containers from monopolizing cluster capacity.

What are Resource Requests and Limits?

Kubernetes provides two mechanisms to manage compute resources.

Resource Control	Purpose
Request	Minimum resources guaranteed to the container
Limit	Maximum resources the container is allowed to consume

These settings help Kubernetes schedule workloads efficiently while enforcing fair resource usage.

Resource Requests

A Request tells Kubernetes the minimum amount of CPU and memory that a container requires.

Example:

Application

↓

Requests

↓

500m CPU

↓

512Mi Memory

The Kubernetes Scheduler uses these values when selecting a suitable worker node.

Resource Limits

A Limit defines the maximum amount of CPU or memory that a container may consume.

Example:

Application

↓

Maximum Allowed

↓

1 CPU

↓

1Gi Memory

The container cannot exceed these configured limits without consequences.

CPU Requests and Limits

CPU resources are measured in cores or millicores (m).

Examples:

Value	Meaning
1000m	1 CPU Core
500m	0.5 CPU
250m	0.25 CPU
100m	0.1 CPU

Example configuration:

resources:
  requests:
    cpu: "500m"
  limits:
    cpu: "1"

Memory Requests and Limits

Memory resources are measured in bytes.

Common units include:

Value	Meaning
Mi	Mebibytes
Gi	Gibibytes

Example:

resources:
  requests:
    memory: "512Mi"
  limits:
    memory: "1Gi"

Memory limits help prevent applications from consuming excessive RAM.

How Kubernetes Uses Requests

The Scheduler evaluates available resources before placing a Pod.

Pod

↓

CPU Request

↓

Memory Request

↓

Scheduler

↓

Suitable Node

Only nodes with sufficient available resources receive the workload.

What Happens When CPU Limits are Reached?

CPU behaves differently from memory.

When CPU usage exceeds the configured limit:

Application

↓

High CPU Usage

↓

CPU Throttling

↓

Application Slows Down

The container is not terminated but is restricted from consuming additional CPU time.

What Happens When Memory Limits are Reached?

Memory limits are stricter.

Application

↓

Consumes Too Much Memory

↓

Memory Limit Exceeded

↓

Out of Memory (OOM)

↓

Container Terminated

The Kubernetes runtime terminates the container to protect the node.

Denial-of-Service (DoS) Prevention

Without Resource Limits:

Application

↓

Consumes All CPU

↓

Consumes All Memory

↓

Other Applications Fail

With Resource Limits:

Application

↓

Maximum Resource Limit

↓

Additional Usage Blocked

↓

Other Applications Continue Running

Resource Limits help reduce the impact of accidental or malicious resource exhaustion.

Noisy Neighbour Problem

A noisy neighbour occurs when one workload consumes excessive resources and affects others.

Node

├── Application A

├── Application B

└── Application C

↓

Application B Consumes Everything

↓

Applications A & C Slow Down

Requests and Limits ensure fair resource allocation.

Quality of Service (QoS) Classes

Kubernetes automatically assigns a Quality of Service (QoS) class based on resource configuration.

QoS Class	Description
Guaranteed	Requests and Limits are equal
Burstable	Requests are lower than Limits
BestEffort	No Requests or Limits defined

Guaranteed workloads receive the highest scheduling priority during resource pressure.

QoS Example

Guaranteed

↓

Critical Banking API

-------------------

Burstable

↓

Web Applications

-------------------

BestEffort

↓

Development Tools

Critical production applications should normally use the Guaranteed QoS class.

LimitRange

A LimitRange defines default Requests and Limits for Pods within a Namespace.

Benefits include:

Consistent workload configuration
Prevents unlimited containers
Simplifies developer onboarding
Enforces minimum and maximum resource usage

ResourceQuota

A ResourceQuota limits total resource consumption within a Namespace.

Example controls:

Total CPU
Total Memory
Maximum number of Pods
Persistent Volume Claims
ConfigMaps
Secrets

ResourceQuotas help prevent one team or application from consuming excessive cluster resources.

Amazon EKS Architecture

Developer

↓

Git Repository

↓

CI/CD Pipeline

↓

Amazon EKS API Server

↓

Resource Validation

↓

Scheduler

↓

Worker Node

↓

Application

Requests and Limits become part of every production deployment.

Enterprise Example

A financial services organization operates multiple Amazon EKS clusters hosting customer-facing applications.

The organization enforces:

CPU Requests on every Pod
Memory Requests on every Pod
CPU Limits
Memory Limits
Namespace ResourceQuotas
Namespace LimitRanges

Critical payment services use the Guaranteed QoS class, while internal tools operate using the Burstable class.

This ensures stable performance even during periods of high demand.

Common Risks

Cloud Security Engineers frequently identify:

Missing CPU Requests
Missing Memory Requests
Unlimited CPU usage
Unlimited memory allocation
BestEffort Pods in production
Missing ResourceQuotas
Missing LimitRanges
Resource exhaustion attacks
Noisy neighbour workloads
Poor capacity planning

These issues increase operational instability and security risks.

Enterprise Monitoring

Security and platform teams should monitor:

CPU utilization
Memory utilization
OOMKilled events
CPU throttling
Namespace quota usage
ResourceQuota violations
LimitRange violations
Pod restart counts
Node resource pressure
Kubernetes Events

Monitoring resource usage helps identify performance bottlenecks before they impact production.

Enterprise Implementation Strategy

A recommended rollout:

Step 1

↓

Inventory Existing Workloads

↓

Step 2

↓

Measure Resource Usage

↓

Step 3

↓

Define Requests

↓

Step 4

↓

Define Limits

↓

Step 5

↓

Configure LimitRanges

↓

Step 6

↓

Apply ResourceQuotas

↓

Step 7

↓

Validate in CI/CD

↓

Step 8

↓

Continuously Monitor

This phased approach improves stability while minimizing disruption.

Best Practices

As a Kubernetes Security Engineer:

Configure CPU and Memory Requests for every production workload.
Define CPU and Memory Limits for every container.
Avoid deploying BestEffort Pods in production.
Use the Guaranteed QoS class for mission-critical applications.
Implement Namespace LimitRanges and ResourceQuotas.
Continuously monitor CPU throttling and OOMKilled events.
Validate resource configurations during CI/CD.
Review Requests and Limits regularly based on actual workload usage.
Prevent noisy neighbour issues through proper resource governance.
Combine Resource Limits with Pod Security Standards and Security Contexts for comprehensive workload protection.

Resource governance is essential for maintaining secure, stable and predictable Kubernetes environments.

Real-World Scenario

A software company hosts an online retail platform on Amazon EKS.

A newly deployed analytics service contains a bug that causes an infinite processing loop.

Without Resource Limits:

CPU usage reaches 100%
Memory consumption grows continuously
Other customer-facing applications become unresponsive
Multiple nodes experience resource pressure

Fortunately, the analytics service is configured with:

CPU Requests and Limits
Memory Requests and Limits
Namespace ResourceQuota

Once the service reaches its CPU limit, Kubernetes throttles CPU usage.

When the application exceeds its memory limit, the container is terminated and automatically restarted.

Customer-facing services continue operating normally because resource governance prevents the faulty application from consuming all cluster resources.

Key Takeaways

After completing this lesson, you should understand:

The purpose of Resource Requests and Limits
How Kubernetes schedules workloads
CPU throttling and memory enforcement
Denial-of-Service prevention
Noisy neighbour protection
Kubernetes Quality of Service (QoS) classes
Namespace LimitRanges and ResourceQuotas
Enterprise monitoring and governance best practices

Resource Requests and Limits are fundamental Kubernetes controls that improve both security and reliability. By enforcing fair resource allocation, preventing resource exhaustion and integrating governance into Amazon EKS deployments, organizations can build resilient, scalable and secure container platforms.

Knowledge Check

Question 1

What is the purpose of a Kubernetes Resource Request?

A. Define the maximum resources a container may consume
B. Define the minimum resources guaranteed to a container
C. Configure network bandwidth
D. Encrypt application traffic

Answer: B

Question 2

What happens when a container exceeds its CPU limit?

A. The container is immediately terminated.
B. Kubernetes throttles CPU usage.
C. The Pod is automatically deleted.
D. The node shuts down.

Answer: B

Question 3

What typically happens when a container exceeds its memory limit?

A. Kubernetes increases the limit automatically.
B. The container is terminated with an Out of Memory (OOM) event.
C. CPU throttling occurs.
D. The workload is moved to another node.

Answer: B

Question 4

Which Kubernetes QoS class provides the highest level of resource guarantee?

A. BestEffort
B. Burstable
C. Guaranteed
D. Standard

Answer: C

Question 5

Which combination represents enterprise best practice?

A. Deploy production workloads without Requests or Limits.
B. Configure CPU and Memory Requests and Limits, use ResourceQuotas and LimitRanges, and continuously monitor resource usage.
C. Allow unlimited memory for all containers.
D. Use BestEffort QoS for mission-critical applications.

Answer: B

What’s Next?

In the next lesson, you will learn about Runtime Security, exploring how Kubernetes detects suspicious activity while containers are running, monitors runtime behaviour, identifies threats such as container escapes and malware, and integrates with enterprise security tools to protect Amazon EKS workloads.

➡️ Next Lesson: Lesson 09 — Runtime Security