Updated: deploy-elastick8s.sh v4.1

If you have been following along since the original post, you know the goal of deploy-elastick8s.sh has always been simple: give you a fast, repeatable way to stand up Elastic Stack configurations on Kubernetes for lab and test environments. No production workloads, no hand-holding through YAML, just get the stack up so you can actually do the thing you came here to do.

Version 4.1 is a significant update. The script has grown from a single-shot deployer into something closer to a proper lab management tool, with interactive version selection, a layered addon command system, helmeck mode, ECK 3.0+ and Stack 9.x support, and a handful of quality-of-life improvements throughout. This post walks through what changed and how to use it.

Download

curl -fsSL https://raw.githubusercontent.com/jlim0930/scripts/master/deploy-elastick8s.sh -o deploy-elastick8s.sh
chmod +x deploy-elastick8s.sh

Prerequisites

Same as before. You need:

jq
openssl
docker (running, and your user in the docker group)
kubectl (connected to a cluster)
helm

The script checks all of these before doing anything. If something is missing it tells you and exits.

What Is New

Interactive Version Selection

The biggest usability change in 4.1 is that you no longer type version numbers. Previously you had to know which ECK versions were valid, which Stack versions were compatible, and manually pass them in. Now the script fetches the actual release lists directly from GitHub and presents numbered menus.

When you run a command, you will see something like this:

Available ECK operator versions (newest first):

   1)  3.1.2
   2)  3.1.1
   3)  3.1.0
   4)  2.16.1
   ...

Select ECK version [1-N]:

After you pick an ECK version, the script figures out which Stack versions are compatible with it and shows you another menu filtered to that range. ECK 2.2+ unlocks 8.x. ECK 3.0+ unlocks 9.x. You pick from what is actually available, not from what you think might work.

Version lists are fetched once and cached for the life of the session, so you do not get extra API calls when you run multiple commands.

The Add-on Command Architecture

This is the structural change that shapes everything else. The old approach bundled everything into single monolithic commands. beats meant deploy stack plus beats. eckldap meant deploy stack plus LDAP. This made the commands fast to invoke but inflexible and hard to layer.

Version 4.1 splits the workflow into two tiers:

Base deployments stand up the stack (Elasticsearch and Kibana). You run one of these first.

Add-on commands layer components on top of an existing deployment. They read state from the working directory, figure out what is already running, validate compatibility, and deploy the addon.

This means you can now do things like:

./deploy-elastick8s.sh stack        # stand up ECK managed ES + Kibana
./deploy-elastick8s.sh add-beats    # add beats on top
./deploy-elastick8s.sh add-logstash # add logstash on top of that

Or:

./deploy-elastick8s.sh helmeck      # stand up ECK via Helm + ES + Kibana
./deploy-elastick8s.sh add-fleet    # add Fleet Server + Elastic Agent
./deploy-elastick8s.sh add-ldap     # add OpenLDAP + configure ES LDAP realm

State is persisted in ~/elastick8s through marker files (ECK, HELMECK, HELM, NATIVE) and version files (VERSION, ECKVERSION). The loadstate function reads these back when you run an addon so it can reconnect to the running cluster, grab the elastic password, and locate endpoints automatically.

Full Add-on Command Reference

Command	What it does	Supported base
`add-ldap`	OpenLDAP with TLS + ES LDAP realm	eck, helmeck, helm
`add-beats`	Filebeat, Metricbeat, Packetbeat, Heartbeat	eck, helmeck, helm, native
`add-monitor1`	Monitoring cluster + beats in pods	eck, helmeck
`add-monitor2`	Sidecar monitoring (ECK 1.7+ / Stack 7.14+)	eck, helmeck
`add-fleet`	Fleet Server + Elastic Agent	eck, helmeck
`add-fleet-nonroot`	Fleet + Agent, non-root (ECK 2.6+)	eck, helmeck
`add-apm`	Standalone APM Server (7.x and 8.x only)	eck, helmeck
`add-logstash`	Logstash + beats routed through Logstash	eck, helmeck, helm
`add-stack-policy`	StackConfigurationPolicy (ECK 2.6+)	eck, helmeck
`add-agent-deploy`	Standalone agent Deployment, root	eck, helmeck
`add-agent-ds`	Standalone agent DaemonSet, root	eck, helmeck
`add-agent-deploy-nonroot`	Standalone agent Deployment, non-root	eck, helmeck
`add-agent-ds-nonroot`	Standalone agent DaemonSet, non-root	eck, helmeck

helmeck Mode

The script now supports deploying the ECK operator itself via Helm (the eck-operator chart) and then deploying Elasticsearch and Kibana as ECK-managed resources through the eck-elasticsearch and eck-kibana Helm charts. This is different from the helm mode which uses Elastic’s standalone charts with no operator at all.

./deploy-elastick8s.sh helmeck

The helmeck deployment writes a HELMECK marker file in the working directory. Addon commands check for this marker and adjust accordingly. Cleanup knows to helm uninstall the ECK operator from elastic-system as part of teardown.

ECK 3.0 and Stack 9.x Support

ECK 3.0 introduced Kubernetes 1.27+ as a requirement and added full Stack 9.x support. It also removed the standalone ApmServer CRD entirely. APM is now managed through the Fleet and Elastic Agent APM integration.

The script handles this cleanly:

Version selection menus are filtered correctly so you cannot accidentally pair ECK 2.x with Stack 9.x
The add-apm command (and the legacy eckapm command) detect ECK 3.0+ and Stack 9.x at runtime and exit with a clear message pointing you toward the Fleet-based APM integration instead
The compatibility check on startup enforces these boundaries before any resources are created

If you are running ECK 3.0+ and want APM:

Run ./deploy-elastick8s.sh add-fleet to get Fleet Server and Elastic Agent deployed
In Kibana Fleet, add the Elastic APM integration to your agent policy
APM runs inside the elastic-agent pod and is accessible on port 8200

Non-root Fleet and Agent Deployments

ECK 2.6+ made it possible to run Fleet Server and Elastic Agent as non-root. The script now has dedicated commands for this:

./deploy-elastick8s.sh fleet-nonroot           # base: stack + fleet non-root
./deploy-elastick8s.sh add-fleet-nonroot       # addon: add non-root fleet to existing stack
./deploy-elastick8s.sh add-agent-deploy-nonroot  # standalone agent Deployment, non-root
./deploy-elastick8s.sh add-agent-ds-nonroot     # standalone agent DaemonSet, non-root

On ECK 2.6+, the operator automatically injects and trusts the ES CA certificate into the agent trust store. The script detects the ECK version and uses the clean CRD form without any bash workaround overrides when running 2.6 or newer.

StackConfigurationPolicy

ECK 2.6 introduced StackConfigurationPolicy, a CRD that lets you define configuration that applies across multiple Elasticsearch clusters managed by the operator. The script supports this both as a base command and as an addon:

./deploy-elastick8s.sh stackpolicy       # stack + StackConfigurationPolicy
./deploy-elastick8s.sh add-stack-policy  # add StackConfigurationPolicy to existing ECK stack

ECK Logstash CRD

When you run add-logstash against an ECK 2.6+ deployment, the script uses the ECK Logstash CRD (logstash.k8s.elastic.co/v1alpha1) with elasticsearchRefs wiring. For older ECK versions it falls back to a plain Kubernetes Deployment with a ConfigMap pipeline and a Secret-mounted CA cert. The SSL output configuration also adapts to the Stack version since the ssl_enabled vs ssl Logstash parameter naming changed in 8.x.

Operator Only Mode

You can now install just the ECK operator without deploying any stack components:

./deploy-elastick8s.sh operator

This is useful if you want to inspect the CRDs, test the operator itself, or prepare a cluster before deciding on a stack version.

Info and Summary

The info (aliased as summary) command reads state from the working directory and prints a summary of the current deployment: all running resources, endpoints, and credentials. You no longer have to scroll back through deployment output to find the Kibana URL.

./deploy-elastick8s.sh info

Base Command Reference

./deploy-elastick8s.sh operator          # ECK operator only
./deploy-elastick8s.sh stack             # ECK + ES + Kibana
./deploy-elastick8s.sh dedicated         # ECK + dedicated master + data nodes
./deploy-elastick8s.sh helmeck           # ECK via Helm + ES + Kibana
./deploy-elastick8s.sh stackpolicy       # ECK stack + StackConfigurationPolicy
./deploy-elastick8s.sh fleet             # ECK stack + Fleet + Elastic Agent
./deploy-elastick8s.sh fleet-nonroot     # ECK stack + Fleet + Agent, non-root
./deploy-elastick8s.sh helm              # ES + Kibana via Elastic Helm charts (7.14 to 7.17.x)
./deploy-elastick8s.sh native            # ES + Kibana as native Kubernetes resources

Utility Commands

./deploy-elastick8s.sh cleanup   # removes all resources and ~/elastick8s
./deploy-elastick8s.sh info      # prints endpoints and credentials for current deployment

Legacy Combined Commands

The old combined commands still work for anyone who prefers the single-step approach:

eckldap  beats  monitor1  monitor2  eckapm
helmldap  helmbeats  helmlogstashbeats  helmmonitor
nativebeats  nativemonitor

These still prompt for ECK and Stack versions interactively and run the base deployment plus the addon in one pass.

Version Compatibility Notes

Stack version	Minimum ECK
7.10+	1.4.0
7.14+ (Fleet)	1.7.0
8.0+	2.2.0
9.0+	3.0.0 (requires Kubernetes 1.27+)

The Helm mode (helm) is limited to Stack 7.14 through 7.17.x. The native mode supports 7.3 through 8.x.

Working Directory

All generated YAML manifests, version files, notes, and the ca.crt are written to ~/elastick8s. If you need to inspect or manually apply anything, that is where to look. The notes file inside that directory has all the endpoints and passwords in plain text for the current deployment.

The cleanup command removes ~/elastick8s entirely and deletes all Kubernetes resources created by the script. Run it before starting a fresh deployment.

Closing Note

As always, the deployments this script creates are not for production use. They are lab and test environments, intentionally simplified with self-signed certificates, fixed passwords, and no persistent storage configuration beyond what is needed to get the stack healthy. The goal is to get you into Kibana quickly so you can do whatever you actually came here to do.

The script is on GitHub at jlim0930/scripts.