Compatibility of classicFullStack with the AWS EKS Auto Mode? OneAgent DaemonSets failing

[DanielS]

Hi everyone,

I'm currently validating the  AWS EKS Auto Mode in our staging environment (Kubernetes v1.29+) and running into blocking issues when trying to deploy the OneAgent via the Dynatrace Operator (v1.9.0, using the v1beta6 DynaKube).

I have extensive experience deploying the Dynatrace Operator across standard EKS clusters without any issues, but EKS Auto Mode seems to introduce a roadblock for the OneAgent.

The Situation:

• What works: The Dynatrace Operator deploys successfully. Platform Observability via ActiveGate works perfectly, and our cluster API visibility/AWS account is fully visible in the Dynatrace UI.

• The Problem: The OneAgent DaemonSets consistently fail to initialize, crash-loop, or fail to schedule onto the managed EKS Auto Mode nodes.

My Configuration & Troubleshooting:

• I am using the classicFullStack configuration parameter within the DynaKube Custom Resource.

• ActiveGate connects fine, but the OneAgent pods never reach a healthy Running state.

Since AWS EKS Auto Mode abstracts, automates, and restricts a lot of the underlying node infrastructure and control plane management, I suspect there might be specific permission constraints, taints, or runtime restrictions blocking the classic deployment pattern.

My Questions for the Community:

1. Is classicFullStack currently supported on AWS EKS Auto Mode, or does the node abstraction introduce an architectural compatibility gap?

2. Should I switch to the cloudNativeFullStack or applicationMonitoring approach for this specific managed infrastructure?

3. Has anyone successfully bypassed this, or is there a known workaround/upcoming support for EKS Auto Mode?

Any insights, official documentation links, or shared experiences would be highly appreciated, as this is currently blocking our production rollout strategy for EKS Auto Mode.

Thanks in advance!

[Julius_Loman]

@DanielS Are there any specific reasons why you use classic full-stack instead of cloud native full stack? Classic full stack requires elevated permissions, and it's not the recommended choice anymore.

[DanielS]

Hi @Julius_Loman no specific reason, until now it always worked.

[Julius_Loman]

I do highly recommend to switching it to cloudNativeFullStack. One of the key reasons for me would be telemetry enrichment, for example.

[DanielS]

I'll give it a try.

[DanielS]

Hi @Julius_Loman thanks for the suggestion. I will keep it in mind as the new default for my next deployments. I’ve finally managed to find the solution for this specific issue, but I really appreciate your help! Only you can use applicationMonitoring because cloudNativeFullStack is not supported on BottleRocket.  https://docs.dynatrace.com/docs/shortlink/injection-readonly-volume#prerequisites 

[DanielS · Accepted solution]

Well I've finally found the problem and the solution. I leave it documented here for others with the same issue.

 Amazon EKS Auto Mode uses Bottlerocket OS by default. When you enable EKS Auto Mode, AWS completely takes over the lifecycle of your worker nodes (using a fully managed implementation of Karpenter). To do this efficiently and securely, AWS provisions specialized Amazon Machine Images (AMIs) that are custom variants of Bottlerocket.

Why EKS Auto Mode relies on Bottlerocket

• No OS management or patching: Because Bottlerocket is an atomic, container-optimized OS with no traditional package manager, AWS can automatically update and roll over your worker nodes behind the scenes without you having to manually manage AMI upgrades.

• Hardened Security: Bottlerocket only contains the absolute bare minimum software needed to run containers. This vastly reduces the attack surface of your EKS worker nodes.

• Native Kubernetes Enhancements: The custom Bottlerocket AMIs used by EKS Auto Mode are tailored specifically for AWS infrastructure. For example, host containers (like standard SSH access) are disabled by default. Instead, AWS provides secure, native Kubernetes-level mechanisms to retrieve logs or troubleshoot nodes directly.

Can you change it?

No. One of the trade-offs of EKS Auto Mode's convenience is that you cannot specify a custom AMI ID or change the underlying operating system (such as switching to Amazon Linux 2/2023 or Ubuntu).

If your workloads strictly require a different host operating system, custom kernel modules, or specific OS-level packages, you will need to stick with EKS Hybrid Mode or Standard EKS using Managed Node Groups.

But Dynatrace only supports Bottlerocket using applicationMonitoring