Can you elaborate on what you found successful or unsuccessful about each of these solutions? It would also be helpful to understand what this state is and what you’re doing with it. Finally, what’s your plan if your whole K8s project goes down?
I think those solutions are great but unfortunately I was not able to make it work. For example when I scale up and down my pods the new ones they could connect to the cluster and keep going but when I run for example kubectl set image … and change the current image of the container the new pods are not able to connect to the previous existing cluster nor keep the previous state. The state would be simple key-value map. if the whole k8s crashes thats not a big problem first of all non of the state should be a sensitive data and also I’m trying to develop this solution just for learning purposes so no real project is being planned just trying to see if this is possible.
point that might be helpfull → Im using the same erlang cookie in every new docker-image so it must be able to connect to the cluster.
This is the problem to dig into figuring out because every single Erlang / elixir specific way of storing state is going to assume you can form a cluster. If you can’t form a cluster, this sort of hand off is going to require more traditional answers where you store the state elsewhere in Redis / postgres / etc.
I mean, I was able to connect to the cluster using other strategies, as this is just for learning purposes I switched to docker swarm orchestration, but even when connected the state is not persisted across the cluster