Potentially, this could happen. In this sense, it looks to me that this is not the proper way to deploy WordPress following the immutability principles (https://engineering.bitnami.com/articles/why-your-next-web-service-should-be-immutable.html). In order to avoid this kind of issues, my advice would be:

• Use environment variables for instead of persisting the wp-config.php configuration
• Store all assets in a service like S3. There are plugins for this (https://deliciousbrains.com/wp-offload-s3/).
• If you want to use plugins, build an image that bundles all of them (this may be a bit more difficult, but it would save you from the pain of having inconsistencies between the pods).

There could be issues if the newer version implies changes in the database. In that case, I would add some kind of readiness check in the pod definition so, in case the old version fails, it gets removed from the service and only the newer WordPress pods are available. In this case, doing a database backup prior to upgrading would be a good choice as well.