A Deployment is set to `maxUnavailable: 0`, and a rollout to a new image version has been "in progress" for twenty minutes with `kubectl rollout status` still waiting. What's actually happening, and where do you look first?

maxUnavailable: 0 means capacity is never allowed to drop, so before an old pod can be removed, a new one has to actually pass its readiness probe — the roll is only as safe as that probe, which cuts both ways. A stuck rollout with this setting almost always means the new pods aren't passing readiness, so the Deployment controller is correctly refusing to remove any old pod, exactly as configured; it isn't stuck by accident, it's stuck by design because the alternative (removing an old pod before a replacement is proven ready) is the outage this setting exists to prevent. The first place to look is the new pods themselves — kubectl get pods for their status, kubectl describe pod on one of the new ones for its readiness probe's actual failure reason, and kubectl logs on a new pod to see whether the application is even starting correctly. Loosening the probe to make the rollout "finish" defeats the entire point of the setting.