Kubernetes config map symlinks (..data/) : is there a way to avoid them?

I think this solution is satisfactory : specifying exact file path in mountPath, will get rid of the symlinks to ..data and ..2018_06_04_19_31_41.860238952

So if I apply such a manifest :

apiVersion: v1kind: Podmetadata:  name: my-lamp-sitespec:    containers:    - name: php      image: php:7.0-apache      volumeMounts:      - mountPath: /var/www/html/users.xml        name: site-data        subPath: users.xml    volumes:    - name: site-data      configMap:        name: users---apiVersion: v1kind: ConfigMapmetadata:  name: usersdata:  users.xml: |      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>      <users>      </users>

Apparently, I'm making use of subpath explicitly, and they're not part of the "auto update magic" from ConfigMaps, I won't see any more symlinks :

$ kubectl exec  my-lamp-site -c php -- ls -al /var/www/htmltotal 12drwxr-xr-x 1 www-data www-data 4096 Jun  4 19:18 .drwxr-xr-x 1 root     root     4096 Jun  4 17:58 ..-rw-r--r-- 1 root     root       73 Jun  4 19:18 users.xml

Be careful to not forget subPath, otherwise users.xml will be a directory !

Back to my initial manifest :

spec:    containers:    - name: php      image: php:7.0-apache      volumeMounts:      - mountPath: /var/www/html        name: site-data    volumes:    - name: site-data      configMap:        name: users

I'll see those symlinks coming back :

$ kubectl exec  my-lamp-site -c php -- ls -al /var/www/htmltotal 12drwxrwxrwx 3 root root 4096 Jun  4 19:31 .drwxr-xr-x 3 root root 4096 Jun  4 17:58 ..drwxr-xr-x 2 root root 4096 Jun  4 19:31 ..2018_06_04_19_31_41.860238952lrwxrwxrwx 1 root root   31 Jun  4 19:31 ..data -> ..2018_06_04_19_31_41.860238952lrwxrwxrwx 1 root root   16 Jun  4 19:31 users.xml -> ..data/users.xml

Many thanks to psycotica0 on K8s Canada slack for putting me on the right track with subpath (they are quickly mentioned in configmap documentation)

I am afraid I don't know if you can tell Kubernetes not to generate those symlinks although I think that it is a native behaviour.

If having those files and links is an issue, a workaround that I can think of is to mount the configmap on one folder and copy the files over to another folder when you initialise the container:

  initContainers:    - name: copy-config      image: busybox      command: ['sh', '-c', 'cp /configmap/* /configs']      volumeMounts:        - name: configmap          mountPath: /configmap        - name: config          mountPath: /configs

But you would have to declare two volumes, one for the configMap (configmap) and one for the final directory (config):

  volumes:    - name: config      emptyDir: {}    - name: configmap      configMap:        name: myconfigmap

Change the type of volume for the config volume as you please obviously.