Support for bind volumes #125

New Issue

2025-07-03T20:27:35Z

jpsnyder commented

2025-07-03 20:27:35 +00:00

(Migrated from github.com)

Greetings, I have been using katenary for a long time and recently got excited to discover there is a new v3 release with lots of nice changes.
However, I'm a bit disappointed to see that bind mounts are still not supported. I'm curious to know why?

I am not very knowledgeable about Kubernetes configurations (which is why I use katenary), but it seems like supporting this wouldn't be very difficult. (At least for simple use cases)

Why can't something like this in the docker compose:

volumes:
  - /host/path:/mnt/path:ro

simply turn into this in the deployment?

spec:
  template:
    spec:
      containers:
        volumeMounts:
          - name: mnt-path
            mountPath: /mnt/path
            readOnly: true
      volumes:
        - name: mnt-path
          hostPath:
            path: /host/path
            type: DirectoryOrCreate

Greetings, I have been using katenary for a long time and recently got excited to discover there is a new v3 release with lots of nice changes. However, I'm a bit disappointed to see that bind mounts are still not supported. I'm curious to know why? I am not very knowledgeable about Kubernetes configurations (which is why I use katenary), but it seems like supporting this wouldn't be very difficult. (At least for simple use cases) Why can't something like this in the docker compose: ```yaml volumes: - /host/path:/mnt/path:ro ``` simply turn into this in the deployment? ```yaml spec: template: spec: containers: volumeMounts: - name: mnt-path mountPath: /mnt/path readOnly: true volumes: - name: mnt-path hostPath: path: /host/path type: DirectoryOrCreate ```

metal3d commented

2025-07-04 07:29:21 +00:00

Hello, and first of all, thank you for these words that give me the courage to spend time trying to improve my tool :)

The “bind volumes” work in V3, but on condition that the volume is a “named volume” in the compose file.

The reason is simple:

a “local” volume is normally used within a local project to drop the application sources and work with them. For example, to mount the sources of a PHP project.
a “named” volume is used for data persistence. For example, data from a database, files uploaded to the application, etc.

Katenary version 3 now allows you to “force” a local file to be written as a configMap. For example, for an NGinx or Apache configuration to be mounted in the container within a Pod.

A volume like the one in your example requires a local directory to be mounted in the container. But within Kubernetes, a “hostPath” will create an empty directory. However, local mounting within Podman or Docker may contain files at the base. This means that the difference in operation will be a problem.

It's a question of best practice: if the volume is to store values, then it's a “named volume” that should be integrated into your compose file.

If your directory is to provide configuration files, you can use the “compose-files” label, which will mount the files in the Pod via configMaps.

The only reason to use a “hostPath” is when two containers (usually within the same Pod), need an exchange space (for example between nginx and FPM, nginx often needs access to the files served by FPM).

Unless you have an example that indicates an error on my part, I think this operation is the most logical.

Hello, and first of all, thank you for these words that give me the courage to spend time trying to improve my tool :) The “bind volumes” work in V3, but on condition that the volume is a “named volume” in the compose file. The reason is simple: - a “local” volume is normally used within a local project to drop the application sources and work with them. For example, to mount the sources of a PHP project. - a “named” volume is used for data persistence. For example, data from a database, files uploaded to the application, etc. Katenary version 3 now allows you to “force” a local file to be written as a configMap. For example, for an NGinx or Apache configuration to be mounted in the container within a Pod. A volume like the one in your example requires a local directory to be mounted in the container. But within Kubernetes, a “hostPath” will create an empty directory. However, local mounting within Podman or Docker may contain files at the base. This means that the difference in operation will be a problem. It's a question of best practice: if the volume is to store values, then it's a “named volume” that should be integrated into your compose file. If your directory is to provide configuration files, you can use the “compose-files” label, which will mount the files in the Pod via configMaps. The only reason to use a “hostPath” is when two containers (usually within the same Pod), need an exchange space (for example between nginx and FPM, nginx often needs access to the files served by FPM). Unless you have an example that indicates an error on my part, I think this operation is the most logical.

jpsnyder commented

2025-07-04 12:54:30 +00:00

(Migrated from github.com)

So what I'm doing is probably not best practice, but sometimes in my container I need access to a directory on the host pod. This is to get access to a smb share that has already been mounted in the pod.

The example I showed is what I go in and manually do after running katenary convert and it works great. I was just hoping it could be done for us instead of bind volumes being ignored.

I am aware of named volumes and configmap mounts. I have used those features too, but they are not useful for what I'm trying to do here.

So what I'm doing is probably not best practice, but sometimes in my container I need access to a directory on the host pod. This is to get access to a smb share that has already been mounted in the pod. The example I showed is what I go in and manually do after running katenary convert and it works great. I was just hoping it could be done for us instead of bind volumes being ignored. I am aware of named volumes and configmap mounts. I have used those features too, but they are not useful for what I'm trying to do here.

metal3d commented

2025-07-04 12:57:55 +00:00

Not sure to understand but:

you mount a smb share inside the node in /x/y
and you want to mount the /x/y host path inisde the pod

So, even if it's not so common to see that kind of mount point, it's probably somthing I can do (e.g. a label to force hostPath)

Not sure to understand but: - you mount a smb share inside the node in /x/y - and you want to mount the /x/y host path inisde the pod So, even if it's not so common to see that kind of mount point, it's probably somthing I can do (e.g. a label to force hostPath)

jpsnyder commented

2025-07-04 14:10:37 +00:00

(Migrated from github.com)

Correct. While I know it's probably more proper to try to mount the smb directly in the container, where I work, dealing with the smb shares are a PITA. So the devop just setup the smb mount on the host kubernetes pod and we are supposed to just do a bind volume to it.
Not something under my control.

https://kubernetes.io/docs/concepts/storage/volumes/#hostpath

I realize the security implications. So maybe it should be opt-in with a label or something?

Correct. While I know it's probably more proper to try to mount the smb directly in the container, where I work, dealing with the smb shares are a PITA. So the devop just setup the smb mount on the host kubernetes pod and we are supposed to just do a bind volume to it. Not something under my control. https://kubernetes.io/docs/concepts/storage/volumes/#hostpath I realize the security implications. So maybe it should be opt-in with a label or something?

metal3d added this to the Enhance volume binding project 2025-09-14 12:22:57 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Katenary/katenary#125