OpenSearch on Kubernetes
OpenSearch on Kubernetes
In short: Running OpenSearch on Kubernetes means using the community OpenSearch Operator to deploy cluster-manager, data, ingest, and coordinating node roles as separate StatefulSets, each backed by PersistentVolumeClaims on SSD StorageClasses. The operator automates TLS, security-config, declarative scaling, snapshot-management backups, and rolling upgrades, with OpenSearch Dashboards for observability.
Deploy and operate production-grade OpenSearch clusters on Kubernetes with the OpenSearch Operator, Helm charts, OpenSearch Dashboards, and enterprise-grade search and analytics infrastructure.
JusDB engineers production-grade OpenSearch on Kubernetes deployments utilizing the official OpenSearch Operator and custom CRD topologies. Certified DBREs isolate dedicated cluster-manager and data pod pools, provision local NVMe storage classes, configure automated TLS cert-manager rotation, and orchestrate zero-downtime rolling upgrades backed by contractual 15-minute Sev-1 response SLAs and SOC 2 Type II compliance.
What we deliver
Comprehensive OpenSearch on Kubernetes Services
From OpenSearch Operator deployment to production monitoring, we provide end-to-end OpenSearch on Kubernetes solutions for search and analytics workloads.
OpenSearch Operator Deployment
Deploy and configure the OpenSearch Kubernetes Operator for automated cluster lifecycle management, rolling upgrades, and security configuration
- Operator installation and CRD setup
- Custom resource definitions for OpenSearch clusters
- TLS certificate auto-management
- Security plugin configuration via Kubernetes Secrets
Helm Chart Management
Production-ready Helm chart configuration and management for repeatable, version-controlled OpenSearch deployments
- Custom values.yaml for each environment
- Helm release lifecycle management
- Chart versioning and rollback strategy
- GitOps integration (ArgoCD / Flux)
Cluster Topology on K8s
Design and deploy dedicated cluster-manager, data, ingest, and coordinating node pools with proper resource isolation
- Dedicated cluster-manager node StatefulSets
- Hot-warm-cold data tier architecture
- Ingest node pipeline configuration
- Coordinating-only nodes for search routing
Storage & Persistence
Configure persistent volumes, storage classes, and data durability for OpenSearch on Kubernetes
- PVC-backed StatefulSet storage
- SSD StorageClass selection and tuning
- Volume expansion and resize policies
- Local PV vs network-attached storage
Monitoring & Observability
Full-stack monitoring with OpenSearch Dashboards on Kubernetes, Prometheus exporters, and Grafana dashboards
- OpenSearch Dashboards deployment on K8s
- Prometheus OpenSearch Exporter
- Grafana dashboards for cluster health
- Alerting on shard allocation and node status
Backup & Snapshots
Automated snapshot lifecycle management with S3, GCS, or Azure Blob storage for disaster recovery
- Snapshot management (SM) policies
- S3 / GCS / Azure Blob snapshot repositories
- Automated backup scheduling and retention
- Cross-cluster snapshot restore and DR drills
Why Kubernetes
Why Run OpenSearch on Kubernetes?
Kubernetes provides the orchestration layer that OpenSearch needs for automated scaling, self-healing, and declarative cluster management in production environments.
Horizontal Scaling
Scale data, ingest, and coordinating nodes independently based on workload demands. Combine Kubernetes HPA with custom Prometheus metrics to automatically add or remove OpenSearch pods as indexing or search traffic fluctuates.
Built-In Security
OpenSearch includes a security plugin out of the box with fine-grained access control, SAML and LDAP authentication, field-level and document-level security, and audit logging -- all without requiring a paid license tier.
Self-Healing Infrastructure
Kubernetes automatically restarts failed OpenSearch pods, reschedules them to healthy nodes, and maintains the desired replica count. Combined with OpenSearch's shard replication, this delivers robust fault tolerance.
Declarative Cluster Management
Define your entire OpenSearch topology as Kubernetes custom resources. Version-control your cluster configuration, enable GitOps workflows, and reproduce identical environments across dev, staging, and production.
OpenSearch on K8s Key Metrics
Node roles
OpenSearch Architecture on Kubernetes
Understanding the node roles and Kubernetes resources that make up a production OpenSearch deployment on K8s.
Cluster-Manager Nodes
StatefulSet (3 replicas)Dedicated cluster-manager nodes handle cluster state, shard allocation, and index metadata management. Run as a 3-node StatefulSet for quorum.
- Cluster state management
- Shard allocation decisions
- Index creation / deletion
- Lightweight resource footprint
Data Nodes
StatefulSet (scalable)Data nodes store index shards and execute search and indexing operations. Sized with high storage and memory, scaled horizontally based on data volume.
- Hot / warm / cold tiering
- PVC-backed persistent storage
- CPU and memory intensive
- Horizontal auto-scaling
Ingest Nodes
StatefulSet (scalable)Ingest nodes run preprocessing pipelines before documents are indexed. Isolate pipeline load from data node resources for better performance.
- Ingest pipeline execution
- Document enrichment
- Processor chain processing
- Independent scaling
Coordinating Nodes
StatefulSet (scalable)Coordinating-only nodes act as smart load balancers, routing search requests and aggregating results across data nodes without holding data.
- Search request routing
- Scatter-gather aggregation
- Client-facing endpoints
- Reduce data node load
Methodology
Our OpenSearch on Kubernetes Implementation Process
A proven methodology for deploying production-ready OpenSearch clusters on Kubernetes with comprehensive testing and validation.
Architecture & Planning
Analyze search, analytics, and log ingestion workloads. Design cluster topology, node roles, storage classes, and resource quotas for your Kubernetes environment.
Operator & Cluster Deployment
Deploy the OpenSearch Operator or Helm charts, configure custom resources, set up TLS and security plugin, provision PersistentVolumes with appropriate StorageClasses.
Integration & Testing
Integrate with ingestion pipelines (Data Prepper, Logstash, Fluent Bit), deploy OpenSearch Dashboards, configure index templates, run failover tests, and benchmark performance.
Production & Operations
Go live with monitoring, alerting, snapshot policies, and scaling. Provide runbooks, on-call playbooks, and ongoing support for rolling upgrades and capacity planning.
How JusDB DBRE Kubernetes Engineering compares to alternative paths.
Operating stateful OpenSearch clusters on Kubernetes without dedicated DBRE operator management risks cluster-manager quorum loss, PersistentVolume CSI attachment deadlocks, and uncoordinated rolling restart shard recovery storms. Here is how our certified cloud-native engineering compares across core evaluation vectors:
| Evaluation Vector | JusDB DBRE | In-House DBA | Legacy Agency | Developer Generalist |
|---|---|---|---|---|
| OpenSearch Operator vs Helm Chart Deployment Architecture | Deploys the official OpenSearch Kubernetes Operator with declarative CustomResourceDefinitions (CRDs), automating cluster topology lifecycle, node pool reconciliation, TLS generation, and GitOps sync via ArgoCD/Flux. | Deploys static Helm charts or monolithic YAML manifests without operator intelligence, requiring manual kubectl exec sessions to execute securityadmin.sh on configuration drift. | Deploys raw Kubernetes StatefulSets without operator automation, failing to configure seed host discovery and breaking automated TLS certificate renewal. | Runs OpenSearch as a standalone single-replica Deployment with ephemeral storage, leading to unrecoverable data loss during pod restarts or node rescheduling. |
| Dedicated Node Pool Isolation (Cluster-Manager vs Data vs Ingest) | Isolates dedicated node pools for cluster-manager (3-pod odd quorum), data (hot/warm NVMe), and ingest/coordinating tiers using Kubernetes taints, tolerations, and strict pod anti-affinity. | Combines cluster-manager and data roles onto uniform worker pods; heavy ingestion or vector search queries saturate CPU and trigger cluster-manager heartbeat timeouts. | Configures 2 cluster-manager pods without odd quorum voting, causing split-brain cluster partitions during routine node drain operations. | Provisions a single combined cluster-manager/data node; any pod rescheduling or container restart halts all read and write traffic across the cluster. |
| Local NVMe Storage Classes & PersistentVolumeClaim Sizing | Provisions high-IOPS local NVMe StorageClasses with DirectPV/local-static-provisioner, volumeClaimTemplates, dynamic volume expansion, and automated S3/GCS snapshot repositories for data durability. | Relies on default cloud network block storage (gp3/pd-standard) with unoptimized baseline IOPS, causing disk queue bottlenecks during concurrent Lucene segment merges. | Mounts shared NFS network volumes across OpenSearch data pods, inducing Lucene segment lock corruption and catastrophic index failure. | Uses hostPath or emptyDir storage with no PVC persistence, losing all index shards whenever Kubernetes evicts a pod. |
| PodDisruptionBudgets (PDB) & Multi-AZ Anti-Affinity Hardening | Enforces strict PodDisruptionBudgets (maxUnavailable: 1 per tier), topologySpreadConstraints, and zone-aware shard allocation routing (cluster.routing.allocation.awareness.attributes: zone). | Omits PDBs and anti-affinity; Kubernetes drains multiple data nodes concurrently during worker node upgrades, inducing yellow/red cluster health. | Deploys all cluster-manager and data pods into a single availability zone, resulting in total cluster outage during cloud zone failure. | Leaves scheduling entirely unconstrained; multiple pods colocate on a single overloaded node that crashes under memory pressure. |
| Zero-Downtime Rolling Stateful Upgrades & Shard Routing Rebalance | Implements preStop lifecycle hooks to temporarily disable shard reallocation (cluster.routing.allocation.enable: "primaries"), flush indices, and drain shards before pod termination. | Runs blind kubectl rollout restarts without disabling allocation, triggering massive unassigned shard recovery storms that saturate network bandwidth. | Shuts down the entire StatefulSet simultaneously during scheduled maintenance windows, causing multi-hour search downtime. | Updates image tags directly in production manifests without graceful drain, causing data corruption and unrecoverable red cluster states. |
| Kubernetes SecurityContext, TLS Cert-Manager & Snapshot Repositories | Hardens pod securityContext (non-root UID 1000, read-only root FS, seccomp), automates transport and REST TLS renewals via cert-manager, and enforces automated S3/GCS snapshot management (SM). | Uses static self-signed certificates with manual expirations, leading to unexpected cluster-wide transport encryption failures when certs expire. | Disables OpenSearch security and TLS plugins entirely to avoid configuration complexity, exposing raw search data on the internal pod network. | Runs containers as root with privileged capabilities, failing security compliance audits and risking host node compromise. |
Kubernetes Failure Modes
Critical OpenSearch on Kubernetes Risks We Eliminate
Operating distributed Lucene search clusters inside containerized Kubernetes environments introduces quorum consensus, CSI storage attachment, and shard rebalancing failure vectors. We engineer resilience into every layer to eliminate these production risks:
Cluster-Manager Pod Eviction Causing Complete Cluster Read/Write Freeze
During Kubernetes worker node drain or spot instance reclamation, multiple cluster-manager pods are evicted simultaneously. Without PodDisruptionBudgets, cluster quorum drops below majority, halting cluster state publishing and freezing all search and indexing operations.
JusDB configures strict PodDisruptionBudgets (maxUnavailable: 1 for cluster-managers), multi-AZ podAntiAffinity, dedicated tainted node pools, and preStop hooks preventing node drain without odd quorum verification.
Kubernetes Volume Detach Timeout Hanging Data Node Restarts
When data node pods are rescheduled across worker nodes, cloud CSI drivers (e.g., AWS EBS or GCP Persistent Disk) frequently experience volume attachment timeouts or Multi-Attach deadlocks. Data pods stay stuck in ContainerCreating, leading to degraded replica shards.
JusDB provisions local NVMe storage classes via DirectPV or volumeClaimTemplates with optimized CSI attach timeouts, configures automated volume detachment reconcilers, and conducts rolling upgrade failover drills.
Uncoordinated Rolling Pod Restart Triggering Shard Rebalance Storm
Standard Kubernetes rollout restarts terminate data pods sequentially without notifying the OpenSearch cluster. OpenSearch treats pods as dropped nodes and immediately triggers expensive network shard relocations, degrading query throughput.
JusDB injects preStop container lifecycle hooks to set cluster.routing.allocation.enable: 'primaries' and flush indices before shutdown, re-enabling allocation with cluster.routing.allocation.enable: 'all' via postStart.
Our DBREs execute non-blocking diagnostic commands across Kubernetes CRD controllers and OpenSearch REST endpoints to audit cluster topology, pod distribution, and shard routing health:
Audits custom resource controller status, cluster-manager/data pod distribution across Kubernetes worker nodes, node IP assignments, and pod ready conditions.
# Audit OpenSearchCluster CRD reconciliation and wide pod topology kubectl get opensearchcluster,pods -n opensearch -o wide
Inspects cluster transient allocation settings (validating disabled rebalance during upgrades) and per-node shard allocation counts with disk utilization metrics.
# 1. Inspect transient cluster settings and allocation status curl -s -X GET "http://localhost:9200/_cluster/settings?flat_settings=true" # 2. View shard distribution, counts, and node disk allocation curl -s -X GET "http://localhost:9200/_cat/allocation?v"
FAQ
OpenSearch on Kubernetes — Frequently Asked Questions
Common questions about deploying and operating OpenSearch on Kubernetes.
Weighing the move from Elasticsearch? Read our Elasticsearch vs OpenSearch comparison, or explore our OpenSearch consulting for architecture and migration advisory.
Ready to Run OpenSearch on Kubernetes?
Let our experts deploy and manage production-grade OpenSearch clusters on Kubernetes with the OpenSearch Operator, built-in security, OpenSearch Dashboards, and scalable search and analytics infrastructure.
Related OpenSearch Services
Explore more ways our OpenSearch experts can help with your database infrastructure.