KUBERNETES

K8s Deprecation Radar

Cluster upgrades slip because nobody knows what will break. This loop answers that question the day a new minor goes GA — per team, per manifest, with the exact patch — so the upgrade window is a decision, not an investigation.

TRIGGER

EKS/GKE release feed: new minor GA

SCAN

live API usage per cluster vs removed/deprecated list

MAP

offending manifests → owning team via CODEOWNERS

ACT

one GitHub issue per team with exact manifest patches

01 — INSTALL

brew install supraj/tap/dep-radar
dep-radar init --contexts prod-eks,staging-eks,dev-eks

02 — CONFIGURE

Point it at your kube contexts and repo. No AI step here — this loop is fully deterministic.

# radar.yaml
trigger:
  feed: eks-release-notes
scan:
  contexts: [prod-eks, staging-eks, dev-eks]
  source: audit-log:30d   # what's actually called
map:
  owners: CODEOWNERS
act:
  issues: acme/platform
  label: k8s-upgrade

03 — HOW IT WORKS

Watches the EKS/GKE release feeds. On GA of a new minor, it diffs the deprecated-API list against 30 days of audit-log usage — not just manifests, actual calls.

Each offending resource is traced to its owning team through CODEOWNERS, so nobody gets a 400-line shared spreadsheet.

Issues include the exact apiVersion patch and a working kubectl-convert command. Close the issues, schedule the upgrade.

04 — EXAMPLE OUTPUT

$ dep-radar report --minor 1.34
cluster prod-eks: 7 deprecated usages
  team payments  → 3 (Ingress v1beta1)
  team ml-infra  → 4 (PodDisruptionBudget v1beta1)
issues filed: 2 · est. effort: ~1h each
clusters staging, dev: clean ✓