Kubernetes
Overview
Check out our Kubernetes Chart Repository on GitHub and our published Helm Charts.
Quick-start
helm repo add flagsmith https://flagsmith.github.io/flagsmith-charts/
helm install -n flagsmith --create-namespace flagsmith flagsmith/flagsmith
kubectl -n flagsmith port-forward svc/flagsmith-frontend 8080:8080
Then view http://localhost:8080
in a browser. This will install the chart using default options, in a new namespace
flagsmith
.
Refer to the chart's default
values.yaml
file to learn
which values are expected by the chart. You can use it as a reference for building your own values file:
wget https://raw.githubusercontent.com/Flagsmith/flagsmith-charts/main/charts/flagsmith/values.yaml
helm install -n flagsmith --create-namespace flagsmith flagsmith/flagsmith -f values.yaml
We would suggest only doing this when running the platform locally, and recommend reading the Helm docs for installation, upgrading and values for further information.
Configuration
Ingress configuration
The above is a quick way of gaining access to Flagsmith, but in many cases you will need to configure ingress to work with an ingress controller.
Port forwarding
In a terminal, run:
kubectl -n [flagsmith-namespace] port-forward svc/[flagsmith-release-name]-frontend 8080:8080
Then access http://localhost:8080
in a browser.
In a cluster that has an ingress controller, using the frontend proxy
In this configuration, api requests are proxied by the frontend. This is simpler to configure, but introduces some latency.
Set the following values for flagsmith, with changes as needed to accommodate your ingress controller, and any associated DNS changes.
Eg in the charts/flagsmith/values.yaml
file:
ingress:
frontend:
enabled: true
hosts:
- flagsmith.[MYDOMAIN]
Then, once any out-of-cluster DNS or CDN changes have been applied, access https://flagsmith.[MYDOMAIN]
in a browser.
In a cluster that has an ingress controller, using separate ingresses for frontend and api
Set the following values for flagsmith, with changes as needed to accommodate your ingress controller, and any
associated DNS changes. Also, set the FLAGSMITH_API_URL
env-var such that the URL is reachable from a browser
accessing the frontend.
Eg in the charts/flagsmith/values.yaml
file:
ingress:
frontend:
enabled: true
hosts:
- flagsmith.[MYDOMAIN]
api:
enabled: true
hosts:
- host: flagsmith.[MYDOMAIN]
paths:
- /api/
- /health/
- /admin/
- /static/admin/
frontend:
extraEnv:
FLAGSMITH_API_URL: 'https://flagsmith.[MYDOMAIN]/api/v1/'
Then, once any out-of-cluster DNS or CDN changes have been applied, access https://flagsmith.[MYDOMAIN]
in a browser.
Minikube ingress
(See [https://kubernetes.io/docs/tasks/access-application-cluster/ingress-minikube/] for more details.)
If using minikube, enable ingress with minikube addons enable ingress
.
Then set the following values for flagsmith in the charts/flagsmith/values.yaml
file:
ingress:
frontend:
enabled: true
hosts:
- flagsmith.local
and apply. This will create two ingress resources.
Run minikube ip
. Set this ip and flagsmith.local
in your /etc/hosts
, eg:
192.168.99.99 flagsmith.local
Then access http://flagsmith.local
in a browser.
Provided Database configuration
By default, the chart creates its own PostgreSQL server within the cluster, referencing https://github.com/helm/charts/tree/master/stable/postgresql for the service.
We recommend running an externally managed database in production, either by deploying your own Postgres instance in your cluster, or using a service like AWS RDS.
You can provide configuration options to the postgres database by modifying the values, for example the below changes
the max_connections in the charts/flagsmith/values.yaml
file:
postgresql:
enabled: true
postgresqlConfiguration:
max_connections: '200' # override the default max_connections of 100
External Database configuration
To connect the Flagsmith API to an external PostgreSQL server set the values under databaseExternal
, eg in the
charts/flagsmith/values.yaml
file:
postgresql:
enabled: false # turn off the chart-managed postgres
databaseExternal:
enabled: true
# Can specify the full URL
url: 'postgres://myuser:mypass@myhost:5432/mydbname'
# Or can specify each part (url takes precedence if set)
type: postgres
host: myhost
port: 5432
database: mydbname
username: myuser
password: mypass
# Or can specify a pre-existing k8s secret containing the database URL
urlFromExistingSecret:
enabled: true
name: my-precreated-db-config
key: DB_URL
Due to a bug in python's urllib module, passwords containing [
, ]
or #
chars
must be urlencoded.
e.g.
postgres://user:pass[word@localhost/flagsmith
should be provided as:
postgres://user:pass%5Bword@localhost/flagsmith
Environment variables
It's important to define a secretKey
value in your helm chart when running in Kubernetes. Use a password manager to generate a random hash and set this so
that all the API nodes are running with an identical DJANGO_SECRET_KEY
.
If you are using our Helm charts and don't provide a secretKey
, one will be generated for you and shared across the
running pods, but this will change upon redeployment, which you probably don't want to happen.
The chart handles most environment variables required, but see the
API readme for all available configuration options. These can
be set using api.extraEnv
, eg in the charts/flagsmith/values.yaml
file:
api:
extraEnv:
LOG_LEVEL: DEBUG
Resource allocation
By default, no resource limits or requests are set.
TODO: recommend some defaults
Replicas
By default, 1 replica of each of the frontend and api is used.
TODO: recommend some defaults.
TODO: consider some autoscaling options.
TODO: create a pod-disruption-budget
Deployment strategy
For each of the deployments, you can set deploymentStrategy
. By default this is unset, meaning you get the default
Kubernetes behaviour, but you can set this to an object to adjust this. See
[https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy].
Eg in the charts/flagsmith/values.yaml
file:
api:
deploymentStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: '50%'