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

groundcover resolves the Service and Team fields from the following Deployment labels:

Enriched field	First priority	Fallback priority
Service	groundcover-service	tags.datadoghq.com/service
Team	groundcover-team	tags.datadoghq.com/team

groundcover-native labels always take priority over Datadog-compatible labels.

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.

---

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