Helm charts should not assume "high availability" is desired. We deploy to kubernetes for dev and production. For dev, we keep it simple, whereas for production, we add replicas, etc. Kubernetes is just a deployment platform that has flexibility and elasticity.
We had to switch back to deploying the docker-compose all-in-one on ec2, as the helm chart was not ready for prime time.
Here are my wish lists for the helm chart:
The helm chart should ideally deploy a Deployment, not a StatefulSet. There's rarely a need to store data using local store when we have databases. We run our databases/redis on ec2, external to kubernetes. StatefulSets add complexity to managing kubernetes.
Do not assume that the customer wants to run a HorizontalPodAutoscaler just because they want to run as a Deployment. Give the option to turn autoscaling on and configure the autoscaler separately from running as a Deployment.
Make sure that it works with external database / redis. There's no need to have multiple databases (mongo and postgres), that adds complexity to backup and maintenance routines. Ideally, use redis for session management, database for storage, and these are run externally. (As a side note, the app should also not generally care about the version of database or redis, otherwise the customer has to run multiple database servers and redis servers to support their multiple apps.)
Either the credentials are in the database URL or they are not. Don't have a username/password config and also expect username password to be in the URL. Stick to one or the other. Don't try to parse a database URL to get credentials!
Don't force the database to be run in a specific "high availability" mode (i.e. MongoDB replicaset as an example).
Allow extraVolumes and extraVolumeMounts. This allows for things like "secret store csi driver" to work, even if the mounted files aren't used for anything.
Allow the configuration to come from existing (external to helm-chart) secrets and config maps using the same flexibility as envFrom on a Deployment. I should be able to get some settings from one secret, others from another, choose the key to get it from, and also set some of the settings directly in values.yaml. We use GitOps and do not wish to store secrets in the values.yaml, and we use the secrets store csi driver to get other secrets.
Do not assume that the user uses a specific technology like "ExternalSecrets".
Make sure that technologies like KeyCloak do not add "yet another database technology" to the stack and it just "works" once you setup the optional SSO options in values.yaml
Make sure error messages are easy to figure out. It isn't obvious that something couldn't log into the database. I see a lot of noise and Temporal messages that are confusing, then the pod just shuts down.
Why should this be worked on?
The helm chart is basically unusable by Enterprises
maximemoreillon
commented
5 months ago
Is there an existing issue for this?
Summary
Helm charts should not assume "high availability" is desired. We deploy to kubernetes for dev and production. For dev, we keep it simple, whereas for production, we add replicas, etc. Kubernetes is just a deployment platform that has flexibility and elasticity.
We had to switch back to deploying the docker-compose all-in-one on ec2, as the helm chart was not ready for prime time.
Here are my wish lists for the helm chart:
Why should this be worked on?
The helm chart is basically unusable by Enterprises