kwhy explains why a Kubernetes object keeps changing.

It is designed for incident response in controller-heavy clusters where manual child edits keep getting overwritten.

curl -L https://raw.githubusercontent.com/fizz/kwhy/main/kwhy -o /usr/local/bin/kwhy
chmod +x /usr/local/bin/kwhy

# First run (real-world Kubeflow case)
kwhy explain deployment ml-pipeline-ui-artifact -n admin --context mlinfra-prod

1. Owner chain (lineage)
2. Write managers (managedFields)
3. Likely reconcilers (annotation/manager heuristics)
4. Desired-state inputs (ConfigMap/Secret refs)
5. Manual edit revert risk
6. Basic RBAC sanity (kubectl auth can-i)

curl -L https://raw.githubusercontent.com/fizz/kwhy/main/kwhy -o /usr/local/bin/kwhy
chmod +x /usr/local/bin/kwhy

• kubectl
• jq
• access to target cluster/context

kwhy explain deployment ml-pipeline-ui-artifact -n admin --context mlinfra-prod
kwhy explain deploy ml-pipeline-ui -n kubeflow --context mlinfra-prod --format json

• Owner Chain
• Write Managers
• Likely Reconcilers
• Desired-State Inputs
• Revert Risk
• RBAC Sanity
• Actions

See examples/incident-kubeflow-ml-pipeline-ui-artifact.txt.

kwhy is heuristic by design. Kubernetes has no universal “single reconciler of record” field.

Use it as a fast narrowing tool, then validate with controller-specific context.

MIT