Choose the mechanism for building container images before deploying. By default your local Docker daemon is used, but you can set it to cluster-buildkit or kaniko to sync files to the cluster, and build container images there. This removes the need to run Docker locally, and allows you to share layer and image caches between multiple developers, as well as between your development and CI workflows.
For more details on all the different options and what makes sense to use for your setup, please check out the in-cluster building guide.
Note: The cluster-docker mode has been deprecated and will be removed in a future release!
"Operator" represents a key's relationship to the value. Valid operators are "Exists" and "Equal". Defaults to "Equal". "Exists" is equivalent to wildcard for value, so that a pod can tolerate all taints of a particular category.
"TolerationSeconds" represents the period of time the toleration (which must be of effect "NoExecute", otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately) by the system.
References to docker-registry secrets to use for authenticating with remote registries when pulling images. This is necessary if you reference private images in your module configuration, and is required when configuring a remote Kubernetes environment with buildMode=local.
Resource requests and limits for the in-cluster builder. It's important to consider which build mode you're using when configuring this.
When buildMode is kaniko, this refers to each Kaniko pod, i.e. each individual build, so you'll want to consider the requirements for your individual image builds, with your most expensive/heavy images in mind.
When buildMode is cluster-buildkit, this applies to the BuildKit deployment created in each project namespace. So think of this as the resource spec for each individual user or project namespace.
When buildMode is cluster-docker, this applies to the single Docker Daemon that is installed and run cluster-wide. This is shared across all users and builds in the cluster, so it should be resourced accordingly, factoring in how many concurrent builds you expect and how heavy your builds tend to be. Note that the cluster-docker build mode has been deprecated!