Kubernetes operator support for the fork

Just curious, can I know the reasons why you are not using helm chart for deployments?

we don’t have a classical devops setup where we build something and have one production environment - we’re running software in various setups (ranging from SaaS (with multiple production environments (for legal reasons)) to on-prem - with more than 100 production environments, most of which are not managed by us), in various different versions (you won’t get an on-prem customer to upgrade every 5min even if you’d release that often :slightly_smiling_face:) and various setups (not every customer has the same set of features and thus not the same set of applications) and various different configurations. furthermore, our software product offering is quite vast (we’re not just talking about 10-20 microservices here).
e.g. we have / will potentially have multiple opensearch clusters running in the same k8s namespace, depending on the use-cases - but they should of course still share most config-related things (i.e. i don’t want to build up the k8s resources manually for each of them - i just want the name to be different).

helm charts were not offering this capability when we started on this journey with k8s (quite a while ago) - they might be now (to be honest i’m not sure, haven’t looked at them in detail) but we’re quite heavily invested in our current approach. so while we might switch at some point i’d probably even then still not be able to use standard opensearch helm charts.


I get your use-case, I was just thinking you can leverage Helm Charts itself for configuring different types of clusters in your production environments but the issue lies on sharing config related things which I guess might not be possible with a Helm Chart as it scaffolds a new release altogether once you install a chart.

Helm charts only help with provisioning, which is just part of the lifecycle. An Operator can do a lot more. In the case of the Zalando operator you can scale based on metrics or other data. The operator can configure cross cluster and how the cluster is setup. The operators also does rolling restarts.

Many other operators do things like backups, data management, upgrades, and chaos/failure testing.


This isn’t strictly true. Helm charts can manage post provisioning lifecycle events using chart hooks.

I think the OpenSearch community would benefit from having a helm chart as well as an operator. It can take quite a bit of detailed operational experience to implement a complex operator and often these details are learned over time. Starting with a helm chart would make a good stop gap and inform the development of a more complex operator.

1 Like

Added a tracking issue in the repo, and hope the community can help resolve: [Help Needed] OpenSearch/Dashboards in Kubernetes Operator · Issue #13 · opensearch-project/opensearch-devops · GitHub


Hi Guys,

Is opensearch planning to use fork of zolando operator? Or something else?Have fair bit of understanding about K8s. Will be more than happy to contribute.

1 Like

Hey! We have built an awesome Kubernetes operator for OpenSearch that will be released soon. If you want to contribute to the project or request a feature, you’re welcome to contact us here: operator@opster.com


see also:

1 Like

Hi, we released the Kubernetes operator.

If you’d like to be an early user or are interested in collaborating on this, check out the github repo: https://github.com/Opster/opensearch-k8s-operator

The open-source Apache 2.0 Operator will be used for automating the deployment, provisioning, management, and orchestration of OpenSearch clusters.


Just updating that both Zalando and Rancher operators are being merged into Opster k8s operator linked above.


That’s really great news @asafmesika!

1 Like

:rocket: New version out for OpenSearch Kubernetes Operator with following features included -

  • Deploy multiple OpenSearch clusters.
  • Spin up OpenSearch Dashboards.
  • Configuration of all node roles (master, data, coordinating…).
    • Drain strategy for smart scale down.
    • Change nodes’ memory & CPU allocation and limits.
  • OpenSearch Version upgrades.
  • Secured installation features.
  • Certificate management.

Checkout this blog to get started - Introducing open-source Kubernetes Operator for OpenSearch · OpenSearch