Demo Resource Allocation

In this lesson you’ll add resource requests and limits to the carts-db Deployment (part of the Sock Shop demo) so the container has guaranteed CPU/memory and a capped memory usage. Below is a complete Deployment manifest that shows where to add resources.requests and resources.limits, along with the container image, ports, environment variables, and an in-memory emptyDir volume.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: carts-db
  labels:
    name: carts-db
spec:
  replicas: 1
  selector:
    matchLabels:
      name: carts-db
  template:
    metadata:
      labels:
        name: carts-db
    spec:
      nodeSelector:
        beta.kubernetes.io/os: linux
      containers:
        - name: carts-db
          image: centos/mongodb-34-centos7
          resources:
            requests:
              memory: "64Mi"
              cpu: "250m"
            limits:
              memory: "128Mi"
          ports:
            - name: mongo
              containerPort: 27017
          env:
            - name: MONGODB_USER
              value: sock-user
            - name: MONGODB_PASSWORD
              value: password
            - name: MONGODB_DATABASE
              value: data
            - name: MONGODB_ADMIN_PASSWORD
              value: admin
          volumeMounts:
            - mountPath: /tmp
              name: tmp-volume
      volumes:
        - name: tmp-volume
          emptyDir:
            medium: Memory

What this manifest configures:

Requests: cpu: "250m", memory: "64Mi" — guaranteed resources used by the scheduler when placing the Pod.
Limits: memory: "128Mi" — maximum memory the container may use. (No CPU limit specified here, so the container can burst CPU beyond 250m if node capacity allows.)

Summary table

Setting	Purpose	Example
Request (cpu)	Scheduling guarantee for CPU	`250m`
Request (memory)	Scheduling guarantee for memory	`64Mi`
Limit (memory)	Maximum memory the container can use	`128Mi`

How to apply this in the OpenShift web console

Open the OpenShift console in your course environment: https://learn.kodekloud.com/user/courses/openshift-4.
In the Administrator view navigate to Workloads → Deployments.
Click Create Deployment and switch to the YAML editor.
Paste the manifest above and create the Deployment.

A Red Hat OpenShift web console screenshot showing the "Deployments" page for the "default" project with the message "No Deployments found" and a blue "Create Deployment" button. The left-hand navigation menu and administrator header are also visible.

After creating the Deployment, OpenShift will create the Pod for it. Wait a moment — the Deployments page should show the Deployment with one running pod:

Status: 1 pod running

A screenshot of the Red Hat OpenShift web console showing the "carts-db" deployment details in the default project. A circular status chart shows one running pod for that deployment.

Inspect the Pod to confirm it’s Running and to view the applied resource settings. From the Pod details page you can open the Pod YAML and confirm the resources block is present.

A screenshot of the Red Hat OpenShift web console showing the Pod details page for "carts-db-dff84c9cd-cnhsv" in the default project with status "Running." The left sidebar shows the Administrator menu with Workloads → Pods selected.

Example excerpt from the PodSpec (what you should see in the Pod YAML):

containers:
  - name: carts-db
    resources:
      limits:
        memory: 128Mi
      requests:
        cpu: 250m
        memory: 64Mi

Why use requests and limits?

Requests ensure the scheduler reserves node capacity for your Pod.
Limits prevent containers from consuming excessive resources and impacting other workloads.
Omitting CPU limits allows CPU bursting, but scheduling still uses the request value.

For cluster-wide enforcement, use ResourceQuotas (Kubernetes) or project quotas (OpenShift) to enforce aggregate limits per namespace so you don’t have to set requests/limits on every single Deployment manually. See:

Kubernetes ResourceQuotas: https://kubernetes.io/docs/concepts/policy/resource-quotas/
OpenShift documentation: https://docs.openshift.com/

Resource requests reserve capacity on a node and influence scheduling; limits cap the maximum usage. Setting sensible requests and limits helps cluster stability and prevents noisy neighbors. If you omit a CPU limit, the container may burst CPU usage (subject to the node’s available CPU) but the scheduler will use the request value when placing the Pod.

Introduction

Pre-Requisite – Docker and Kubernetes

Getting Started with OpenShift

OpenShift Concepts – Projects and Users

Concepts – Builds and Deployments

Networks, Services, Routes and Scaling

Storage, Templates and Catalog

OpenShift Security

Conclusion and APPENDIX

Demo Resource Allocation

Watch Video