Gardener Shoot Controller and Cloud API: Metadata Persistence During Cancellation

Direct answer

Cancellation is evaluated at the start of each reconciliation iteration, before the shoot controller invokes the function that persists metadata to the Gardener API server. If the shutdown signal is present then, the loop exits and the persistence call is never made. Because cloud resource tagging is sequenced after that persistence step, cancellation before persistence also prevents tagging. There is no established atomicity guarantee spanning metadata persistence and cloud tagging, so a graceful shutdown can leave cloud resources provisioned without expected tags, or leave metadata in an intermediate state.

Likely explanation versus confirmed facts

Likely explanation: controller-runtime stops reconciliation workers when StopCh is closed or the associated context is cancelled. The check occurs at loop entry, so a signal arriving mid-cycle is not honored until the next iteration boundary. The seed-update persistence path and the cloud-tagging call are separate operations; the latter depends on the former completing successfully.

Confirmed facts: This answer does not verify the exact Gardener source code or release. The controller-runtime shutdown pattern is well established, but the precise seed-update stage, tagging sequence, and retry behavior must be confirmed against the deployed Gardener version.

Steps for this case

1. Record the Gardener version and cloud provider in use.
2. Enable debug logging for the shoot controller.
3. Trigger a controlled shutdown while a seed update is active.
4. Correlate cancellation timestamps with API server audit events for the Shoot resource.
5. Check the cloud provider console for resources created during the window and verify whether expected tags are present.

Safe verification commands

kubectl logs -n garden -l app=gardener --component=shoot-controller --tail=200
kubectl get shoots --all-namespaces -o jsonpath='{.items[*].metadata.name}'

Avoid running cloud provider delete or tag commands until the orphaned resources are identified.

Missing diagnostic detail

Which cloud provider and API version are involved? This changes the recommendation because tagging atomicity and cleanup behavior differ by provider.

Assumptions and uncertainty

• Assumes the controller uses controller-runtime's standard StopCh/WakeUpCh shutdown mechanism.
• Uncertain whether the persistence function inspects context cancellation inside the API call or only before it.
• Uncertain whether Gardener automatically retries the failed seed update after the controller restarts.