Kubernetes
Garden can apply Kubernetes manifests via the kubernetes
module type. In many cases you'll want to use a kubernetes
module to deploy a container
module. You can do this by referencing the image ID of the container
module in your Kubernetes manifests.
Basics
First off, a couple of things to note on how Kubernetes support is implemented, with respect to Garden primitives:
One
kubernetes
module maps to a single Garden service (not to be confused with the Kubernetes Service resources), with the same name as the module.Because a Kubernetes manifest does not contain actual code (i.e. your containers/images), you'll often need to make two Garden modules for a single deployed service, e.g. one
container
module for your image, and then thekubernetes
module that references it.
Referencing manifests
When configuring a kubernetes
module, you have a choice between pointing Garden to the actual manifest files via the files
directive or simply adding the manifests inline in your Garden config under the manifests
directive.
Manifest files
If your project structure looks something like this:
You can reference the manifests 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:
Inline
You can also include the manifests inline with your Garden configuration. For example:
Using variables
Whether you have your manifests inline or reference them as files, you can use Garden template strings. For example:
Tasks and tests
You may also want to define tests and/or tasks that execute in one of the containers defined in the manifest. For example:
Note first the serviceResource
field. This tells Garden which Kubernetes Deployment, DaemonSet or StatefulSet to regard as the primary resource of the manifest. In this case, it is simply the postgres
application itself. When running the db-init
and db-clear
tasks, Garden will find the appropriate container spec in the manifest based on the serviceResource
spec, and then execute that container with the task's args
and (optionally) the specified env
variables.
The same applies to any tests that you specify. For example:
Instead of the top-level serviceResource
you can also add a resource
field with the same schema to any individual task or test specification. This can be useful if you have different containers in the chart that you want to use for different scenarios.
Linking container modules and Kuberneretes modules
When your project also contains one or more container
modules that build the images used by a kubernetes
module, you want to make sure the container
s are built ahead of applying the Kubernetes manifests, and that the correct image tag is used when deploying. For example:
Here the api
module specifies the image as a build dependency, and additionally injects the api-image
version into the Kubernetes manifest.
Code Synchronization (Dev Mode)
For dev mode to work you must specify serviceResource.containerModule
, so that Garden knows which module contains the sources to use for code syncing. You can also use the devMode.command
directive to, for example, start the container with automatic reloading or in development mode.
For the above example, you could then run garden deploy -w --dev=api
to start the api
service in hot-reloading mode. When you then change the sources in the api-image module, Garden syncs the changes to the running container from the Helm chart.
Production environments
Next steps
Last updated