Deploy Kubernetes Inline Manifests

To deploy Kubernetes using inline manifests with kubectl apply, you need to configure them within the deployments section of the devspace.yaml.

Example

devspace.yaml

pipelines:
  dev: 
    run: |
      create_deployments backend
      create_deployments frontend
deployments:
  backend:
    kubectl:
      inlineManifest: |-
        apiVersion: v1
        kind: Pod
        metadata:
          name: busybox-sleep
        spec:
          containers:
          - name: busybox
            image: busybox:1.28
            args:
            - sleep
            - "1000000"
  frontend:
    kubectl:
      manifests:
      - frontend/manifest.yaml

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

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep
spec:
  containers:
  - name: busybox
    image: busybox:1.28
    args:
    - sleep
    - "1000000"
EOF

You can also use variables:

vars:
  CONTAINER_NAME: $(cat my-example.txt)

deployments:
  backend:
    kubectl:
      inlineManifest: |-
        apiVersion: v1
        kind: Pod
        metadata:
          name: busybox-sleep
        spec:
          containers:
          - name: ${CONTAINER_NAME}
            # name: $(cat my-example.txt) won't work!
            image: busybox:1.28
            args:
            - sleep
            - "1000000"
      createArgs:
      - "--recursive"

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.

kubectl Binary

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 kubectlBinaryPath option, DevSpace will download the kubectl binary into the $HOME/.devspace/bin folder.

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:
      inlineManifest: |-
        apiVersion: v1
        kind: Pod
        metadata:
          name: busybox-sleep
        spec:
          containers:
          - name: busybox
            image: busybox:1.28
            args:
            - sleep
            - "1000000"
      createArgs:
      - "--recursive"

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

cat <<EOF | kubectl create --dry-run --output yaml --validate=false --recursive -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep
spec:
  containers:
  - name: busybox
    image: busybox:1.28
    args:
    - sleep
    - "1000000"
EOF

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/