Self-Host Elasticsearch on Kubernetes

Running Elasticsearch on Kubernetes by hand means writing StatefulSets, managing TLS between nodes, and handling rolling restarts without losing a shard. The Elastic Cloud on Kubernetes (ECK) operator does that work. Edka installs ECK with cert-manager and brings up the cluster, certificates, and Kibana configured, on a cluster in your own cloud account.

What Elasticsearch Needs to Run

• Memory, more than CPU. Elasticsearch is a JVM application that caches aggressively. The JVM heap should sit at roughly half the container memory limit, leaving the rest for the filesystem cache Lucene depends on.
• Persistent storage per node. Each node needs its own volume. Shards do not survive a pod moving to a fresh disk.
• An odd node count for clusters above one, so master election has a quorum.

Edka provisions all three through the operator rather than leaving them as YAML you maintain.

Resource Requirements

Setting	Default	Range
Node count	1	1, 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

A single node at 2 GB memory and a 1g heap runs comfortably on a CPX21 (3 vCPU, 4GB) for development. Production indexing wants more filesystem cache, so a CPX41 (8 vCPU, 16GB) is a more realistic starting point per node. See the Hetzner instance types table.

Storage is set at install and resizable later, so start smaller than you think you need.

Elasticsearch vs OpenSearch

They share a Lucene ancestry and most of the query API. The operational differences that matter when self-hosting:

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

The node minimum is the practical one. OpenSearch’s operator requires at least three cluster-manager nodes, so the floor is three volumes and three sets of resources. Elasticsearch runs on one. For a small search index or a development cluster, that is a real cost difference.

Choose Elasticsearch when you want a single node or you rely on Elastic’s commercial features. Choose OpenSearch when the Apache 2.0 licence matters to you and you were going to run three nodes regardless.

What Edka Provisions

Edka installs Elasticsearch through the ECK operator:

• Version. Choose between the current 9.x and 8.x release lines.
• Node count. 1, 3, 5, 7, or 9 nodes. A single node carries the master, data, ingest, ml, remote_cluster_client, and transform roles.
• Persistent storage. A hcloud-volumes PersistentVolume per node, set at install and resizable later.
• Generated credentials. A password for the elastic user is generated and stored as a Kubernetes Secret.
• TLS. ECK issues certificates for the cluster’s internal traffic.
• REST API endpoint. A ClusterIP service on port 9200, reachable in cluster at https://elasticsearch-es-http.elastic-system.svc.cluster.local:9200.

Kibana

Kibana ships alongside the cluster by default. Edka deploys a single Kibana instance wired to the Elasticsearch reference, listening on port 5601. 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, with one persistent volume per node.
• Kibana. Toggle it on or off and set its memory and CPU limits.
• Access. Publish Kibana through an Envoy Gateway traffic class on your own hostname, with TLS from a cert-manager cluster issuer.

Deploy Elasticsearch

1. Click “Deploy Elasticsearch” below.
2. Select your version, node count, and per-node resources.
3. Choose storage size, and optionally expose Kibana through a Gateway hostname.
4. Deploy. The cluster is ready in 3 to 5 minutes.
5. Retrieve the generated elastic password from your cluster and open Kibana.

Deploy Elasticsearch