Deploy Kustomizations

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

Example

devspace.yaml

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

The above example will be executing during the deployment process as follows if the kustomize binary is not installed:

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

Kustomize Deployments

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

kustomize vs kubectl -k

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

DevSpace also provides the kustomizeBinaryPath field which expects a path to the kustomize binary. By default, DevSpace will use the kustomize located on your $PATH. Use this to specify a location for kustomize if it is not on your $PATH.

Example: Setting Path To Kustomize Binary

deployments:
  backend:
    kubectl:
      kustomize: true
      kustomizeBinaryPath: /path/to/kustomize
      manifests:
      - backend/

Deploying the above example would use the /path/to/kustomize binary to render the manifests.

danger

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

Update Image Tags

If the updateImageTags field is set to true for a deployment, DevSpace will replace/update all image tags before deploying the project.

When enabled, 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.

Example: Enable Tag Updates

deployments:
  backend:
    updateImageTags: true
    kubectl:
      manifests:
      - backend/

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.

Extra Arguments

When deploying manifests via kubectl, DevSpace can pass additional arguments and flags to the kubectl commands used for the deployment process.

Args For kubectl create

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

Example: Custom Kubectl Args & Flags

deployments:
  backend:
    kubectl:
      manifests:
      - backend/
      createArgs:
      - "--recursive"

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

kubectl create --dry-run --output yaml --validate=false --recursive -f backend/

Kustomize Deployments

DevSpace only uses kustomize create to render the manifests using the default flags --dry-run --output yaml --validate=false. The actual deployment will be executed using kubectl apply after DevSpace has replaced the image tags within the rendered manifests in memory.

Args For kubectl apply

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.

Example: Custom Kubectl Args & Flags

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

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

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

Args For kustomize

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

Example: Custom Kustomize Args & Flags

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

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

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

Note: Directly copying the example shown above would result in your deploy failing (it would result in Error: unknown flag: --timeout).