Kubernetes Logging in 2026: Elasticsearch, OpenSearch, Loki, or Just Renting It from Your Cloud

Nobody chooses a logging stack. Teams choose a metrics stack deliberately, argue about it, benchmark it. Logging just sort of happens: whatever the cloud gives you, or whatever chart someone installed in 2022, quietly ingesting gigabytes a day until the bill or the OOM forces the first real decision. Then the team discovers that logging solutions differ more than almost any other category of infrastructure, and that the differences were all downstream of one question nobody asked at the start.

The question: how much of your log data do you index?

Index everything, and every query is instant but you run a search engine cluster. Index almost nothing, and storage is nearly free but queries do the work at read time. Rent the whole problem, and someone else operates it while you pay per gigabyte forever. Every serious option is one of these three answers wearing a product name. Here is the comparison, with the numbers.

Family one: index everything (Elasticsearch and OpenSearch)

Elasticsearch and OpenSearch are the same answer from two vendors, and their shared story is quick to tell: both are built on Apache Lucene, both tokenize and index every field of every log line at ingest, and both give you the payoff of that work: full-text search across terabytes in milliseconds, arbitrary aggregations, and a mature dashboard layer (Kibana, or OpenSearch Dashboards).

They split in 2021, when Elastic moved off Apache 2.0 to fight AWS’s managed offering, and AWS forked the last open commit into OpenSearch. Five years on, both halves of the fork are healthy, and the licensing has settled into something you can finally reason about. Elasticsearch (9.4 today) added AGPLv3 back as an option in late 2024, so it is open source again by OSI rules, though the trademark and roadmap remain Elastic’s. OpenSearch (3.7 as of June) is Apache 2.0 under the OpenSearch Software Foundation, part of the Linux Foundation since 2024, with genuinely multi-party governance. If the 2021 fork was about trust, 2026’s honest scorecard says: Elastic rebuilt a lot of it, and OpenSearch built the more neutral home.

Functionally they remain close enough that choosing between them is mostly a governance and ecosystem question, not a capability one. Elasticsearch moves faster on vendor-led features (ES|QL, the vector search push); OpenSearch has been closing gaps and adding its own (3.7 even ships native PromQL support, of all things).

What both make you pay is the same tax: you are now operating a distributed search engine. JVM heap sizing, shard strategy, index lifecycle management to tier old indices off hot storage, cluster upgrades, and the RAM appetite that comes from holding an inverted index of everything you have ever logged. The rule of thumb that survives every generation of this stack: the index costs as much as the data. For a Kubernetes cluster logging 50 GB a day, an Elastic-family deployment is typically three dedicated nodes and someone who knows what refresh_interval does.

That tax buys real things. If your logs are a product surface (search-heavy support tooling, audit trails a customer queries), if you run security analytics or SIEM workloads over them, or if analysts genuinely ask arbitrary questions of full log content all day, the Elastic family is the correct tool and nothing else on this page truly substitutes for it.

Family two: index almost nothing (Grafana Loki)

Loki’s founding insight is that most log queries are not arbitrary. An engineer debugging production does not search “all logs containing this string ever.” They look at one service, in one namespace, over the last hour, and then grep. So Loki indexes only a small set of labels (namespace, app, pod, the things you filter by), and stores the log content itself as compressed chunks in object storage. The index is tiny. The storage is S3-priced. The grep happens at query time, brute-forced in parallel over just the chunks your labels selected.

The consequences, good and bad, all follow from that one design choice:

• Cost collapses. Object storage plus a small index means Loki’s cost per retained terabyte is a fraction of an indexed store’s, and retention becomes a bucket lifecycle policy instead of a cluster expansion.
• Kubernetes fit is natural. Labels are already how Kubernetes thinks. Your LogQL query mirrors your kubectl mental model, and Grafana displays logs next to the metrics they correlate with.
• Queries are only as fast as their label selection. A well-labeled query over an hour is instant. An unbounded “find this request ID across everything, last 30 days” is a cluster-wide brute-force scan, exactly the query the Elastic family eats for breakfast.
• Cardinality discipline is mandatory. Labels are the index; a high-cardinality label (user ID, request ID) explodes the index and defeats the design. Those values belong in the log line, found by grep, not in labels.

One operational note that matters this year specifically: Promtail, the log shipper most Loki tutorials (ours included) grew up with, reached end-of-life on March 2, 2026. Its replacement is Grafana Alloy, Grafana’s OpenTelemetry Collector distribution, which carries Promtail’s capabilities plus metrics, traces, and OTLP in one agent, and ships a one-command config converter. If you deploy Loki today, deploy Alloy beside it, not Promtail; if you run Promtail today, the migration is a config conversion, not a re-architecture.

Loki is AGPLv3, single-vendor (Grafana Labs) but with the structural mitigation that your data sits in your object storage in an open format, and the ecosystem around it is the largest in observability.

Family three: rent the whole problem (GCP Logs Explorer and friends)

Every hyperscaler will make logging entirely not your problem: an agent ships everything to a managed service, retention is a setting, the query UI is a browser tab, and the operational burden is zero. Google’s Cloud Logging with its Logs Explorer is the cleanest example, so let us use its actual prices.

Cloud Logging charges $0.50 per GiB ingested after a free 50 GiB per project per month, with 30 days of storage included; keeping logs longer costs $0.01 per GiB-month, and querying costs nothing extra. Run the math on a modest 200 GB per month: 150 paid GiB is $75, plus $3 if you keep 90 days. Call it $78 a month for a fully managed, quite good, log system. At 1 TB per month the same math lands around $500. AWS CloudWatch Logs and Azure Monitor price with the same shape: cheap-looking per-GB rates that scale linearly with volume, forever.

The catches are structural, not hidden. The bill tracks your log volume, and log volume grows with traffic, debug verbosity, and team size, none of which anyone budgets for. The query languages and dashboards are provider-specific, so your runbooks and muscle memory are non-portable. And the moment you have clusters on more than one provider, or on Hetzner where there is no managed logging at all, you either run two logging systems or none. Cloud logging is the right answer for single-cloud teams below a few hundred gigabytes a month, and it gets quietly wrong as either of those conditions decays.

The same 1 TB, three ways

Rough numbers, deliberately conservative, for 1 TB of logs a month with 90-day retention:

Approach	What you run	Monthly cost shape
GCP Cloud Logging	Nothing	About $495 ingestion plus $19 retention, roughly $515, scaling linearly with volume forever
Elasticsearch / OpenSearch	3+ node cluster, ILM, someone who owns it	Roughly $300 to $600 of compute and disk (more on a hyperscaler), plus the real cost: the engineer-hours
Loki + Alloy	2 small pods plus object storage	Tens of euros of compute, single-digit euros of object storage, cardinality discipline as the price of admission

The pattern generalizes: cloud logging wins below roughly 100 to 200 GB per month on convenience, Loki wins on cost from there to nearly any scale if your query patterns are label-shaped, and the Elastic family wins whenever the queries themselves are the product, at whatever the cluster costs, because nothing else answers them.

The decision framework

Four questions settle almost every case:

1. Are logs a product or a debugging tool? Product (search features, SIEM, customer-facing audit): Elastic family. Debugging: keep reading.
2. Is all your Kubernetes on one hyperscaler, under ~200 GB per month, and likely to stay that way? Yes: use the cloud’s logging, stop here, spend the saved attention elsewhere.
3. Multi-cloud, cost-sensitive, or European-cloud clusters? Loki with Alloy, in your object storage. This is the default answer for most Kubernetes teams in 2026, and it is why it is the default in our stacks too.
4. Do you need both? Common at scale: Loki for the debugging firehose, a small Elastic-family index for the subset that needs real search (security events, audit logs). Route with Alloy; it exists to do exactly this kind of splitting.

Where Ankra sits in this

Deliberately underneath, and deliberately neutral, the same position as with metrics backends.

First: for the most common thing teams use logs for, live debugging, you need none of the above to start. The Ankra agent streams pod logs directly from any managed cluster, and the AI reads them, along with events, manifests, and the stack change that broke things, when it investigates an incident or explains a crashloop. A logging backend is for retention and search across time, not for “why is this pod crashing right now.” Plenty of small teams run on live logs plus alerts for months, which is exactly the right amount of infrastructure for their stage.

When you do want retention, the logging stack is an ordinary Stack: Loki and Alloy (or an OpenSearch cluster, if your answer to question one was “product”) as pinned-version addons with the namespace first and dependencies wired through parents, deployed by Ankra’s engine, committed to your Git repo, and cloned to every cluster that needs it. Grafana credentials and shipper tokens go through SOPS, because plaintext secrets in a values file is how logging stacks end up in security postmortems.

The stack is yours to choose. The part where someone has to remember how it was wired, keep it identical across environments, and explain at 3 AM what changed, that part is the platform’s job.

Pick your family with the framework above, then deploy it once, as a stack, and let it be boring. Start free, and if you are unsure, the AI will happily draft you the Loki stack to react to.

---

Get started: Create a free account on Ankra.

Join our community: Slack

Follow us on: LinkedIn | GitHub

Contact us: [email protected]