<p>In the <a href="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md#qos-classes" rel="nofollow noreferrer">kubernetes documentation here</a> the conditions for a pod that is classified as <code>Burstable</code> in regards to resource QOS is defined as </p>

<blockquote>
  <p>If requests and optionally limits are set (not equal to 0) for one or
  more resources across one or more containers, and they are not equal,
  then the pod is classified as Burstable. When limits are not
  specified, they default to the node capacity.</p>
</blockquote>

<p>so basically stated differently:</p>

<ol>
<li><code>requests</code> set for <strong>one or more</strong> resources (cpu/memory) across <strong>one or more</strong> containers in the pod.</li>
<li><code>limits</code> are optional: if set, they should be <strong>not be equal</strong> to the <code>requests</code> of the same
resource.</li>
</ol>

<p>But then later on the documentation gives the following as an example of <code>Burstable</code> pod:</p>

<pre><code>containers:
  name: foo
    resources:
      limits:
        cpu: 10m
        memory: 1Gi
      requests:
        cpu: 10m
        memory: 1Gi

  name: bar
</code></pre>

<p><em>Note:</em> Container <code>bar</code> has no resources specified.</p>

<p>This example fulfils condition 1. However, it doesn't satisfy condition 2, since the limits and requests are  set for one container but they are <strong>equal</strong>.</p>

<p>So why is this pod classified as a <code>Burstable</code> pod?</p>

<p>K8s documentation containing QOS explanation and examples: <a href="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md#qos-classes" rel="nofollow noreferrer">https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md#qos-classes</a></p>

<p>The evaluation of the <strong>Quality of Service (QoS)</strong> is done by scheduler on the <strong>whole</strong> pod, i.e. container by container and then taking the lowest evaluation.</p>

<p>Take a look at this example:</p>

<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: class
spec:
  containers:
  - name: container1
    image: busybox
    command: ["sh"]
    args: ["-c","sleep 3600"]
    resources:
      requests:
        memory: 100Mi
        cpu: 200m
      limits:
        memory: 100Mi
        cpu: 200m
  - name: container2
    image: busybox
    command: ["sh"]
    args: ["-c","sleep 3600"]
    resources:
      requests:
        memory: 100Mi
        cpu: 200m
</code></pre>

<p><code>container1</code> has Guaranteed QoS, because it has both requests and limits defined, and they are equals.</p>

<p><code>container2</code> has Burstable QoS, because it hasn't limits defined, but only requests.</p>

<p>class pod is evaluated, based on both containers and taking the lowest evaluation:</p>

<pre><code>min(Guaranteed, Burstable) = Burstable
</code></pre>

<p>Reference: <a href="https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/</a></p>
