OpenSearch Kubernetes operator vs Helm charts vs VM installs

Both the OpenSearch Kubernetes Operator and the community Helm charts run on top of a Kubernetes cluster that you operate, so the cluster's own upkeep becomes part of the OpenSearch bill of work. The operator automates node pools, rolling upgrades and TLS certificate hot reloading, but it does not upgrade Kubernetes, rotate the control plane or back up etcd for you. The charts leave even more to your team. Before you pick either model, confirm who owns the Kubernetes layer, because that owner carries the upgrade calendar. Kubernetes ships roughly three minor releases per year on cycles of about 14 weeks, and the project maintains only the three most recent minors. As of September 2026 those were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027). Plan a standing upgrade every few months rather than an occasional project. The version skew policy requires kube-apiserver to move first, one minor at a time, before kube-controller-manager, kube-scheduler and kubelets, and kubelets may trail the API server by up to three minors. That gives you a workable window, but it also means an OpenSearch node pool can sit on an older kubelet for longer than you expect. Check the exact support dates on kubernetes.io before you commit to a distribution.

A production control plane needs more than upgrades. The kubeadm high availability guide describes a stacked topology with etcd on the control plane nodes or an external etcd cluster, with at least three control plane nodes behind a TCP load balancer on port 6443. Kubernetes documentation says etcd should run with an odd number of members, recommends five in production, and requires a tested backup plan using etcdctl snapshot save and etcdutl for restores. Kubernetes Secrets are stored unencrypted in etcd by default, so the cluster needs encryption at rest, least-privilege RBAC and a decision on whether OpenSearch credentials come from an external store. Ask whoever runs the cluster to show a restore drill, not only a backup job. Confirm which Kubernetes distribution you will use and what its support contract covers: patch cadence, the minor versions it supports, who handles etcd backup and restore, and who is on call for control plane incidents. Certified distributions are listed through the CNCF conformance program, but conformance only confirms API support, not operations. If your team has no Kubernetes skills today, price that gap in staff training or a support retainer before you choose the operator over a VM install.

On VM installs, the host is the part of the deployment you own completely, so the documented production settings become your checklist. OpenSearch's installation docs say vm.max_map_count must be at least 262144 on production Linux workloads, the Java heap should be set to half of system RAM, and bootstrap.memory_lock should be enabled so the JVM is not swapped out, because swapping can dramatically decrease performance and stability. Each node needs these values applied and kept applied across reboots. Under the operator, the same settings are expressed through the cluster spec and Kubernetes node configuration, and the operator manages the pods. On VMs, nothing enforces them except your configuration management, so confirm them with a check on every node after each build and each change.

The four install routes differ mainly in how repeatable the result is. Debian and RPM packages give you a systemd-managed service and standard package upgrades, but the tuning, the opensearch.yml contents and the security setup still have to be applied by hand or by your own scripts, so drift between nodes is common. A tarball install is the most manual, since you also own the service unit, the user, the file paths and the upgrade procedure. The Ansible playbook documented by the OpenSearch project is the route closest to infrastructure-as-code without Kubernetes: the host settings, heap sizing and node configuration live in version-controlled variables, and a rebuilt node follows the same path as the original. Before you adopt it, read the playbook's variables and confirm that they cover the three tuning settings, TLS and your security configuration, because the playbook covers what its maintainers chose to cover.

Plan upgrades around the maintenance policy. OpenSearch versions stay in maintenance until the next major version enters maintenance or one year passes, whichever is longer, and during maintenance they receive bug fixes and security patches but no new features. The 2.19 line still shipped 2.19.6 on July 6, 2026, while 3.9.0 shipped on September 29, 2026, and a new minor version is targeted about every eight weeks. This means a VM fleet on a maintained 2.x line can take patches without a major change, but moving to 3.x is a planned migration with its own testing. Ask the vendor or your integrator to confirm the current support end date for the line you run before you schedule the work, and rehearse rolling restarts on a non-production copy, since a VM cluster has no operator enforcing quorum-safe restarts for you.

All three models run the same OpenSearch software, so the data and cluster configuration can move between them in principle. What differs is the operational contract each model puts around that software. On the operator, persistent volumes, node pools and TLS certificates are managed through custom resources. On the Helm charts, those same concerns live in values files and the Kubernetes objects they render, which you maintain. On VMs, the contract is host configuration: vm.max_map_count, the Java heap, bootstrap.memory_lock, data paths and certificate files on each node. Moving from one model to another means rebuilding that contract on the new side, so the migration effort depends on how much of the old setup was hand-maintained.

Migration in principle is supported by the lineage of the software. OpenSearch is wire-compatible with Elasticsearch 7.10, can use indices from Elasticsearch 6.0 through 7.10, and supports rolling upgrades from those versions, according to the OpenSearch FAQ. That path is documented context for moving data forward through versions, not a documented route for changing deployment model. Before you assume a move between the operator, the charts and VMs is routine, confirm the steps with the vendor and rehearse them in a test environment that mirrors your certificates, storage layout and Helm values. Ask specifically how the operator adopts an existing cluster, how the charts handle an existing data volume, and what the rollback path is if the cutover fails.

Plan for the one-time and recurring costs separately. The one-time cost is the rebuild of persistent volume claims, certificate issuance and host tuning on the new side, plus the test cycles needed to prove the move. The recurring cost is whichever model you keep, since the operator reduces hand-run upgrade steps, while the charts and VMs leave more of that work with your team. If you expect to change models later, record the current opensearch.yml settings, the Helm values or operator resources, and the certificate chain in version control, so the next move starts from documented state rather than from memory.