kubernetes

Description

The kubernetes provider allows you to deploy container modules to Kubernetes clusters, and adds the helm and kubernetes module types.
For usage information, please refer to the guides section. A good place to start is the Remote Kubernetes guide guide if you're connecting to remote clusters. The Getting Started guide is also helpful as an introduction.
Note that if you're using a local Kubernetes cluster (e.g. minikube or Docker Desktop), the local-kubernetes provider simplifies (and automates) the configuration and setup quite a bit.
Below is the full schema reference for the provider configuration. For an introduction to configuring a Garden project with providers, please look at our configuration guide.
The reference is divided into two sections. The first section contains the complete YAML schema, and the second section describes each schema key.

Complete YAML Schema

The values in the schema below are the default values.
1
providers:
2
- # List other providers that should be resolved before this one.
3
dependencies: []
4
​
5
# If specified, this provider will only be used in the listed environments. Note that an empty array effectively
6
# disables the provider. To use a provider in all environments, omit this field.
7
environments:
8
​
9
# Choose the mechanism for building container images before deploying. By default your local Docker daemon is
10
# used, but you can set it to `cluster-buildkit` or `kaniko` to sync files to the cluster, and build container
11
# images there. This removes the need to run Docker locally, and allows you to share layer and image caches
12
# between multiple developers, as well as between your development and CI workflows.
13
#
14
# For more details on all the different options and what makes sense to use for your setup, please check out the
15
# [in-cluster building guide](https://docs.garden.io/guides/in-cluster-building).
16
#
17
# **Note:** The `cluster-docker` mode has been deprecated and will be removed in a future release!
18
buildMode: local-docker
19
​
20
# Configuration options for the `cluster-buildkit` build mode.
21
clusterBuildkit:
22
# Enable rootless mode for the cluster-buildkit daemon, which runs the daemon with decreased privileges.
23
# Please see [the buildkit docs](https://github.com/moby/buildkit/blob/master/docs/rootless.md) for caveats when
24
# using this mode.
25
rootless: false
26
​
27
# Exposes the `nodeSelector` field on the PodSpec of the BuildKit deployment. This allows you to constrain the
28
# BuildKit daemon to only run on particular nodes.
29
#
30
# [See here](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) for the official Kubernetes
31
# guide to assigning Pods to nodes.
32
nodeSelector: {}
33
​
34
# Setting related to Jib image builds.
35
jib:
36
# In some cases you may need to push images built with Jib to the remote registry via Kubernetes cluster, e.g.
37
# if you don't have connectivity or access from where Garden is being run. In that case, set this flag to true,
38
# but do note that the build will take considerably take longer to complete! Only applies when using in-cluster
39
# building.
40
pushViaCluster: false
41
​
42
# Configuration options for the `kaniko` build mode.
43
kaniko:
44
# Specify extra flags to use when building the container image with kaniko. Flags set on `container` modules
45
# take precedence over these.
46
extraFlags:
47
​
48
# Change the kaniko image (repository/image:tag) to use when building in kaniko mode.
49
image: 'gcr.io/kaniko-project/executor:v1.6.0-debug'
50
​
51
# Choose the namespace where the Kaniko pods will be run. Set to `null` to use the project namespace.
52
#
53
# **IMPORTANT: The default namespace will change to the project namespace instead of the garden-system namespace
54
# in an upcoming release!**
55
namespace: garden-system
56
​
57
# Exposes the `nodeSelector` field on the PodSpec of the Kaniko pods. This allows you to constrain the Kaniko
58
# pods to only run on particular nodes.
59
#
60
# [See here](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) for the official Kubernetes
61
# guide to assigning Pods to nodes.
62
nodeSelector:
63
​
64
# Specify tolerations to apply to each Kaniko Pod. Useful to control which nodes in a cluster can run builds.
65
tolerations:
66
- # "Effect" indicates the taint effect to match. Empty means match all taint effects. When specified,
67
# allowed values are "NoSchedule", "PreferNoSchedule" and "NoExecute".
68
effect:
69
​
70
# "Key" is the taint key that the toleration applies to. Empty means match all taint keys.
71
# If the key is empty, operator must be "Exists"; this combination means to match all values and all keys.
72
key:
73
​
74
# "Operator" represents a key's relationship to the value. Valid operators are "Exists" and "Equal".
75
# Defaults to
76
# "Equal". "Exists" is equivalent to wildcard for value, so that a pod can tolerate all taints of a
77
# particular category.
78
operator: Equal
79
​
80
# "TolerationSeconds" represents the period of time the toleration (which must be of effect "NoExecute",
81
# otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate
82
# the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately)
83
# by the system.
84
tolerationSeconds:
85
​
86
# "Value" is the taint value the toleration matches to. If the operator is "Exists", the value should be
87
# empty,
88
# otherwise just a regular string.
89
value:
90
​
91
# A default hostname to use when no hostname is explicitly configured for a service.
92
defaultHostname:
93
​
94
# Sets the deployment strategy for `container` services.
95
#
96
# The default is `"rolling"`, which performs rolling updates. There is also experimental support for blue/green
97
# deployments (via the `"blue-green"` strategy).
98
#
99
# Note that this setting only applies to `container` services (and not, for example, `kubernetes` or `helm`
100
# services).
101
deploymentStrategy: rolling
102
​
103
# Configuration options for dev mode.
104
devMode:
105
# Specifies default settings for dev mode syncs (e.g. for `container`, `kubernetes` and `helm` services).
106
#
107
# These are overridden/extended by the settings of any individual dev mode sync specs for a given module or
108
# service.
109
#
110
# Dev mode is enabled when running the `garden dev` command, and by setting the `--dev` flag on the `garden
111
# deploy` command.
112
#
113
# See the [Code Synchronization guide](https://docs.garden.io/guides/code-synchronization-dev-mode) for more
114
# information.
115
defaults:
116
# Specify a list of POSIX-style paths or glob patterns that should be excluded from the sync.
117
#
118
# Any exclusion patterns defined in individual dev mode sync specs will be applied in addition to these
119
# patterns.
120
#
121
# `.git` directories and `.garden` directories are always ignored.
122
exclude:
123
​
124
# The default permission bits, specified as an octal, to set on files at the sync target. Defaults to 0600
125
# (user read/write). See the [Mutagen
126
# docs](https://mutagen.io/documentation/synchronization/permissions#permissions) for more information.
127
fileMode:
128
​
129
# The default permission bits, specified as an octal, to set on directories at the sync target. Defaults to
130
# 0700 (user read/write). See the [Mutagen
131
# docs](https://mutagen.io/documentation/synchronization/permissions#permissions) for more information.
132
directoryMode:
133
​
134
# Set the default owner of files and directories at the target. Specify either an integer ID or a string name.
135
# See the [Mutagen docs](https://mutagen.io/documentation/synchronization/permissions#owners-and-groups) for
136
# more information.
137
owner:
138
​
139
# Set the default group on files and directories at the target. Specify either an integer ID or a string name.
140
# See the [Mutagen docs](https://mutagen.io/documentation/synchronization/permissions#owners-and-groups) for
141
# more information.
142
group:
143
​
144
# Require SSL on all `container` module services. If set to true, an error is raised when no certificate is
145
# available for a configured hostname on a `container` module.
146
forceSsl: false
147
​
148
# References to `docker-registry` secrets to use for authenticating with remote registries when pulling
149
# images. This is necessary if you reference private images in your module configuration, and is required
150
# when configuring a remote Kubernetes environment with buildMode=local.
151
imagePullSecrets:
152
- # The name of the Kubernetes secret.
153
name:
154
​
155
# The namespace where the secret is stored. If necessary, the secret may be copied to the appropriate
156
# namespace before use.
157
namespace: default
158
​
159
# Resource requests and limits for the in-cluster builder, container registry and code sync service. (which are
160
# automatically installed and used when `buildMode` is `cluster-docker` or `kaniko`).
161
resources:
162
# Resource requests and limits for the in-cluster builder. It's important to consider which build mode you're
163
# using when configuring this.
164
#
165
# When `buildMode` is `kaniko`, this refers to _each Kaniko pod_, i.e. each individual build, so you'll want to
166
# consider the requirements for your individual image builds, with your most expensive/heavy images in mind.
167
#
168
# When `buildMode` is `cluster-buildkit`, this applies to the BuildKit deployment created in _each project
169
# namespace_. So think of this as the resource spec for each individual user or project namespace.
170
#
171
# When `buildMode` is `cluster-docker`, this applies to the single Docker Daemon that is installed and run
172
# cluster-wide. This is shared across all users and builds in the cluster, so it should be resourced
173
# accordingly, factoring in how many concurrent builds you expect and how heavy your builds tend to be. **Note
174
# that the cluster-docker build mode has been deprecated!**
175
builder:
176
limits:
177
# CPU limit in millicpu.
178
cpu: 4000
179
​
180
# Memory limit in megabytes.
181
memory: 8192
182
​
183
# Ephemeral storage limit in megabytes.
184
ephemeralStorage:
185
​
186
requests:
187
# CPU request in millicpu.
188
cpu: 100
189
​
190
# Memory request in megabytes.
191
memory: 512
192
​
193
# Ephemeral storage request in megabytes.
194
ephemeralStorage:
195
​
196
# Resource requests and limits for the in-cluster image registry. Built images are pushed to this registry,
197
# so that they are available to all the nodes in your cluster.
198
#
199
# This is shared across all users and builds, so it should be resourced accordingly, factoring
200
# in how many concurrent builds you expect and how large your images tend to be.
201
registry:
202
limits:
203
# CPU limit in millicpu.
204
cpu: 2000
205
​
206
# Memory limit in megabytes.
207
memory: 4096
208
​
209
# Ephemeral storage limit in megabytes.
210
ephemeralStorage:
211
​
212
requests:
213
# CPU request in millicpu.
214
cpu: 200
215
​
216
# Memory request in megabytes.
217
memory: 512
218
​
219
# Ephemeral storage request in megabytes.
220
ephemeralStorage:
221
​
222
# Storage parameters to set for the in-cluster builder, container registry and code sync persistent volumes
223
# (which are automatically installed and used when `buildMode` is `cluster-docker` or `kaniko`).
224
#
225
# These are all shared cluster-wide across all users and builds, so they should be resourced accordingly,
226
# factoring in how many concurrent builds you expect and how large your images and build contexts tend to be.
227
storage:
228
# Storage parameters for the in-cluster Docker registry volume. Built images are stored here, so that they
229
# are available to all the nodes in your cluster.
230
#
231
# Only applies when `buildMode` is set to `cluster-docker` or `kaniko`, ignored otherwise.
232
registry:
233
# Volume size in megabytes.
234
size: 20480
235
​
236
# Storage class to use for the volume.
237
storageClass: null
238
​
239
# One or more certificates to use for ingress.
240
tlsCertificates:
241
- # A unique identifier for this certificate.
242
name:
243
​
244
# A list of hostnames that this certificate should be used for. If you don't specify these, they will be
245
# automatically read from the certificate.
246
hostnames:
247
​
248
# A reference to the Kubernetes secret that contains the TLS certificate and key for the domain.
249
secretRef:
250
# The name of the Kubernetes secret.
251
name:
252
​
253
# The namespace where the secret is stored. If necessary, the secret may be copied to the appropriate
254
# namespace before use.
255
namespace: default
256
​
257
# Set to `cert-manager` to configure [cert-manager](https://github.com/jetstack/cert-manager) to manage this
258
# certificate. See our
259
# [cert-manager integration guide](https://docs.garden.io/advanced/cert-manager-integration) for details.
260
managedBy:
261
​
262
# cert-manager configuration, for creating and managing TLS certificates. See the
263
# [cert-manager guide](https://docs.garden.io/advanced/cert-manager-integration) for details.
264
certManager:
265
# Automatically install `cert-manager` on initialization. See the
266
# [cert-manager integration guide](https://docs.garden.io/advanced/cert-manager-integration) for details.
267
install: false
268
​
269
# The email to use when requesting Let's Encrypt certificates.
270
email:
271
​
272
# The type of issuer for the certificate (only ACME is supported for now).
273
issuer: acme
274
​
275
# Specify which ACME server to request certificates from. Currently Let's Encrypt staging and prod servers are
276
# supported.
277
acmeServer: letsencrypt-staging
278
​
279
# The type of ACME challenge used to validate hostnames and generate the certificates (only HTTP-01 is supported
280
# for now).
281
acmeChallengeType: HTTP-01
282
​
283
# Exposes the `nodeSelector` field on the PodSpec of system services. This allows you to constrain the system
284
# services to only run on particular nodes.
285
#
286
# [See here](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) for the official Kubernetes guide
287
# to assigning Pods to nodes.
288
systemNodeSelector: {}
289
​
290
# For setting tolerations on the registry-proxy when using in-cluster building.
291
# The registry-proxy is a DaemonSet that proxies connections to the docker registry service on each node.
292
#
293
# Use this only if you're doing in-cluster building and the nodes in your cluster
294
# have [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/).
295
registryProxyTolerations:
296
- # "Effect" indicates the taint effect to match. Empty means match all taint effects. When specified,
297
# allowed values are "NoSchedule", "PreferNoSchedule" and "NoExecute".
298
effect:
299
​
300
# "Key" is the taint key that the toleration applies to. Empty means match all taint keys.
301
# If the key is empty, operator must be "Exists"; this combination means to match all values and all keys.
302
key:
303
​
304
# "Operator" represents a key's relationship to the value. Valid operators are "Exists" and "Equal". Defaults
305
# to
306
# "Equal". "Exists" is equivalent to wildcard for value, so that a pod can tolerate all taints of a
307
# particular category.
308
operator: Equal
309
​
310
# "TolerationSeconds" represents the period of time the toleration (which must be of effect "NoExecute",
311
# otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate
312
# the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately)
313
# by the system.
314
tolerationSeconds:
315
​
316
# "Value" is the taint value the toleration matches to. If the operator is "Exists", the value should be
317
# empty,
318
# otherwise just a regular string.
319
value:
320
​
321
# The name of the provider plugin to use.
322
name: kubernetes
323
​
324
# The kubectl context to use to connect to the Kubernetes cluster.
325
context:
326
​
327
# The registry where built containers should be pushed to, and then pulled to the cluster when deploying services.
328
#
329
# Important: If you specify this in combination with in-cluster building, you must make sure `imagePullSecrets`
330
# includes authentication with the specified deployment registry, that has the appropriate write privileges
331
# (usually full write access to the configured `deploymentRegistry.namespace`).
332
deploymentRegistry:
333
# The hostname (and optionally port, if not the default port) of the registry.
334
hostname:
335
​
336
# The port where the registry listens on, if not the default.
337
port:
338
​
339
# The namespace in the registry where images should be pushed.
340
namespace: _
341
​
342
# The ingress class to use on configured Ingresses (via the `kubernetes.io/ingress.class` annotation)
343
# when deploying `container` services. Use this if you have multiple ingress controllers in your cluster.
344
ingressClass:
345
​
346
# The external HTTP port of the cluster's ingress controller.
347
ingressHttpPort: 80
348
​
349
# The external HTTPS port of the cluster's ingress controller.
350
ingressHttpsPort: 443
351
​
352
# Path to kubeconfig file to use instead of the system default. Must be a POSIX-style path.
353
kubeconfig:
354
​
355
# Specify which namespace to deploy services to, and optionally annotations/labels to apply to the namespace.
356
#
357
# You can specify a string as a shorthand for `name: <name>`. Defaults to `<project name>-<environment
358
# namespace>`.
359
#
360
# Note that the framework may generate other namespaces as well with this name as a prefix. Also note that if the
361
# namespace previously exists, Garden will attempt to add the specified labels and annotations. If the user does
362
# not have permissions to do so, a warning is shown.
363
namespace:
364
# A valid Kubernetes namespace name. Must be a valid RFC1035/RFC1123 (DNS) label (may contain lowercase letters,
365
# numbers and dashes, must start with a letter, and cannot end with a dash) and must not be longer than 63
366
# characters.
367
name:
368
​
369
# Map of annotations to apply to the namespace when creating it.
370
annotations:
371
​
372
# Map of labels to apply to the namespace when creating it.
373
labels:
374
​
375
# Set this to `nginx` to install/enable the NGINX ingress controller.
376
setupIngressController: false
Copied!

Configuration Keys

providers[]

Type
Default
Required
array[object]
[]
No

providers[].dependencies[]

​providers > dependencies
List other providers that should be resolved before this one.
Type
Default
Required
array[string]
[]
No
Example:
1
providers:
2
- dependencies:
3
- exec
Copied!

providers[].environments[]

​providers > environments
If specified, this provider will only be used in the listed environments. Note that an empty array effectively disables the provider. To use a provider in all environments, omit this field.
Type
Required
array[string]
No
Example:
1
providers:
2
- environments:
3
- dev
4
- stage
Copied!

providers[].buildMode

​providers > buildMode
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!
Type
Default
Required
string
"local-docker"
No

providers[].clusterBuildkit

​providers > clusterBuildkit
Configuration options for the cluster-buildkit build mode.
Type
Required
object
No

providers[].clusterBuildkit.rootless

​providers > clusterBuildkit > rootless
Enable rootless mode for the cluster-buildkit daemon, which runs the daemon with decreased privileges. Please see the buildkit docs for caveats when using this mode.
Type
Default
Required
boolean
false
No

providers[].clusterBuildkit.nodeSelector

​providers > clusterBuildkit > nodeSelector
Exposes the nodeSelector field on the PodSpec of the BuildKit deployment. This allows you to constrain the BuildKit daemon to only run on particular nodes.
​See here for the official Kubernetes guide to assigning Pods to nodes.
Type
Default
Required
object
{}
No
Example:
1
providers:
2
- clusterBuildkit:
3
...
4
nodeSelector:
5
disktype: ssd
Copied!

providers[].clusterDocker

​providers > clusterDocker
Deprecated: This field will be removed in a future release.
Configuration options for the cluster-docker build mode.
Type
Required
object
No

providers[].clusterDocker.enableBuildKit

​providers > clusterDocker > enableBuildKit
Deprecated: This field will be removed in a future release.
Enable BuildKit support. This should in most cases work well and be more performant, but we're opting to keep it optional until it's enabled by default in Docker.
Type
Default
Required
boolean
false
No

providers[].jib

​providers > jib
Setting related to Jib image builds.
Type
Required
object
No

providers[].jib.pushViaCluster

​providers > jib > pushViaCluster
In some cases you may need to push images built with Jib to the remote registry via Kubernetes cluster, e.g. if you don't have connectivity or access from where Garden is being run. In that case, set this flag to true, but do note that the build will take considerably take longer to complete! Only applies when using in-cluster building.
Type
Default
Required
boolean
false
No

providers[].kaniko

​providers > kaniko
Configuration options for the kaniko build mode.
Type
Required
object
No

providers[].kaniko.extraFlags[]

​providers > kaniko > extraFlags
Specify extra flags to use when building the container image with kaniko. Flags set on container modules take precedence over these.
Type
Required
array[string]
No

providers[].kaniko.image

​providers > kaniko > image
Change the kaniko image (repository/image:tag) to use when building in kaniko mode.
Type
Default
Required
string
"gcr.io/kaniko-project/executor:v1.6.0-debug"
No

providers[].kaniko.namespace

​providers > kaniko > namespace
Choose the namespace where the Kaniko pods will be run. Set to null to use the project namespace.
IMPORTANT: The default namespace will change to the project namespace instead of the garden-system namespace in an upcoming release!
Type
Default
Required
string
"garden-system"
No

providers[].kaniko.nodeSelector

​providers > kaniko > nodeSelector
Exposes the nodeSelector field on the PodSpec of the Kaniko pods. This allows you to constrain the Kaniko pods to only run on particular nodes.
​See here for the official Kubernetes guide to assigning Pods to nodes.
Type
Required
object
No

providers[].kaniko.tolerations[]

​providers > kaniko > tolerations
Specify tolerations to apply to each Kaniko Pod. Useful to control which nodes in a cluster can run builds.
Type
Default
Required
array[object]
[]
No

providers[].kaniko.tolerations[].effect

​providers > kaniko > tolerations > effect
"Effect" indicates the taint effect to match. Empty means match all taint effects. When specified, allowed values are "NoSchedule", "PreferNoSchedule" and "NoExecute".
Type
Required
string
No

providers[].kaniko.tolerations[].key

​providers > kaniko > tolerations > key
"Key" is the taint key that the toleration applies to. Empty means match all taint keys. If the key is empty, operator must be "Exists"; this combination means to match all values and all keys.
Type
Required
string
No

providers[].kaniko.tolerations[].operator

​providers > kaniko > tolerations > operator
"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.
Type
Default
Required
string
"Equal"
No

providers[].kaniko.tolerations[].tolerationSeconds

​providers > kaniko > tolerations > tolerationSeconds
"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.
Type
Required
string
No

providers[].kaniko.tolerations[].value

​providers > kaniko > tolerations > value
"Value" is the taint value the toleration matches to. If the operator is "Exists", the value should be empty, otherwise just a regular string.
Type
Required
string
No

providers[].defaultHostname

​providers > defaultHostname
A default hostname to use when no hostname is explicitly configured for a service.
Type
Required
string
No
Example:
1
providers:
2
- defaultHostname: "api.mydomain.com"
Copied!

providers[].deploymentStrategy

​providers > deploymentStrategy
Experimental: this is an experimental feature and the API might change in the future.
Sets the deployment strategy for container services.
The default is "rolling", which performs rolling updates. There is also experimental support for blue/green deployments (via the "blue-green" strategy).
Note that this setting only applies to container services (and not, for example, kubernetes or helm services).
Type
Default
Required
string
"rolling"
No

providers[].devMode

​providers > devMode
Configuration options for dev mode.
Type
Required
object
No

providers[].devMode.defaults

​providers > devMode > defaults
Specifies default settings for dev mode syncs (e.g. for container, kubernetes and helm services).
These are overridden/extended by the settings of any individual dev mode sync specs for a given module or service.
Dev mode is enabled when running the garden dev command, and by setting the --dev flag on the garden deploy command.
See the Code Synchronization guide for more information.
Type
Required
object
No

providers[].devMode.defaults.exclude[]

​providers > devMode > defaults > exclude
Specify a list of POSIX-style paths or glob patterns that should be excluded from the sync.
Any exclusion patterns defined in individual dev mode sync specs will be applied in addition to these patterns.
.git directories and .garden directories are always ignored.
Type
Required
array[posixPath]
No
Example:
1
providers:
2
- devMode:
3
...
4
defaults:
5
...
6
exclude:
7
- dist/**/*
8
- '*.log'
Copied!

providers[].devMode.defaults.fileMode

​providers > devMode > defaults > fileMode
The default permission bits, specified as an octal, to set on files at the sync target. Defaults to 0600 (user read/write). See the Mutagen docs for more information.
Type
Required
number
No

providers[].devMode.defaults.directoryMode

​providers > devMode > defaults > directoryMode
The default permission bits, specified as an octal, to set on directories at the sync target. Defaults to 0700 (user read/write). See the Mutagen docs for more information.
Type
Required
number
No

providers[].devMode.defaults.owner

​providers > devMode > defaults > owner
Set the default owner of files and directories at the target. Specify either an integer ID or a string name. See the Mutagen docs for more information.
Type
Required
`number
string`

providers[].devMode.defaults.group

​providers > devMode > defaults > group
Set the default group on files and directories at the target. Specify either an integer ID or a string name. See the Mutagen docs for more information.
Type
Required
`number
string`

providers[].forceSsl

​providers > forceSsl
Require SSL on all container module services. If set to true, an error is raised when no certificate is available for a configured hostname on a container module.
Type
Default
Required
boolean
false
No

providers[].imagePullSecrets[]

​providers > imagePullSecrets
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.
Type
Default
Required
array[object]
[]
No

providers[].imagePullSecrets[].name

The name of the Kubernetes secret.
Type
Required
string
Yes
Example:
1
providers:
2
- imagePullSecrets:
3
- name: "my-secret"
Copied!

providers[].imagePullSecrets[].namespace

​providers > imagePullSecrets > namespace
The namespace where the secret is stored. If necessary, the secret may be copied to the appropriate namespace before use.
Type
Default
Required
string
"default"
No

providers[].resources

​providers > resources
Resource requests and limits for the in-cluster builder, container registry and code sync service. (which are automatically installed and used when buildMode is cluster-docker or kaniko).
Type
Default
Required
object
{"builder":{"limits":{"cpu":4000,"memory":8192},"requests":{"cpu":100,"memory":512}},"registry":{"limits":{"cpu":2000,"memory":4096},"requests":{"cpu":200,"memory":512}},"sync":{"limits":{"cpu":500,"memory":512},"requests":{"cpu":100,"memory":90}}}
No

providers[].resources.builder

​providers > resources > builder
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!
Type
Default
Required
object
{"limits":{"cpu":4000,"memory":8192},"requests":{"cpu":100,"memory":512}}
No

providers[].resources.builder.limits

​providers > resources > builder > limits
Type
Default
Required
object
{"cpu":4000,"memory":8192}
No

providers[].resources.builder.limits.cpu

​providers > resources > builder > limits > cpu
CPU limit in millicpu.
Type
Default
Required
number
4000
No
Example:
1
providers:
2
- resources:
3
...
4
builder:
5
...
6
limits:
7
...
8
cpu: 4000
Copied!

providers[].resources.builder.limits.memory

​providers > resources > builder > limits > memory
Memory limit in megabytes.
Type
Default
Required
number
8192
No
Example:
1
providers:
2
- resources:
3
...
4
builder:
5
...
6
limits:
7
...
8
memory: 8192
Copied!

providers[].resources.builder.limits.ephemeralStorage

​providers > resources > builder > limits > ephemeralStorage
Ephemeral storage limit in megabytes.
Type
Required
number
No
Example:
1
providers:
2
- resources:
3
...
4
builder:
5
...
6
limits:
7
...
8
ephemeralStorage: 8192
Copied!

providers[].resources.builder.requests

​providers > resources > builder > requests
Type
Default
Required
object
{"cpu":100,"memory":512}
No

providers[].resources.builder.requests.cpu

CPU request in millicpu.
Type
Default
Required
number
100
No
Example:
1
providers:
2
- resources:
3
...
4
builder:
5
...
6
requests:
7
...
8
cpu: 100
Copied!

providers[].resources.builder.requests.memory

​providers > resources > builder > requests > memory
Memory request in megabytes.
Type
Default
Required
number
512
No
Example:
1
providers:
2
- resources:
3
...
4
builder:
5
...
6
requests:
7
...
8
memory: 512
Copied!

providers[].resources.builder.requests.ephemeralStorage

​providers > resources > builder > requests > ephemeralStorage
Ephemeral storage request in megabytes.
Type
Required
number
No
Example:
1
providers:
2
- resources:
3
...
4
builder:
5
...
6
requests:
7
...
8
ephemeralStorage: 8192
Copied!

providers[].resources.registry

​providers > resources > registry
Resource requests and limits for the in-cluster image registry. Built images are pushed to this registry, so that they are available to all the nodes in your cluster.
This is shared across all users and builds, so it should be resourced accordingly, factoring in how many concurrent builds you expect and how large your images tend to be.
Type
Default
Required
object
{"limits":{"cpu":2000,"memory":4096},"requests":{"cpu":200,"memory":512}}
No

providers[].resources.registry.limits

​providers > resources > registry > limits
Type
Default
Required
object
{"cpu":2000,"memory":4096}
No

providers[].resources.registry.limits.cpu

CPU limit in millicpu.
Type
Default
Required
number
2000
No
Example:
1
providers:
2
- resources:
3
...
4
registry:
5
...
6
limits:
7
...
8
cpu: 2000
Copied!

providers[].resources.registry.limits.memory

​providers > resources > registry > limits > memory
Memory limit in megabytes.
Type
Default
Required
number
4096
No
Example:
1
providers:
2
- resources:
3
...
4
registry:
5
...
6
limits:
7
...
8
memory: 4096
Copied!

providers[].resources.registry.limits.ephemeralStorage

​providers > resources > registry > limits > ephemeralStorage
Ephemeral storage limit in megabytes.
Type
Required
number
No
Example:
1
providers:
2
- resources:
3
...
4
registry:
5
...
6
limits:
7
...
8
ephemeralStorage: 8192
Copied!

providers[].resources.registry.requests

​providers > resources > registry > requests
Type
Default
Required
object
{"cpu":200,"memory":512}
No

providers[].resources.registry.requests.cpu

CPU request in millicpu.
Type
Default
Required
number
200
No
Example:
1
providers:
2
- resources:
3
...
4
registry:
5
...
6
requests:
7
...
8
cpu: 200
Copied!

providers[].resources.registry.requests.memory

​providers > resources > registry > requests > memory
Memory request in megabytes.
Type
Default
Required
number
512
No
Example:
1
providers:
2
- resources:
3
...
4
registry:
5
...
6
requests:
7
...
8
memory: 512
Copied!

providers[].resources.registry.requests.ephemeralStorage

​providers > resources > registry > requests > ephemeralStorage
Ephemeral storage request in megabytes.
Type
Required
number
No
Example:
1
providers:
2
- resources:
3
...
4
registry:
5
...
6
requests:
7
...
8
ephemeralStorage: 8192
Copied!

providers[].resources.sync

​providers > resources > sync
Deprecated: This field will be removed in a future release.
Resource requests and limits for the code sync service, which we use to sync build contexts to the cluster ahead of building images. This generally is not resource intensive, but you might want to adjust the defaults if you have many concurrent users.
Type
Default
Required
object
{"limits":{"cpu":500,"memory":512},"requests":{"cpu":100,"memory":90}}
No

providers[].resources.sync.limits

​providers > resources > sync > limits
Deprecated: This field will be removed in a future release.
Type
Default
Required
object
{"cpu":500,"memory":512}
No

providers[].resources.sync.limits.cpu

​providers >