Skip to main content
Hello and welcome back. Now that our deployment is complete, let’s go straight to the core problem: inconsistent labeling. When Alina was troubleshooting an incident, inconsistent label naming prevented her from quickly finding the right team and routing the incident. With the SkyLine Air cluster fully deployed, we’ll inspect how labeling varies across namespaces and deployments and then outline how to enforce and remediate a consistent labeling standard.

​
What we’ll do

  1. List namespaces in the cluster.
  2. Inspect deployments and their labels in two namespaces (inventory and payment).
  3. Observe inconsistencies and summarize the gaps.
  4. Propose a minimal labeling standard and enforcement options.

​
1) List namespaces

Run this command to see the namespaces in the cluster:
Example output:

​
2) Inspect deployments and labels

First, check deployments and the labels they expose in the inventory namespace:
Example output:
Next, inspect the payment namespace:
Example output:

​
3) Observations — label inconsistency

From the outputs above:
  • inventory namespace
    • inventory-service includes: app.kubernetes.io/name, app.kubernetes.io/tier, cost-center, criticality, environment, and owner.
    • This mix contains both operational metadata (owner, environment) and business metadata (cost-center, criticality).
  • payment namespace
    • payment-gateway has app.kubernetes.io/name, app.kubernetes.io/tier, app, and environment, but lacks owner, criticality, cost-center.
    • payment-gateway-api similarly lacks owner, criticality, cost-center.
    • payment-processor includes cost-center and owner but does not include app.kubernetes.io/name in the same format as the others.
This inconsistency occurs both between namespaces and between deployments in the same namespace.

​
Quick summary table

​
4) Why this matters

In a large organization (many clusters and many teams), inconsistent labels cause problems with:
  • Auditing and inventory reporting
  • Cost allocation and chargeback (FinOps)
  • Incident routing and ownership (SRE / on-call)
  • Automated tooling (monitoring, dashboards, autoscaling or policy enforcement)
Who applies labels? Engineering teams typically add labels as they deploy resources. Who defines the standard? Platform teams, SRE, and FinOps should collaborate to define required keys, allowed values, and naming conventions. Enforcement mechanisms (described next) are needed so teams don’t drift from the standard.

​
5) Suggested minimal label policy

Consider this minimal set of required labels and conventions:
  • Required keys:
    • owner — team or person responsible (e.g., payments-team)
    • environment — prod, staging, dev
    • cost-center — cost or billing code
  • Kubernetes recommended labels:
    • app.kubernetes.io/name — application name
    • app.kubernetes.io/tier — frontend, backend, middleware
  • Optional but useful:
    • criticality — e.g., P0, P1, P2
    • release — release/tag identifier
  • Naming conventions:
    • Use lowercase, hyphen-separated team and app names (e.g., payments-team, payment-gateway)
    • environment should be one of a finite list (prod, preprod, staging, dev)
Define a label policy (required keys, allowed values, and naming rules) and enforce it via admission controllers (e.g., Open Policy Agent / Gatekeeper) or CI checks so resources are labeled consistently at creation time.

​
6) Enforcement and remediation options

  • Admission controllers
    • OPA/Gatekeeper: enforce required labels and allowed values during resource creation.
    • Kyverno: another policy engine focused on Kubernetes resource mutation and validation.
  • CI / GitOps checks
    • Lint manifests in CI pipelines to ensure required labels exist before merging.
  • Automated remediation
    • Controllers that add missing labels (with audit logs), or assign default values where safe.
  • Reporting and alerts
    • Continuous audits that report unlabeled resources and alert owners.
  • Documentation and templates
    • Provide manifest templates and starter charts that include required labels.

​
7) How to audit labels across the cluster

  • Find all pods/deployments missing a required label (example using kubectl + jq or grep):
  • Search cluster resources for specific labels:
  • Use label-based reporting in dashboards and cost tools (e.g., Prometheus, Grafana, cloud billing exports).
  1. Define the label policy (required keys, allowed values, naming rules).
  2. Publish policy and templates to engineering teams.
  3. Implement enforcement (Gatekeeper / Kyverno) in a staged rollout (non-blocking → audit → deny).
  4. Add CI checks to catch label issues at PR time.
  5. Implement reporting and remediation workflows for existing resources.
This walkthrough highlights the real operational impact of inconsistent labels and provides practical steps to standardize, enforce, and remediate labeling across SkyLine Air (or any organization).

Watch Video