Split services based on Kubernetes Cluster they are running

[Theodore_x86]

Hello.

We have two identical AKS clusters with deployed the exact applications/services. As expected, Dynatrace wraps all the above apps to the same process group/service.

We want to distinguish the services based on the AKS they are running. However, on process detection rules there is no condition based on Kubernetes Cluster ID. My best guess is to assign AKS nodes to different host groups so that different process groups are created. I am not quite sure if this is even going to work, since AKS nodes are more of an abstract layer rather that common hosts.

Any better idea to tune this than the "host group" concept?

[Yosi_Neuman · Accepted solution]

Hi @Theodore_x86 

IMO You can use the Group filed in the k8s installation page 

Which will add the arg --set-host-group=first to the dynakub.yaml

And also a network zone will be crated under this name.

HTH

Yos 

[Theodore_x86]

Thanks Yosi. We are not using the direct "Deploy Dynatrace" page, since we go for the CloudNativeFullStack deployment. But it's basically the same thing, it just creates the yaml for you.

BR

Theodore

[PacoPorro]

Also, you can use the DT_RELEASE_STAGE and DT_RELEASE_PRODUCT env variables.

https://docs.dynatrace.com/docs/shortlink/workload-detection#workload-detection-rules-for-kubernetes

[DynaGibbo · Accepted solution]

We had the same issue when we moved to cloud native full stack and kubernetes cluster isn't a field you can distinguish services on.
Our solution was to inject the set-host-group value into the dynatrace CRD, specifically the cloud

eg.

apiVersion: dynatrace.com/v1beta1

kind: DynaKube

metadata:

  name: dynakube

  namespace: dynatrace

  annotations:

    feature.dynatrace.com/automatic-kubernetes-api-monitoring: "true"

    feature.dynatrace.com/enable-activegate-authtoken: "true"

    feature.dynatrace.com/max-csi-mount-attempts: "3"

spec:

  customPullSecret: dynakube-pull-secret

  apiUrl: https://{environmentid}.live.dynatrace.com/api

  oneAgent:

    cloudNativeFullStack:

      args:

        - "--set-host-group=###"

[Theodore_x86]

Yes exactly, that is what we did also eventually. Host group is the solution ultimately.

BR