Troubleshooting logging in GKE

---

This page shows you how to investigate and resolve GKE logging related issues.

If you need additional assistance, reach out to Cloud Customer Care.

Missing cluster logs in Cloud Logging

Verify logging is enabled in the project

1. List enabled services:

   gcloud services list --enabled --filter="NAME=logging.googleapis.com"
   

   The following output indicates that logging is enabled for the project:

   NAME                    TITLE
   logging.googleapis.com  Cloud Logging API
   

   Optional: Check the logs in Logs Viewer to determine who disabled the API and when they disabled the API:

   protoPayload.methodName="google.api.serviceusage.v1.ServiceUsage.DisableService"
   protoPayload.response.services="logging.googleapis.com"
   

2. If logging is disabled, enable logging:

   gcloud services enable logging.googleapis.com
   

Verify logging is enabled on the cluster

1. List the clusters:

   gcloud container clusters list \
       --project=PROJECT_ID \
       '--format=value(name,loggingConfig.componentConfig.enableComponents)' \
       --sort-by=name | column -t
   

   Replace the following:

   • PROJECT_ID: your Google Cloud project ID.

   The output is similar to the following:

   cluster-1              SYSTEM_COMPONENTS
   cluster-2              SYSTEM_COMPONENTS;WORKLOADS
   cluster-3
   

   If the value for your cluster is empty, logging is disabled. For example, cluster-3 in this output has logging disabled.

2. Enable cluster logging if set to NONE:

   gcloud container clusters update CLUSTER_NAME  \
       --logging=SYSTEM,WORKLOAD \
       --location=COMPUTE_LOCATION
   

   Replace the following:

   • CLUSTER_NAME: the name of your cluster.
   • COMPUTE_LOCATION: the Compute Engine location for your cluster.

Verify nodes in the node pools have Cloud Logging access scope

One of the following scopes is required for nodes to write logs to Cloud Logging:

• https://www.googleapis.com/auth/logging.write
• https://www.googleapis.com/auth/cloud-platform
• https://www.googleapis.com/auth/logging.admin

1. Check the scopes configured on each node pool in the cluster:

   gcloud container node-pools list --cluster=CLUSTER_NAME \
       --format="table(name,config.oauthScopes)" \
       --location COMPUTE_LOCATION
   

   Replace the following:

   • CLUSTER_NAME: the name of your cluster.
   • COMPUTE_LOCATION: the Compute Engine location for your cluster.

   Migrate your workloads from the old node pool to the newly created node pool and monitor the progress.

2. Create new node pools with the correct logging scope:

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=COMPUTE_LOCATION \
       --scopes="gke-default"
   

   Replace the following:

   • CLUSTER_NAME: the name of your cluster.
   • COMPUTE_LOCATION: the Compute Engine location for your cluster.

Identify and fix permissions issues with writing logs

GKE uses IAM service accounts that are attached to your nodes to run system tasks like logging and monitoring. At a minimum, these node service accounts must have the Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) role on your project. By default, GKE uses the Compute Engine default service account, which is automatically created in your project, as the node service account.

If your organization enforces the iam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint, the default Compute Engine service account in your project might not automatically get the required permissions for GKE.

• To identify the issue, check for 401 errors in the system logging workload in your cluster:

  [[ $(kubectl logs -l k8s-app=fluentbit-gke -n kube-system -c fluentbit-gke | grep -cw "Received 401") -gt 0 ]] && echo "true" || echo "false"
  

  If the output is true, then the system workload is experiencing 401 errors, which indicate a lack of permissions. If the output is false, skip the rest of these steps and try a different troubleshooting procedure.

1. Find the name of the service account that your nodes use:

   console

   1. Go to the Kubernetes clusters page:

      Go to Kubernetes clusters

   2. In the cluster list, click the name of the cluster that you want to inspect.
   3. Depending on the cluster mode of operation, do one of the following:
      • For Autopilot mode clusters, in the Security section, find the Service account field.
      • For Standard mode clusters, do the following:
        1. Click the Nodes tab.
        2. In the Node pools table, click a node pool name. The Node pool details page opens.
        3. In the Security section, find the Service account field.

   If the value in the Service account field is default, your nodes use the Compute Engine default service account. If the value in this field is not default, your nodes use a custom service account. To grant the required role to a custom service account, see Use least privilege IAM service accounts.

   gcloud

   For Autopilot mode clusters, run the following command:

   gcloud container clusters describe CLUSTER_NAME \
       --location=LOCATION \
       --flatten=autoscaling.autoprovisioningNodePoolDefaults.serviceAccount

   For Standard mode clusters, run the following command:

   gcloud container clusters describe CLUSTER_NAME \
       --location=LOCATION \
       --format="table(nodePools.name,nodePools.config.serviceAccount)"

   If the output is default, your nodes use the Compute Engine default service account. If the output is not default, your nodes use a custom service account. To grant the required role to a custom service account, see Use least privilege IAM service accounts.

2. To grant the roles/container.defaultNodeServiceAccount role to the Compute Engine default service account, complete the following steps:

   console

   1. Go to the Welcome page:

      Go to Welcome

   2. In the Project number field, click content_copy Copy to clipboard.
   3. Go to the IAM page:

      Go to IAM

   4. Click person_add Grant access.
   5. In the New principals field, specify the following value:

      PROJECT_NUMBER-compute@developer.gserviceaccount.com

      Replace PROJECT_NUMBER with the project number that you copied.
   6. In the Select a role menu, select the Kubernetes Engine Default Node Service Account role.
   7. Click Save.

   gcloud

   1. Find your Google Cloud project number:

      gcloud projects describe PROJECT_ID \
          --format="value(projectNumber)"

      Replace PROJECT_ID with your project ID.

      The output is similar to the following:

      12345678901
      

   2. Grant the roles/container.defaultNodeServiceAccount role to the Compute Engine default service account:

      gcloud projects add-iam-policy-binding PROJECT_ID \
          --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
          --role="roles/container.defaultNodeServiceAccount"

      Replace PROJECT_NUMBER with the project number from the previous step.

Verify that Cloud Logging write API quotas have not been reached

Confirm that you have not reached API write quotas for Cloud Logging.

1. Go to the Quotas page in the Google Cloud console.

   Go to Quotas

2. Filter the table by "Cloud Logging API".

3. Confirm that you have not reached any of the quotas.

Debugging GKE logging issues with gcpdiag

If you are missing or getting incomplete logs from your GKE cluster, use the gcpdiag tool for troubleshooting.

gcpdiag is an open source tool. It is not an officially supported Google Cloud product. You can use the gcpdiag tool to help you identify and fix Google Cloud project issues. For more information, see the gcpdiag project on GitHub.

Google Cloud console

1. Complete and then copy the following command.

gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=GKE_NAME \
    --parameter location=LOCATION

2. Open the Google Cloud console and activate Cloud Shell.
Open Cloud console
3. Paste the copied command.
4. Run the gcpdiag command, which downloads the gcpdiag docker image, and then performs diagnostic checks. If applicable, follow the output instructions to fix failed checks.

Docker

You can run gcpdiag using a wrapper that starts gcpdiag in a Docker container. Docker or Podman must be installed.

1. Copy and run the following command on your local workstation.

   curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag

2. Execute the gcpdiag command.

   ./gcpdiag runbook gke/logs \
       --parameter project_id=PROJECT_ID \
       --parameter name=GKE_NAME \
       --parameter location=LOCATION

What's next

If you need additional assistance, reach out to Cloud Customer Care.