The behaviour you are seeing is correct. When you trigger a new build, a transient build pod is created which co-ordinates the building of the new image. When the new image has been built, it is pushed into the internal image registry and the build pod gets shutdown.
In the case of default rolling deployment strategy, what happens next is that a new pod is created which runs the new image. The pod using the old image is then shutdown.
The question is, why are you expecting the old pod to stay around?
The file system of the container for a deployment is not updated in place. If you need data created or changes made by the application within the running container to be preserved across a new deployment, you need to use a persistent volume and store your changes there.