Kubernetes
You can use the kubernetes
Deploy action type to deploy the parts of your stack that already have Kubernetes manifests.
In the sections below we'll explain how to:
Point Garden to your manifests
Deploy a container image that's been built by Garden
Overwrite values in your manifests to suit your environment
Set the deployment target so Garden can stream logs and sync code changes
Configure code syncing for rapid development
Referencing manifests
When configuring a kubernetes
Deploy action, you point Garden to the manifest files via the spec.files
directive.
You can also specify them inline in your Garden config via the spec.manifests
field but we recommend the former approach since that allows you to re-use them with other tools.
Option 1: Manifest files (recommended)
If your project structure looks something like this:
You can reference the manifests like so:
You can also use glob patterns like so:
You can also use templating to reference different manifests based on environment.
For example, if your project structure looks like this:
You can reference the manifests like so:
If your manifests are in a parent directory relative to the action config file, you need to set the source.path
field for your action since Garden cannot include files from parent directories.
For example, if your project has the following structure:
You can reference manifests like so:
Option 2: Inline
You can also include the manifests inline with your Garden configuration although we generally recommend having dedicated manifest files since those are easier to re-use and will work with other tools.
You define manifests inline like so:
Deploying a container image built by Garden
Most commonly you'll use the kubernetes
Deploy action together with a container
Build action. That is, you build your source code with one action and deploy it with another.
Simplified, it looks like this:
The problem here is that your manifests will likely contain a "hard coded" container image whereas the image built by Garden will have a different version.
There's a few ways to handle that but the recommend approach is to use the patchResources
field.
Option 1: Patching resources (recommended)
The config will look like this:
With this approach, you can add the Garden action to your project without making any changes to existing config.
Option 2: Using Garden template strings
You can use Garden template strings in your Kubernetes manifests, both in manifests from files and in inline manifests.
For example, if you're using manifest files you can set the image like so:
Similarly, if you define your manifest inline you can set the image like so:
Overwriting values
You can use the exact same pattern as above where we set the container image to overwrite other values from your manifests.
If you for example need to change the number or replicas depending on environment and/or set some env variables, you can do so via the patchResources
field like we did above. For example:
The benefit of this approach is that you don't need to make any changes to your existing manifests.
Setting a default target resource
This is only relevant for Deploy actions that deploy resources that contain a Pod spec. If you're using the action to e.g. deploy a ConfigMap or a Secret you can skip this.
Some Garden commands like the logs
and exec
commands depend on Garden knowing what the target Kubernetes resource is. Same applies to code synchronization, Garden needs to know into what container in which Pod to sync code changes.
To enable this, users can configure a default target for Garden to use for these commands like so:
Instead of specifying the target kind and name, you can also set a pod selector directly like so:
Code Synchronization
Code synchronization (i.e. hot reloading) can be configured for the Kubernetes Deploy action. In the example below, code synchronization is set up from the api
Build action's directory.
Production environments
Next steps
Last updated