Why not support official helm charts ? about helm-charts

[Crazybus]

Hey Maciej!

But the question is why you don't participate in creating charts from helm/charts repo ?

This is a great question and is something that we gave a lot of thought about before making the decision to create our own charts.

The most important reason is when it comes to support. We have a lot of demand from users for "official" helm charts that they know will continue to be maintained and supported by Elastic. It is not possible to provide official support or any guarantees on a community helm chart that is not under our own control.

From a technical point of view there are also a few things about the helm/charts version that would require breaking changes to update.

The current helm chart in the default charts repo does not support dedicated node types. Meaning you can only specify how many master, clients and data nodes that you require. While this works for most use cases it has quite a few downsides that means we can not recommend this approach for all of our users. This chart takes a very different approach where each group of nodes is a separate helm release install. This solves several very important requirements for running Elasticsearch.

1. Not all types of persistent volume claims support resizing. In 1.11 a beta feature was added to support resizing volumes. Our target is to support all currently supported versions of Kubernetes (which don't all have the resizing feature yet), and also other persistent volume types that may not support resizing, it is also a feature that must be enabled by the cluster admin for it to be used. In the end it means we can't assume that this feature will be available and we aren't comfortable with having users deploying an Elasticsearch cluster which can not be resized when they start to run out of space. By using separate helm releases for different groups of nodes, a new group can be added to cluster with a new disk size and then the old group can be removed.
2. Upgrade order. By putting each group of dedicated nodes into separate releases the user has full control over which order the groups of nodes are updated in.
3. All kinds of custom architecture can be supported such as hot warm instead of being opinionated on what architecture our users should have.

Apart from having dedicated node groups as separate helm releases these charts also have a dual-mode readiness probe to make sure that cluster upgrades or Kubernetes upgrades do not impact the availability of Elasticsearch. On initial startup the readinessProbe is checking the cluster health to ensure that Kubernetes waits for the cluster to become green before taking down the next node in the cluster. Without this a pod disruption budget will not prevent Kubernetes from impacting the availability of Elasticsearch.

They are more mature and well tested

Do you have any feedback or suggestions on what is missing testing wise? Unless I'm mistaken the helm/charts repo is only testing a default install of the helm chart with a single version of Kubernetes plus running a helm lint and helm template command. On top of that this charts also contains extensive testing of the helm templating logic itself. And we test multiple different configurations on different Kubernetes versions (currently all GKE versions) with plans to extend our coverage to other providers in the near future. The Kibana charts are also tested based on the deployed Elasticsearch charts to make sure that they work together properly.

You can find the Jenkins job on our devops-ci cluster.

And for sure they have many more options.

Could you note which particular options you are missing? From a helm point of view these charts appear to be very bare. But that is because we made the concious decision to use normal Elasticsearch configuration to configure our Elasticsearch docker images instead of creating helm abstractions to do the same thing.

As an example there is currently a todo item in the helm/charts version to "Implement TLS/Auth/Security". For our charts there is no helm specific logic to implement this. Instead it is all possible by configuring Elasticsearch directly in the native way via environment variables and secret mounts. You can see the example (which is also automatically tested) in the examples directory. And added side bonus of this is that is is very easy for us to support multiple versions and configurations without needing to figure out a helm way to do everything.

[Crazybus]

Hey Maciek!

I'm going to close this issue. If you do have any more questions or feel like something needs more clarification please feel free to re-open it!