Kubernetes non-configurable cloud disappears when reloading the CasC bundle

CasC supersedes the need for Shared Cloud Configurations as explained in Supported items using CasC. Shared configurations, such as the Kubernetes shared cloud configuration, can be defined directly in your controller CasC bundle. It is not supported to define shared configurations at the operations center level and push them to the controllers, as per Supported items using CasC. With controller bundle inheritance, this can also be defined once and shared among multiple controllers, as documented at Configuring bundle inheritance with CasC. For more information, refer to Shared configurations and Shared cloud configuration.

When you define clouds with CasC, CasC reloads will create the list of clouds without the non-configurable ones. In particular, the NonConfigurableKubernetesCloud is not recreated until a certain event triggers the update of the Operations Center context, for instance a controller reconnection to OC, a login to the controller through the Operations Center, or the automatic resynchronization of the remote context.

If you define clouds for your controllers with CasC, don’t use the default created Kubernetes Shared Cloud and create a custom one as CasC instead (with a name different than kubernetes). Since that new cloud will be configurable, and therefore can be managed by CasC, it will be available even shortly after reloading the bundle.

Please note that when you define a cloud in a controller and no endpoint is given, it defaults to the cluster endpoint. If you want to keep using the same cluster as with the default shared cloud, the cloud configuration is very simple. Here is an example of a jenkins.yaml that only defines the custom cloud and gives a maximum number of concurrent containers in it: