Set up Dynatrace on Kubernetes

Kubernetes (K8s) is a simple, flexible, and efficient solution for container orchestration that deploys, manages, scales, and automates applications.

Supported Kubernetes flavors

Dynatrace supports a variety of Kubernetes flavors. Supported distributions are managed and operated by customers. Hosted versions are managed by cloud providers.

Distributions

  • Google Anthos
  • Docker Enterprise
  • Rancher 2.0
  • Red Hat OpenShift Container Platform
  • OpenShift Dedicated
  • VMware Tanzu Kubernetes Grid Integrated Edition (formerly Pivotal Kubernetes Service)

Hosted versions

  • Amazon Elastic Kubernetes Service
  • Azure Kubernetes Service
  • Google Kubernetes Engine
  • IBM Kubernetes Service
  • SUSE Container as a Service platform

Components

Kubernetes observability relies on components with different purposes, default configurations, and permissions.

Dynatrace Operator

Purpose: Maintains the lifecycle of Dynatrace components. Replaces OneAgent Operator.

Default configuration: 1-replica-per-cluster

Cluster-wide permissions: The following table shows the permissions needed for Dynatrace Operator.

Resources accessed APIs used Resource names
Nodes Get/List/Watch -
Namespaces Get/List/Watch -
Secrets Create -
Secrets Get/Update/Delete dynatrace-dynakube-config
MutatingWebhookConfigurations List/Create/Watch -
MutatingWebhookConfigurations Get/Update dynatrace-webhook
ValidatingWebhookConfigurations List/Create/Watch -
ValidatingWebhookConfigurations Get/Update dynatrace-webhook
Events Create/Patch -
CustomResourceDefinitions List/Watch -
CustomResourceDefinitions Get/Update dynakubes.dynatrace.com

OneAgent

Purposes:

  • Collects host metrics from Kubernetes nodes.
  • Detects new containers and injects OneAgent code modules into application pods using classic full-stack injection. optional

Default configuration: 1-replica-per-node (deployed via a DaemonSet)

Policy settings: Allow HostNetwork, HostPID, to use any volume types.

PodSecurityPolicies

These permissions used to be managed using a PodSecurityPolicy (PSP), but in Kubernetes version 1.25 PSPs will be removed from the following components:

Dynatrace Operator version 0.2.1 is the last version in which PSPs are applied by default, so it's up to you to enforce these rules. As PSP alternatives, you can use other policy enforcement tools such as:

Note: If you choose to use a PSP alternative, be sure to provide the necessary permissions to the Dynatrace components.

Necessary capabilities: CHOWN, DAC_OVERRIDE, DAC_READ_SEARCH, FOWNER, FSETID, KILL, NET_ADMIN, NET_RAW, SETFCAP, SETGID, SETUID, SYS_ADMIN, SYS_CHROOT, SYS_PTRACE, SYS_RESOURCE

Dynatrace CSI driver

Purpose: Provides the necessary OneAgent binary for application monitoring to the pods on each node.

Default configuration: 1-replica-per-node (deployed via a DaemonSet)

Cluster-wide permissions: The following table shows the permissions needed for Dynatrace CSI driver.

Resources accessed APIs used Resource names
Namespaces Get/List/Watch -
Events List/Watch/Create/Update/Patch -
Nodes Get/List/Watch -
CsiNodes Get/List/Watch -
Pods Get/List/Watch -

Dynatrace webhook server

Purposes:

  • Modifies pod definitions to include Dynatrace code modules for application observability
  • Validates DynaKube custom resources
  • Handles the DynaKube conversion between versions

Default configuration: 1-replica-per-cluster, can be scaled

Cluster-wide permissions: The following table shows the permissions needed for the Dynatrace webhook server.

Resources accessed APIs used Resource names
Namespaces Get/List/Watch -
Events Create/Patch -

Dynatrace Kubernetes Monitoring (ActiveGate)

Purpose: collects cluster and workload metrics, events, and status from the Kubernetes API.

Default configuration: 1-replica-per-cluster, can be scaled

Cluster-wide permissions: The following table shows the permissions needed for Dynatrace Kubernetes Monitoring.

Resources accessed APIs used Resource names
Nodes Get/List/Watch -
Pods Get/List/Watch -
Namespaces Get/List/Watch -
Deployments Get/List/Watch -
ReplicaSets Get/List/Watch -
DeploymentConfigs Get/List/Watch -
ReplicationControllers Get/List/Watch -
Jobs Get/List/Watch -
CronJobs Get/List/Watch -
StatefulSets Get/List/Watch -
DaemonSets Get/List/Watch -
Events Get/List/Watch -
ResourceQuotas Get/List/Watch -
Pods/Proxy Get/List/Watch -
Nodes/Proxy Get/List/Watch -
Services Get/List/Watch -
ClusterVersions Get/List/Watch -
/metrics Get -
/version Get -
/readyz Get -
/healthz Get -

Dynatrace routing (ActiveGate)

Purpose: Routes information from all Dynatrace components on the Kubernetes cluster through one point.

Default configuration: 1-replica-per-cluster, can be scaled

Dynatrace data ingest (ActiveGate)

Purpose: Ingests user-specific data.

Default configuration: 1-replica-per-cluster, can be scaled

Integrations

There are different ways to activate Dynatrace on Kubernetes. Each way has its own advantages. We recommend these deployment strategies in terms of feature completeness and lack of constraints.

Starting with Dynatrace Cluster version 1.215, you can deploy full-stack OneAgents and containerized ActiveGates using Dynatrace Operator. For migration instructions, see Migrate to Dynatrace Operator.

1. Classic full-stack injection

For the installation guide, see Classic full-stack injection.

Dynatrace Operator manages the classic full-stack injection after deploying the following custom resources.

  • OneAgent, deployed as a DaemonSet, collects host metrics from Kubernetes nodes. It also detects new containers and injects OneAgent code modules into application pods.
  • Dynatrace Kubernetes monitor collects cluster and workload metrics, events, and status from the Kubernetes API.

classicFullStack Illustration

Note: Classic full-stack injection requires write access from the OneAgent pod to the Kubernetes node in order to detect and inject into newly deployed containers.

2. Application-only injection

You can use the application-only injection strategy for application pods. You don't install OneAgent pods and can't collect host metrics from Kubernetes nodes. You can collect alternative node metrics from other sources such as Prometheus or StatsD.

Note: This deployment strategy requires extra ephemeral storage:

  • ~325 MB for glibc
  • ~290 MB for musl
  • ~650 MB for glibc and musl combined

There are three types of application-only injection.

2.1. Automatic application-only injection

The application-only injection strategy uses OneAgent Operator. Support for using Dynatrace Operator to handle application-only injection is in development.

For the installation guide, see Automatic application-only injection.

Dynatrace Operator manages the automatic application-only injection after deploying the following custom resources.

  • Dynatrace Kubernetes monitor collects cluster and workload metrics, events, and status from the Kubernetes API.
  • Dynatrace webhook server modifies pod definitions to include Dynatrace code modules for application observability.

automaticAppOnly Illustration

2.2. Pod runtime injection

For the installation guide, see Pod runtime injection.

podRuntime Illustration

2.3. Container build-time injection

For the installation guide, see Container build-time injection.

buildTimeInjection illustration

3. Classic manual full-stack injection

You can use the classic manual full-stack injection strategy for manual deployment of OneAgent DaemonSet and Kubernetes API without Dynatrace Operator.

Deprecated

Deploy OneAgent Operator on Kubernetes.

Configuration

Activate ActiveGate on Kubernetes using Dynatrace Operator

Deploy ActiveGate in Kubernetes as a StatefulSet

Deploy ActiveGate in a VM for Kubernetes monitoring

Migrate Dynatrace Operator to a new Dynatrace environment - Kubernetes

Store Dynatrace images in private registries in Kubernetes

Configure Istio for OneAgent traffic in Kubernetes

Instrument ingress-nginx for Kubernetes

Troubleshooting

Troubleshoot deployment and connectivity errors on Kubernetes

See also

Kubernetes monitoring