Use Cases — Runtimez

Use Case

Series B SaaS · 3 EKS clusters · stuck on 1.28, deadline looming

Current version

1.28

Blockers found

Carry CVEs too

To first report

<1 hr

Stage

Series B · 45 employees

Fleet

3 EKS clusters · 304 objects · 15 namespaces

Workloads

Deployments, StatefulSets, Traefik ingress, operators

Cluster Owner

1 backend engineer, no dedicated platform/SRE

Target

1.31 — extended support fees already accruing

Why They Connected

Forced upgrade looming, no idea what would break

Findings

6 upgrade blockers. 3 also carry critical CVEs.

Finding 01 · Cross-axis

checkout-api — removed HPA API + critical CVE

CRITICAL

The checkout-api Deployment uses autoscaling/v2beta2 for its HorizontalPodAutoscaler — removed in 1.26, so the upgrade to 1.31 will silently drop autoscaling. The same workload's image carries a critical OpenSSL CVE with a fix available. It blocks the upgrade and is your top security exposure.

Fix first — one change clears both

Rebuild on the patched base image and migrate the HPA to autoscaling/v2. Retires a critical CVE and an upgrade blocker in a single deploy.

Impact: blocks 1.31 + critical CVE Effort: 1 PR

Finding 02 · Cross-axis

payments-worker — deprecated CRD + high CVEs

HIGH

payments-worker is managed by an operator declaring a deprecated CRD version that won't serve on 1.31. Tier-C runtime signals confirm the deprecated API is actually being called. The worker image also carries several high-severity package CVEs with fixes available.

Fix

Bump the operator to a release that serves the current CRD version, and pull the patched worker image in the same rollout.

Impact: blocks 1.31 + high CVEs Effort: operator bump + redeploy

Finding 03 · Cross-axis

auth-service — removed Ingress API + critical CVE

CRITICAL

auth-service still ships networking.k8s.io/v1beta1 Ingress objects — removed long before 1.31 — and the pod runs as root with a critical CVE in a base library. Public-facing and unowned: no owner label, no PodDisruptionBudget.

Fix

Migrate Ingress to networking.k8s.io/v1, rebuild on the patched image, drop root, and add an owner label + PDB.

Impact: blocks 1.31 + critical CVE + public Effort: 1 PR + manifest update

Finding 04 · Upgrade

batch/v1beta1 CronJobs across 4 namespaces

HIGH

11 CronJobs still declared as batch/v1beta1 — removed in 1.25. They'll stop scheduling the moment the cluster crosses the version line. Aggregated by kind so you see every namespace affected, not just a sample.

Fix

Update the manifests to batch/v1 (spec is compatible) and re-apply. Pure manifest change, no image rebuild.

Impact: 11 CronJobs stop scheduling Effort: apiVersion bump

Finding 05 · Readiness

Single-replica, no PDB on 5 production workloads

MEDIUM

5 production Deployments run a single replica with no PodDisruptionBudget. The node drains that happen during a version upgrade will take them fully offline — exactly when you can least afford it.

Fix

Scale to ≥2 replicas and add a PDB with minAvailable: 1 before you start the rolling upgrade.

Impact: downtime during upgrade drains Effort: replica + PDB per workload

Finding 06 · Security

:latest image tags + over-sized memory limits

LOW

7 workloads pull :latest — unpinned and unscannable for drift — and 4 request 8Gi memory limits against a p95 usage under 900Mi, wasting scheduling headroom. Right-sizing flags them HIGH on limit, fine on CPU.

Fix

Pin images to a digest or semver tag, and bring memory limits down toward observed p95 + headroom.

Impact: drift risk + wasted cost Effort: manifest tidy-up

Upgrade blockers

Fix-first (block + CVE)

1.31

Cleared to upgrade

<1 hr

Connect to first report

Example outcome: the team fixed the three workloads that carried both a critical CVE and an upgrade blocker first, then completed the version upgrade with a much smaller blast radius.

Illustrative scenario — not a customer quote

Also Identified

Posture & compliance (beyond the upgrade)

CIS benchmark: 16 controls failing across RBAC and workload policy
A ClusterRole bound wildcard ["*"] verbs to a default ServiceAccount
$48/mo of namespace spend with no owner label — nobody accountable

Fintech startup · Series A

PR-time gating caught a memory limit removed in review — the change that would've OOM-killed checkout in prod, blocked before merge.

Full write-up coming soon

E-commerce platform · 80 employees

2,700+ image CVEs scanned in-cluster across the fleet, ranked by the workloads that also block the next upgrade.

Full write-up coming soon

What we find on real Kubernetes clusters.

Series B SaaS · 3 EKS clusters · stuck on 1.28, deadline looming

6 upgrade blockers. 3 also carry critical CVEs.

Posture & compliance (beyond the upgrade)

Want to see what's on your clusters?