Operate OpenSearch on Kubernetes with the project operator

The OpenSearch Kubernetes Operator is an open-source operator that provisions and manages OpenSearch and OpenSearch Dashboards through custom resources. Its official documentation covers node pools, TLS, plugins, keystore secrets, persistence, lifecycle operations, users, roles, and snapshots. It automates reconciliation, while teams remain responsible for Kubernetes, capacity, recovery, and workload design.

The current operator documentation states that single-node clusters are not supported and requires at least three nodes with the master or cluster_manager role. That requirement must be checked against the exact operator release used. Production topology then adds data, ingest, or coordinating node pools based on workload, failure domains, and recovery objectives.

Node-pool replica counts can be changed declaratively, but safe scaling depends on shard placement, storage, JVM and native memory, disk watermarks, recovery bandwidth, failure capacity, and the operator version. A generic CPU or memory HPA does not understand every OpenSearch constraint. JusDB tests scaling and shard movement under representative workload before automating it.

The operator creates StatefulSets and supports node-pool storage configuration. We choose storage classes, volume size and expansion, topology, reclaim policy, throughput, and latency from workload and recovery evidence. PersistentVolumeClaims preserve data across ordinary pod replacement, but external snapshots and restore tests are still required for recoverability.

The operator supports lifecycle operations, but upgrade impact depends on the source and target versions, plugin compatibility, node pools, shard health, capacity, storage, disruption controls, and workload. We review release notes and compatibility, take and test snapshots, stage changes, observe each node pool, and define rollback or rebuild conditions before production rollout.