Fine‑grained health‑check probes in Gardener shoots after version upgrade

When upgrading a Gardener managed Kubernetes environment from a release that only provides basic liveness and readiness probes to a newer release that exposes fine‑grained probe configuration (e.g., separate startup, liveness, readiness settings with adjustable timeouts and failure thresholds), operators must decide whether to retain the legacy probe behavior or adopt the new granular options for existing shoot clusters.

The goal is to maintain consistent health‑check semantics across all shoots while avoiding unexpected restarts or prolonged unavailability caused by mismatched timeout values. Constraints include the provider‑agnostic nature of shoot YAML, the requirement that seed cluster quotas remain sufficient, and the need to keep the same manifest usable across AWS, GCP, and Azure without provider‑specific overrides.

Because the change introduces new fields that are ignored by older control planes, there is uncertainty about how the Gardener controller treats missing fine‑grained sections after an upgrade and whether default values align with the previous basic probe behavior.

What are the recommended steps to evaluate the impact of enabling fine‑grained probes on existing shoots? How can operators verify that the new probe settings do not degrade recovery latency or trigger false‑positive failures? Is there a safe migration path that allows a gradual rollout of the granular configuration without requiring a full shoot recreation?