Skip to main content
Hello and welcome back. Now that we understand FinOps and why adopting it inside a Kubernetes cluster matters, one point is obvious: Kubernetes gives you objects — Pods, PVCs, Services — not a cost breakdown by team. If those objects are not tagged consistently, you cannot reliably answer a simple question like “who owns this cost?” Before we begin hunting cost hotspots in the cluster, create a single, machine-consumable standard that defines what “good” tagging looks like. We’ll call that file tagging-rules.yaml. Below explains why YAML is the right choice for that policy file, and shows a practical example you can adopt. Why not spreadsheets, wiki pages, or JSON?
  • Spreadsheets and wiki pages can serve human readers well, but they are hard to consume programmatically in automation pipelines.
  • JSON is great for API responses and structured findings (we’ll use JSON later for FinOps results), but it’s a poor authoring format for a policy file that people will edit frequently: no native comments, strict syntax, and fragile to trailing commas or minor errors.
Example JSON output (good for automation/finding payloads):
YAML fits the policy role because it balances human readability and machine parsability:
  • native support for comments and inline notes,
  • familiar structure (lists, maps, nesting) for platform engineers and SREs,
  • the same declarative format as Kubernetes manifests, lowering cognitive overhead.
A dark-themed slide titled "Kubernetes Already Speaks YAML" with the Kubernetes logo centered. Below are four YAML file badges — deployment.yaml, service.yaml, configmap.yaml, and a highlighted tagging-rules.yaml — with the caption "One mental model" at the bottom.
We’re not choosing YAML because it’s trendy. We choose it because the people who own FinOps policy — platform engineers, SRE leads, and finance partners — must be able to read and update the same file that automation consumes.
A slide diagram titled "YAML Sits in the Middle" showing a central file icon labeled "tagging-rules.yaml" with arrows connecting it to "People" (read and edit) on the left and "Automation" (parses reliably) on the right.
YAML sits comfortably in the middle: a readable format for humans that automation can parse reliably. Use YAML for policy files and JSON for structured results or API responses. Quick comparison A concise tagging-rules.yaml example
  • This skeleton shows the most useful fields for a cluster tagging policy: global defaults, namespace overrides, owners, compliance tier, and exclusions.
  • Keep the policy opinionated and focused on metadata that answers ownership and billing questions.
Best practices for tagging policy files
  • Keep the file small, opinionated, and single-purpose: metadata and ownership belong here; enforcement and cost calculations belong in the automation that consumes it.
  • Prefer defaults with namespace-level overrides to limit duplication.
  • Use clear owner identifiers (team aliases or on-call rotations) so remediation can be routed reliably.
  • Exclude system namespaces explicitly to avoid noisy findings.
Keep the tagging policy small and opinionated. Store ownership, required labels, and exclusions here; leave enforcement rules and cost calculations to the automation that consumes this YAML.
Links and references
  • Kubernetes Basics
  • YAML specification: https://yaml.org/
  • Consider tools that validate YAML and apply policy (e.g., CI validation, OPA/Gatekeeper) to enforce tagging consistency during manifest deployment.

Watch Video