Articles

Minikube Resources: Set CPU and Memory Limits (2026)

April 18, 2026 6 min read

Minikube’s default resource allocations are surprisingly stingy, often leading to performance issues and unexpected application restarts if you’re not actively managing them.

Let’s see what happens when we don’t set resources, and then how we fix it.

Imagine you’ve got a simple web app running in Minikube. You deploy it, and it seems to work fine.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-web-app
  template:
    metadata:
      labels:
        app: my-web-app
    spec:
      containers:
      - name: web
        image: nginx:latest
        ports:
        - containerPort: 80

You check kubectl get pods. Everything’s Running. But then, you start hitting it with a few requests. Suddenly, kubectl get pods shows your pod as Evicted or OOMKilled. What gives?

The problem is that Minikube, by default, is often configured with very limited CPU and memory. When your application, even something as simple as Nginx, starts consuming more resources than the node (which is your local machine, effectively) has available for its Kubernetes components, the scheduler starts making tough decisions. It might decide to evict your pod to make room for other system-level Kubernetes processes that are deemed more critical.

Let’s say you’re running Minikube with default settings on a machine that’s already a bit taxed. The Kubernetes control plane, the Kubelet running on your Minikube node, and your application are all competing for the same limited pool of CPU and RAM. When an application’s demand exceeds its allocated (or in this case, unallocated) resources, and the node itself is under pressure, the Kubelet might terminate the process. This is often signaled as an Out-Of-Memory (OOM) kill.

Here’s how you can diagnose and fix this, covering the most common culprits:

1. Check the Node’s Actual Resource Availability (and Minikube’s Configuration)

Before blaming your app, check what Minikube is actually configured to give itself.

  • Diagnosis: Run minikube ssh and then top -b -n 1 | grep -E 'kubelet|docker|containerd' to see what the node is using. More importantly, check Minikube’s VM settings. If you started Minikube with minikube start --cpus 1 --memory 2048, that’s your baseline. If you didn’t specify, it’s likely much lower (e.g., 1 CPU, 2GB RAM).
  • Fix: Stop Minikube (minikube stop) and restart it with more resources. For a development machine, minikube start --cpus 4 --memory 8192 (4 CPUs, 8GB RAM) is a good starting point.
  • Why it works: This allocates more raw CPU and RAM to the virtual machine that Minikube runs in, giving the Kubernetes components and your pods more breathing room.

2. Set Resource Requests and Limits on Your Pods

This is the most direct way to manage your application’s resource consumption within Kubernetes.

  • Diagnosis: Your pod is OOMKilled or Evicted, and kubectl describe pod <pod-name> shows an OOMKilled status or a reason like Evicted.

  • Fix: Add resources to your container spec:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-web-app
  template:
    metadata:
      labels:
        app: my-web-app
    spec:
      containers:
      - name: web
        image: nginx:latest
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "100m" # 0.1 CPU core
          limits:
            memory: "128Mi"
            cpu: "200m" # 0.2 CPU cores

  • Why it works: requests tell Kubernetes the minimum amount of resources your pod needs to be scheduled. limits tell Kubernetes the maximum amount of resources your pod can consume. If a pod exceeds its memory limit, it will be OOMKilled. If it exceeds its CPU limit, it will be throttled. This prevents runaway processes from starving other pods or the system.

3. Check for Resource-Hungry System Pods

Sometimes, it’s not your app, but the Kubernetes components themselves that are hogging resources.

  • Diagnosis: After restarting Minikube with more resources and setting pod limits, you still see issues. Run kubectl top nodes and kubectl top pods -A to see which pods and nodes are consuming the most. Look for pods in the kube-system namespace using excessive resources.
  • Fix: This is less common in a standard Minikube setup unless you’ve installed a lot of add-ons or complex operators. If you suspect a specific system pod (e.g., a metrics server gone wild), you might need to restart the Minikube node (minikube stop then minikube start), or in extreme cases, delete and recreate the problematic pod within kube-system (use with extreme caution!).
  • Why it works: Identifying and potentially restarting or reconfiguring a rogue system component frees up the resources it was monopolizing.

4. Insufficient Docker/Container Runtime Resources

Minikube often uses Docker (or another container runtime) under the hood. The resource limits imposed on Docker itself can indirectly affect Minikube.

  • Diagnosis: If you’re on macOS or Windows, check your Docker Desktop resource allocation. Go to Docker Desktop Preferences -> Resources. Ensure it has a reasonable amount of CPU and RAM allocated (e.g., 4-6 CPUs, 8-16GB RAM).
  • Fix: Increase the resources allocated to Docker Desktop in its settings. Restart Docker Desktop and then restart Minikube.
  • Why it works: Minikube runs inside a VM managed by Docker. If Docker itself is starved for resources, the VM it provides to Minikube will also be starved.

5. Network Plugin Issues or Overhead

Certain CNI plugins can have a higher resource footprint than others.

  • Diagnosis: If you’ve manually configured a CNI or are using a complex networking setup, check the resource usage of your CNI pods (e.g., Calico, Flannel). kubectl get pods -n kube-system and kubectl top pods -n kube-system.
  • Fix: For typical Minikube use, the default CNI is usually fine. If you’re experiencing issues, consider resetting Minikube to its defaults or trying a different CNI (though this is advanced for Minikube). A simpler fix might be to increase overall Minikube resources as per point 1.
  • Why it works: Ensuring the networking components have enough resources prevents them from becoming bottlenecks or crashing.

6. Minikube Add-ons Resource Consumption

Many Minikube add-ons (like Dashboard, Ingress, Metrics Server) consume resources.

  • Diagnosis: Run minikube addons list and kubectl get pods -n kube-system. Check the resource usage of these add-on pods.
  • Fix: If an add-on is consuming too much, you can disable it (minikube addons disable <addon-name>) or increase overall Minikube node resources.
  • Why it works: Reducing the load from non-essential components or giving the system more capacity directly addresses resource contention.

After applying these fixes, you should find your pods running more stably. The next common hurdle you’ll face is understanding how to manage persistent storage, as Minikube’s default ephemeral storage isn’t suitable for most real-world applications.

Want structured learning?

Take the full Minikube course →