You have containerized a legacy application that stores its configuration on an NFS share. You need to deploy this application to Google Kubernetes Engine
(GKE) and do not want the application serving traffic until after the configuration has been retrieved. What should you do?
To ensure the application does not serve traffic until the configuration has been retrieved, the most appropriate solution is to create a PersistentVolumeClaim (PVC) on the GKE cluster. This method allows the application to access the configuration files stored on the NFS share directly from the volume. By using an ENTRYPOINT script, you can ensure that the service starts only after the configuration files have been properly accessed, providing a seamless and scalable approach for configuration management within Kubernetes. Additionally, this approach utilizes Kubernetes-native tools which enhance robustness and flexibility.
It's not necessary to mount NFS to each node in GKE. Just create PVC point to shared NFS, mount to container, and use configuration in ENTRYPOINT. Vote B
I am not convinced but it does seem to be best option among all options
vote C
B is correct
I think B is more suitable in this situation
B and C are valid, but B use native tools of Kubernetes, so is a best practice and easy to implement.
answer is B
The best answer here is B. Create a PersistentVolumeClaim on the GKE cluster. Access the configuration files from the volume and start the service using an ENTRYPOINT script. [1] Here's why: PersistentVolumeClaim (PVC): A PVC is the Kubernetes way to request storage. By creating a PVC that points to your NFS share, you ensure that your pods have access to the configuration files. This approach is more robust and scalable than copying files at startup. ENTRYPOINT Script: An ENTRYPOINT script is the ideal way to handle the startup logic. You can use it to: Mount the PVC volume. Verify that the configuration files are present. Start your application's main process.
B is correct.
B is more formal and standardized way to mount NFS onto the worker node compared to A where it asks us to create a startup script to mount the volume.
With PersisentVolumeClaim object, we can claim the volume what we need dynamically. The storage class will be defined by network administrator. Container/Pod needs to wait until it reads configuration from the mounted volume before serving traffic to its clients.
https://cloud.google.com/kubernetes-engine/docs/concepts/persistent-volumes. PersistentVolume resources are used to manage durable storage in a cluster. In GKE, a PersistentVolume is typically backed by a persistent disk. You can also use other storage solutions like NFS. Filestore is a NFS solution on Google Cloud
B and D are the main candidate answers Option B: allows the application to be stateless and have no dependencies on the filesystem of the host. D: is a good solution since it allows the application to access its configuration as soon as the application starts, without having to copy the configuration files into the container. But the best option is B, because it allows the application to be stateless and have no dependencies on the filesystem of the host. This approach is more flexible, makes it easy to update the configuration files, and reduces the size of the container image.
B is correct using default tools
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
B is the answer.