Add support for `subPath` in mounted configmaps

[criskurtin]

Expected Behavior

As of current version, kubedeploy chart does not support mounting a configmap data key as a single file, without destroying the existing mountpath contents. Supporting a subPath solves this issue and allows for various use-cases, such as modifying a single configuration file in a pre-populated path within a container.

Current Behavior

Currently, a configmap can only be mounted as a whole, by defining a mountpath (a directory) and mounting the configmap data keys as files within that directory. This is a destructive process and it removes all pre-existing contents from the target mountpath.

Possible Solution

subPath field support should be added to the configMaps section. This field should be mapped to the container volume mounts for the corresponding configmaps.

Context

I'm trying to deploy a softwaremill/elasticmq service using kubedeploy chart. This service is configured by replacing the /opt/elasticmq.conf file contents with a custom version of configuration. Unfortunately, elasticmq.conf is not an only file in /opt directory. There are some additional XMLs, as well as the entire GUI application in there. If I just mount a configmap with elasticmq.conf file to the /opt path, the container just crashes as it can't find the rest of the files anymore.

• Chart version used: 1.1.*
• Kubernetes version: v1.27.7-eks

[btoic]

Hi @criskurtin, thank you for the report and the contribution.

That is true, mount parameter in the configmap values section is an additional convenience method for mounting whole configmap as directory inside the pod while overwriting the whole folder within that pod. While the subPath feature within configmap value section is currently not available, I do see your proposal as an enhancement to the end user experience and I'll definitely consider this as a feature for one of the next releases.

While you wait for the review on the pull request, might I offer you alternative solution for this particular issue.

Most of the application executables offer some way of defining custom configuration path via command line arguments. In that case, you should be able to mount configmap on any other path that will not overwrite other application content. You can then reference the configuration file from there by using commands or args parameters on image or any other values subsection like initContainers, additionalContainers etc..

In your specific case, it should be even easier as the softwaremill/elasticmq offers some additional options while configuring ElasticMQ via Docker and modifying it via application.ini in /opt/docker/conf

I would suggest following configmap configuration

configMaps:
  - name: configmap1
    mount: True 
    mountPath: /opt/docker/conf
    data:
      application.ini: |
        -Dconfig.file=/opt/docker/conf/elasticmq.conf
      elasticmq.conf: |
        your custom configuration here

The whole custom elasticmq.conf and application.ini is then mounted in /opt/docker/conf where no other files (except the default application.in) would be destroyed.

As an additional feature, I would suggest using configMapsHash to automatically restart pods whenever you change the contents of configMaps.

[btoic]

Another alternative solution is to use extraVolumeMounts in combination with secrets.

I see that I've missed the opportunity to add configmaps in extraVolumeMounts and documentation on subPaths, however the feature is available to use with secrets.

Example

image:
  repository: nginx
  tag: latest

extraVolumeMounts:
  - name: secret-mount
    mountPath: /mnt/volume4
    secretName: my-secret
    subPath: key.cfg

Please note that you should reference the secretName by the chart generated secret name rather than name of the secret as defined in extraSecrets.

I'll probably issue a point release over the weekend including configmaps as valid extraVolumeMounts as this is a bug in already released feature.

[criskurtin]

In your specific case, it should be even easier as the softwaremill/elasticmq offers some additional options while configuring ElasticMQ via Docker and modifying it via application.ini in /opt/docker/conf

This would be the case for the full JVM image. However, I'm trying to use the GraalVM ("native") build which has much faster startup times and smaller image footprint (94MB vs 644MB). This image contains only a single AOT pre-compiled binary. So there isn't an application.ini as such.

I can fall back to the full JVM image temporarily until the extraVolumeMounts configmap support gets added. extraVolumeMounts was my initial idea when I realised what the issue was, but I noticed it isn't supported. I just falsely assumed it was like that by design since configmap mounting is handled differently :sweat_smile: