Split K8S services by version

[Yosi_Neuman]

Hi guys,

Customer developers running few version of the same application on K8S cluster.

Dynatrace merge together all the pods from different version into unified service and we are asked to split the process by versions.

Each version running on its separated workload name which look like name-version#-subversion#

Kubernetes full pod name for each process also look like  name-version#-subversion#-podid

But Kubernetes group detection rule result shows as name-*-*-* and eventually collect all the process of different version together.

We have tried to set  Cloud application and workload detection to ignore Base pod name with no success 😞

Any suggestion on how to sperate the processes ?

@yair_mashmor & Yos 

[cesarsaravia]

Hi @Yosi_Neuman 
You should create an Advanced detection rule for the Process Groups based on k8s. Be sure to do not ignore the numbers because those are the versions are you expecting to split.

Example:

Note: After creating this rule, you need to restart/killing the pods and wait to recreate new ones and the new PG rules applies.

Regards,
Cesar S.

[Yosi_Neuman]

Hi @cesarsaravia 

That was our first approach, because it failed to split the processes we tried the Cloud application and workload detection.

Will give it another try and will update 

Thanks 

Yos & @yair_mashmor 

[Julius_Loman]

Hey @Yosi_Neuman ,

first of all - what deployment model in Kubernetes are you using? The answer pretty much depends on that. If you use cloudNativeFullStack or applicationOnly, you can use the build label propagation feature. It will set DT_RELEASE* environment variables based on the metadata of the workload. 

If you use classicFullStack, this does not have any effect, but you can set the variables also manually in the application deployment (one of our customers preferred this way and stayed with classicFullStack for now).  Don't forget to set a rule in the cloud application and workload detection, for example:

If all this fails, you can use also old school methods of defining your own variable (maybe customer is using that!) and create a classic process group detection rule using this variable. But anyway, you should do that in a way which scales globally in your environment.

[PacoPorro]

This is how I would approach to this too.

[Yosi_Neuman]

Hi @Julius_Loman 

Its classicFullStack and we tried the cloud application and workload detection with no success 😞

Will try the old school way 😐

Thanks @yair_mashmor & Yos 

[Julius_Loman]

Yes, old school way will work. However, it might be possible for you to automate this at the deployment level - but it depends on how the customer is deploying apps. If they have automation and basic templates, it's possible to do it there and maybe setup the DT_RELEASE* variables. 

Be sure to investigate this option too.