Question-21: Extreme persistent discs enable you to provide IOPS and capacity in a distinct manner, in addition to having a greater maximum number of IOPS and throughput. Extreme persistent discs are accessible in all zones. When you establish an extremely persistent disc, you have the option of selecting an IOPS level somewhere between 10,000 and 120,000, depending on how much IOPS performance you need. A web application that you want to serve is being managed by a cluster that is being operated on Kubernetes Engine (GKE). Users have reported that a certain section of the programme is no longer functioning as it should. You have observed that every pod in your deployment will automatically restart after every two seconds. Logs are sent to the standard output by the programme. You should investigate the logs to see what caused the problem you are experiencing. Which method would you recommend I use?
A. Examine the Stackdriver logs for each instance of Compute Engine that is participating in the cluster in its capacity as a node.
B. Review the Stackdriver logs for the specific GKE container that is serving the unresponsive part of the application.
C. You can read the logs by connecting to the cluster with your G Cloud credentials and then connecting to a container within one of the pods.
D. Examine the Serial Port logs for every instance of Compute Engine that is participating in the cluster and acting as a node.
Correct Answer
Get All 340 Questions and Answer for Google Professional Cloud Architect
: 2 Explanation: You don't need to connect to the container to view logs, you connect to stackdriver for this. Stackdriver Logging is independent and first needs to enable with GKE. Stackdriver Logging seems to be enabled by default for GKE. Looking here: For container and system logs, GKE deploys a per-node logging agent that reads container logs, adds helpful metadata, and then stores them. The logging agent checks for container logs in the following sources: Standard output and standard error logs from containerized processes. Review Stackdriver logs for specific GKE container that is serving the unresponsive part of the app. This is a most directly matching answer for this Q, since it reviews GKE container logs, by that advertising this Stackdriver feature. “For container and system logs, GKE deploys a per-node logging agent that reads container logs, adds helpful metadata, and then stores them. The logging agent checks for container logs in the following sources: • Standard output and standard error logs from containerized processes • kubelet and container runtime logs • Logs for system components, such as VM startup scripts� Originally we thought that Option-4 is a right answer, since we were confused with 2 seconds restart. But, that’s restart for Pod, not for Node (GCE) Option-4 – Review Serial Port logs for each Compute Engine instance, that is serving as the in the cluster. Serial Port output is standard feature of Compute Engine (which retains 1 MB most recent logs for analysis). But, it is irrelevant for Pod’s restart, caused by malfunction of some container.