Manage a un-managed configMap as resource

[mancave]

Hi Team,

Here is my use-case:

• A deployment is depending on a ConfigMap mapped to a file in a pod.
• This configMap represents a dynamic configuration for that application running in that pod, so if the configmap changes K8s will reflect does changed in the file by the k8s sync mechanism.
• When that configmap is deleted the n-1 state of the config map is still synced to the file (K8s will not remove the file on the pod, but also no show a empty file)

I want that the configMap content can be changed by a CRD, but I'm running in some problems.

The configmap needs to be there before the application is deployed, so having a Reconciler with a dependant configmap will not work because the configmap will only be created when the Reconciler is triggers with a CRD.

The same thing is when the configmap is managend as a dependancy on the Reconciler when the last CRD is delete, the configmap will also be deleted result is that the file on the pod will reflect the n-1 state of the configmap.

It looks like we can't manage the content of the configmap with a Reconciler and managed configmap as a resource.

So we need a Reconciler that managed the config map on it's own and not as a dependancy. Also it needs some different bootstrap because the configmap needs already to be existing(with some "empty" configuration) before the application is deployed, otherwise the pod will not be started because of the missing dependancy. It will only start if the configmap is create with some CRD.

Also when the configmap is changed(external) the reconcil loop needs to be triggerd to get the configmap again in the correct state with the CRD's data.

Can you please help me out how I can achieve this with the java-operator-sdk framework ?

yours sincerely

[csviri]

Hi @mancave

Some questions first to see this clearly:

• what do you mean exactly by n-1 config map? that is a separate resources?
• the deployment is managed by the controller?
• so if I understand the controller creates if not exists the config map but does not delete it, correct?

[mancave]

Hi csvire,

• If a config map changes those changes are eventually synced with the pod as file system as default working of k8s, if the config map is deleted the mapped file will still having the content of the configmap before it was deleted. So if n represent the changes on the configmap, I see n - 1 the state of the config map before it has been deleted.

• No, the deployment at this moment is managed by helm and is the responsibility of a different team. We are looking to change that.

• If you define the configmap as a dependancy the configmap is create if it is not there when there is a custom crd applied. But if its get delete because there a no custom crd relations any more(operatorsdk working), thats where the first point comes into play. While for the sync mechanism the configmap should not be removed, there should be some kind of empty/default content so the k8s sync will kick in and leaf a "partial empty/default" file on the pod. And thats is oke because the application can handle that.

[csviri]

I think I still don't understand all the details, but will describe you how to implement the following situation:

To manage config map content from a custom resource (CR); if the config map already present if there is no CR yet, after creating the CR the config map concent should be overriten, if the CR is deleted the config map should be still there (so we don't delete the ConfigMap):

I think this is doable with base API but also with dependent resources + workflows. But I think this might be simpler to underdstand with base API, pseudo code:

public class MyCustomResourceReconciler implements Reconciler<MyCustomResource> {

InformerEventSource<ConfigMap> configMapEventSource;

  public void reconcie(MyCustomResource cr, Context context) {

   // this assumes you have some naming convention for the config map name;
      Optional<MyCustomResource> configMap = configMapEventSource.get(new ResourceID(cr.getMetadata().getName(),cr.getMetadata().getNamespace()))
      // check if CM exists
     if (configMap.isPresent()) {
          // check the content of the config map, add missing annotations if needed, update the content with Kubernetes client  (data from cr)       
      } else {
         // create the config map with data from cr add annotations
     }
    // you can here add some info to status of the CR, for example the resource version of the config Map
     return UpdateControl.noUpdate();
  }


  @Override
  public List<EventSource<?, MyCustomResource>> prepareEventSources(EventSourceContext<MyCustomResource> context) {
     configMapEventSource =
  
        new InformerEventSource<>(
            InformerEventSourceConfiguration.from(ConfigMap.class, MyCustomResource.class)
                  // this is important, the CR will triggered based on the annotation no owner references,
                  // so if you delete the CR the K8S GC won't delete the config map. See source code what annotations you need 
                  // to add in reconiler. 
                 .withSecondaryToPrimaryMapper(Mappers.fromDefaultAnnotations(MyCustomResource.class))
                .build(),
            context);
    return List.of(configMapEventSource);
  }
}

In additional to that you can implement Cleaner methods is you want to have some explicit logic when CR is deleted.