Skip to content

Latest commit

 

History

History
91 lines (67 loc) · 5.25 KB

README.md

File metadata and controls

91 lines (67 loc) · 5.25 KB
Raw

Datadog Operator

badge Go Report Card codecov

Overview

Warning

Operator v1.7.0 removes support for DatadogAgent v1alpha1 reconciliation (v2APIEnabled flag). v1.8.0 will remove the conversion webhook as well, and users will not be able to apply the DatadogAgent v1alpha1 manifest.

Operator v1.8.0 will deprecate custom resource definitions using apiextensions.k8s.io/v1beta1. They will be kept in the repository but will not be updated. They will be removed in v1.10.0.

The Datadog Operator aims to provide a new way of deploying the Datadog Agent on Kubernetes. Once deployed, the Datadog Operator provides:

  • Agent configuration validation that limits configuration mistakes.
  • Orchestration of creating/updating Datadog Agent resources.
  • Reporting of Agent configuration status in its Kubernetes CRD resource.
  • Optionally, use of an advanced DaemonSet deployment by leveraging the ExtendedDaemonSet.
  • Many other features to come :).

The Datadog Operator is RedHat certified and available on operatorhub.io.

Datadog Operator vs. Helm chart

You can also use official Datadog Helm chart or a DaemonSet to install the Datadog Agent on Kubernetes. However, using the Datadog Operator offers the following advantages:

  • The Operator has built-in defaults based on Datadog best practices.
  • Operator configuration is more flexible for future enhancements.
  • As a Kubernetes Operator, the Datadog Operator is treated as a first-class resource by the Kubernetes API.
  • Unlike the Helm chart, the Operator is included in the Kubernetes reconciliation loop.

Datadog fully supports using a DaemonSet to deploy the Agent, but manual DaemonSet configuration leaves significant room for error. Therefore, using a DaemonSet is not highly recommended.

Getting started

See the Getting Started dedicated documentation to learn how to deploy the Datadog operator and your first Agent, and Configuration to see examples, a list of all configuration keys, and default values.

Migrating from 0.8.x to 1.0.0

Operator 1.0.0 contains several changes users need to be aware of:

  • DatadogAgent CRD has two versions, v1alpha1 and v2alpha1. They are used as a stored version by Operator 0.8.x and 1.0.0 respectively. See this Kubernetes documentation page for more details about CRD versioning.
  • v1alpha1 and v2alpha1 are not backward or forward compatible. The Datadog Operator 1.0.0 implements a Conversion Webhook to migrate, though it only supports migrating from v1alpha1 to v2alpha1.
  • With the Conversion Webhook enabled, users can run 1.0.0 but continue applying a v1alpha1 manifest. However, they won't be able to retrieve the DatadogAgent manifest as a v1alpha1 object (see the previous item).
  • The Conversion Webhook requires a cert manager. See the migration guide in the public or helm chart documentation for more details.
  • 0.8.x managed PodDisruptionBudget for Cluster Agent and Cluster Checks Worker deployments. 1.0.0 doesn't, however this is on our roadmap.

Default Enabled Features

  • Cluster Agent
  • Admission Controller
  • Cluster Checks
  • Kubernetes Event Collection
  • Kubernetes State Core Check
  • Live Container Collection
  • Orchestrator Explorer
  • UnixDomainSocket transport for DogStatsD (and APM if enabled)
  • Process Discovery

Functionalities

The Datadog operator also allows you to:

How to contribute

See the How to Contribute page.

Release

Release process documentation is available here.