Header background

Address Kubernetes-observability configuration chaos with unparalleled automation

The release of Dynatrace OneAgent Operator version 0.8.0 sets the standard for flexible and automated Kubernetes observability by removing the need to configure OneAgent and simplifying application-only configuration.

Kubernetes can be a confounding platform for system architects. Microservice design principles force people to think along a spectrum of loose coupling. Configuration headaches for Kubernetes observability are no different. We need a middle ground between the chaos of configuring individual applications and the inflexibility of centralized control.

Fortunately, at Dynatrace, we’ve solved this problem with the release of OneAgent Operator version 0.8.0. Our approach sets an unparalleled industry standard for flexible and automated observability for Kubernetes. We’re very excited, and you will be too.

OneAgent Operator v0.8.0:

  • Relieves application development teams from the burden of configuring OneAgent.
  • Simplifies application-only configuration by targeting pods and technologies using Kubernetes namespaces and annotations.
  • Introduces the Dynatrace long-term design pattern for full-stack observability, described below.

Automated rollout of application observability

Dynatrace supports full-stack monitoring for Kubernetes, from the application down to the infrastructure layer. However, if you don’t have access to the infrastructure layer, Dynatrace also provides the option of application-only monitoring. As of OneAgent Operator v0.8.0, we support a new automated approach to application-only observability.

If your organization currently deploys OneAgent using application-only injection, you can learn how to implement different deployment strategies in Dynatrace help, keeping these advantages in mind:

Application-only strategy Overview Advantages
Automated injection (new!) OneAgent Operator injects into pods as they start. Injection is centrally managed. Pods can be selected by using namespaces or pod-level annotations.
Pod runtime injection Pod uses an init container to download OneAgent. Can mount a volume to speed up injection for subsequent pods.
Container build-time injection Copies image layer into Docker image during build process. No dependency on specific k8s features like init containers or admission controllers.

Cloud-native injection with admission controllers

Our new automated injection relies on a feature called extensible admission, introduced two years ago in Kubernetes 1.9. Extensible admission lets us change the definition of a pod after the pod is authorized but before it’s scheduled to run. This is a common approach used by Kubernetes ninjas, but it’s unprecedented among other monitoring solutions on the market.

Under the hood, extensible admission uses a set of plugins called admission controllers, one of which fires a mutating webhook to a Dynatrace service. The mutating webhook, defined by the OneAgent Operator, tells our service that a pod is about to start, and asks if anything should be changed. If your custom resource-definition targets the pod’s namespace, OneAgent will be injected before it starts. If not, the pod will remain as is.

Admission controllers are used for all sorts of things in Kubernetes. The Dynatrace OneAgent Operator takes advantage of its configuration-management features. We can also use them for security governance and control, such as pulling images from authorized registries or rejecting deployments that don’t pass security checks.

Looking ahead

Further improvements will take advantage of our innovative injection approach. On top of automating application-only observability, we’ll increase the flexibility of Kubernetes node monitoring. This unprecedented level of flexibility, across applications and nodes, includes:

  • Central management via a single custom resource definition.
  • Pod selection via namespace/annotation.
  • Consistent admission controller-based injection for nodes and applications.

Cloud-native software design, much like microservices architecture, is founded on the premise of speed to delivery via phases, or iterations. This is why we deliver new Dynatrace functionality early, and often, learning quickly as we go. So rather than waiting for the complete full-stack solution to be released, we’ll provide you with application-only observability as soon as it’s available.

It’s easy to imagine a raised eyebrow as you look over the above bullet points for upcoming improvements. A few of these items are of tremendous interest and deserve more than a short sentence to whet your appetite. Of course, each valuable innovation will eventually have a blog post of its own, explaining how Dynatrace can further solve your Kubernetes-observability challenges.