For you to store your data you need to set up persistent storage, if you're using for example Google Cloud as your platform, you would need to create a disk to store your data on and define the use of this disk in your manifest.

With Bluemix it looks like you just have to create the volumes and use them.

bx ic volume-create myapplication_volume ext4 

bx ic run --volume myapplication_volume:/data --name myapplication registry.eu-gb.bluemix.net/<my_namespace>/my_image

Bluemix - Persistent storage documentation

I don't use Bluemix myself so i'll proceed with an example manifest using Google's persistent disks.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myapplication
  namespace: default
spec:
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  selector:
    matchLabels:
      app: myapplication
  template:
    metadata:
      labels:
        app: myapplication
    spec:
      containers:
      - name: myapplication
        image: eu.gcr.io/myproject/myimage:latest
        imagePullPolicy: Always
        ports:
        - containerPort: 80
        - containerPort: 443
        volumeMounts:
        - mountPath: /data
          name: myapplication-volume
      volumes:
      - name: myapplication-volume
        gcePersistentDisk:
          pdName: mydisk-1
          fsType: ext4

Here the disk mydisk-1 is mapped to the /data mountpoint. The only data that will persist after reboots will be inside that folder.

If you want to store your logs for example you could symlink the logs folder.

/var/log/someapplication -> /data/log/someapplication

It works, but this is NOT recommended!

It's not clear to me if you're sshing to the nodes or using some tool to execute a shell inside the containers. Even though running multiple processes per container is bad practice it seems to be working very well, if you keep tabs on memory and cpu use.

Running a ssh server and cronjobs in the same container for example will absolutely work though it's not the best of solutions.

We've been using supervisor with multiple (2-5) processses in production for over a year now and it's working surprisingly well.

For more information about persistent volumes in a variety of platforms. https://kubernetes.io/docs/concepts/storage/persistent-volumes/

You need to learn more about containers as your question suggests that you are not fully grasping the concepts.

1. Running SSH in a container is an anti-pattern, a container is not a virtual machine. So remove the SSH server from it.
2. the fact that you run SSH indicates that you may be running more than one process per container. This is usually bad practice. So remove that supervisor and call your main process directly in your entrypoint.
3. Setup your container image main process to use environment variables or configuration files for configuration at runtime.

The last item means that you can define environment variables in your Pod manifest or use Kubernetes configmaps to store configuration file. Your Pod will read those and your process in your container will get configured properly. If not your Pod will die or your process will not run properly and you can just edit the environment variable or config map.

My main suggestion here is to not use Kubernetes until you have your docker image properly written and your configuration thought through, you should not have to exec in the container to get your process running.

Finally, more generally, you should not keep state inside a container.