I have been recently working on K8s. I can pick this up but will be needing an additional hand from the community as I don’t have in depth understanding about OpenSearch.
@TheAlgo That’s great news. What kind of help specifically do you need?
I am currently working on creating a Helm Chart for OpenSearch. This is helping me understand it better. Once the PR is merged I can start on the operator.
I know the RedHat team was asking about a Helm Chart. Personally, I think the operator would be more useful. I really like the Zalando one. I hope we adopt OpenSearch on k8s in the future.
Here is a tracking issue from May: Interest in contributing to OpenSearch · Issue #169 · zalando-incubator/es-operator (github.com)
I have already created basic Helm charts for deploying official docker images of OpenSearch and OpenSearch Dashboards[PR is in review]. I will try going through how Zelando have built it and try doing a POC for OpenSearch to kickstart.
we’re definitely looking for an operator.
we’re not using helm charts for various reasons and have built our own k8s deployment descriptors for now as a quick-win (sorry, nothing i can easily share since it contains various company-internal things as well for our specific way of rolling things out).
we’d want an operator to have all the nice things which it usually brings you: properly managing rolling upgrades (as pointed out in How To: Upgrade from Open Distro to OpenSearch · OpenSearch you e.g. need to set some cluster settings before starting it & at the end), auto-scaling, etc. and it’d just in general make our life a lot easier if we can just create a custom resource and then get a full cluster deployed.
i’m still hoping that Zalando can be convinced to move their license to Apache 2.0 so that either their operator can be forked for OpenSearch or that they might also move to OpenSearch themselves and thus the operator itself is directly moved to support OpenSearch.
building a complete new operator from scratch is a lot more effort than re-using their existing, battle-proven operator. and “just having a look” at what they’re doing is a bit of a gray-zone from a legal point of view (different license, so copying would be re-licensing without their approval and also w/o attribution). but i’m no lawyer and hate all things licenses (well, actually by now all things lawyer-related ), just wanted to point out that there’s also a legal component to the whole thing.
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 ) 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.
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
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.
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: firstname.lastname@example.org
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!
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