<p>I'm setting up an InferenceService using Argo and KFServing with Amazon EKS (Kubernetes). Its important to know that our team has one EKS cluster per environment, which means there can be multiple applications  within our cluster that we don't control.</p>
<p><strong>Here is what we have setup so far</strong></p>
<ol>
<li>We push up a docker image to Amazon ECR that contains our logic to train and deploy our model</li>
<li>We use <code>argo</code> to submit workflows which start the training in #1. When installing argo into our kubernetes cluster, we notice that its components are sometimes assigned to the GPU nodes.</li>
<li>We are using <a href="https://github.com/kubeflow/kfserving" rel="noreferrer">KFServing</a> as well. KFServing allows us to auto-scale our GPU up and down, specifically scaling to zero when its not in use. The components in KFServing also get assigned to GPU nodes when applying them to our cluster.</li>
</ol>
<p>The current setup we have for #2 and #3 (above) seems to prohibit KFServing's ability to scale down to zero. It concerns us that having these components in the GPU would not allow the GPU to scale down.</p>
<p><strong>Which pods need to be assigned to our GPU nodes?</strong></p>
<p>(Option 1) Do we only need our argo workflow pod to be assigned and repel the rest?</p>
<p>-- OR --</p>
<p>(Option 2) Are there other kfserving components needed within the GPU node to work right?</p>
<ul>
<li><p>Option 1: <strong>How do we repel all pods from going into our GPU nodes other than the argo workflow pod?</strong> As a reminder, we have other applications we can't control, so adding node affinities for every pod seems unrealistic.</p>
</li>
<li><p>Option 2: <strong>How do the GPU nodes scale to zero when these GPU nodes have kfserving components in them?</strong> I was under the impression that scaling down means there are no pods in the node.</p>
</li>
</ul>

<p>tl;dr
You can use <a href="https://eksctl.io/usage/autoscaling/" rel="noreferrer">taints</a>.</p>
<blockquote>
<p>Which pods need to be assigned to our GPU nodes?</p>
</blockquote>
<p>The pods of the jobs that require GPU.</p>
<p>If your <strong>training</strong> job requires GPU you need to assign it using the <code>nodeSelector</code> and <code>tolerations</code> in the spec of your training/deployment deployment, see a nice example <a href="https://alexei-led.github.io/post/eks_gpu_spot/" rel="noreferrer">here</a>.</p>
<p>If your model is CV/NLP (many matrix multiplications), you might want to have the <strong>inferenceservice</strong> in the GPU as well, in that case you need to have it requested in its spec as described <a href="https://github.com/kubeflow/kfserving/blob/master/docs/samples/v1alpha2/pytorch/pytorch_gpu.yaml" rel="noreferrer">here</a>.</p>
<blockquote>
<p>Do we only need our argo workflow pod to be assigned and repel the
rest?</p>
</blockquote>
<p>Yes, if your inferenceservice does not require GPU.</p>
<blockquote>
<p>Are there other kfserving components needed within the GPU node to work right?</p>
</blockquote>
<p>No, the only kfserving component is the <code>kfserving-controller</code> and does not require a gpu as it's only orchestrating the creation of the istio&amp;knative resources for your inferenceservice.</p>
<p>If there are inferenceservices running in your gpu nodegroup without having the GPU requested in the spec, it means that the nodegroup is not configured to have the taint effect <code>NoSchedule</code>. Make sure that the gpu nodegroup in the eksctl configuration has the taint as described in the <a href="https://eksctl.io/usage/autoscaling/" rel="noreferrer">doc</a>.</p>
