topic Re: Split K8S services by version in Container platforms

Split K8S services by version

Yosi_Neuman — Mon, 03 Jun 2024 14:21:22 GMT

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

Re: Split K8S services by version

cesarsaravia — Mon, 03 Jun 2024 15:37:59 GMT

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.

Re: Split K8S services by version

Yosi_Neuman — Tue, 04 Jun 2024 08:20:25 GMT

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

Re: Split K8S services by version

Julius_Loman — Tue, 04 Jun 2024 09:25:22 GMT

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.

Re: Split K8S services by version

PacoPorro — Tue, 04 Jun 2024 09:53:46 GMT

This is how I would approach to this too.

Re: Split K8S services by version

Yosi_Neuman — Tue, 04 Jun 2024 12:44:27 GMT

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

Re: Split K8S services by version

Julius_Loman — Tue, 04 Jun 2024 14:01:24 GMT

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.