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).

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

• Define a path where you would mount the volume in your source code example /myfiles/private
• Create a storage class in your GKE https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/ssd-pd
• Create a Persistent Volume Claim in your GKE https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/ssd-pd
• Relate this storage class with your Kubernetes deployment

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