Migrate from classic full-stack to cloud-native full-stack mode

Latest Dynatrace
4-min read

Dynatrace Operator version 1.11+

This guide describes the steps required to migrate your Dynatrace deployment from classic full-stack to the cloud-native full-stack mode.

Advantages

The cloud-native full-stack deployment mode represents a major advancement in security, utilizing cloud native methods for OneAgent injection. This approach addresses two key limitations found in the traditional full stack mode:

The cloud-native full-stack mode prevents race conditions that can occur when OneAgent DaemonSet pods and monitored application pods start simultaneously.
By leveraging Kubernetes concepts such as admission webhooks and image volumes for code modules injection, cloud-native full-stack monitoring reduces the required privileges for OneAgent. Image volumes also remove the need for the CSI driver.

Considerations and implications

When switching to cloud-native full-stack monitoring, previously deployed OneAgents will get deactivated and deep monitoring of applications will stop. Consequently, the restart of all application pods requiring deep monitoring becomes mandatory. Restarting these pods will ensure that applications are reinjected, allowing deep monitoring to resume.
In cloud-native full-stack mode, Host IDs are determined differently, leading to the temporary presence of both new and old hosts in the host list screens. Old host entities and their associated data follow the data retention policy defined by Dynatrace, remaining accessible for the specified duration.
In cloud-native full-stack mode, container monitoring rules are ignored. Instead, label selectors should be employed to precisely manage OneAgent injection.
Automatic injection of statically linked Go applications that run as the container entrypoint isn't supported. To monitor them, start the application through a shell or init process. See Go known limitations.

Migrate to cloud-native full-stack

This section provides all the information needed to migrate from classic to cloud-native full-stack mode.

Using CRI-O container runtime

The standard migration procedure described below requires OneAgent version 1.281 or higher for Kubernetes clusters using CRI-O as their container runtime, so you need to upgrade OneAgents accordingly before continuing with the steps below.

If that upgrade cannot be performed, follow the Running CRI-O with OneAgent versions 1.279 or earlier procedure for an alternative migration flow, and then return to step 1 of this procedure.

Verify the image volume prerequisites:

This guide uses image volumes, the recommended delivery mode, to deliver code modules, so the CSI driver is not needed. Make sure your environment meets the image volume prerequisites.

Reconfigure (existing) DynaKube for cloud-native full-stack mode:

The following side-by-side comparison outlines how to reconfigure a DynaKube CR from classic full-stack to cloud-native full-stack monitoring:

apiVersion: dynatrace.com/v1beta6
kind: DynaKube
metadata:
  name: dynakube
  namespace: dynatrace
spec:
  apiUrl: https://<environment-id>.live.dynatrace.com/api
  networkZone: <network-zone>
  oneAgent:
    hostGroup: <host-group>
    classicFullStack: {}
  activeGate:
      capabilities:
        - routing
        - kubernetes-monitoring
        - dynatrace-api

The feature.dynatrace.com/mount-code-modules-via-image-volume annotation enables image volume injection.

For further information on how to configure DynaKube for cloud-native full-stack mode, see the comparison below, visit the deployment guide or DynaKube parameters. Alternatively, download the DynaKube custom resource sample for cloud-native full-stack from GitHub and adapt the DynaKube custom resource according to your requirements.

Apply the DynaKube custom resource:

Run the command below to apply the DynaKube custom resource. A validation webhook will provide helpful error messages if there's a problem.
```
kubectl apply -f dynakube.yaml
```
This action will lead to the removal of OneAgents in classic full-stack mode and subsequently result in the termination of deep monitoring for application pods shortly thereafter.
Wait for OneAgents to become ready:

The Dynatrace Operator will pick up the changes in the DynaKube custom resource and ensure new OneAgents are available on each node.
Restart application workloads:

Restart all application workloads promptly to trigger OneAgent injection and enable deep monitoring preventing/minimizing monitoring outages.

To confirm that pods are injected with image volumes, see Verify injection.
Disable the CSI driver (optional):

This step is optional and applies only if the CSI driver is installed in your cluster. Image volume injection doesn't use the CSI driver, so you can disable it to remove the CSI DaemonSet and all related resources.

Make sure no other DynaKube or workload in the cluster still relies on CSI volumes. Pods that use CSI mounts will fail after the CSI driver is disabled. To check, see Verify no pods with CSI volumes remain.
```
helm upgrade dynatrace-operator oci://public.ecr.aws/dynatrace/dynatrace-operator \
  --namespace dynatrace \
  --reset-then-reuse-values \
  --set csidriver.enabled=false \
  --atomic
```

Running CRI-O with OneAgent versions 1.279 or earlier

This section outlines the migration procedure for Kubernetes clusters utilizing a CRI-O container runtime and running OneAgent version 279 or earlier.

It is necessary to remove CRI-O hooks installed and utilized for OneAgent injection in classic full-stack mode. For additional details on CRI-O hooks, refer to this Red Hat blog post.

Show step-by-step instructions

Follow these instructions to successfully migrate from classic full-stack mode:

Delete DynaKube custom resource:

Delete the DynaKube configured in classic full-stack mode by running the following command:
```
kubectl delete dynakube -n dynatrace <dynakube-name>
```
This action will lead to the removal of OneAgents in classic full-stack mode and subsequently result in the termination of deep monitoring for application pods shortly thereafter. Additionally, if Kubernetes monitoring is configured in the DynaKube custom resource, Kubernetes monitoring will stop instantly with the removal of the ActiveGate.
Wait for the OneAgent pods to terminate.
Follow the instructions in the Cleanup nodes section to remove Dynatrace CRI-O hooks from all Linux nodes.
Continue with step 1 of the standard migration procedure.

Changes in Kubernetes resources

This migration impacts several Kubernetes resources, altering their functions or introducing new components to support cloud-native injection mode. Key changes include:

Component	classic full-stack	cloud-native full-stack
OneAgent	Deployed as a DaemonSet Collect host metrics on nodes Inject code modules into application pods	Deployed as a DaemonSet Collect host metrics on nodes
Dynatrace Webhook Server	Validates DynaKube definitions	Validates DynaKube definitions Inject code modules into application pods by modifying pod definitions
Code modules delivery	Injected by the OneAgent DaemonSet	Image volumes mounted by the container runtime One shared copy of the code modules image per node, no CSI driver required