Incident Overview
At 09:20, a fictional platform team reports that newly created catalogue-api pods remain unready in an isolated Kubernetes validation cluster. Existing pods still serve requests, so the simulated impact is degraded deployment capacity rather than a complete outage.
The difficulty began after a planned change assigned a dedicated service account to the Deployment.The team has confirmed neither the Kubernetes version nor the authorisation configuration. Operators have read access to the namespace but cannot apply changes.
The immediate objective is therefore to identify the strongest supported hypothesis, preserve the remaining healthy replicas and prepare a bounded recovery proposal for an authorised reviewer.
Investigation Options
Review the available operational moves and select the best immediate action.
Inspect the pod's service account, relevant RoleBindings and effective authorisation with read-only queries, while leaving healthy replicas untouched.
Collect node conditions and recent node events first, because a scheduling or host-capacity problem may explain the failed readiness probe.
Inspect Service selectors and endpoint membership first, because traffic routing could explain why users see degraded responses.
Escalate immediately without gathering more evidence, preserving the current workload exactly as it is.