OneAgent container delays

[Sagar_CE]

We are experiencing significant delays during Dynatrace OneAgent initialization across our Kubernetes clusters. The main issue is that every time a pod starts, it downloads the OneAgent and a special package from our Dynatrace API URL which we have. Reviewing the logs, we consistently observe this special package being downloaded from URL which we have, which seems to be the primary cause of the delay. (Screenshot attached for reference.)
Is there a way to optimize OneAgent initialization so it uses a local or cached version of the agent and package, instead of downloading them each time?
Any best practices or recommendations to help reduce this startup delay would be greatly appreciated.

[Julius_Loman]

What is your deployment mode for Dynatrace Operator and do you use CSI driver in your setup (applicationOnly and cloudNativeFullStack)? Without a CSI driver, OneAgent gets downloaded for each deep-monitored pod.  

[Sagar_CE]

Our deployment mode is Kubernetes platform monitoring and Application observability without the CSI driver because it requires hostpath access, which is not possible in GDCE clusters. Without the CSI driver, our solution works, but the special package is downloaded every time a pod restarts. Is there a way to cache this package for reuse when the pod restarts?

[Julius_Loman]

CSI driver does the caching. Also be sure to check https://docs.dynatrace.com/docs/shortlink/installation-k8s-supported-distros for details.

If you are unable to use CSI, then I think you have just two options left - at least I can think of:

• store the Dynatrace images in a repository local to your clusters
• include the OneAgent layer in your images

[Sagar_CE]

Hi Team,

I am following up above issue. Do we have any updates on this.