0

I'm having trouble understanding where to store files in a GKE container? I've seen the following documentation of the filesystem layout:

https://cloud.google.com/kubernetes-engine/docs/concepts/node-images#file_system_layout

But then there are also Dockerfile examples on the web that copy executable files to other paths not listed in the layout, such as /usr or /go. One of these examples is here:

https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/blob/master/hello-app/Dockerfile

Another question is: If I have runtime code that needs to download certain configuration information after the container starts, can I write the configuration file to the same directory as my executable? Or do I have to choose /etc or /tmp.

And finally, the layout documentation states that /home and /var store data for the the lifetime of the boot disk? What does that mean? How does that compare to the lifetime of the pod or the node?

jacob
  • 2,762
  • 1
  • 20
  • 49

2 Answers2

1

When you want to store something in a container you can either store something ephemeral or permanent

  • To store ephemeral way just choose a path /tmp, /var, /opt etc (this depends on the container set up as well), once the container is restarted the information you would have is the same at the moment the container was created, for instance your binary files and initial config files.

  • To store permanent you must have to mount a volume, this is a support for your container where a volume (container path) is linked with a external storage. with this if your container is restarted the volume will be mounted once the container is ready again and you are no gonna lose anything.

In kubernetes this is called Persistent Volumes and you can leverage this even if you are in another cloud provider,

steps to used

Example

link the volume with your container

volumeMounts:
  - mountPath: /myfiles/private
    name: any-name-you-want

relate the persistent volume with your deployment

volumes:
  - name: any-name-you-want
    persistentVolumeClaim:
    claimName: my-claim-name
cperez08
  • 709
  • 4
  • 9
0

This is really up to you. By default most base images will leave /tmp writeable as per normal. But anything written inside the container will be gone if/when the container restarts for any reason. For something like config data, that might be fine, for a database probably less so. To get more stable storage you need to use a Volume. The exact type to use depends on your environment and how long the data should live. An emptyDir volume lives only as long as the pod but can be shared between containers in the same pod. Beyond that you would probably use a PersistentVolumeClaim to dynamically provision a new Google Cloud disk which will last unless the claim is deleted (or forever depending on your Reclaim setting).

coderanger
  • 52,400
  • 4
  • 52
  • 75
  • Thanks In my case, it can be ephemeral even when the container restarts, and I do not need to share between containers in a pod. I'm still not totally clear on the meaning of the documented filesystem layout properties. Perhaps I'll guess that it will allow the container image to copy files to any path, but once the container starts running, the file permissions are as documented. So for example, if a dockerfile created a folder and files under /usr, that's fine. But once it starts running, it takes on the permissions of the documented path '/'. Is that correct? – jacob Jul 28 '19 at 23:24
  • 1
    No, there are no special paths of any kind unless you set up volume mounts yourself. Otherwise the image is just the image. – coderanger Jul 29 '19 at 02:23
  • Thanks you are correct. I deployed a hello world node app to `usr/src/app` directory, and the node app itself writes a file to that directory when it runs. It was not a problem. I don't understand that documentation page on the layout. Seems like I can ignore that information. – jacob Jul 29 '19 at 20:34
  • 1
    You were looking at docs for GKE Nodes, i.e. the virtual machine that run Kubernetes, nothing to do with containers. – coderanger Jul 29 '19 at 20:57