My reading into Kubernetes has seemed to say that Statefulsets are the best answer for "stateful" applications. (A Gitlab instance in my case.) Creating a single replica of the container is fine, but what happens when I push an update?
If my application has a claim for a single persistent volume, does pushing an update connect back to the same disk? The Google Kubernetes Engine docs state that each pod will receive its own volume and that "rolling" updates are the default. How can this work if the new container created during a rolling update needs the data in the volume still in use by the first replica?
I'm probably missing something that has me running in circles around the answer.
You are right, a statefulset controller is used to run stateful applications.
Upgrading a node pool version will not delete the persistent volume, It will connect the new pod back to the same persistent volume after the update.
As per the GCP documentation, after the update, only the data stored in the host hostPath and emptyDir will be erased. The data in the persistent volume will not be erased.
What will happen is that Kubernetes stops scheduling, drains and then deletes all of the cluster’s nodes and pods. One by one. The persistent volume will be unmounted from the pod, and then mounted to a new pod once the update is completed. The data in the persistent volume will be kept. After the update, the new updated container will be mounted with the same persistent disk.
Since it is a single replica, there will be a period when the container will be offline, during which the pod will be unavailable, and the persistent volume will be unmounted.