Elastic Cloud on Kubernetes (ECK): running Elasticsearch and Kibana as Kubernetes custom resources

The problem ECK solves for Elasticsearch operators

Running Elasticsearch on Kubernetes without an operator means writing your own StatefulSets, your own TLS wiring, your own rolling restart logic for topology changes, and your own handling of the keystore that holds secure settings. ECK exists to replace that work. The README states it automates deployment, provisioning, management and orchestration of Elasticsearch, Kibana, APM Server, Enterprise Search, Beats, Elastic Agent, Elastic Maps Server, Logstash, Elastic AutoOps Agent and Elastic Package Registry on Kubernetes, based on the operator pattern.

The audience is narrow and specific. You need a Kubernetes cluster you control, and you need to run Elastic stack components on it. If you are evaluating ECK as a way to avoid operating Kubernetes at all, it is the wrong direction: it adds custom resources to a cluster you already have to run. The listed feature set is also a fair summary of what the operator takes over: TLS certificate management, safe cluster configuration and topology changes, persistent volume usage, custom node configuration and attributes, and secure settings keystore updates. Those last two are the parts teams most often get wrong by hand.

How the operator pattern maps onto Elastic stack components

ECK is written in Go, and the repository layout reflects a controller-runtime operator rather than a CLI tool. The top level holds cmd/, pkg/, config/, deploy/ and test/, plus PROJECT, which is the Kubebuilder marker file. Controllers live under pkg/, generated CRD and RBAC manifests under config/, and the Makefile drives code generation and image builds. The go.mod file shows the dependencies you would expect from a Kubernetes operator that also talks to cloud storage: controller-runtime, client-go and the API machinery alongside AWS, Azure and Google Cloud storage SDKs.

Each Elastic component becomes a custom resource in your cluster. You declare an Elasticsearch resource, and a Kibana resource that references it; the operator reconciles the underlying StatefulSets, Services and Secrets. TLS certificates are issued and rotated by the operator, so the Elasticsearch HTTP layer and the Kibana connection to it are configured from generated material rather than from certificates you paste in by hand. Secure settings go into a keystore that the operator updates, which is why the README lists keystore updates as a distinct feature rather than folding it into configuration management.

The Makefile is worth reading before you touch the code. It pins controller-gen to the version recorded in go.mod and installs it into GOBIN if the local binary does not match, and it installs setup-envtest for the test suite. It also reads optional .registry.env and .env files, and defaults LOG_VERBOSITY to 1. None of that affects a cluster install, but it tells you the project expects contributors to regenerate manifests rather than edit them.

Installing the ECK operator and deploying a first cluster

The README does not inline installation commands. It points to the Quickstart in the Elastic documentation at elastic.co/guide/en/cloud-on-k8s/current/k8s-quickstart.html, and that page is where the CRDs and the operator manifest come from. Treat the Quickstart as the source of truth for the exact manifest URL, because the README does not reproduce it and this article will not invent one.

What you can verify from the repository is the version envelope you are installing into. The README lists Kubernetes 1.32 to 1.36 and OpenShift 4.16 to 4.22 as supported. Elasticsearch, Kibana and APM Server are supported at 8+ and 9+; Enterprise Search at 8+; Beats at 8+ and 9+; Elastic Agent at 8+ and 9+ in both Fleet and Standalone modes; Elastic Maps Server at 8+ and 9+; Logstash at 8.12+ and 9+; Elastic Package Registry at 8+; and Elastic AutoOps Agent at 9.2.1+ for Enterprise and 9.2.4+ for Basic. Check your cluster version against that list before anything else, since an unsupported Kubernetes version is not something the operator can work around.

Once the operator is running, components are declared as custom resources. The README does not include a manifest, so this article does not reproduce one. Read the Quickstart for the resource shape it documents, and confirm the apiVersion and the stack version string for your release there, because both track the operator version.

For contributors rather than users, the repository expects Go and a working kubectl context. The Makefile reads the current context into KUBECTL_CLUSTER and uses these targets:

make controller-gen
make setup-envtest

Those targets install the pinned controller-gen and install setup-envtest if it is missing. If you edit a CRD type under pkg/, regenerate the manifests under config/ rather than hand-editing YAML.

Where ECK is the wrong tool

ECK is not a small-footprint add-on. The operator watches custom resources across the cluster, manages certificates, and reconciles StatefulSets for every Elastic component you declare. On a single-node development cluster where you want one Elasticsearch process for a test, that machinery costs more than it saves, and a plain container or a local install will get you there faster.

The version envelope is the harder constraint. Kubernetes 1.32 to 1.36 is the supported range stated in the README. If your platform team runs an older cluster, or a managed Kubernetes service that lags or leads that window, ECK is not the right fit until the versions line up. The same applies to the stack side: Elastic Package Registry is listed as 8+ only, and Elastic AutoOps Agent has separate minimums for Enterprise and Basic, so a mixed-version rollout needs checking component by component rather than as one upgrade.

The README also documents no rollback procedure, no uninstall steps and no guidance on what happens to persistent volume claims when you delete a custom resource. That silence is not proof that nothing exists, but it means you should not assume the operator cleans up storage for you. Decide your retention policy before you delete anything.

Finally, ECK manages Elastic components; it does not manage the rest of your cluster. Certificate management, keystore updates and topology changes are scoped to the resources it owns. Anything outside those resources is your problem, and the operator will not reconcile it.

ECK against the Elastic Cloud managed service

The real alternative is Elastic Cloud, the hosted offering from the same vendor. The difference is who runs the control plane. With ECK, the operator runs inside your cluster, and you own the Kubernetes control plane, node pools, storage classes and upgrade windows for both Kubernetes and the operator. With the hosted service, Elastic runs the infrastructure and you interact with a managed endpoint.

That changes the failure surface. With ECK, an upgrade of the operator and an upgrade of the Elasticsearch resource are two separate operations, and the operator version determines which CRD fields exist. With the hosted service, that coordination is not yours to perform. The trade is control and data locality against operational surface area. ECK is the option when the data has to stay in a cluster you operate, or when you need the Elastic stack to sit next to other workloads in the same Kubernetes environment.

There is a middle position worth naming: running the Elastic stack on Kubernetes without ECK, using your own StatefulSets. That is a legitimate choice for a single component with unusual configuration, but you then own TLS rotation, keystore updates and safe topology changes, which are exactly the items the README lists as current features. The comparison is not about capability; it is about whether you want to maintain that logic yourself.

Maintenance, releases and licence questions

The last push to the main branch was on 2026-09-23, and the most recent release in the list is v3.5.0 from 2026-08-04, following v3.4.1 (2026-06-22) and v3.4.0 (2026-05-05). That release cadence means you should expect to track operator versions rather than install once and forget. The Go module path carries a major version suffix, github.com/elastic/cloud-on-k8s/v3, so the v3 line is the current import path for anything that depends on the operator's packages.

Upgrade cost is mostly about the CRDs and the stack version matrix. The README's supported-version list is the document to re-read on each upgrade, because it changes between releases: the AutoOps Agent entries with their separate Enterprise and Basic minimums are the clearest example of a component whose floor moves independently of the rest. Plan upgrades as two steps, operator first, then the Elastic resources, and verify the target stack version appears in the README's list before you change a resource.

The licence field for this repository is reported as NOASSERTION, and the Makefile header carries the notice that the file is licensed under the Elastic License 2.0. The repository also contains LICENSE.txt and NOTICE.txt at the top level, and those two files are what you should read for the actual terms, since the GitHub licence field is not a reliable summary here. Elastic's licensing has changed over time, and the terms that apply to the operator are not necessarily the same as those that apply to the Elasticsearch distribution you deploy with it. This is a factual observation about where the terms live, not legal advice; if the distinction matters to your organisation, have someone read LICENSE.txt and NOTICE.txt rather than relying on the repository metadata.

Editorial conclusion

Adopt ECK if you already run Kubernetes and want Elasticsearch, Kibana, APM Server or Beats managed through the operator pattern instead of hand-rolled StatefulSets. Do not adopt it if you only need a single Elasticsearch node, or if your cluster sits outside the supported Kubernetes 1.32 to 1.36 and OpenShift 4.16 to 4.22 ranges. Before installing, confirm which stack versions you need, because the README lists Elastic AutoOps Agent as requiring 9.2.1+ for Enterprise and 9.2.4+ for Basic, and Elastic Package Registry as 8+ only.

Frequently asked questions

Official sources

1. elastic/cloud-on-k8s on GitHub
2. Issues
3. README
4. Releases