Understanding Kubernetes Limits and Requests
Tags: kubernetes, monitoring, cpu, memory
Published: 2022-11-21 08:43:18

---
title: Understanding Kubernetes Limits and Requests
published: true
description: Have you set up Limits and Requests in your Kubernetes Pods. You need first to understand what are the implications. Check this guide for CPU and memory rightsizing

tags: kubernetes, monitoring, cpu, memory
cover_image: https://sysdig.com/wp-content/uploads/Kubernetes-Limits-and-Request-01.png
canonical_url: https://sysdig.com/blog/kubernetes-limits-requests/
# Use a ratio of 100:42 for best results.
---

<!-- wp:paragraph -->
<p>When working with containers in Kubernetes, it’s important to know what are the resources involved and how they are needed. Some processes will require more CPU or memory than others. Some are critical and should never be starved.&nbsp;</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Knowing that, we should configure our containers and Pods properly in order to get the best of both.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>In this article, we will see:</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><!-- wp:list-item -->
<li><a href="#introduction">Introduction to Kubernetes Limits and Requests</a></li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li><a href="#handson">Hands-on example</a></li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li><a href="#kubernetesrequests">Kubernetes Requests</a></li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li><a href="#kuberneteslimits">Kubernetes Limits</a></li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li><a href="#cpuparticularities">CPU particularities</a></li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li><a href="#memoryparticularities">Memory particularities</a></li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li><a href="#namespaceresourcequota">Namespace ResourceQuota</a></li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li><a href="#namespacelimitrange">Namespace LimitRange</a></li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li><a href="#conclusion">Conclusion</a></li>
<!-- /wp:list-item --></ul>
<!-- /wp:list -->

<!-- wp:heading -->
<h2 id="introduction">Introduction to Kubernetes Limits and Requests</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Limits and Requests are important settings when working with Kubernetes. This article will focus on the two most important ones: CPU and memory.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><strong>Kubernetes defines Limits as the</strong> <strong>maximum amount of a resource</strong> to be used by a container. This means that the container can never consume more than the memory amount or CPU amount indicated.&nbsp;</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><strong>Requests, on the other hand, are the minimum guaranteed amount of a resource</strong> that is reserved for a container.</p>
<!-- /wp:paragraph -->

<!-- wp:image {"id":61556,"width":878,"height":439,"sizeSlug":"large","linkDestination":"none"} -->
<figure class="wp-block-image size-large is-resized"><img src="https://sysdig.com/wp-content/uploads/Kubernetes-Limits-and-Request-04-1-1170x585.png" alt="" class="wp-image-61556" width="878" height="439"/></figure>
<!-- /wp:image -->

<!-- wp:heading -->
<h2 id="handson">Hands-on example</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Let’s have a look at this deployment, where we are setting up limits and requests for two different containers on both CPU and memory.</p>
<!-- /wp:paragraph -->

<!-- wp:code {"language":"javascript"} -->
<pre class="wp-block-code"><code>kind: Deployment
apiVersion: extensions/v1beta1
…
template:
&nbsp; spec:
&nbsp; &nbsp; containers:
&nbsp; &nbsp; &nbsp; - name: redis
&nbsp; &nbsp; &nbsp; &nbsp; image: redis:5.0.3-alpine
&nbsp; &nbsp; &nbsp; &nbsp; resources:
<strong>limits</strong>:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; memory: 600Mi
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; cpu: 1
<strong>requests</strong>:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; memory: 300Mi
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; cpu: 500m
&nbsp; &nbsp; &nbsp; - name: busybox
&nbsp; &nbsp; &nbsp; &nbsp; image: busybox:1.28
&nbsp; &nbsp; &nbsp; &nbsp; resources:
<strong>limits</strong>:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; memory: 200Mi
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; cpu: 300m
<strong>requests</strong>:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; memory: 100Mi
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; cpu: 100m</code></pre>
<!-- /wp:code -->

<!-- wp:paragraph -->
<p>Let’s say we are running a cluster with, for example, 4 cores and 16GB RAM nodes. We can extract a lot of information:</p>
<!-- /wp:paragraph -->

<!-- wp:image {"id":61328,"width":1170,"height":828,"sizeSlug":"large","linkDestination":"media"} -->
<figure class="wp-block-image size-large is-resized"><a href="https://sysdig.com/wp-content/uploads/Kubernetes-Limits-and-Request-05.png"><img src="https://sysdig.com/wp-content/uploads/Kubernetes-Limits-and-Request-05-1170x828.png" alt="Kubernetes Limits and Requests practical example" class="wp-image-61328" width="1170" height="828"/></a></figure>
<!-- /wp:image -->

<!-- wp:list {"ordered":true} -->
<ol><!-- wp:list-item -->
<li><strong>Pod effective request</strong> is 400 MiB of memory and 600 millicores of CPU. You need a node with enough free allocatable space to schedule the pod.</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li><strong>CPU shares</strong> for the redis container will be 512, and 102 for the busybox container. Kubernetes always assign 1024 shares to every core, so redis: 1024 * 0.5 cores ≅ 512 and busybox: 1024 * 0.1cores ≅ 102</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>Redis container will be <strong>OOM killed</strong> if it tries to allocate more than 600MB of RAM, most likely making the pod fail.</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>Redis will suffer <strong>CPU throttle</strong> if it tries to use more than 100ms of CPU in every 100ms, (since we have 4 cores, available time would be 400ms every 100ms) causing performance degradation.</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>Busybox container will be <strong>OOM killed</strong> if it tries to allocate more than 200MB of RAM, resulting in a failed pod.</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>Busybox will suffer <strong>CPU throttle</strong> if it tries to use more than 30ms of CPU every 100ms, causing performance degradation.</li>
<!-- /wp:list-item --></ol>
<!-- /wp:list -->

<!-- wp:heading -->
<h2 id="kubernetesrequests">Kubernetes Requests</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Kubernetes defines requests as a <strong>guaranteed minimum amount of a resource</strong> to be used by a container.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Basically, it will set the minimum amount of the resource for the container to consume.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>When a Pod is scheduled, kube-scheduler will check the Kubernetes requests in order to allocate it to a particular Node that can satisfy at least that amount for all containers in the Pod. If the requested amount is higher than the available resource, the Pod will not be scheduled and remain in Pending status.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>For more information about Pending status, check <a href="https://sysdig.com/blog/kubernetes-pod-pending-problems/" target="_blank" rel="noreferrer noopener">Understanding Kubernetes Pod pending problems</a>.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>In this example, in the container definition we set a request for 100m cores of CPU and 4Mi of memory:</p>
<!-- /wp:paragraph -->

<!-- wp:code {"language":"javascript"} -->
<pre class="wp-block-code"><code>resources:
   requests:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cpu: 0.1
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;memory: 4Mi</code></pre>
<!-- /wp:code -->

<!-- wp:paragraph -->
<p>Requests are used:</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><!-- wp:list-item -->
<li>When allocating Pods to a Node, so the indicated requests by the containers in the Pod are satisfied.</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>At runtime, the indicated amount of requests will be guaranteed as a minimum for the containers in that Pod.</li>
<!-- /wp:list-item --></ul>
<!-- /wp:list -->

<!-- wp:image {"id":21414,"sizeSlug":"full","linkDestination":"none"} -->
<figure class="wp-block-image size-full"><img src="https://sysdig.com/wp-content/uploads/image4.png" alt="How to set good CPU requests" class="wp-image-21414"/></figure>
<!-- /wp:image -->

<!-- wp:heading -->
<h2 id="kuberneteslimits">Kubernetes Limits</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Kubernetes defines <strong>limits</strong> as a <strong>maximum amount of a resource</strong> to be used by a container.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>This means that the container can never consume more than the memory amount or CPU amount indicated.</p>
<!-- /wp:paragraph -->

<!-- wp:code {"language":"javascript"} -->
<pre class="wp-block-code"><code>    resources:
      limits:
        cpu: 0.5
        memory: 100Mi
</code></pre>
<!-- /wp:code -->

<!-- wp:paragraph -->
<p>Limits are used:</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><!-- wp:list-item -->
<li>When allocating Pods to a Node. If no requests are set, by default, Kubernetes will assign requests = limits.</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>At runtime, Kubernetes will check that the containers in the Pod are not consuming a higher amount of resources than indicated in the limit.</li>
<!-- /wp:list-item --></ul>
<!-- /wp:list -->

<!-- wp:image {"id":21412,"sizeSlug":"full","linkDestination":"none"} -->
<figure class="wp-block-image size-full"><img src="https://sysdig.com/wp-content/uploads/image6.png" alt="Setting good Limits in Kubernetes" class="wp-image-21412"/></figure>
<!-- /wp:image -->

<!-- wp:heading -->
<h2 id="cpuparticularities">CPU particularities</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>CPU is a <strong>compressible resource</strong>, meaning that it can be stretched in order to satisfy all the demand. In case that the processes request too much CPU, some of them will be throttled.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><strong>CPU</strong> represents <strong>computing processing time</strong>, measured in cores.&nbsp;</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><!-- wp:list-item -->
<li>You can use millicores (m) to represent smaller amounts than a core (e.g., 500m would be half a core)</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>The minimum amount is 1m</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>A Node might have more than one core available, so requesting CPU &gt; 1 is possible</li>
<!-- /wp:list-item --></ul>
<!-- /wp:list -->

<!-- wp:image {"id":61738,"sizeSlug":"large","linkDestination":"none"} -->
<figure class="wp-block-image size-large"><img src="https://sysdig.com/wp-content/uploads/Kubernetes-Limits-and-Requests-1-1170x644.png" alt="Kubernetes requests for CPU image" class="wp-image-61738"/></figure>
<!-- /wp:image -->

<!-- wp:heading -->
<h2 id="memoryparticularities">Memory particularities</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p><strong>Memory</strong> is a <strong>non-compressible</strong> resource, meaning that it can’t be stretched in the same manner as CPU. If a process doesn’t get enough memory to work, the process is killed.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Memory is measured in Kubernetes in <strong>bytes</strong>.</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><!-- wp:list-item -->
<li>You can use, E, P, T, G, M, k to represent Exabyte, Petabyte, Terabyte, Gigabyte, Megabyte and kilobyte, although only the last four are commonly used. (e.g., 500M, 4G)</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>Warning: don’t use lowercase m for memory (this represents Millibytes, which is ridiculously low)</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>You can define Mebibytes using Mi, as well as the rest as Ei, Pi, Ti (e.g., 500Mi)</li>
<!-- /wp:list-item --></ul>
<!-- /wp:list -->

<p><span style="text-size: smaller; font-style: italic; border: 1px solid #ff9e1b; display: block; border-radius: 25px; padding: 25px; max-width: 96%; margin: 2em auto;"><em>A Mebibyte (and their analogues Kibibyte, Gibibyte,...) is 2 to the power of 20 bytes. It was created to avoid the confusion with the Kilo, Mega definitions of the metric system. You should be using this notation, as it's the canonical definition for bytes, while Kilo and Mega are multiples of 1000</em><br></span></p>

<!-- wp:image {"align":"center","id":61739,"sizeSlug":"large","linkDestination":"none"} -->
<figure class="wp-block-image aligncenter size-large"><img src="https://sysdig.com/wp-content/uploads/Kubernetes-Limits-and-Requests-2-1170x644.png" alt="Kubernetes Limits for memory image" class="wp-image-61739"/></figure>
<!-- /wp:image -->

<!-- wp:heading -->
<h2 id="bestpractices">Best practices</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>In very few cases should you be using limits to control your resources usage in Kubernetes. This is because if you want to avoid starvation (ensure that every important process gets its share), you should be using requests in the first place.&nbsp;</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>By setting up limits, you are only preventing a process from retrieving additional resources in exceptional cases, causing an OOM kill in the event of memory, and Throttling in the event of CPU (process will need to wait until the CPU can be used again).</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>For more information, check the <a href="https://sysdig.com/blog/troubleshoot-kubernetes-oom/">article about OOM and Throttling</a>.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>If you’re setting a request value equal to the limit in all containers of a Pod, that Pod will get the Guaranteed Quality of Service.&nbsp;</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Note as well, that Pods that have a resource usage higher than the requests are more likely to be evicted, so setting up very low requests cause more harm than good.For more information, check the article about <a href="https://docs.google.com/document/u/0/d/1NvedVZgcPdtiSIFZH_-q5-C43xt12nfMWERA6Mk5dOc/edit">Pod eviction and Quality of Service</a>.</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2 id="namespaceresourcequota">Namespace ResourceQuota</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Thanks to namespaces, we can isolate Kubernetes resources into different groups, also called tenants.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>With <strong>ResourceQuotas</strong>, you can <strong>set a memory or CPU limit to the entire namespace</strong>, ensuring that entities in it can’t consume more from that amount.</p>
<!-- /wp:paragraph -->

<!-- wp:code {"language":"javascript"} -->
<pre class="wp-block-code"><code>apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:
    requests.cpu: 2
    requests.memory: 1Gi
    limits.cpu: 3
    limits.memory: 2Gi

</code></pre>
<!-- /wp:code -->

<!-- wp:list -->
<ul><!-- wp:list-item -->
<li>requests.cpu: the maximum amount of CPU for the sum of all requests in this namespace</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>requests.memory: the maximum amount of Memory for the sum of all requests in this namespace</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>limits.cpu: the maximum amount of CPU for the sum of all limits in this namespace</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>limits.memory: the maximum amount of memory for the sum of all limits in this namespace</li>
<!-- /wp:list-item --></ul>
<!-- /wp:list -->

<!-- wp:paragraph -->
<p>Then, apply it to your namespace:</p>
<!-- /wp:paragraph -->

<!-- wp:code {"language":"javascript"} -->
<pre class="wp-block-code"><code>kubectl apply -f resourcequota.yaml --namespace=mynamespace
</code></pre>
<!-- /wp:code -->

<!-- wp:paragraph -->
<p>You can list the current ResourceQuota for a namespace with:</p>
<!-- /wp:paragraph -->

<!-- wp:code {"language":"javascript"} -->
<pre class="wp-block-code"><code>kubectl get resourcequota -n mynamespace
</code></pre>
<!-- /wp:code -->

<!-- wp:paragraph -->
<p>Note that if you set up ResourceQuota for a given resource in a namespace, you then need to specify limits or requests accordingly for every Pod in that namespace. If not, Kubernetes will return a “failed quota” error:</p>
<!-- /wp:paragraph -->

<!-- wp:code {"language":"javascript"} -->
<pre class="wp-block-code"><code>Error from server (Forbidden): error when creating "mypod.yaml": pods "mypod" is forbidden: failed quota: mem-cpu-demo: must specify limits.cpu,limits.memory,requests.cpu,requests.memory
</code></pre>
<!-- /wp:code -->

<!-- wp:paragraph -->
<p>In case you try to add a new Pod with container limits or requests that exceed the current ResourceQuota, Kubernetes will return an “exceeded quota” error:</p>
<!-- /wp:paragraph -->

<!-- wp:code {"language":"javascript"} -->
<pre class="wp-block-code"><code>Error from server (Forbidden): error when creating "mypod.yaml": pods "mypod" is forbidden: exceeded quota: mem-cpu-demo, requested: limits.memory=2Gi,requests.memory=2Gi, used: limits.memory=1Gi,requests.memory=1Gi, limited: limits.memory=2Gi,requests.memory=1Gi
</code></pre>
<!-- /wp:code -->

<!-- wp:heading -->
<h2 id="namespacelimitrange">Namespace LimitRange</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>ResourceQuotas are useful if we want to restrict the total amount of a resource allocatable for a namespace. But what happens if we want to give default values to the elements inside?</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><strong>LimitRanges</strong> are a Kubernetes policy that <strong>restricts the resource settings for each entity</strong> in a namespace.</p>
<!-- /wp:paragraph -->

<!-- wp:code {"language":"javascript"} -->
<pre class="wp-block-code"><code>apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default:
      cpu: 500m
    defaultRequest:
      cpu: 500m
    min:
      cpu: 100m
    max:
      cpu: "1"
    type: Container
</code></pre>
<!-- /wp:code -->

<!-- wp:list -->
<ul><!-- wp:list-item -->
<li><code>default</code>: Containers created will have this value if none is specified.</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li><code>min</code>: Containers created can’t have limits or requests smaller than this.</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li><code>max</code>: Containers created can’t have limits or requests bigger than this.</li>
<!-- /wp:list-item --></ul>
<!-- /wp:list -->

<!-- wp:paragraph -->
<p>Later, if you create a new Pod with no requests or limits set, LimitRange will automatically set these values to all its containers:</p>
<!-- /wp:paragraph -->

<!-- wp:code {"language":"javascript"} -->
<pre class="wp-block-code"><code>    Limits:
      cpu:  500m
    Requests:
      cpu:  100m
</code></pre>
<!-- /wp:code -->

<!-- wp:paragraph -->
<p>Now, imagine that you add a new Pod with 1200M as limit. You will receive the following error:</p>
<!-- /wp:paragraph -->

<!-- wp:code {"language":"javascript"} -->
<pre class="wp-block-code"><code>Error from server (Forbidden): error when creating "pods/mypod.yaml": pods "mypod" is forbidden: maximum cpu usage per Container is 1, but limit is 1200m
</code></pre>
<!-- /wp:code -->

<!-- wp:paragraph -->
<p>Note that by default, all containers in Pod will effectively have a request of 100m CPU, even with no LimitRanges set.</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2 id="conclusion">Conclusion</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Choosing the optimal limits for our Kubernetes cluster is key in order to get the best of both energy consumption and costs.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Oversizing or dedicating too many resources for our Pods may lead to costs skyrocketing.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Undersizing or dedicating very few CPU or Memory will lead to applications not performing correctly, or even Pods being evicted.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>As mentioned, Kubernetes limits shouldn’t be used, except in very specific situations, as they may cause more harm than good. There’s a chance that a Container is killed in case of Out of Memory, or throttled in case of Out of CPU.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>For requests, use them when you need to ensure a process gets a guaranteed share of a resource.</p>
<!-- /wp:paragraph -->

<!-- wp:separator -->
<hr class="wp-block-separator has-alpha-channel-opacity"/>
<!-- /wp:separator -->

<!-- wp:heading -->
<h2>Rightsize your Kubernetes resources with Sysdig Monitor</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>With Sysdig Monitor new feature, cost advisor, you can optimize your Kubernetes costs</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><!-- wp:list-item -->
<li>Memory requests</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>CPU requests</li>
<!-- /wp:list-item --></ul>
<!-- /wp:list -->

<!-- wp:paragraph -->
<p>Sysdig Advisor accelerates mean time to resolution (MTTR) with live logs, performance data, and suggested remediation steps. It’s the easy button for Kubernetes troubleshooting!</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p id="gdcalert2"></p>
<!-- /wp:paragraph -->

<!-- wp:image {"id":61326,"width":878,"height":797,"sizeSlug":"large","linkDestination":"none"} -->
<figure class="wp-block-image size-large is-resized"><img src="https://sysdig.com/wp-content/uploads/Kubernetes-Limits-and-Request-06-1170x1063.png" alt="" class="wp-image-61326" width="878" height="797"/></figure>
<!-- /wp:image -->

<!-- wp:paragraph -->
<p><a href="https://sysdig.com/company/free-trial-monitor/">Try it free for 30 days!</a></p>
<!-- /wp:paragraph -->