Diagnosing and Fixing ShootNotReady in SAP Gardener

Diagnosing and Fixing ShootNotReady in SAP Gardener

\n

Your Gardener shoot reports ShootNotReady. The control‑plane health check fails, and kubectl describe shoot <name> shows the condition in the Conditions section. This usually stems from a TLS certificate issue, but network policies or resource quotas can trigger the same status. Follow the ordered checks below to determine the root cause and apply the matching fix, avoiding unnecessary restarts.

\n

Diagnostic overview

\n

Condition	Most Common Cause(s)
ShootNotReady	InvalidCertificate, NetworkPolicyDeny, ResourceExhaustion

\n

Ordered checks

\n

\n
1. \n

   Verify certificate validity period and Subject Alternative Names (SANs).

   \n

   openssl x509 -in <path-to-shoot-cert> -noout -dates

   \n

   Run this command on the management cluster where the shoot is admitted. You need read access to the shoot's serving certificate secret (typically named shoot-<name>-cert or similar, depending on your Gardener configuration).

   \n

   Expected result: the certificate's notBefore and notAfter dates should enclose the current time, and the SAN list must include the shoot's DNS name (e.g., shoot.my-domain.com).

   \n

   Relevant risk: if the cert path is incorrect, the command fails silently or points to a different object; verify the secret name first with kubectl get secret.

   \n
\n
2. \n

   Confirm shoot API server reachability.

   \n

   nc <shoot-api-host> 443

   \n

   Execute from a host that can reach the management cluster's shoot API endpoint. The shoot API host is typically exposed as shoot.<gardener-region>.internal or via the shoot's status endpoint.

   \n

   Expected result: the connection succeeds within a few seconds; no timeout or connection refused.

   \n

   Relevant risk: network policies or firewalls between your workstation and the management cluster may block the test even though the shoot API is healthy.

   \n
\n
3. \n

   Check node resource usage on the shoot's control plane.

   \n

   kubectl top nodes

   \n

   Run in the namespace where the shoot's control plane components are scheduled (usually the shoot's own cluster or the gardener system namespace). You need the metrics-server installed.

   \n

   Expected result: no node should be at 100 % CPU or memory; typical headroom is 20‑30 %.

   \n

   Relevant risk: transient load spikes can cause a false positive; repeat the check after a minute if resources appear saturated.

   \n
\n

\n

Fixes mapped to findings

\n

\n
• \n

  InvalidCertificate: renew or reissue the shoot's serving certificate. Use your internal PKI or cert-manager if configured for Gardener shoots. After the new cert is in place, the shoot control plane typically picks it up automatically, but a restart may be required. Limitation: certificate renewal may require a shoot restart; plan the change during a maintenance window and verify the shoot returns to ShootReady afterward.

  \n
\n
• \n

  NetworkPolicyDeny: adjust the NetworkPolicy that controls traffic to the shoot's API server. Add an ingress rule allowing the shoot's CIDR on port 443 (or the relevant ports) to the management plane endpoints. Caution: NetworkPolicy changes are cluster‑wide; test the modified policy in a staging environment before applying it to production shoots.

  \n
\n
• \n

  ResourceExhaustion: increase resource quotas or limits for the shoot's control plane components (e.g., shoot-control-plane deployment). Modify the shoot's Extension or Shoot manifest to raise CPU/memory limits, then wait for the operator to reconcile.

  \n
\n

\n

When to escalate

\n

\n
• The diagnostic checks are inconclusive after two repetitions.
\n
• Certificate renewal does not resolve the condition even after a shoot restart.
\n
• NetworkPolicy changes fail to propagate or cause unintended traffic drops across other shoots.
\n
• Resource quota increases are rejected by the cluster administrator due to cluster‑wide limits.
\n

\n

In these cases, open a ticket with the Gardener operator team and include the full kubectl describe shoot <name> output, certificate expiry logs, and the applied NetworkPolicy diff.

\n

Verifying the fix

\n

After applying the matching fix, run:

\n

kubectl describe shoot <name>

\n

Check the Conditions section. The ShootNotReady status should be replaced by ShootReady or the condition should disappear. Additionally, repeat the certificate expiry check with openssl to confirm the new cert's validity period. Allow 2–3 minutes after any shoot restart for the control plane to reconcile before re‑checking.