Kubernetes recommended deployment option

[Pierre_L]

Hello all,

A quick question about K8S deployment option.
I actually use the Dyna Operator in classic full stack mode which is the recommended deployment option.
I recently parse the documentation and notice this specific note :

Please note: The recommended deployment option for full Kubernetes Observability will be switched from classic full stack to cloud native full stack within one of the next Dynatrace Operator releases.

Did someone know what are the reasons of this change ?
When reading the current limitations of the 2 deployment options, for my point of view the Cloud native full stack has still more limitations than the classic full stack option.

Thank you.

[Romanenkov_Al3x · Accepted solution]

Hello.

Quick answer at "recommended deployment option" - it depends.

Different methods are usable for different tasks. If you have small k8s on-prem cluster with 10 nodes and 10 namespaces - maybe it's better to choose classicFullStack. 

I don't know cause " The recommended deployment option for full Kubernetes Observability will be switched from classic full stack to cloud native full stack" but from my experience:

You have only 100 monitoring rules ottb. This value can be increased by Dynatrace support, but it will add additional operational  overhead, if you have 150 namespaces in you k8s. You need to create 151 rules (1 last rule - if namespace exist don't inject)

Also monitoring administator responsible for instrumentation and possible consequences.

With CloudNativeFullStack we can easly control instrumentation from yaml manifests. 

With DT_CLUSTER_ID, DT_RELEASE_STAGE and other special environment variables (usually also defined in deployment yamls to control tags, and process groups)

Teams/Ops\DevOps control manifests in this case and control instrumentation.  Also in this case - you completely eliminate human error if the container monitoring rules are not configured correctly.

Regards,

Alex Romanenkov

[radek_jasinski]

Hi,

CloudNativeFullStack, despite some limitations, seems to offer more flexible management and configuration via yaml manifest files. This reduces the risk of human error that can occur when manually configuring monitoring rules. In addition, the ability to control instrumentation via environment variables offers greater granularity and flexibility in customizing monitoring. It happened to me that on newer versions of the K8S the classical method generated all sorts of problems (such as problems with the correct instrumentation of the application).

Radek