<p>I'd like to use spare CPU capacity in our kubernetes cluster for low-priority jobs -- specifically ML training using Tensorflow in this case -- without depriving higher-priority services on our cluster from CPU when they suddenly spike, akin to how one would with OS process priority. Currently we configure our autoscaler to add more nodes if CPU usage exceeds 60%, meaning as much as 40% of our CPU is unused at all times.</p>

<p>Questions:
(1) Is this possible with K8s? After some experimentation it seems that <a href="https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/" rel="nofollow noreferrer">Pod priority</a> is not 
exactly the same, as my lower priority deployment does not instantly yield back CPU to my higher priority deployment.
(2) If not possible, is there another generally-used strategy to utilize intentionally-overprovisioned CPU capacity, but yield immediately to higher priority services?</p>

Aaron
<p>According to <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>

<blockquote>
  <p>In an overcommitted system (where sum of limits > machine capacity) containers might eventually have to be killed, for example if the system runs out of CPU or memory resources. Ideally, we should kill containers that are less important. For each resource, we divide containers into 3 QoS classes: Guaranteed, Burstable, and Best-Effort, in decreasing order of priority.</p>
</blockquote>

<p>You can do like:</p>

<p>Set high to Guaranteed</p>

<pre><code>containers:
  name: high
    resources:
      limits:
        cpu: 8000m
        memory: 8Gi
</code></pre>

<p>Set ml-job to Best-Effort.</p>

<pre><code>containers:
  name: ml-job
</code></pre>

<p>I'm not sure if your ml-job is killable. If not, then this strategy might not suitable to you.</p>
