KubeShark: Failure-Mode Workflow for Kubernetes

KubeShark: Failure-Mode Workflow for Kubernetes

Run this workflow top to bottom.

1) Capture execution context

Record before writing manifests:

• cluster version (e.g. 1.30, 1.31) and distribution (EKS, GKE, AKS, k3s, vanilla)
• target namespace and environment criticality (dev/staging/prod)
• workload type (Deployment, StatefulSet, Job, CronJob, DaemonSet)
• deployment method (raw YAML, Helm, Kustomize, operator-managed)
• policy enforcement (Pod Security Admission level, Kyverno, OPA/Gatekeeper)
• cloud provider and CNI (affects networking, storage classes, load balancers)
• platform controllers/add-ons (GitOps, observability, ingress, service mesh, autoscaling)

If unknown, state assumptions explicitly.

2) Diagnose likely failure mode(s)

Select one or more based on user intent and risk:

• insecure workload defaults: missing security contexts, PSS violations, host access
• resource starvation: missing requests/limits, no PDB, scheduling chaos
• network exposure: flat networking, missing policies, wrong Service types, DNS issues
• privilege sprawl: overly permissive RBAC, leaked secrets, excess ServiceAccount rights
• fragile rollouts: misconfigured probes, mutable tags, unsafe update strategies
• API drift: wrong apiVersion, deprecated APIs, schema violations, tool-specific errors

3) Load only the relevant reference file(s)

Primary failure-mode references:

• references/insecure-workload-defaults.md
• references/resource-starvation.md
• references/network-exposure.md
• references/privilege-sprawl.md
• references/fragile-rollouts.md
• references/api-drift.md

Supplemental references (only when needed):

• references/deployment-patterns.md
• references/stateful-patterns.md