Pilote Kubernetes

Le pilote Kubernetes vous permet de connecter vos environnements de développement local ou d'intégration continue à des builders dans un cluster Kubernetes pour permettre l'accès à des ressources de calcul plus puissantes, éventuellement sur plusieurs architectures natives.

Synopsis

Exécutez la commande suivante pour créer un nouveau builder, nommé kube, qui utilise le pilote Kubernetes :

$ docker buildx create \
  --bootstrap \
  --name=kube \
  --driver=kubernetes \
  --driver-opt=[key=value,...]

Le tableau suivant décrit les options spécifiques au pilote disponibles que vous pouvez passer à --driver-opt :

Mise à l'échelle de BuildKit

L'un des principaux avantages du pilote Kubernetes est que vous pouvez augmenter et diminuer le nombre de répliques de builder pour gérer une charge de build accrue. La mise à l'échelle est configurable à l'aide des options de pilote suivantes :

• replicas=N

  Cela met à l'échelle le nombre de pods BuildKit à la taille souhaitée. Par défaut, il ne crée qu'un seul pod. L'augmentation du nombre de répliques vous permet de tirer parti de plusieurs nœuds dans votre cluster.

• requests.cpu, requests.memory, requests.ephemeral-storage, limits.cpu, limits.memory, limits.ephemeral-storage

  Ces options permettent de demander et de limiter les ressources disponibles pour chaque pod BuildKit conformément à la documentation officielle de Kubernetes ici.

Par exemple, pour créer 4 pods BuildKit répliqués :

$ docker buildx create \
  --bootstrap \
  --name=kube \
  --driver=kubernetes \
  --driver-opt=namespace=buildkit,replicas=4

En listant les pods, vous obtenez ceci :

$ kubectl -n buildkit get deployments
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
kube0   4/4     4            4           8s

$ kubectl -n buildkit get pods
NAME                     READY   STATUS    RESTARTS   AGE
kube0-6977cdcb75-48ld2   1/1     Running   0          8s
kube0-6977cdcb75-rkc6b   1/1     Running   0          8s
kube0-6977cdcb75-vb4ks   1/1     Running   0          8s
kube0-6977cdcb75-z4fzs   1/1     Running   0          8s

De plus, vous pouvez utiliser l'option loadbalance=(sticky|random) pour contrôler le comportement d'équilibrage de charge lorsqu'il y a plusieurs répliques. random sélectionne des nœuds aléatoires dans le pool de nœuds, offrant une répartition uniforme de la charge de travail entre les répliques. sticky (la valeur par défaut) tente de connecter le même build effectué plusieurs fois au même nœud à chaque fois, garantissant une meilleure utilisation du cache local.

Pour plus d'informations sur la mise à l'échelle, consultez les options pour docker buildx create.

Affectation de nœud

Le pilote Kubernetes vous permet de contrôler la planification des pods BuildKit en utilisant les options de pilote nodeSelector et tolerations. Vous pouvez également définir l'option schedulername si vous souhaitez utiliser un planificateur personnalisé.

Vous pouvez utiliser les options de pilote annotations et labels pour appliquer des métadonnées supplémentaires aux déploiements et aux pods qui hébergent vos builders.

La valeur du paramètre nodeSelector est une chaîne de paires clé-valeur séparées par des virgules, où la clé est l'étiquette du nœud et la valeur est le texte de l'étiquette. Par exemple : "nodeselector=kubernetes.io/arch=arm64"

Le paramètre tolerations est une liste de taints séparés par des points-virgules. Il accepte les mêmes valeurs que le manifeste Kubernetes. Chaque entrée tolerations spécifie une clé de taint et la valeur, l'opérateur ou l'effet. Par exemple : "tolerations=key=foo,value=bar;key=foo2,operator=exists;key=foo3,effect=NoSchedule"

Ces options acceptent des chaînes délimitées par des virgules comme valeurs. En raison des règles de citation pour les commandes shell, vous devez envelopper les valeurs dans des guillemets simples. Vous pouvez même envelopper l'ensemble de --driver-opt dans des guillemets simples, par exemple :

$ docker buildx create \
  --bootstrap \
  --name=kube \
  --driver=kubernetes \
  '--driver-opt="nodeselector=label1=value1,label2=value2","tolerations=key=key1,value=value1"'

Builds multi-plateformes

Le pilote Kubernetes prend en charge la création d' images multi-plateformes, soit en utilisant QEMU, soit en tirant parti de l'architecture native des nœuds.

QEMU

Comme le pilote docker-container, le pilote Kubernetes prend également en charge l'utilisation de QEMU (mode utilisateur) pour créer des images pour des plates-formes non natives. Incluez l'indicateur --platform et spécifiez les plates-formes vers lesquelles vous souhaitez générer.

Par exemple, pour créer une image Linux pour amd64 et arm64 :

$ docker buildx build \
  --builder=kube \
  --platform=linux/amd64,linux/arm64 \
  -t <user>/<image> \
  --push .

Warning

QEMU effectue une émulation complète du processeur des plates-formes non natives, ce qui est beaucoup plus lent que les builds natifs. Les tâches gourmandes en calcul comme la compilation et la compression/décompression subiront probablement une baisse de performance importante.

L'utilisation d'une image BuildKit personnalisée ou l'invocation de binaires non natifs dans les builds peut nécessiter que vous activiez explicitement QEMU à l'aide de l'option qemu.install lors de la création du builder :

$ docker buildx create \
  --bootstrap \
  --name=kube \
  --driver=kubernetes \
  --driver-opt=namespace=buildkit,qemu.install=true

Natif

Si vous avez accès à des nœuds de cluster d'architectures différentes, le pilote Kubernetes peut en tirer parti pour les builds natifs. Pour ce faire, utilisez l'indicateur --append de docker buildx create.

Tout d'abord, créez votre builder avec une prise en charge explicite pour une seule architecture, par exemple amd64 :

$ docker buildx create \
  --bootstrap \
  --name=kube \
  --driver=kubernetes \
  --platform=linux/amd64 \
  --node=builder-amd64 \
  --driver-opt=namespace=buildkit,nodeselector="kubernetes.io/arch=amd64"

This creates a Buildx builder named kube, containing a single builder node named builder-amd64. Assigning a node name using --node is optional. Buildx generates a random node name if you don't provide one.

Note that the Buildx concept of a node isn't the same as the Kubernetes concept of a node. A Buildx node in this case could connect multiple Kubernetes nodes of the same architecture together.

With the kube builder created, you can now introduce another architecture into the mix using --append. For example, to add arm64:

$ docker buildx create \
  --append \
  --bootstrap \
  --name=kube \
  --driver=kubernetes \
  --platform=linux/arm64 \
  --node=builder-arm64 \
  --driver-opt=namespace=buildkit,nodeselector="kubernetes.io/arch=arm64"

Listing your builders shows both nodes for the kube builder:

$ docker buildx ls
NAME/NODE       DRIVER/ENDPOINT                                         STATUS   PLATFORMS
kube            kubernetes
  builder-amd64 kubernetes:///kube?deployment=builder-amd64&kubeconfig= running  linux/amd64*, linux/amd64/v2, linux/amd64/v3, linux/386
  builder-arm64 kubernetes:///kube?deployment=builder-arm64&kubeconfig= running  linux/arm64*

You can now build multi-arch amd64 and arm64 images, by specifying those platforms together in your build command:

$ docker buildx build --builder=kube --platform=linux/amd64,linux/arm64 -t <user>/<image> --push .

You can repeat the buildx create --append command for as many architectures that you want to support.

Rootless mode

The Kubernetes driver supports rootless mode. For more information on how rootless mode works, and its requirements, see here.

To turn it on in your cluster, you can use the rootless=true driver option:

$ docker buildx create \
  --name=kube \
  --driver=kubernetes \
  --driver-opt=namespace=buildkit,rootless=true

This will create your pods without securityContext.privileged.

Requires Kubernetes version 1.19 or later. Using Ubuntu as the host kernel is recommended.

Example: Creating a Buildx builder in Kubernetes

This guide shows you how to:

• Create a namespace for your Buildx resources
• Create a Kubernetes builder.
• List the available builders
• Build an image using your Kubernetes builders

Prerequisites:

• You have an existing Kubernetes cluster. If you don't already have one, you can follow along by installing minikube.
• The cluster you want to connect to is accessible via the kubectl command, with the KUBECONFIG environment variable set appropriately if necessary.

1. Create a buildkit namespace.

   Creating a separate namespace helps keep your Buildx resources separate from other resources in the cluster.

   $ kubectl create namespace buildkit
   namespace/buildkit created
   

2. Create a new builder with the Kubernetes driver:

   $ docker buildx create \
     --bootstrap \
     --name=kube \
     --driver=kubernetes \
     --driver-opt=namespace=buildkit
   

   Note

   Remember to specify the namespace in driver options.

3. List available builders using docker buildx ls

   $ docker buildx ls
   NAME/NODE                DRIVER/ENDPOINT STATUS  PLATFORMS
   kube                     kubernetes
     kube0-6977cdcb75-k9h9m                 running linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/386
   default *                docker
     default                default         running linux/amd64, linux/386
   

4. Inspect the running pods created by the build driver with kubectl.

   $ kubectl -n buildkit get deployments
   NAME    READY   UP-TO-DATE   AVAILABLE   AGE
   kube0   1/1     1            1           32s
   
   $ kubectl -n buildkit get pods
   NAME                     READY   STATUS    RESTARTS   AGE
   kube0-6977cdcb75-k9h9m   1/1     Running   0          32s
   

   The build driver creates the necessary resources on your cluster in the specified namespace (in this case, buildkit), while keeping your driver configuration locally.

5. Use your new builder by including the --builder flag when running buildx commands. For example: :

   # Replace <registry> with your Docker username
   # and <image> with the name of the image you want to build
   docker buildx build \
     --builder=kube \
     -t <registry>/<image> \
     --push .
   

That's it: you've now built an image from a Kubernetes pod, using Buildx.

Further reading

For more information on the Kubernetes driver, see the buildx reference.