DEV Community

Cover image for Dynatrace Operator Kubernetes/OpenShift: connecting to a Managed cluster
Span Observer
Span Observer

Posted on Originally published at span.observer

Dynatrace Operator Kubernetes/OpenShift: connecting to a Managed cluster

#activegate #cloudnative #containers #dynakube

Kubernetes and OpenShift clusters have made installing agents « by hand » on each host obsolete. Nodes come and go with autoscaling, pods move around, and platform teams want everything to be declarative, versioned and reconciled automatically. For observability, this means the lifecycle of OneAgent and ActiveGate must be driven by Kubernetes too. This is the job of Dynatrace Operator: Kubernetes/OpenShift then deploys and updates the agents itself.

That is the role of Dynatrace Operator and its custom resource DynaKube. But most available examples assume a SaaS environment reachable over the internet. In a Dynatrace Managed context, the questions are different: the API URL points to your own domain, the cluster certificate is often issued by an internal PKI, public image registries are not always reachable, and network flows between the Kubernetes cluster and the Managed cluster cross firewalls that you administer.

This article explains how to connect Dynatrace Operator to a Managed environment, on standard Kubernetes as well as OpenShift, with a DynaKube configuration suited to these constraints.

Dynatrace Operator Kubernetes/OpenShift architecture: what it deploys

  • The Operator itself, which watches DynaKube resources and reconciles the desired state.
  • The webhook, which injects code modules into application pods (cloud-native mode) and validates DynaKube resources.
  • The CSI driver (depending on the mode), which caches OneAgent binaries on each node to avoid repeated downloads.
  • OneAgent as a DaemonSet, one pod per node, for host visibility and injection.
  • An ActiveGate as a StatefulSet, which monitors the Kubernetes API and can route agent traffic to the Managed cluster.

All these components talk to the environment API, exposed in Managed at https://{your-domain}/e/{environment-id}/api.

Choosing the deployment mode

DynaKube mode Principle When to use it
cloudNativeFullStack Host OneAgent + injection into pods via the webhook Recommended default for most clusters
applicationMonitoring Injection into pods only, no host agent Platforms where privileged DaemonSets are forbidden
hostMonitoring Host agent without application injection Infrastructure monitoring of nodes
classicFullStack Legacy approach, injection at host level Compatibility with older deployments

The available modes and their behaviour change with Operator and DynaKube API versions: check the compatibility matrix between your Managed version and the Operator version before choosing.

Prerequisites on the Managed side

  • A dedicated or shared environment, and its ID visible in the URL /e/{environment-id}.
  • An Operator token (API token) created from the Kubernetes: Dynatrace Operator template: InstallerDownload, DataExport, settings.read, settings.write and activeGateTokenManagement.create (entities.read is no longer required since Operator 1.7.0).
  • A data ingest token (Kubernetes: Data Ingest template: metrics.ingest, logs.ingest, openTelemetryTrace.ingest).
  • An HTTPS flow open from the Kubernetes nodes to the Managed nodes or to an ActiveGate.
  • Your PKI’s root authority certificate in PEM format (see SSL certificates and the cluster domain) if the Managed cluster does not use a public certificate.
  • A Managed cluster version recent enough for the target Operator version.

Step-by-step tutorial

Step 1 — Validate API access from the cluster

Start an ephemeral pod to test the network path from inside the cluster:

kubectl run nettest --rm -it --restart=Never --image=curlimages/curl -- \
  curl -sS -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Api-Token {token}" \
  https://{your-domain}/e/{environment-id}/api/v1/time
Enter fullscreen mode Exit fullscreen mode

The Operator token includes the DataExport scope this call requires: a 200 code confirms the network and the token. A certificate error means you will need to give your root authority to DynaKube (step 4).

Step 2 — Install the Operator

Create the namespace, then install the Operator with the official Helm chart or the manifests published for your version:

kubectl create namespace dynatrace

helm install dynatrace-operator oci://public.ecr.aws/dynatrace/dynatrace-operator \
  --namespace dynatrace --version {operator-version} --atomic

kubectl -n dynatrace get pods
Enter fullscreen mode Exit fullscreen mode

On OpenShift, the same Helm command applies: the platform is detected automatically during installation (OperatorHub remains an alternative). Security Context Constraints are required for cloudNativeFullStack and applicationMonitoring with the CSI driver. In a disconnected environment, mirror the images to your internal registry first and override the image references in the Helm values.

Step 3 — Create the token secret 

kubectl -n dynatrace create secret generic {dynakube-name} \
  --from-literal="apiToken={operator-token}" \
  --from-literal="dataIngestToken={ingest-token}"
Enter fullscreen mode Exit fullscreen mode

The secret must have the same name as the DynaKube resource, unless you reference it explicitly in the spec.

Step 4 — Provide your PKI certificate 

kubectl -n dynatrace create configmap dynatrace-trusted-ca \
  --from-file=certs=/path/to/internal-ca.pem
Enter fullscreen mode Exit fullscreen mode

The certs key is the one the Operator expects. This ConfigMap will be referenced in the trustedCAs field.

Step 5 — Declare the DynaKube resource 

apiVersion: dynatrace.com/{dynakube-api-version}
kind: DynaKube
metadata:
  name: {dynakube-name}
  namespace: dynatrace
spec:
  apiUrl: https://{your-domain}/e/{environment-id}/api
  trustedCAs: dynatrace-trusted-ca
  networkZone: {network-zone}
  oneAgent:
    hostGroup: {k8s-cluster}_{environment}
    cloudNativeFullStack: {}
  activeGate:
    capabilities:
      - kubernetes-monitoring
      - routing
    resources:
      requests:
        cpu: 500m
        memory: 1Gi
      limits:
        cpu: 1000m
        memory: 2Gi
Enter fullscreen mode Exit fullscreen mode

The apiVersion value (for example v1beta2, v1beta3…) and some fields change between versions: hostGroup sits under spec.oneAgent, and recent Operators replace the kubernetes-monitoring capability with the spec.kubernetesMonitoring section (the two are mutually exclusive). Always start from the example shipped with the Operator version you installed. The ActiveGate resources are orders of magnitude to adjust to the size of the cluster.

kubectl apply -f dynakube.yaml
kubectl -n dynatrace get dynakube
kubectl -n dynatrace get pods -o wide
Enter fullscreen mode Exit fullscreen mode

Step 6 — Check the connection 

kubectl -n dynatrace describe dynakube {dynakube-name}
kubectl -n dynatrace logs deploy/dynatrace-operator --tail=100
Enter fullscreen mode Exit fullscreen mode

The resource must reach the Running phase. In the environment, the Kubernetes cluster appears in the Kubernetes view, and the nodes appear in the host list with the group you defined.

Step 7 — Check injection

Restart a test application, then check for the annotations or volumes added by the webhook:

kubectl -n {app-namespace} rollout restart deployment/{application}
kubectl -n {app-namespace} get pod -l app={application} -o yaml | grep -i dynatrace
Enter fullscreen mode Exit fullscreen mode

To limit injection to certain namespaces, use a namespaceSelector in the DynaKube rather than instrumenting the whole cluster from the start.

Best practices

  • Version the DynaKube and the Helm values in Git and apply them through your GitOps tool.
  • Align the Operator version with the compatibility matrix for your Managed version before every upgrade.
  • Use an internal registry for images in restricted environments, and test image pulls on a node.
  • Exclude system namespaces (kube-system, openshift-*) from injection.
  • Size the ActiveGate according to the number of Kubernetes objects monitored and watch its memory consumption.
  • Rotate tokens regularly by simply updating the secret.

Frequently asked questions

Which DynaKube mode should I choose with a Managed cluster?

cloudNativeFullStack is the default choice for most clusters. If privileged DaemonSets are forbidden, applicationMonitoring limits itself to injection into pods. In every case, check the compatibility matrix between your Managed version and the Operator version.

What should I do if the API test returns a certificate error?

It means the Managed cluster uses a certificate issued by an internal PKI. Create a ConfigMap holding the root authority in PEM format under the certs key, then reference it in the DynaKube trustedCAs field.

How do I avoid instrumenting the whole cluster at once?

Use a namespaceSelector in the DynaKube to limit injection to the namespaces you want, and exclude system namespaces such as kube-system and openshift-*.

Conclusion

Connecting Dynatrace Operator to a Managed cluster needs no special mechanism, but it does require you to deal explicitly with what SaaS hides: an API URL on your domain, internal certificates, private registries and network flows. With a declarative, versioned DynaKube adapted to your PKI, Kubernetes and OpenShift become first-class citizens of your on-premises observability platform.

span.observer is an independent community blog, not affiliated with Dynatrace LLC. Dynatrace is a trademark of Dynatrace LLC. Always check values (ports, versions, sizes) in the official documentation for your version of Managed.

Originally published on span.observer. French version: https://span.observer/fr/dynatrace-operator-kubernetes-managed/.

Top comments (0)