Self-Host OpenSearch on Kubernetes

OpenSearch is the Apache 2.0 licensed fork of Elasticsearch, maintained under the Linux Foundation. Self-hosting it on Kubernetes means running the OpenSearch Kubernetes Operator, which handles StatefulSets, transport TLS between nodes, and rolling upgrades. Edka installs the operator with cert-manager and brings up the cluster, certificates, and OpenSearch Dashboards configured, on a cluster in your own cloud account.

What OpenSearch Needs to Run

• Three nodes, minimum. The operator requires at least three cluster-manager nodes for quorum. This is the single biggest planning difference versus Elasticsearch, which runs on one.
• Memory over CPU. The JVM heap should sit at roughly half the container memory limit. The remainder feeds the filesystem cache that Lucene reads through.
• A persistent volume per node. Shards do not survive a pod landing on an empty disk.

Resource Requirements

Setting	Default	Range
Node count	3	3, 5, 7, or 9
JVM heap	1g	roughly 50% of the memory limit
Memory limit per node	2 GB	2 GB to 128 GB
CPU limit per node	set at install	0.5 to 48 CPU
Storage per node	50Gi	10 GiB to 1 TB, resizable

Budget for three of everything. At the 2 GB floor that is 6 GB of memory limits plus Dashboards before you index a document. A three node cluster on CPX31 nodes (4 vCPU, 8GB each) is a sensible production floor. See the Hetzner instance types table.

OpenSearch vs Elasticsearch

	OpenSearch	Elasticsearch
Minimum nodes	3	1
Operator	OpenSearch Kubernetes Operator	ECK
UI	OpenSearch Dashboards	Kibana
Licence	Apache 2.0, under the Linux Foundation	Elastic License and SSPL, AGPL added in 2024

Both descend from the same Lucene core and share most of the query API, so migrating an index mapping between them is usually mechanical.

Choose OpenSearch when the Apache 2.0 licence settles a procurement or redistribution question, or when you were going to run three or more nodes anyway. Choose Elasticsearch when you want a single node cluster or depend on Elastic’s commercial features. At three nodes and above the cost difference largely disappears.

What Edka Provisions

Edka installs OpenSearch through the OpenSearch Kubernetes Operator:

• Node count. 3, 5, 7, or 9 nodes. Each node carries the cluster_manager, data, and ingest roles.
• Persistent storage. A hcloud-volumes PersistentVolume per node, set at install and resizable later.
• Generated credentials. A password for the built-in admin user is generated and stored as a Kubernetes Secret, retrievable from the console.
• TLS. The operator issues certificates for both the transport (per-node) and HTTP layers.
• REST API endpoint. A ClusterIP service on port 9200, reachable in cluster at https://opensearch.opensearch-system.svc.cluster.local:9200.

OpenSearch Dashboards

Dashboards ships alongside the cluster by default. Edka deploys a single instance wired to the cluster, listening on port 5601, with a generated cookie secret that keeps browser sessions stable for the lifetime of the instance. Disable it from the console if you only need the REST API.

Configuration Options

• Resources. Memory limit per node, CPU limit per node, and the JVM heap size.
• Storage. Volume size per node and storage class.
• Dashboards. Toggle it on or off and set its memory (1 GB to 4 GB) and CPU (0.5 to 4 CPU) limits.
• Access. Publish Dashboards through an Envoy Gateway traffic class on your own hostname, with TLS from a matching Edka-managed wildcard or hostname certificate. A public hostname can fall back to Edka’s Gateway HTTP-01 issuer.

Deploy OpenSearch

1. Click “Deploy OpenSearch” below.
2. Select your node count, per-node resources, and JVM heap size.
3. Choose storage size, keep Dashboards on or off, and optionally expose it through a Gateway hostname.
4. Deploy. The cluster is ready in a few minutes.
5. Retrieve the generated admin password from the console and sign in to Dashboards.

Deploy OpenSearch