Helm Chart Updates
Available on: Open Source EditionEnterprise Edition
Release: 1.0.0
Overview
We have updated our Helm charts to be more comprehensive for production environments while also offering charts for starter use cases. Previously, we offered one chart that deployed one standalone Kestra service with one replica (i.e., all Kestra server components deployed in a single pod). It also came with preinstalled dependencies, such as PostgreSQL and MinIO, which were helpful to get started, but which were typically unnecessary for production installations. The Kestra Operator is also available as a custom Kubernetes Operator, specifically for reading Resource Definitions to conduct various actions in Kestra.
We also restructured configurations and values to be more comprehensive and production grade.
There are now three charts: kestra
(production chart), kestra-starter
(starter chart with dependencies), and kestra-operator
(Enterprise only custom Kubernetes operator).
Breaking changes have been made to the Helm chart in order to support the new features and improvements introduced in Kestra 1.0.0. Please review the following changes carefully before upgrading.
kestra
This chart is intended for production deployments. Here is how you can install it under the release name my-kestra
:
$ helm repo add kestra https://helm.kestra.io/
$ helm install my-kestra kestra/kestra --version 1.0.0
We removed PostgreSQL, MinIO, Kafka and Elasticsearch from the chart dependencies. You can now use your own managed services or deploy them separately. If you want to install Kestra with dependencies, use kestra-starter
chart. Keep in mind, that you will then have to manage these dependencies yourself.
Deployment configuration
Most of the deployment configuration options have been restructured. There is now a common entry in the values.yaml
— compare the Before
and After
sections below.
Before
nodeSelector: {}
tolerations: []
affinity: {}
extraVolumeMounts: []
extraVolumes: []
extraEnv: []
# more...
After
common:
nodeSelector: {}
tolerations: []
affinity: {}
extraVolumeMounts: []
extraVolumes: []
extraEnv: []
# more...
You can override all those configuration options in the deployments
entry in the values.yaml
file.
deployments:
standalone:
nodeSelector: {}
tolerations: []
affinity: {}
extraVolumeMounts: []
extraVolumes: []
extraEnv: []
# more...
Custom configuration files
We changed the way to provide custom configuration files to Kestra. It's now all under configurations entry in the values.yaml
file.
Before
### This creates a config map of the Kestra configuration
configuration: {}
# Example: Setting the plugin defaults for the Docker runner
# kestra:
# plugins:
# configurations:
# - type: io.kestra.plugin.scripts.runner.docker.Docker
# values:
# volume-enabled: true
### This will create a Kubernetes Secret for the values provided
## This will be appended to kestra-secret with the key application-secrets.yml
secrets: {}
# Example: Store your postgres backend credentials in a secret
# secrets:
# kestra:
# datasources:
# postgres:
# username: pguser
# password: mypass123
# url: jdbc:postgresql://pghost:5432/db
### Load Kestra configuration from existing secret
## Here this assumes the secret is already deployed and the following apply:
## 1. The secret type is "Opaque"
## 2. The secret has a single key
## 3. The value of the secret is the Kestra configuration.
externalSecret: {}
#secretName: secret-name
#key: application-kestra.yml
### configuration files
## This option allows you to reference existing local files to configure Kestra, e.g.
configurationPath:
# configurationPath: /app/application.yml,/app/application-secrets.yml
extraConfigMapEnvFrom:
# - name: my-existing-configmap-no-prefix
# - name: my-existing-configmap-with-prefix
# prefix: KESTRA_
extraSecretEnvFrom:
# - name: my-existing-no-prefix
# - name: my-existing-with-prefix
# prefix: SECRET_
After
configurations:
application:
kestra:
queue:
type: h2
repository:
type: h2
storage:
type: local
local:
basePath: "/app/storage"
datasources:
h2:
url: jdbc:h2:mem:public;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE
username: kestra
password: ""
driverClassName: org.h2.Driver
configmaps:
- name: kestra-others
key: others.yml
secrets:
- name: kestra-basic-auth
key: basic-auth.yml
There is no more need to take care of configurationPath:
; it's automatically managed by the chart. If you need to add extra environment variables from existing ConfigMaps
or Secrets
, you can still use extraEnv
and extraEnvFrom
under the common
entry.
Managing Docker in Docker (dind)
We upgraded the way that dind
is managed. It's now under the dind
entry in the values.yaml
. We added dind.mode
, to choose between rootless
and insecure
; rootless
is the default and recommended mode.
For a full list of values, refer to the Values in the chart's source code.
Was this page helpful?