Deploy Kustomizations

To deploy Kustomizations using kustomize / kubectl apply -k, you need to configure them within the deployments section of the devspace.yaml.

Example

deployments:
- name: my-deployment
  kubectl:
    kustomize: true
    manifests:
    - my-kustomization/
    - another-kustomization/

The above example will be executing during the deployment process as follows:

kubectl apply -k my-kustomization/
kubectl apply -k another-kustomization/

Kubectl or Kustomize Required

Kustomization deployments require kubectl or kustomize to be installed. If both are available, DevSpace will use the kustomize binary by default.

Manifests

manifests

The manifests option is mandatory and expects an array of paths that point to directories containing Kustomizations.

Example: Manifests

deployments:
- name: backend
  kubectl:
    kustomize: true
    manifests:
    - my-kustomization/
    - another-kustomization/

kustomize

The kustomize option expects a boolean stating if DevSpace should deploy using kustomize (or alternatively: kubectl apply -k).

danger

If you set kustomize = true, all of your manifests must be paths to Kustomizations. If you want to deploy some plain manifests and some Kustomizations, create multiple deployments for each of them.

Default Value for kustomize

kustomize: false

Example: Kustomize

deployments:
- name: backend
  kubectl:
    kustomize: true
    manifests:
    - kustomization1/
    - glob/path/to/more/kustomizations/

replaceImageTags

The replaceImageTags option expects a boolean stating if DevSpace should replace/update all image tags before deploying the project.

By default, DevSpace searches all your manifests for images that are defined in the images section of the devspace.yaml. If DevSpace finds an image, it replaces or appends the image tag with the tag it created during the image building process. Image tag replacement makes sure that your application will always be started with the most up-to-date image that DevSpace has built for you.

In-Memory Tag Replacement

Tag replacement takes place in-memory and is not writing anything to the filesystem, i.e. it will never change any of your configuration files.

Default Value for replaceImageTags

replaceImageTags: true

Example: Disable Tag Replacement

deployments:
- name: backend
  kubectl:
    replaceImageTags: false
    manifests:
    - backend/

Kubectl Options

applyArgs

The applyArgs option expects an array of strings stating additional arguments (and flags) that should be used when calling kubectl apply.

Apply for Kustomize Deployments

Even if you set kustomize: true, DevSpace only renders the manifest templates using kustomize but the actual deployment will be executed using kubectl apply.

Default Value for applyArgs

applyArgs: []

Example: Custom Kubectl Args & Flags

deployments:
- name: backend
  kubectl:
    manifests:
    - backend/
    applyArgs:
    - "--timeout"
    - "10s"
    - "--grace-period"
    - "30"

Explanation:
Deploying the above example would roughly be equivalent to this command:

kubectl apply --timeout=10s --grace-period=30 -f backend/

kustomizeArgs

The kustomizeArgs option expects an array of strings stating additional arguments (and flags) that should be used when calling kustomize build.

Kustomize Deployments

DevSpace only uses kustomize build to render the manifest templates. The actual deployment will be executed using kubectl apply.

Default Value for kustomizeArgs

kustomizeArgs: []

Example: Custom Kustomize Args & Flags

deployments:
- name: backend
  kubectl:
    manifests:
    - backend/
    kustomize: true
    kustomizeArgs:
    - "--timeout"
    - "10s"
    - "--grace-period"
    - "30"

Explanation:
Deploying the above example would roughly be equivalent to this command:

kustomize build --timeout=10s --grace-period=30 -f backend/

deleteArgs

The deleteArgs option expects an array of strings stating additional arguments (and flags) that should be used when calling kubectl delete.

Purging Deployments

For plain manifests or Kustomizations, DevSpace uses kubectl delete to remote deployments when you run the command devspace purge.

Default Value for deleteArgs

deleteArgs: []

Example: Custom Kubectl Args & Flags

deployments:
- name: backend
  kubectl:
    manifests:
    - backend/
    deleteArgs:
    - "--timeout"
    - "10s"
    - "--grace-period"
    - "30"

Explanation:
Deploying the above example would roughly be equivalent to this command:

kubectl delete --timeout=10s --grace-period=30 -f backend/

cmdPath

The cmdPath option expects an array of strings stating additional flags and flag values that should be used when calling kubectl apply.

danger

Setting cmdPath makes it much harder to share your devspace.yaml with other team mates. It is recommended to add kubectl to your $PATH environment variable instead.

Example: Setting Path To Kubectl Binary

deployments:
- name: backend
  kubectl:
    manifests:
    - backend/
    cmdPath: /path/to/kubectl

Explanation:
Deploying the above example would roughly be equivalent to this command:

/path/to/kubectl apply -f backend/

General Options

name

The name option is required and expects a string to identify this deployment.

Example: Deployment Name

deployments:
- name: backend
  kubectl:
    manifests:
    - backend/
    - backend-extra/

namespace

The namespace option is required and expects a string with the namespace used to deploy the manifests.

danger

Only use this option if you really need to. Hard-coding the namespace in devspace.yaml makes it harder to share the configuration with your colleagues. It is recommended to set the default namespace of the current context instead using:

devspace use namespace [some-namespace]

Example: Deployment Namespace

deployments:
- name: backend
  namespace: some-namespace
  kubectl:
    manifests:
    - backend/
    - backend-extra/

disabled

If true, the deployment will not be deployed, rendered or purged. Can be useful in combination with config expressions or command variables.