Shoot hibernation stuck in Hibernating state due to gardener-controller-manager connectivity loss

Immediate answer

Gardener’s controller‑manager keeps the last known Hibernation condition in an in‑memory map. When the seed becomes unreachable, the map is never refreshed until the next reconciliation event. Therefore a Shoot can stay stuck in Hibernating even if spec.hibernation.enabled is false.

What triggers a cache flush?

• Any status update from the seed (e.g. a new Shoot.status object).
• Success of a periodic seed‑health‑probe.
• Explicit sync timer firing.

How to clear the stale state

1. Patch the Shoot to force the controller into a new reconciliation round. A common pattern is to add or update a dummy annotation:

2. kubectl patch shoot <name> -n <ns> -p '{"metadata":{"annotations":{"hibernation-clear":"$(date +%s)"}}}'

3. Watch the controller logs for a line such as Reconciliation triggered by seed status update. Within a few minutes the Hibernation condition should move to Awakening or Ready.

Is there a flag to force immediate re‑evaluation?

No documented configuration or annotation exists that makes the controller poll the seed immediately after reconnection. The only supported method is to trigger reconciliation via a resource change.

Detecting the stale condition

1. Check the Shoot status: kubectl get shoot <name> -n <ns> -o jsonpath='{.status.conditions[?(@.type=="Hibernation")].status}'. A value of Hibernating indicates a stale cache.
2. Verify the controller logs around the time the seed becomes reachable. The absence of a reconciliation trigger confirms that the cache was not invalidated.

Practical verification

1. Patch the Shoot as shown above.
2. After ~5 min, run kubectl get shoot <name> -n <ns> -o yaml and confirm that status.conditions[].type for Hibernation is no longer Hibernating.

Missing detail that may change the recommendation

Do you run more than one replica of gardener-controller‑manager in your control plane? If so, only the replica that last updated the cache will be authoritative, and a patch may need to be applied to each replica’s view.