One Agent, Three Ways: Running Elastic Agent on Kubernetes!
TL;DR: This post provides an overview of the available options for deploying Elastic Agent on Kubernetes with the new OTel configuration, rather than serving as a hands-on, step-by-step technical guide.
Starting with version 9.2 and continuing to evolve, Elastic Agent can natively collect telemetry using OpenTelemetry (OTel) based configurations. This gives existing Elastic users a gradual path to modernize their telemetry collection and ingestion, adopt OTel-compatible workflows and align with emerging industry standards.
Kubernetes, the de facto platform for modern cloud-native and AI workloads, has also become a preferred deployment platform for organizations running the Elastic Stack and Elastic Agent for telemetry collection and ingestion.
In this post, we’ll explore three different ways to deploy Elastic Agent using OTel configuration on Kubernetes, giving you the flexibility to choose the approach that best fits your environment.
Note: This space is continuously evolving and the approaches described in this post may change in future releases. Always refer to the official Elastic documentation for the latest guidance before proceeding.
Elastic Agent can be deployed on Kubernetes using three approaches:
- Native Kubernetes resources — using DaemonSet or Deployment objects
- Elastic Agent CRD — using the Elastic Agent custom resource provided by the ECK Operator
- OpenTelemetry CRD — using the OpenTelemetry Collector custom resource provided by the OpenTelemetry Operator
The infographic below provide a high level overview of these three deployment scenarios on Kubernetes.
1. Using Native Kubernetes Resources
This is the simplest and most straightforward approach to deploying Elastic Agent on Kubernetes. It is also the current deployment model, where the agent is deployed directly using native Kubernetes DaemonSet or Deployment resources.
With the OpenTelemetry Collector now embedded in Elastic Agent, this approach also provides a straightforward way for existing Elastic users to start leveraging OTel configuration without introducing a separate OpenTelemetry Collector deployment.
This approach is well suited for:
- Existing users running Elastic agent on Kubernetes, who need to collect telemetry from their Kubernetes environments using OTel configurations.
- New users who want a simple and flexible way to deploy Elastic Agent on Kubernetes.
2. Using the Elastic Agent CRD
This approach is best suited for customers already running Elastic on Kubernetes using the Elastic Cloud on Kubernetes (ECK) Operator.
ECK provides an Elastic Agent CRD, allowing users to deploy and manage Elastic Agent using Kubernetes-native custom resources. With the OpenTelemetry Collector embedded in Elastic Agent, existing ECK users can also leverage OTel configuration within their existing ECK-based deployment model.
Get Anand Vyas’s stories in your inbox
Join Medium for free to get updates from this writer.
This approach is best suited for:
- Existing users already using ECK Operator to manage Elastic deployments on Kubernetes.
- New users who want to leverage Elastic’s supported Kubernetes operator pattern to manage elastic resources.
Note: ECK requires an appropriate Elastic subscription.
3. Using the OpenTelemetry Collector CRD
This approach is particularly suitable for users who already have OpenTelemetry deployed in their Kubernetes environments, either using the upstream OpenTelemetry Collector or a custom-built Collector distribution.
The OpenTelemetry Operator provides the OpenTelemetryCollector CRD, which can be used to deploy and manage the Collector on Kubernetes. By using the Elastic-provided image, users can retain the Kubernetes-native OpenTelemetry deployment model while leveraging Elastic’s supported OpenTelemetry Collector distribution and configuration.
This approach is well suited for:
- Existing users already using the OpenTelemetry Operator and Collector in their Kubernetes environments and want to leverage Elastic’s supported OpenTelemetry Collector distribution.
- New users beginning their OpenTelemetry journey and want to adopt OTel using a Kubernetes-native approach supported by Elastic.
With 300+ native integrations, Elastic makes it easy to onboard data in just a few steps and start generating value from the ingested data almost immediately.
Similar experience for OpenTelemetry (OTel) configuration will be available, as Elastic continues to invest in OTel-native integrations and inputs. The goal is to provide a seamless path for users to adopt OTel while simplifying the transition from ECS-based telemetry to OTel-compatible schema.
As of today, there are two type of integration packages available for OTel.
Conclusion
The growing support for OpenTelemetry configuration in Elastic Agent gives users more flexibility to adopt OTel without having to completely rethink their existing observability architecture. Whether you are starting your OTel journey, already running ECK or have an established OpenTelemetry environment, you can choose the deployment model that best fits your environment and operational model.
As Elastic continues to expand its OTel-native integrations and capabilities, these options will continue to evolve — making it easier to bring OpenTelemetry and Elastic together.
Disclaimer:
The views expressed and the content shared in this blog are solely those of the author and do not reflect the views or positions of the author’s employer. All information is based on personal experience and is shared for informational purposes only. While every effort has been made to ensure accuracy, there is no guarantee of completeness or correctness. Readers are advised to verify and use the content at their own discretion. All trademarks mentioned are the property of their respective owners.
