Your organization has recently begun an initiative to replatform their legacy applications onto Google Kubernetes Engine. You need to decompose a monolithic application into microservices. Multiple instances have read and write access to a configuration file, which is stored on a shared file system. You want to minimize the effort required to manage this transition, and you want to avoid rewriting the application code. What should you do?
The best approach for managing a shared configuration file that requires both read and write access among multiple instances is to create a new Filestore instance and mount the volume as an NFS PersistentVolume. Filestore provides a managed network file system that supports concurrent access, which is essential when multiple instances need read/write access to the same file. Using an NFS PersistentVolume ensures data integrity and consistency, which is necessary when different parts of an application share configuration files.
A is incorrect, because Cloud Storage FUSE does not support concurrency and file locking. B is incorrect, because a persistent disk PersistentVolume is not read-write-many. It can only be read-write once or read-many. C is correct, because it’s the only managed, supported read-write-many storage option available for file-system access in Google Kubernetes Engine. D is incorrect, because the ConfigMap cannot be written to from the Pods. https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes https://cloud.google.com/filestore/docs/accessing-fileshares https://cloud.google.com/storage/docs/gcs-fuse
Generally ConfigMaps (D) are the right choice to store pod config-files, but: They are read-only, which does not match what is asked for here. If, as stated in the question, the application-parts need to be able to also write to that Configfile that should be on a shared file system, the only valid choice is a NFS PV.
Agree with C that a NFS will be required.
Answer C An nfs volume allows an existing NFS (Network File System) share to be mounted into a Pod. Unlike emptyDir, which is erased when a Pod is removed, the contents of an nfs volume are preserved and the volume is merely unmounted. This means that an NFS volume can be pre-populated with data, and that data can be shared between pods
D is the answer. https://cloud.google.com/kubernetes-engine/docs/concepts/configmap ConfigMaps bind non-sensitive configuration artifacts such as configuration files, command-line arguments, and environment variables to your Pod containers and system components at runtime. A ConfigMap separates your configurations from your Pod and components, which helps keep your workloads portable. This makes their configurations easier to change and manage, and prevents hardcoding configuration data to Pod specifications.
C is the correct answer instead. https://kubernetes.io/docs/concepts/storage/volumes/#nfs An nfs volume allows an existing NFS (Network File System) share to be mounted into a Pod. Unlike emptyDir, which is erased when a Pod is removed, the contents of an nfs volume are preserved and the volume is merely unmounted. This means that an NFS volume can be pre-populated with data, and that data can be shared between pods. NFS can be mounted by multiple writers simultaneously.
ConfigMap is the usual way to store application configurations those runs under the cluster. I donot understand why many of you are saying C. The question is asking us to how we are going to manage configuration data in a GKE environment.
ConfigMaps are Kubernetes objects that allow you to store configuration data in a key-value format. ConfigMaps are immutable, which means that they cannot be changed once they are created. This makes them ideal for storing configuration data that needs to be shared between multiple Pods.
In this case the configuration file will be both read and written by the instances, so D is not the answer