Skip to main content
Mapagam

Configuring Resource Management

1. Setting CPU Requests

Property Value Description
requests.cpu 500m Amount of CPU requested by the container
limits.cpu 1000m Maximum amount of CPU the container can use

Example: Setting CPU Requests in a Pod

apiVersion: v1
kind: Pod
metadata:
  name: cpu-pod
spec:
  containers:
  - name: cpu-container
    image: nginx
    resources:
      requests:
        cpu: "500m"
      limits:
        cpu: "1000m"

2. Setting Memory Requests

Property Description Value Type Default
resources.requests.memory Defines the guaranteed amount of memory a Pod will receive string None
resources.limits.memory Defines the maximum amount of memory a Pod can use string None

Example: Setting Memory Requests in a Pod Spec

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
  - name: memory-container
    image: nginx
    resources:
      requests:
        memory: "64Mi"
      limits:
        memory: "128Mi"
Note: Memory requests and limits are specified in bytes. You can use suffixes like K, M, G for kilobytes, megabytes, and gigabytes respectively.
Warning: If a Pod's memory usage exceeds its limit, it will be terminated by the OOM (Out-of-Memory) killer.

3. Setting CPU Limits

Property Value Description
requests.cpu 500m Minimum CPU resources requested by the container
limits.cpu 1000m Maximum CPU resources allowed for the container

Example: CPU Limits in Pod Spec

apiVersion: v1
kind: Pod
metadata:
  name: cpu-limited-pod
spec:
  containers:
  - name: app-container
    image: nginx
    resources:
      requests:
        cpu: "500m"
      limits:
        cpu: "1000m"
Note: CPU limits are specified in millicores (m). 1000m = 1 CPU core.

4. Setting Memory Limits

Resource Value Description
memory 512Mi Memory limit for the container
memory 1Gi Memory limit in gigabytes
memory 1024Mi Memory limit in mebibytes

Example: Setting Memory Limits in a Pod

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
  - name: memory-container
    image: nginx
    resources:
      limits:
        memory: "512Mi"
      requests:
        memory: "256Mi"
Note: Memory limits should be set to prevent a container from consuming all available memory on a node.

5. Understanding Resource Units

Unit Description Examples Notes
millicores (m) 1/1000th of a CPU core 500m, 2000m Used for CPU requests and limits. 1000m = 1 CPU core
bytes (B) Base unit for memory 1024B, 1048576B Not commonly used; prefer more readable units
kibibytes (Ki) 1024 bytes 512Ki, 1024Ki Used for memory requests and limits
mebibytes (Mi) 1024 KiB 256Mi, 1024Mi Used for memory requests and limits
gibibytes (Gi) 1024 MiB 1Gi, 2Gi Used for memory requests and limits
tebibytes (Ti) 1024 GiB 1Ti, 2Ti Used for memory requests and limits

Example: Resource Requests and Limits in Pod Spec

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: app-container
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
Note: CPU units are always specified in millicores (m) and memory units can use Ki, Mi, Gi suffixes.

6. Configuring LimitRange

Property Description Values Notes
limitRange.spec.limits Array of limit definitions [{type: 'Container'|'PersistentVolumeClaim', default: {}, defaultRequest: {}}] Each limit defines resource constraints
limitRange.spec.limits.type Scope of the limit 'Container' or 'PersistentVolumeClaim' Defines whether limits apply to containers or PVCs
limitRange.spec.limits.default Default resource limits {cpu: '100m', memory: '128Mi'} Applied to containers without explicit limits
limitRange.spec.limits.defaultRequest Default resource requests {cpu: '100m', memory: '128Mi'} Applied to containers without explicit requests

Example: LimitRange Configuration

apiVersion: v1
kind: LimitRange
metadata:
  name: container-limits
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 250m
      memory: 256Mi
    type: Container
Note: LimitRange is applied per namespace and affects all pods in that namespace unless overridden.

7. Setting ResourceQuota

Property Description Values Notes
hard.cpu Hard limit for CPU usage 1000m 1000m = 1 CPU core
hard.memory Hard limit for memory usage 2Gi 2 Gibibytes
hard.pods Hard limit for number of pods 10 Total pods in namespace
hard.services.loadbalancers Hard limit for LoadBalancer services 2 Number of LoadBalancer services allowed
hard.services.nodeports Hard limit for NodePort services 5 Number of NodePort services allowed

Example: ResourceQuota YAML Definition

apiVersion: v1
kind: ResourceQuota
metadata:
  name: example-quota
  namespace: production
spec:
  hard:
    cpu: "1000m"
    memory: 2Gi
    pods: "10"
    services.loadbalancers: "2"
    services.nodeports: "5"
Note: ResourceQuota limits are enforced at the namespace level and apply to all resources within that namespace.

8. Viewing Resource Usage

Command Description Example
kubectl top node Display CPU and memory usage for nodes kubectl top node
kubectl top pod Display CPU and memory usage for pods kubectl top pod
kubectl top pod -n <namespace> Display resource usage for pods in a specific namespace kubectl top pod -n production

Example: Resource Usage Output

NODE           CPU(cores)   CPU%   MEMORY     MEMORY%
minikube       150m         7%     340Mi      12%
worker-node-1  90m          4%     280Mi      10%
Note: The kubectl top command requires a resource usage monitoring solution like Metrics Server to be installed in the cluster.

Key Points

  • kubectl top is used to view real-time resource usage.
  • It provides CPU and memory consumption for nodes and pods.
  • Resource usage is displayed in cores and MiB.
  • Requires Metrics Server to be installed for accurate data.

9. Understanding QoS Classes

QoS Class Description Guaranteed Resources Usage Notes
Guaranteed Pods where all containers have CPU and memory limits set to the same value as requests Full resource allocation guaranteed High priority for scheduling and eviction; no resource sharing with other pods
Burstable Pods where containers have CPU or memory requests less than limits, or only one resource specified Minimum requested resources guaranteed Lower priority than Guaranteed; may be evicted under resource pressure
BestEffort Pods where containers have no CPU or memory requests or limits specified No guaranteed resources Lowest priority; most likely to be evicted under resource pressure

Example: QoS Class Determination

apiVersion: v1
kind: Pod
metadata:
  name: qos-pod
spec:
  containers:
  - name: app-container
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
Note: The QoS class is determined by comparing resource requests and limits across all containers in a Pod. A Pod is Guaranteed only if every container has matching requests and limits for both CPU and memory.

QoS Class Summary

  • Guaranteed: All containers have matching CPU and memory requests/limits
  • Burstable: Containers have limits higher than requests or only one resource specified
  • BestEffort: No CPU or memory requests/limits specified

10. Setting Priority Classes

Field Description Example
metadata.name Name of the PriorityClass high-priority
value Integer value determining priority (higher = more priority) 1000000
globalDefault Set to true to make this the default priority class for all pods without a specified class false
description Human-readable description of the priority class Used for critical system pods

Example: Creating a PriorityClass

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "Used for critical system pods"
Note: Priority classes are used to influence pod scheduling order. Pods with higher priority values are scheduled before those with lower values.

11. Configuring Pod Disruption Budgets

Example: Basic PDB Configuration

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: nginx
Field Description Values
apiVersion API version of the PDB resource policy/v1
kind Kind of the resource PodDisruptionBudget
metadata.name Name of the PDB String
spec.minAvailable Minimum number of pods that must remain available during disruptions Integer or Percentage (e.g., 50%)
spec.maxUnavailable Maximum number of pods that can be unavailable during disruptions Integer or Percentage (e.g., 25%)
spec.selector Label selector to identify pods managed by this PDB Object
Note: minAvailable and maxUnavailable are mutually exclusive. You must define one or the other, but not both.

Example: PDB with maxUnavailable

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: redis-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: redis

Key Points

  • PDBs prevent voluntary disruptions like node drains or upgrades from taking down too many pods at once.
  • Use minAvailable or maxUnavailable, not both.
  • Pods must be selected by a label selector to be managed by the PDB.
  • Pods must have a stable identity (e.g., not from a Job or StatefulSet without proper labeling).

12. Using Extended Resources

Resource Type Description Usage Example Notes
example.com/gpu Custom GPU resource for specialized hardware 
resources:
  limits:
    example.com/gpu: "1"
  requests:
    example.com/gpu: "1"
 Requires custom device plugin
example.com/fpga Field-Programmable Gate Array resource 
resources:
  limits:
    example.com/fpga: "2"
  requests:
    example.com/fpga: "2"
 Used for hardware acceleration tasks

Example: Requesting Extended Resource in Pod Spec

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  containers:
  - name: gpu-container
    image: nvidia/cuda:11.0-base-ubuntu20.04
    resources:
      limits:
        example.com/gpu: "1"
      requests:
        example.com/gpu: "1"
Note: Extended resources must be registered with the kubelet via a DevicePlugin before they can be used in pods.
Warning: Using extended resources without proper device plugins will result in pods stuck in Pending state.

Was this article helpful?

Related Cheat Sheets