<p>We are using a K8s development tool called Tilt <em>(<a href="https://tilt.dev/" rel="nofollow noreferrer">https://tilt.dev/</a>)</em> which builds dev images of a stack with a ton of microservices and allows live reloading, etc.</p>
<p>I have deployed remote builder pods to an AWS K8s cluster using <code>buildx create</code> with 10 replicas. However, spinning off a build appears to only use two of these pods for the actual build <em>(based on CPU and Memory metrics I am seeing in the cluster)</em> and the other 8 stand idle. Running tilt up kicks off concurrent image builds for all microservices, so it would be ideal to spread the build steps across all 10 running builder pods.</p>
<p>I suspect this is because our project currently exists in a monorepo and is using the same Dockerfile.dev at the root level of the project to build all images <em>(minor config passed in at build time using <code>--build-arg</code>)</em></p>
<ol>
<li><p>Am I correct in suspecting this? It's hard to tell but it seems like buildx load balances based on the Dockerfile context. If so, can this behavior be overridden?</p>
</li>
<li><p>Alternatively, is there a way to manually select a buildx node? Easy enough to script a selector that loops across the existing remote nodes to spread out the building load</p>
</li>
</ol>

Zfalen
<p><strong>FWIW -</strong> I found a viable workaround by doing something like this:</p>
<pre><code>#!/usr/bin/env bash
for dir in myMonorepoServices/*; do
  # get the name of the service folder
  SERVICE=$(echo $dir | cut -d'/' -f 2)

  echo &quot;🏗 🏗 🏗 Creating a remote builder for $SERVICE... 🏗 🏗 🏗&quot;
  $(docker buildx create --name $SERVICE-docker-builder --driver kubernetes --driver-opt replicas=1,namespace=docker-builder --use)
  docker buildx inspect --bootstrap

done
</code></pre>
<p>This creates an individually &quot;named&quot; builder pod on the remote cluster, which i can target directly using the <code>--builder</code> flag like so:</p>
<p><code>docker buildx build --builder=myServiceName-docker-builder</code></p>
<p>Not really &quot;load balancing&quot; per-say, but this does ensure that each of the services get built on their own dedicated pod.</p>
