Kubernetes manifests

Planned. This page describes designed behaviour that is not built yet. Details may change before it ships.

Ported from Garden’s documentation: garden-for/kubernetes/deploy-k8s-resource.md, gliss-cli at 3bc62a036 (Garden 0.14). Gliss runs Garden under the hood; the notes on this page say where Gliss differs.

In Gliss, kubernetes Deploy actions are available at level 2 only. Your IT team enables level 2 per project, and every release is checked against IT’s policy instead of the catalog. The project still uses the gliss provider: the deploy becomes a signed release request, and the cluster agent applies it. You don’t configure Garden’s kubernetes provider or a kubeconfig.

You deploy your own Kubernetes resources with the kubernetes Deploy action. This page shows how to point Garden at your manifests, deploy an image you build, and change values per environment. The kubernetes Deploy action works much like the helm Deploy action. The full field list is in Garden’s kubernetes Deploy reference.

Reference manifests

Point Garden at your manifest files with the spec.manifestFiles field. You can also put manifests inline in spec.manifests, but files are easier to reuse with other tools.

Option 1: Manifest files (recommended)

If your project looks like this:

.
├── api
│   ├── garden.yml
│   ├── manifests
│   │   ├── Deployment.yaml
│   │   ├── Ingress.yaml
│   │   └── Service.yaml
│   └── src
└── project.garden.yml

reference the manifests like this:

kind: Deploy
type: kubernetes
name: api
spec:
  manifestFiles:
    - ./manifests/Deployment.yaml
    - ./manifests/Ingress.yaml
    - ./manifests/Service.yaml

Glob patterns work too:

kind: Deploy
type: kubernetes
name: api
spec:
  manifestFiles:
    - ./manifests/*

You can use templating to pick manifests per environment, for example with a manifests/dev and a manifests/prod directory:

kind: Deploy
type: kubernetes
name: api
spec:
  manifestFiles:
    - ./manifests/${environment.name}/Deployment.yaml
    - ./manifests/${environment.name}/Ingress.yaml
    - ./manifests/${environment.name}/Service.yaml

Garden can’t include files from parent directories. If your manifests are in a parent directory of the action’s garden.yml, set source.path:

kind: Deploy
type: kubernetes
name: api
source:
  path: ../ # <--- Garden will now treat the parent directory as the action source path
spec:
  manifestFiles:
    - ./manifests/Deployment.yaml # <--- Reference the manifests relative to the source path
    - ./manifests/Ingress.yaml
    - ./manifests/Service.yaml

Option 2: Inline

kind: Deploy
type: kubernetes
name: api
spec:
  manifests:
    - apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: api
        labels:
          app: api
      spec:
        # ...
    - apiVersion: v1
      kind: Service
      metadata:
        name: api
        labels:
          app: api
      spec:
        # ...

Deploy an image built by Garden

Most commonly you use the kubernetes Deploy action with a container Build action: one builds your code, the other deploys it. Your manifests will likely contain a hard-coded image, while the image Garden builds has a different version. The recommended way to set the right image is the patchResources field.

Option 1: Patch resources (recommended)

patchResources overwrites any field in your manifests with Kubernetes’ built-in patch functionality, without changing the manifest files:

kind: Build
type: container
name: api
---
kind: Deploy
type: kubernetes
name: api
dependencies: [build.api]
spec:
  manifestFiles: [my-manifests.yml]
  patchResources:
    - name: api # <--- The name of the resource to patch, should match the name in the K8s manifest
      kind: Deployment # <--- The kind of the resource to patch
      patch:
        spec:
          template:
            spec:
              containers:
                - name: api # <--- Should match the container name from the K8s manifest
                  image: ${actions.build.api.outputs.deployment-image-id} # <--- The output from the Build action above

This way you add the Garden action to your project without changing existing configuration. Garden has a complete example project that uses this approach.

Option 2: Template strings in inline manifests

If you define the manifests inline, you can use template strings in them directly:

kind: Deploy
type: kubernetes
name: api
dependencies: [build.api]
spec:
  manifests:
    - apiVersion: apps/v1
      kind: Deployment
      spec:
        template:
          spec:
            containers:
              - name: api
                image: ${actions.build.api.outputs.deployment-image-id} # <--- The output from the Build action above

Overwrite values

The same patchResources pattern overwrites other values. For example, to change the number of replicas and an environment variable per environment:

kind: Deploy
type: kubernetes
name: api
spec:
  manifestFiles: [my-manifests.yml]
  patchResources:
    - name: api # <--- The name of the resource to patch, should match the name in the K8s manifest
      kind: Deployment # <--- The kind of the resource to patch
      patch:
        spec:
          replicas: "${environment.name == 'dev' ? 1 : 3}" # <--- Set replicas depending on environment
          template:
            spec:
              containers:
                - name: api # <--- Should match the container name from the K8s manifest
                  env:
                    - name: LOG_LEVEL
                      value: "${environment.name == 'dev' ? 'verbose' : 'info' }"

You can also loop over Garden variables and set each one as a container environment variable:

kind: Deploy
type: kubernetes
name: api

variables:
  apiEnv: # <--- Garden variables that we'll set as K8s container env vars
    NODE_ENV: development
    PORT: ${var.API_PORT} # <--- A shared variable that's set in the project config that we reference here

spec:
  manifestFiles: [my-manifests.yml]
  patchResources:
    - name: api
      kind: Deployment
      patch:
        spec:
          template:
            spec:
              containers:
                - name: api
                  env:
                    $forEach: ${var.apiEnv} # <--- Iterate over the values of ${var.apiEnv} variable...
                    $filter: "${item.value ? true : false}" # <--- ...optionally filter out empty values since Kubernetes doesn't support it...
                    $return: # <--- ...return them as valid Kubernetes name/value pairs
                      name: ${item.key}
                      value: ${string(item.value)}

See Variables and templating for the template syntax.

In Gliss, don’t put secret values in Garden variables or manifests, and don’t use Garden Cloud secrets. Secret values are set through Gliss secret requests, and your configuration refers to secrets by name only.

In Gliss, Garden’s sync mode and port forwarding aren’t available, so the spec.sync field and Garden’s guidance on default targets for sync don’t apply. Live code changes are Git-backed and work in Preview only, through gliss dev.

To add tests, see Tests and runs.

Get started

Build apps

Administer

Engineers

Troubleshooting

Kubernetes manifests

Reference manifests

Option 1: Manifest files (recommended)

Option 2: Inline

Deploy an image built by Garden

Option 1: Patch resources (recommended)

Option 2: Template strings in inline manifests

Overwrite values

​Reference manifests

​Option 1: Manifest files (recommended)

​Option 2: Inline

​Deploy an image built by Garden

​Option 1: Patch resources (recommended)

​Option 2: Template strings in inline manifests

​Overwrite values

Reference manifests

Option 1: Manifest files (recommended)

Option 2: Inline

Deploy an image built by Garden

Option 1: Patch resources (recommended)

Option 2: Template strings in inline manifests

Overwrite values