Enrich workloads with service and team metadata

groundcover can enrich Kubernetes workloads with Service and Team metadata from labels on the Kubernetes Deployment object.

Once enriched, these fields can be displayed as optional columns on the Workloads page and used to search workloads by service or team ownership.

This is useful for teams that want to:

• understand which service a workload belongs to

• identify the team responsible for a workload

• search and organize workloads by ownership

• keep existing Datadog-compatible labels during migration to groundcover

The Service field is a logical service name used by groundcover. It does not require or modify a Kubernetes Service resource.

---

Supported labels

By default, groundcover resolves the Service and Team fields from the following Deployment labels, in priority order:

Enriched field	Priority order
Service	groundcover.com/service → groundcover-service → tags.datadoghq.com/service
Team	groundcover.com/team → groundcover-team → tags.datadoghq.com/team

Labels earlier in the list take priority over later ones.

For example, if both groundcover-service and tags.datadoghq.com/service exist on the same Deployment, groundcover uses the value from groundcover-service.

Each field is resolved independently. For example, a Deployment can use groundcover-service for Service and tags.datadoghq.com/team for Team if only the Datadog-compatible team label exists.

---

Customize team and service label mappings

The labels used for Service and Team enrichment are configurable through Helm values. Override global.labelEnrichment.identifiersMapping in your groundcover deployment values.yaml to use your own label keys, or to change the priority order.

The default configuration is:

global:
  labelEnrichment:
    identifiersMapping:
      team:
        - groundcover.com/team
        - groundcover-team
        - tags.datadoghq.com/team
      service:
        - groundcover.com/service
        - groundcover-service
        - tags.datadoghq.com/service

Each list is evaluated in order: the first matching label on the Deployment is used for that field.

For example, to also accept a custom owner label for Team, add it to the team list:

global:
  labelEnrichment:
    identifiersMapping:
      team:
        - groundcover.com/team
        - groundcover-team
        - tags.datadoghq.com/team
        - owner
      service:
        - groundcover.com/service
        - groundcover-service
        - tags.datadoghq.com/service

If you override global.labelEnrichment.identifiersMapping, replace the full mapping for the fields you configure. Include any default labels you still want resolved.

---

Add service and team labels to a Deployment

Add the labels to the Kubernetes Deployment object metadata.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout-api
  namespace: production
  labels:
    groundcover-service: checkout
    groundcover-team: payments
spec:
  replicas: 3
  selector:
    matchLabels:
      app: checkout-api
  template:
    metadata:
      labels:
        app: checkout-api
    spec:
      containers:
        - name: checkout-api
          image: example/checkout-api:latest