Inspecting Kubernetes Cluster Logs for Application Issues
Question
You are running a cluster on Kubernetes Engine (GKE) to serve a web application.
Users are reporting that a specific part of the application is not responding anymore.
You notice that all pods of your deployment keep restarting after 2 seconds.
The application writes logs to standard output.
You want to inspect the logs to find the cause of the issue.
Which approach can you take?
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D.B.
In this scenario, you are running a web application on Kubernetes Engine (GKE) and users are reporting that a specific part of the application is not responding. All pods of your deployment keep restarting after 2 seconds, and you want to inspect the logs to find the cause of the issue.
Option A: Review the Stackdriver logs for each Compute Engine instance that is serving as a node in the cluster.
This option is not the best approach because Stackdriver logs for Compute Engine instances do not capture the logs of the containers running inside those instances. Therefore, you would not be able to access the logs of your web application pods, which are running in Kubernetes.
Option B: Review the Stackdriver logs for the specific GKE container that is serving the unresponsive part of the application.
This option is a better approach since Stackdriver logs capture the logs of the containers running in GKE. You can filter the logs by container name or by the labels applied to your pods to find the logs for the specific container or application you want to inspect.
Option C: Connect to the cluster using gcloud credentials and connect to a container in one of the pods to read the logs.
This option is also a good approach. You can use the kubectl logs command to retrieve the logs of a container running in a pod. You will need to have the appropriate permissions and credentials to access the cluster and pods.
Option D: Review the Serial Port logs for each Compute Engine instance that is serving as a node in the cluster.
This option is not relevant to the issue at hand, as Serial Port logs do not contain application logs and are generally used for debugging and troubleshooting system-level issues.
Therefore, the best approach to inspect the logs to find the cause of the issue in this scenario is option B or C, depending on your preference and available access to the cluster.
