Assuming that you are required to allow wordpress users to install/upgrade plugins, burning wordpress in a Docker image is not gonna work: either you allow the app to be updated only by distributing a new docker image or you don't. What you want to do allows for app updates to come from two sources.
If you don't have such requirement, just add:
define(‘DISALLOW_FILE_MODS’,true);
to wp-config.php and you are good to go.
Make sure that when you upgrade your Docker image with a new version of Wordpress, the database schema is upgraded accordingly and all versions of Wordpress currently in execution can use that db schema.
If you can't disable plugin installation/updates, you need to solve 2 problems:
1) You need to have all containers access the same wordpress installation.
On-disk files in a container are ephemeral, which means when a container crashes, kubelet will restart it, but the files will be lost - everytime you get a clean slate.
A typical solution to this problem is to create a volume just to store your wordpress installation and mount it on all containers in the Pod, like this:
volumes:
- name: wp-webroot
emptyDir: {}
- name: wp-container
image: wp
volumeMounts:
- name: wp-webroot
mountPath: /var/www/html
- name: wp-container2
image: wp
volumeMounts:
- name: wp-webroot
mountPath: /var/www/html
More info:
https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/
2) You need to make the storage of the shared volume reliable/redundant.
Kubernetes offers many options that vary depending on where you are running your Kubernetes installation.
If you are in a public cloud use whatever that cloud makes available (e.g. EFS on AWS), if you are on-premise you might want to look into glusterfs or if you have an existing SAN use that.
More info on: https://kubernetes.io/docs/concepts/storage/volumes/
Regarding your request for some bibliography on the topic, you will find many documents telling you that your application should be part of the image, e.g. point #7 in:
https://developers.redhat.com/blog/2016/02/24/10-things-to-avoid-in-docker-containers/
but again, that assumes that the application can only be upgraded/modified by the admin, not the end users. You must contextualize the suggestions that you find on the web to your specific requirements.