Simpler YAML for Elasticsearch on Kubernetes with ECK - Elasticsearch Labs

Start free trial

Blog

Elastic Cloud on Kubernetes, simplified: zone awareness, restarts, and mTLS<br>ECK 3.4 reduces zone-aware HA from 40 lines of YAML to one field, adds declarative rolling restarts via annotation, and wires Kibana-Elasticsearch mTLS automatically.<br>Kubernetes<br>OK<br>By: Omer KushmaroMay 15, 2026

Get hands-on with Elasticsearch: Dive into our sample notebooks in the Elasticsearch Labs repo, start a free cloud trial, or try Elastic on your local machine now.

ECK 3.4 makes the Elastic Stack on Kubernetes simpler to operate. Zone-aware HA, safe rolling restarts, and Kibana↔Elasticsearch mTLS each become a one-line answer in your manifest.<br>If you operate Elastic Cloud on Kubernetes (ECK), this release is about reducing the friction in the things you do every day.<br>Easier to operate, easier to understand<br>ECK 3.4 is a release focused on reducing what you have to think about when you run The Elastic Stack on Kubernetes. Each headline change picks a multi-step task and turns it into a single declarative answer:<br>Simplified zone awareness. Telling ECK that a cluster should be spread across availability zones is now a single field on the NodeSet. The operator handles the topology, the scheduling, and the Elasticsearch-side awareness configuration on your behalf. Your manifests reflect what you mean, not how it's wired.<br>Restart a cluster the same way you do everything else. Triggering a rolling restart is now an annotation on the Elasticsearch resource. It's declarative, fits GitOps, and leaves an audit trail. No force-edit on an unrelated field to get a rollout.<br>mTLS is automatically configured by the operator. Wiring mutual TLS between Kibana and Elasticsearch by hand requires managing CAs, per-component client certificates, mounts, rotation, and configurations on both ends. ECK 3.4 takes care of all of that: flip a flag on Elasticsearch, point Kibana at it, and the operator manages the rest.<br>This release is to make day-to-day ECK operations boring, in the best sense: fewer fields to remember, fewer side trips to keep in sync, and simpler-to-understand manifests.<br>Simplified zone awareness<br>Make an Elasticsearch cluster highly available across availability zones by setting one field on the NodeSet. ECK 3.4 handles the topology spread, the pod scheduling, and the Elasticsearch-side awareness configuration for you.<br>Before, you had to wire all of this by hand across four separate objects: an annotation on the Elasticsearch resource for downward node labels, awareness attributes in the NodeSet config, a fieldRef env var in the pod template to surface the zone, and a matching topologySpreadConstraints block plus a nodeAffinity rule pinning the cluster to specific zones. Roughly forty lines of YAML, easy to misconfigure.<br>In ECK 3.4, the same zone-aware cluster is four lines:<br>To pin to a specific set of zones, name them, and ECK adds the matching required node affinity rules:<br>If you do need to customize maxSkew or whenUnsatisfiable, providing a matching topology spread constraint with the same topologyKey in podTemplate still wins. Your override stays an override.<br>One note for upgrades: enabling zoneAwareness on an existing NodeSet changes the StatefulSet pod template (new topology spread constraints, ZONE env var, node affinity, node.attr.zone), which triggers a one-time rolling restart of the affected NodeSet. Plan accordingly.<br>To learn more about simplified zones management, you can read this page at Elastic Docs.<br>Declarative rolling restarts<br>Restarting an Elasticsearch cluster without changing its spec is now a first-class workflow in 3.4. Two new annotations on the Elasticsearch resource do the work:<br>eck.k8s.elastic.co/restart-trigger: set or change this value (a timestamp is the conventional choice) to start a rolling restart. Changing the value triggers another restart later; removing the annotation does not.<br>eck.k8s.elastic.co/restart-allocation-delay: optional duration string (e.g. "20m") passed to the Elasticsearch node shutdown API as the allocation delay during the restart, so you can hold off on rebalancing while a pod recycles.<br>Under the hood, ECK propagates the trigger value to pod annotations, which changes the StatefulSet template hash and feeds every pod through the existing rolling-upgrade path (node shutdown API, predicates, one-pod-at-a-time deletion). There's no new restart mechanism to learn, and the status messages and observability you already have on rolling upgrades carry over.<br>For GitOps users, this means a Flux/ArgoCD pipeline can request a restart by patching one annotation: no spec drift, no diff churn, no force-edit on an unrelated field.<br>Managed mTLS for Kibana ↔ Elasticsearch<br>Mutual TLS orchestration between Kibana and Elasticsearch arrives with this release. The Elasticsearch CRD accepts a single new field, spec.http.tls.client.authentication: true, that tells the cluster to require client certificates...