Currently, the lifecycle-controller performs API discovery exactly once during the SetupWithManager phase at startup. This approach creates a static watch list based on the cluster state at boot time.
If a CRD is installed or a new API service is enabled while the controller is running, the manager remains unaware of these types and cannot process lifecycle annotations on them until the controller pod is manually restarted.
The controller should be universal and self-healing regarding the cluster's API surface. A background discovery mechanism should be implemented that periodically refreshes the watch list and injects new watches into the running controller without requiring a restart.
Currently, the
lifecycle-controllerperforms API discovery exactly once during theSetupWithManagerphase at startup. This approach creates a static watch list based on the cluster state at boot time.If a CRD is installed or a new API service is enabled while the controller is running, the manager remains unaware of these types and cannot process lifecycle annotations on them until the controller pod is manually restarted.
The controller should be universal and self-healing regarding the cluster's API surface. A background discovery mechanism should be implemented that periodically refreshes the watch list and injects new watches into the running controller without requiring a restart.