Set up Cost Allocation for Kubernetes deployments

• Latest Dynatrace
• How-to guide
• 5-min read
• Updated on Nov 27, 2025

You can use Cost Allocation to allocate your Dynatrace DPS usage on Kubernetes deployments to the cost centers and products that you define. Allocating costs in this way provides a transparent and detailed account of the Dynatrace expenditures that originate from each cost center, which in turn helps your organization optimize its budgets.

When you base your Cost Allocation on Kubernetes namespaces, which is the recommended method, you can allocate the following data.

No matter your use case or tag strategy, you can easily implement Cost Allocation for Kubernetes.

On this page, you'll learn how to set up Cost Allocation in Kubernetes-based deployments.

Overview

We recommend setting up Cost Allocation along organizational lines and deployment scopes. Suitable concepts include Kubernetes clusters and Kubernetes namespaces. These attributes are typically available for all the telemetry data that you ingest.

Generally, to add Cost Allocation information to your Kubernetes data, you'll enrich your signals with the dt.cost.costcenter and dt.cost.product Grail attributes. You can enrich all telemetry data that originates from Kubernetes sources, whether logs, spans, metrics, or events. Dynatrace automatically propagates these dt.cost.* attributes from spans to the service entity and any resulting service metrics.

For more information, see Which data will be enriched.

Cost Allocation based on primary Grail fields with OpenPipeline

If you only need to allocate costs at the deployment level of granularity (clusters or namespaces), we recommend to set up Cost Allocation in OpenPipeline. This allows you to set up Cost Allocation with existing organizational lines or deployment scopes.

Cost Allocation based on labels or annotations

Suppose that setting Cost Allocation based on the Kubernetes cluster or namespace is not sufficient. This could be because you have already defined your own cost centers and products outside of Dynatrace and defined them, for example, as Kubernetes labels or annotations. In that case, Dynatrace allows you to set up more fine-grained allocation: you can leverage your own Kubernetes namespace labels or annotations as the source for your Cost Allocation metadata in Dynatrace.

The metadata you create can represent your own security architecture, and can even be hierarchical by encoding it into a string such as department-A/department-AB/team-C.

To allocate costs in line with your existing strategy for Kubernetes tags, there are different ways that you can map your labels or annotations to dt.cost.costcenter and dt.cost.product. You can either use metadata enrichment, DynaKube custom resources, or dedicated pod annotations, depending on your needs and deployment setup.

Cost Allocation based on existing namespace labels or annotations

Recommended

Using existing namespace labels or annotations is helpful for:

This method allows you to use existing namespace labels and annotations as sources for your Cost Allocation metadata.

To set up metadata enrichment, select an existing label and set the Target to dt.cost.costcenter or dt.cost.product as appropriate. That label will then be added as dt.cost.costcenter or dt.cost.product in your telemetry.

Cost Allocation based on DynaKube custom resources

DynaKube custom resources are helpful when you have Kubernetes Platform Monitoring with Full-Stack Observability. You can allocate the cost of memory consumption for the whole node (billed as GiB-hours).

To set up Cost Allocation with DynaKube custom resources, pass the configuration via the args parameter in the DynaKube parameters for Dynatrace Operator, as shown in the example below.

spec:
  apiUrl: https://<environment-id>.live.dynatrace.com/api
  oneAgent:
    cloudNativeFullStack:
      args:
        - --set-host-tag=dt.cost.costcenter=it_services
        - --set-host-tag=dt.cost.product=fin_app

Cost Allocation based on dedicated pod annotations

Dedicated pod annotations are useful for:

The code block below shows how to use dedicated pod annotations to map Kubernetes tags to Cost Allocation attributes.

metadata:
  annotations:
    metadata.dynatrace.com/dt.cost.costcenter: it_services
    metadata.dynatrace.com/dt.cost.product: fin_app

Derive cost centers and products based on multiple labels, annotations, and other metadata

If you have a more sophisticated strategy for cost center tags, it might not be enough to map Kubernetes labels/tags directly to dt.cost.costcenter or dt.cost.product.

In this case, we recommend that you use metadata enrichment to enrich all telemetry data with the Kubernetes labels or annotations that you need to define a cost center or product. Then, use OpenPipeline to derive cost centers or products based on those labels or annotations. Adding new attributes is described in OpenPipeline processing examples.