Deploy Kubernetes Manifests
To deploy Kubernetes manifests with kubectl apply, you need to configure them within the deployments section of the devspace.yaml.
Example
deployments:
- name: backend
kubectl:
manifests:
- backend/
- backend-extra/
- name: frontend
kubectl:
manifests:
- frontend/manifest.yaml
The above example will be executing during the deployment process as follows:
kubectl apply -f backend/
kubectl apply -f backend-extra/
kubectl apply -f frontend/manifest.yaml
Deployments with kubectl require kubectl to be installed. If the kubectl binary cannot be found within the $PATH variable and it is not specified by specifying the cmdPath option, DevSpace will download the kubectl binary into the $HOME/.devspace/bin folder.
Manifests
manifests
The manifests option is mandatory and expects an array of paths or path globs that point to Kubernetes manifest files (yaml or json files) or to folders containing Kubernetes manifests or Kustomizations.
Example: Manifests
deployments:
- name: backend
kubectl:
manifests:
- backend/
- backend-extra/
- glob/path/to/manifests/
kustomize
The kustomize option expects a boolean stating if DevSpace should deploy using kustomize (or alternatively: kubectl apply -k).
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.
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.
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/
createArgs
The createArgs option expects an array of strings stating additional arguments (and flags) that should be used when calling kubectl create.
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.
Default Value for createArgs
createArgs: []
Example: Custom Kubectl Args & Flags
deployments:
- name: 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/
deleteArgs
The deleteArgs option expects an array of strings stating additional arguments (and flags) that should be used when calling kubectl delete.
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.
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.
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.