Solución de problemas

En esta página, se muestran los pasos para solucionar problemas con Google Kubernetes Engine (GKE).

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

Depura recursos de Kubernetes

En el caso de los recursos de Kubernetes, si tienes un problema con lo siguiente:

Soluciona problemas con el comando kubectl

En esta sección, se incluyen pasos para solucionar problemas de varios tipos con el comando kubectl.

No se encuentra el comando kubectl

Si recibes un mensaje que indica que no se encontró el comando kubectl, reinstala el objeto binario kubectl y configura la variable de entorno $PATH.

  1. Instala el objeto binario kubectl mediante la ejecución del siguiente comando:

    gcloud components update kubectl

  2. Responde “sí” cuando el instalador te solicite modificar la variable de entorno $PATH. Si modificas esta variable, podrás usar los comandos kubectl sin necesidad de escribir la ruta completa.

    Como alternativa, agrega la siguiente línea a cualquier lugar donde tu shell almacene las variables de entorno, como ~/.bashrc (o ~/.bash_profile en macOS):

    export PATH=$PATH:/usr/local/share/google/google-cloud-sdk/bin/

  3. Ejecuta el siguiente comando para cargar el archivo actualizado. En el siguiente ejemplo, se usa .bashrc.

    source ~/.bashrc

    Si usas macOS, usa ~/.bash_profile en lugar de .bashrc.

Los comandos kubectl muestran el error “conexión rechazada”

Si los comandos kubectl muestran un error de “conexión rechazada”, debes configurar el contexto del clúster con el siguiente comando:

  gcloud container clusters get-credentials CLUSTER_NAME

Si tienes dudas sobre qué ingresar para CLUSTER_NAME, usa el siguiente comando para hacer una lista de tus clústeres:

  gcloud container clusters list

Error: Se agotó el tiempo de espera del comando kubectl

Si creaste un clúster y trataste de ejecutar el comando kubectl en él, pero se agotó el tiempo de espera, verás un error como el siguiente:kubectl

  • Unable to connect to the server: dial tcp IP_ADDRESS: connect: connection timed out
  • Unable to connect to the server: dial tcp IP_ADDRESS: i/o timeout.

Estos errores indican que kubectl no puede comunicarse con el plano de control del clúster.

Para resolver este problema, verifica y establece el contexto donde se establece el clúster y, luego, asegúrate de que haya conectividad con él:

  1. Ve a $HOME/.kube/config o ejecuta el comando kubectl config view para verificar que el archivo de configuración contenga el contexto del clúster y la dirección IP externa del plano de control.

  2. Configura las credenciales del clúster:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --project=PROJECT_ID

    Reemplaza lo siguiente:

    • CLUSTER_NAME: es el nombre de tu clúster.
    • COMPUTE_LOCATION: la ubicación de Compute Engine.
    • PROJECT_ID es el ID del proyecto en el que se creó el clúster de GKE.

  3. Si el clúster es un clúster de GKE privado, asegúrate de que su lista de redes autorizadas existentes incluya la IP saliente de la máquina desde la que intentas conectarte. Puedes encontrar las redes autorizadas existentes en Console o mediante la ejecución del siguiente comando:

    gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --project=PROJECT_ID \
    --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"

    Si la IP saliente de la máquina no se incluye en la lista de redes autorizadas del resultado del comando anterior, haz lo siguiente:

Error: Los comandos kubectl muestran el error “no se pudo negociar una versión de API”

Si los comandos kubectl muestran el error “no se pudo negociar una versión de API”, debes asegurarte de que kubectl tenga credenciales de autenticación:

  gcloud auth application-default login

Problema: Los comandos kubectl logs, attach, exec y port-forward dejan de responder

Si los comandos kubectl, logs, attach, exec o port-forward dejan de responder, por lo general, el servidor de la API no puede comunicarse con los nodos.

Primero, verifica si tu clúster tiene algún nodo. Si reduces la cantidad de nodos en tu clúster a cero, los comandos no funcionarán. Para resolver este problema, cambia el tamaño del clúster para tener al menos un nodo.

Si tu clúster tiene al menos un nodo, verifica si usas SSH o túneles de proxy de Konnectivity para habilitar la comunicación segura. En las siguientes secciones, se analizan los pasos para solucionar problemas específicos de cada enfoque:

Soluciona problemas de SSH

Si usas SSH, GKE guarda un archivo de clave pública SSH en los metadatos del proyecto de Compute Engine. Todas las VM de Compute Engine que usan imágenes proporcionadas por Google verifican con regularidad los metadatos comunes del proyecto y los metadatos de la instancia para las claves SSH a fin de agregarlos a la lista de usuarios autorizados de la VM. GKE también agrega una regla de firewall a la red de Compute Engine, lo que permite el acceso SSH desde la dirección IP del plano de control a cada nodo en el clúster.

Los problemas con SSH pueden deberse a lo siguiente:

  • Las reglas de firewall de la red no permiten el acceso de SSH desde el plano de control.

    Todas las redes de Compute Engine se crean con una regla de firewall llamada default-allow-ssh que permite el acceso SSH desde todas las direcciones IP (mediante la solicitud de una clave privada válida). GKE también inserta una regla SSH para cada clúster público con el formato gke-CLUSTER_NAME-RANDOM_CHARACTERS-ssh que permite el acceso SSH de forma específica desde el plano de control del clúster hacia los nodos del clúster.

    Si no existe ninguna de estas reglas, el plano de control no puede abrir los túneles SSH.

    Para verificar que esta sea la causa del problema, comprueba si tu configuración tiene estas reglas.

    Para resolver este problema, identifica la etiqueta que se encuentra en todos los nodos del clúster y, luego, vuelve a agregar una regla de firewall que permita el acceso a las VMs con esa etiqueta desde la dirección IP del plano de control.

  • La entrada de metadatos comunes del proyecto para ssh-keys está llena.

    Si la entrada de metadatos del proyecto llamada "llaves SSH" está cerca del límite de tamaño máximo, GKE no puede agregar su propia llave SSH para abrir túneles SSH.

    Para verificar que este es el problema, verifica la longitud de la lista de llaves SSH. Para ver los metadatos del proyecto, ejecuta el siguiente comando y, de manera opcional, incluye la marca --project:

    gcloud compute project-info describe [--project=PROJECT_ID]

    Para resolver este problema, borra algunas de las llaves SSH que ya no sean necesarias.

  • Estableciste un campo de metadatos con la clave “ssh-keys” en las VM del clúster.

    El agente de nodo en las VM prefiere claves SSH por instancia en vez de claves SSH por proyecto completo, por lo que, si estableciste claves SSH de forma específica en los nodos del clúster, los nodos no respetaran la clave SSH del plano de control en los metadatos del proyecto.

    Para verificar que este es el problema, ejecuta gcloud compute instances describe VM_NAME y busca un campo ssh-keys en los metadatos.

    Para solucionar el problema, borra las claves SSH por instancia de los metadatos de la instancia.

Soluciona problemas de proxy de Konnectivity

Para determinar si tu clúster usa el proxy de Konnectivity, verifica la siguiente implementación del sistema:

  kubectl get deployments konnectivity-agent --namespace kube-system

Los problemas con el proxy de Konnectivity pueden deberse a lo siguiente:

  • Las reglas de firewall de la red no permiten el acceso del agente de Konnectivity al plano de control.

    Durante la creación del clúster, los Pods del agente de Konnectivity establecen y mantienen una conexión con el plano de control en el puerto 8132. Cuando se ejecuta uno de los comandos kubectl, el servidor de la API usa esta conexión para comunicarse con el clúster.

    Si las reglas de firewall de la red contienen reglas de denegación de salida, puede impedir que el agente se conecte.

    Para verificar que esta sea la causa del problema, verifica las reglas de firewall de tu red para ver si contienen reglas de denegación de salida.

    Para resolver este problema, permite el tráfico de salida al plano de control del clúster en el puerto 8132. (En comparación, el servidor de la API usa 443).

  • La política de red del clúster bloquea la entrada del espacio de nombres kube-system al espacio de nombres workload.

    Estas características no se requieren para el funcionamiento correcto del clúster. Si prefieres mantener el acceso exterior bloqueado para la red del clúster, ten en cuenta que las características como estas no funcionarán.

    Para verificar que esta sea la causa del problema, ejecuta el siguiente comando para encontrar las políticas de red en el espacio de nombres afectado:

    kubectl get networkpolicy --namespace AFFECTED_NAMESPACE

    Para resolver este problema, agrega lo siguiente al campo spec.ingress de las políticas de red:

    - from:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: kube-system
    podSelector:
      matchLabels:
        k8s-app: konnectivity-agent

Soluciona problemas de error 4xx

En las siguientes secciones, encontrarás ayuda para solucionar los errores 400, 401, 403 y 404, y los errores de autenticación y autorización relacionados.

Problema: Errores de autenticación y autorización para conectarte a clústeres de GKE

Cuando te conectas a clústeres de GKE, puedes obtener un error de autenticación y autorización con el código de estado HTTP 401 (no autorizado). Este problema puede ocurrir cuando intentas ejecutar un comando kubectl en tu clúster de GKE desde un entorno local.

La causa de este problema podría ser una de las siguientes:

  • El complemento de autenticación gke-gcloud-auth-plugin no está instalado ni configurado de forma correcta.
  • No tienes los permisos para conectarte al servidor de la API del clúster y ejecutar comandos de kubectl.

Para diagnosticar la causa, sigue los pasos que se indican en las siguientes secciones:

  1. Conéctate al clúster mediante curl
  2. Configura el complemento en kubeconfig

Conéctate al clúster mediante curl.

Para diagnosticar la causa del error de autenticación y autorización, conéctate al clúster con curl. Mediante curl, se omiten la CLI de kubectl y el complemento gke-gcloud-auth-plugin.

  1. Establece las variables de entorno:

    APISERVER=https://$(gcloud container clusters describe CLUSTER_NAME --location=COMPUTE_LOCATION --format "value(endpoint)")
TOKEN=$(gcloud auth print-access-token)

  2. Verifica que tu token de acceso sea válido:

    curl https://oauth2.googleapis.com/tokeninfo?access_token=$TOKEN

  3. Intenta conectarte al extremo principal de la API en el servidor de la API:

    gcloud container clusters describe CLUSTER_NAME --location=COMPUTE_LOCATION --format "value(masterAuth.clusterCaCertificate)" | base64 -d > /tmp/ca.crt
curl -s -X GET "${APISERVER}/api/v1/namespaces" --header "Authorization: Bearer $TOKEN" --cacert /tmp/ca.crt

    Si el comando curl se ejecuta de forma correcta, verifica si el complemento es la causa con los pasos que se indican en la sección Configura el complemento en kubeconfig.

    Si el comando curl falla con un resultado similar al siguiente, significa que no tienes los permisos correctos para acceder al clúster:

    {
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "Unauthorized",
"reason": "Unauthorized",
"code": 401
}

Para resolver este problema, obtén los permisos correctos para acceder al clúster.

Configura el uso del complemento en kubeconfig

Si recibes errores de autenticación y autorización cuando te conectas a tus clústeres, pero pudiste conectarte al clúster con curl, asegúrate de poder acceder a tu clúster sin necesidad del complemento gke-gcloud-auth-plugin.

Para resolver este problema, configura tu entorno local para ignorar el objeto binario gke-gcloud-auth-plugin cuando se autentique en el clúster. En los clientes de Kubernetes que ejecutan la versión 1.25 y posteriores, el objeto binario gke-gcloud-auth-plugin es obligatorio, por lo que debes usar la versión 1.24 o anterior de la CLI de kubectl.

Sigue estos pasos para acceder a tu clúster sin necesidad del complemento:

  1. Instala la versión 1.24 de la CLI de kubectl mediante curl:

    curl -LO https://dl.k8s.io/release/v1.24.0/bin/linux/amd64/kubectl

    Puedes usar cualquier versión 1.24 o anterior de la CLI de kubectl.

  2. Abre el archivo de secuencia de comandos de inicio de la shell, como .bashrc para la shell de Bash, en un editor de texto:

    vi ~/.bashrc

    Si usas MacOS, usa ~/.bash_profile en lugar de .bashrc en estas instrucciones.

  3. Agrega la siguiente línea al archivo y guárdala:

    export USE_GKE_GCLOUD_AUTH_PLUGIN=False

  4. Ejecuta la secuencia de comandos de inicio:

    source ~/.bashrc

  5. Obtén credenciales para el clúster, que configura el archivo .kube/config:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=COMPUTE_LOCATION

    Reemplaza lo siguiente:

  6. Ejecuta un comando kubectl:

    kubectl cluster-info

Si recibes un error 401 o un error de autorización similar cuando ejecutas estos comandos, asegúrate de tener los permisos correctos y, luego, vuelve a ejecutar el paso que mostró el error.

Error 400: El grupo de nodos requiere recreación

Un error 400, el grupo de nodos requiere recreación, se ve de la siguiente manera:

  ERROR: (gcloud.container.clusters.update) ResponseError: code=400, message=Node pool "test-pool-1" requires recreation.

Este error ocurre cuando intentas realizar una acción que vuelve a crear el plano de control y los nodos. Por ejemplo, este error puede ocurrir cuando completas una rotación de credenciales en curso.

En el backend, los grupos de nodos están marcados para su recreación, pero la operación de recreación real puede tomar un tiempo en comenzar. Por lo tanto, la operación falla porque GKE aún no volvió a crear uno o más grupos de nodos en el clúster.

Para solucionar este problema, realiza una de las siguientes acciones:

  • Espera a que se realice la recreación. Esto puede tardar horas, días o semanas, según factores como los períodos de mantenimiento y las exclusiones existentes.

  • Inicia de forma manual una recreación de los grupos de nodos afectados mediante el inicio de una actualización de la versión a la misma versión que el plano de control.

    Para iniciar una recreación, ejecuta el siguiente comando:

    gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=POOL_NAME

    Una vez completada la actualización, vuelve a intentar la operación.

Error 403: Permisos insuficientes

Un error 403, permisos insuficientes, similar al siguiente:

  ERROR: (gcloud.container.clusters.get-credentials) ResponseError: code=403, message=Required "container.clusters.get" permission(s) for "projects/<your-project>/locations/<region>/clusters/<your-cluster>".

Este error ocurre cuando intentas conectarte a un clúster de GKE mediante gcloud container clusters get-credentials, pero la cuenta no tiene permiso para acceder al servidor de la API de Kubernetes.

Para solucionar este problema, haz lo siguiente:

  1. Identifica la cuenta que tiene el problema de acceso:

    gcloud auth list

  2. Otorga el acceso requerido a la cuenta mediante las instrucciones que aparecen en Autenticar en el servidor de la API de Kubernetes.

Error 403: Se agotó el presupuesto de reintentos

El siguiente error ocurre cuando intentas crear un clúster de GKE:

Error: googleapi: Error 403: Retry budget exhausted: Google Compute Engine:
Required permission 'PERMISSION_NAME' for 'RESOURCE_NAME'.

En este mensaje de error, se aplican las siguientes variables:

  • PERMISSION_NAME: Es el nombre de un permiso, como compute.regions.get.
  • RESOURCE_NAME: Es la ruta de acceso al recurso de Google Cloud al que intentaste acceder, como una región de Compute Engine.

Este error se produce si la cuenta de servicio de IAM adjunta al clúster no tiene los permisos mínimos necesarios para crearlo.

Para solucionar este problema, haz lo siguiente:

  1. Crea o modifica una cuenta de servicio de IAM para tener todos los permisos necesarios para ejecutar un clúster de GKE. Para obtener instrucciones, consulta Usa cuentas de servicio de IAM con privilegios mínimos.
  2. Especifica la cuenta de servicio de IAM actualizada en el comando de creación del clúster con la marca --service-account. Para obtener instrucciones, consulta Crea un clúster de Autopilot.

Como alternativa, omite la marca --service-account para permitir que GKE use la cuenta de servicio predeterminada de Compute Engine en el proyecto, que tiene los permisos necesarios de forma predeterminada.

Error 404: Recurso “no encontrado” cuando se llama a los comandos gcloud container

Si recibes un error 403, recurso no encontrado, cuando llames a los comandos gcloud container, corrige el problema volviendo a autenticarte en Google Cloud CLI:

  gcloud auth login

Error 400/403: Faltan permisos de edición en una cuenta

Si falta el permiso de edición en una cuenta (error 400 o 403), se indica que se borró o editó manualmente uno de los siguientes elementos:

Cuando habilitas la API de Compute Engine o la API de Kubernetes Engine, Google Cloud crea las siguientes cuentas de servicio y agentes:

  • Cuenta de servicio predeterminada de Compute Engine con permisos de edición en tu proyecto.
  • Agente de servicio de las APIs de Google con permisos de edición en tu proyecto.
  • Cuenta de servicio de Google Kubernetes Engine con el rol de Agente de servicio de Kubernetes Engine en tu proyecto.

La creación de clústeres y todas las funciones de administración fallarán si, en algún momento, alguien edita esos permisos, quita las vinculaciones de roles del proyecto, quita la cuenta de servicio por completo o inhabilita la API.

Para verificar si la cuenta de servicio de Google Kubernetes Engine tiene el rol de Agente de servicio de Kubernetes Engine asignado en el proyecto, sigue estos pasos:

  1. Usa el siguiente patrón para calcular el nombre de tu cuenta de servicio de Google Kubernetes Engine:

    service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

    Reemplaza PROJECT_NUMBER por el número del proyecto.

  2. Verifica que tu cuenta de servicio de Google Kubernetes Engine aún no tenga el rol de Agente de servicio de Kubernetes Engine asignado en el proyecto. En este comando, reemplaza PROJECT_ID por el ID de tu proyecto:

    gcloud projects get-iam-policy PROJECT_ID

Para solucionarlo, haz lo siguiente,

  • Si alguien quitó el rol de Agente de servicio de Kubernetes Engine de la cuenta de servicio de Google Kubernetes Engine, vuelve a agregarlo.

  • De lo contrario, sigue las instrucciones que se indican a continuación para volver a habilitar la API de Kubernetes Engine, así, se restablecerán las cuentas de servicio y permisos de forma correcta.

Console

  1. Ve a la página API y servicios en la consola de Google Cloud.

    Ir a APIs y servicios.

  2. Elige tu proyecto.

  3. Haga clic en Habilitar API y servicios.

  4. Busca Kubernetes y, luego, selecciona la API de los resultados de la búsqueda.

  5. Haz clic en Habilitar. Si habilitaste la API antes, primero debes inhabilitarla y, luego, habilitarla de nuevo. La habilitación de la API y los servicios relacionados puede tomar varios minutos.

gcloud

Ejecuta el siguiente comando en gcloud CLI:

PROJECT_NUMBER=$(gcloud projects describe "PROJECT_ID"
    --format 'get(projectNumber)')
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:service-${PROJECT_NUMBER?}@container-engine-robot.iam.gserviceaccount.com" \
    --role roles/container.serviceAgent

Soluciona problemas de creación de clústeres de GKE

Error CONDITION_NOT_MET: Restricción de constraints/compute.vmExternalIpAccess violada

Tienes la restricción de la política de la organización constraints/compute.vmExternalIpAccess configurada en Deny All o para restringir las IP externas a instancias de VM específicas en el nivel de organización, carpeta o proyecto en el que intentas crear un clúster de GKE público.

Cuando creas clústeres de GKE públicos, las VMs de Compute Engine subyacentes, que conforman los nodos trabajadores de este clúster, tienen asignadas direcciones IP externas. Si configuras la restricción de la política de la organización constraints/compute.vmExternalIpAccess como Deny All o para restringir IP externas a instancias de VM específicas, la política evitará que los nodos trabajadores de GKE obtengan direcciones IP externas, lo que da como resultado la falla de creación del clúster.

Para encontrar los registros de la operación de creación de clústeres, puedes revisar los Registros de auditoría de operaciones de clústeres de GKE mediante el Explorador de registros con una búsqueda similar a la siguiente:

resource.type="gke_cluster"
logName="projects/test-last-gke-sa/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.methodName="google.container.v1beta1.ClusterManager.CreateCluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.project_id="PROJECT_ID"

Para resolver este problema, asegúrate de que la política vigente de la restricción constraints/compute.vmExternalIpAccess sea Allow All en el proyecto en el que intentas crear un clúster público de GKE. Consulta Restringe direcciones IP externas a instancias de VM específicas para obtener información sobre cómo trabajar con esta restricción. Después de establecer la restricción en Allow All, borra el clúster con errores y crea uno nuevo. Esto es necesario porque no es posible reparar el clúster con errores.

Soluciona problemas de cargas de trabajo implementadas

GKE muestra un error si existen problemas con los pods de una carga de trabajo. Puedes comprobar el estado de un pod mediante la herramienta de línea de comandos de kubectl o la consola de Google Cloud.

kubectl

Para ver todos los pods en ejecución en tu clúster, ejecuta el comando siguiente:

kubectl get pods

Resultado:

NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

Para obtener más información sobre un pod específico, ejecuta el siguiente comando:

kubectl describe pod POD_NAME

Reemplaza POD_NAME con el nombre del pod que desees.

Console

Sigue los siguientes pasos:

  1. Ve a la página Cargas de trabajo en la consola de Google Cloud.

    Ir a Cargas de trabajo

  2. Selecciona la carga de trabajo deseada. La pestaña Descripción general muestra el estado de la carga de trabajo.

  3. En la sección Pods administrados, haz clic en el mensaje de estado de error.

En las secciones siguientes, se explican algunos errores comunes que muestran las cargas de trabajo y cómo resolverlos.

Error: CrashLoopBackOff

CrashLoopBackOff indica que un contenedor falla repetidas veces después de reiniciarse. Un contenedor puede fallar por varias razones y verificar los registros de un pod puede ayudar a solucionar la causa del problema.

De forma predeterminada, los contenedores que fallan se reinician con una demora exponencial limitada a cinco minutos. Puedes cambiar este comportamiento si configuras el campo restartPolicy de la especificación del pod de la implementación como spec: restartPolicy. El valor predeterminado del campo es Always.

Puedes solucionar los errores CrashLoopBackOff con la consola de Google Cloud:

  1. Ve a la guía interactiva de Pods en un bucle de fallas:

    Ir a la guía

  2. En Clúster, ingresa el nombre del clúster en el que deseas solucionar problemas.

  3. En Espacio de nombres, ingresa el espacio de nombres con el que deseas solucionar problemas.

  4. (Opcional) Crea una alerta que te notifique sobre errores CrashLoopBackOff futuros:

    1. En la sección Sugerencias para mitigaciones futuras, selecciona Crear una alerta.

Inspecciona registros

Puedes averiguar por qué el contenedor de tu pod falla mediante la herramienta de línea de comandos de kubectl o la consola de Google Cloud.

kubectl

Para ver todos los pods en ejecución en tu clúster, ejecuta el comando siguiente:

kubectl get pods

Busca el pod con el error CrashLoopBackOff.

Para obtener los registros del pod, ejecuta el siguiente comando:

kubectl logs POD_NAME

Reemplaza POD_NAME con el nombre del pod problemático.

También puedes pasar la marca -p para obtener los registros de la instancia anterior del contenedor de un pod, si existe.

Console

Sigue los siguientes pasos:

  1. Ve a la página Cargas de trabajo en la consola de Google Cloud.

    Ir a Cargas de trabajo

  2. Selecciona la carga de trabajo deseada. La pestaña Descripción general muestra el estado de la carga de trabajo.

  3. En la sección Pods administrados, haz clic en el pod problemático.

  4. En el menú de pods, haz clic en la pestaña Registros.

Verifica el “Código de salida” del contenedor que falla

Para encontrar el código de salida, realiza las siguientes tareas:

  1. Ejecuta el siguiente comando:

    kubectl describe pod POD_NAME

    Reemplaza POD_NAME con el nombre del pod.

  2. Revisa el valor en el campo containers: CONTAINER_NAME: last state: exit code:

    • Si el código de salida es 1, el contenedor falló debido a que la aplicación falló.
    • Si el código de salida es 0, verifica por cuánto tiempo se ejecutó la app.

    Los contenedores se detienen cuando el proceso principal de la aplicación se detiene. Si la app finaliza la ejecución con mucha rapidez, es posible que el contenedor continúe con el proceso de reinicio.

Conéctate a un contenedor en ejecución

Abre una shell al pod:

kubectl exec -it POD_NAME -- /bin/bash

Si hay más de un contenedor en tu pod, agrega -c CONTAINER_NAME.

Ahora, puedes ejecutar comandos bash desde el contenedor: puedes probar la red o verificar si tienes acceso a los archivos o a las bases de datos que usa tu aplicación.

Errores: ImagePullBackOff y ErrImagePull

ImagePullBackOff y ErrImagePull indican que la imagen que usa un contenedor no se puede cargar desde el registro de imágenes.

Puedes verificar este problema mediante la consola de Google Cloud o la herramienta de línea de comandos de kubectl.

kubectl

Para obtener más información sobre una imagen de contenedor de un Pod, ejecuta el comando siguiente:

kubectl describe pod POD_NAME

Console

Sigue los siguientes pasos:

  1. Ve a la página Cargas de trabajo en la consola de Google Cloud.

    Ir a Cargas de trabajo

  2. Selecciona la carga de trabajo deseada. La pestaña Descripción general muestra el estado de la carga de trabajo.

  3. En la sección Pods administrados, haz clic en el pod problemático.

  4. En el menú de pod, haz clic en la pestaña Eventos.

Problema: Si no se encuentra la imagen

Si tu imagen no se encuentra:

  1. Verifica que el nombre de la imagen sea correcto.
  2. Verifica que la etiqueta de la imagen sea correcta. (Intenta extraer la última imagen con :latest o sin etiqueta).
  3. Si la imagen tiene una ruta de registro completa, verifica que exista en el registro Docker que usas. Si proporcionas solo el nombre de la imagen, verifica el registro de Docker Hub.

  4. Prueba extraer la imagen de Docker de manera manual:

    • Establece una conexión SSH al nodo:

      Por ejemplo, para establecer una conexión SSH a una VM, ejecuta lo siguiente:

      gcloud compute ssh VM_NAME --zone=ZONE_NAME

      Reemplaza lo siguiente:

    • Ejecuta docker-credential-gcr configure-docker. Con este comando, se genera un archivo de configuración en /home/[USER]/.docker/config.json. Asegúrate de que este archivo incluya el registro de la imagen en el campo credHelpers. Por ejemplo, el siguiente archivo incluye información de autenticación para imágenes alojadas en asia.gcr.io, eu.gcr.io, gcr.io, marketplace.gcr.io y us.gcr.io:

      {
  "auths": {},
  "credHelpers": {
    "asia.gcr.io": "gcr",
    "eu.gcr.io": "gcr",
    "gcr.io": "gcr",
    "marketplace.gcr.io": "gcr",
    "us.gcr.io": "gcr"
  }
}

    • Ejecuta docker pull IMAGE_NAME.

    Si esa opción funciona, necesitarás especificar ImagePullSecrets en un pod. Los pods solo pueden hacer referencia a los secretos de extracción de imagen en su propio espacio de nombres, por lo que este proceso puede realizarse una vez por espacio de nombres.

Error: Permiso denegado

Si encuentras el error “permiso denegado” o “sin acceso de extracción”, verifica que accediste y tienes acceso a la imagen. Prueba uno de los siguientes métodos según el registro en el que alojas tus imágenes.

Artifact Registry

Si la imagen está en Artifact Registry, la cuenta de servicio del grupo de nodos necesita acceso de lectura al repositorio que contiene la imagen.

Otorga el rol artifactregistry.reader a la cuenta de servicio:

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --location=REPOSITORY_LOCATION \
    --member=serviceAccount:SERVICE_ACCOUNT_EMAIL \
    --role="roles/artifactregistry.reader"

Reemplaza lo siguiente:

  • REPOSITORY_NAME: Es el nombre de tu repositorio de Artifact Registry.
  • REPOSITORY_LOCATION: Es la región de tu repositorio de Artifact Registry.
  • SERVICE_ACCOUNT_EMAIL: La dirección de correo electrónico de la cuenta de servicio de IAM asociada con tu grupo de nodos.

Registro privado

Si la imagen está en un registro privado, es posible que necesites claves para acceder a las imágenes. Consulta Usa registros privados para obtener más información.

Error 401 Sin autorización: No se pueden extraer imágenes del repositorio de Container Registry privado

Un error similar al siguiente puede ocurrir cuando extraes una imagen de un repositorio de Container Registry privado:

gcr.io/PROJECT_ID/IMAGE:TAG: rpc error: code = Unknown desc = failed to pull and
unpack image gcr.io/PROJECT_ID/IMAGE:TAG: failed to resolve reference
gcr.io/PROJECT_ID/IMAGE]:TAG: unexpected status code [manifests 1.0]: 401 Unauthorized

Warning  Failed     3m39s (x4 over 5m12s)  kubelet            Error: ErrImagePull
Warning  Failed     3m9s (x6 over 5m12s)   kubelet            Error: ImagePullBackOff
Normal   BackOff    2s (x18 over 5m12s)    kubelet            Back-off pulling image

  1. Identifica el nodo que ejecuta el Pod:

    kubectl describe pod POD_NAME | grep "Node:"

  2. Verifica que el nodo tenga el permiso de almacenamiento:

    gcloud compute instances describe NODE_NAME \
    --zone=COMPUTE_ZONE --format="flattened(serviceAccounts[].scopes)"

    El permiso de acceso del nodo debe contener al menos uno de los siguientes elementos:

    serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/devstorage.read_only
serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/cloud-platform

  3. Vuelve a crear el grupo de nodos al que pertenece el nodo con suficiente permiso. No puedes modificar los nodos existentes, debes volver a crear el nodo con el permiso correcto.

    • Recomendado: Crea un grupo de nodos nuevo con el permiso gke-default:

      gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --scopes="gke-default"

    • Crea un grupo de nodos nuevo solo con el permiso de almacenamiento:

      gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --scopes="https://www.googleapis.com/auth/devstorage.read_only"

Error: Pod no programable

PodUnschedulable indica que tu pod no se puede programar debido a que los recursos son insuficientes o que hay algún error de configuración.

Si tienes configurado el clúster de GKE para enviar el servidor de la API de Kubernetes y las métricas del programador de Kubernetes a Cloud Monitoring, puedes encontrar más información sobre estos errores en métricas del programador y métricas del servidor de la API .

Puedes solucionar los errores PodUnschedulable con la consola de Google Cloud:

  1. Ve a la guía interactiva de Pods no programables:

    Ir a la guía

  2. En Clúster, ingresa el nombre del clúster en el que deseas solucionar problemas.

  3. En Espacio de nombres, ingresa el espacio de nombres con el que deseas solucionar problemas.

  4. (Opcional) Crea una alerta que te notifique sobre errores PodUnschedulable futuros:

    1. En la sección Sugerencias para mitigaciones futuras, selecciona Crear una alerta.

Error: Recursos insuficientes

Puedes encontrar un error que indique una falta de CPU, memoria o algún otro recurso. Por ejemplo: “No hay nodos disponibles que coincidan con todos los predicados: CPU insuficiente (2)”, que indica que no hay CPU suficiente disponible en dos nodos para cumplir con las solicitudes de un pod.

Si las solicitudes de recursos de tu pod superan las de un solo nodo de cualquier grupo de nodos apto, GKE no programa el pod ni activa el escalamiento vertical para agregar un nodo nuevo. Para que GKE programe el Pod, debes solicitar menos recursos para el Pod o crear un grupo de nodos nuevo con recursos suficientes.

También puedes habilitar el aprovisionamiento automático de nodos para que GKE pueda crear de forma automática grupos de nodos con nodos en los que puedan ejecutarse los Pods no programados.

La solicitud de CPU predeterminada es de 100m o el 10% de una CPU (o un núcleo). Si deseas solicitar más o menos recursos, detalla el valor en la especificación del Pod en spec: containers: resources: requests.

Error: MatchNodeSelector

MatchNodeSelector indica que no hay nodos que coincidan con el selector de etiquetas del pod.

Para verificar esto, revisa las etiquetas que se especifican en el campo nodeSelector de la especificación del pod, debajo de spec: nodeSelector.

Para ver cómo están etiquetados los nodos en tu clúster, ejecuta el siguiente comando:

kubectl get nodes --show-labels

Para adjuntar una etiqueta a un nodo, ejecuta el siguiente comando:

kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

Reemplaza lo siguiente:

  • NODE_NAME: el nodo deseado.
  • LABEL_KEY: la clave de la etiqueta.
  • LABEL_VALUE: el valor de la etiqueta.

Para obtener más información, consulta asigna Pods a nodos.

Error: PodToleratesNodeTaints

PodToleratesNodeTaints indica que el Pod no se puede programar en ningún nodo porque, por el momento, ningún nodo tolera su taint de nodo.

Para verificar que este sea el caso, ejecuta el comando siguiente:

kubectl describe nodes NODE_NAME

En el resultado, verifica el campo Taints, que enumera pares clave-valor y efectos de programación.

Si el efecto enumerado es NoSchedule, entonces no se puede programar ningún pod en ese nodo, a menos que tenga una tolerancia coincidente.

Una manera de resolver este problema es quitar el taint. Por ejemplo, para quitar un taint NoSchedule, ejecuta el siguiente comando:

kubectl taint nodes NODE_NAME key:NoSchedule-

Error: PodFitsHostPorts

PodFitsHostPorts indica que un puerto que un nodo quiere usar ya está en uso.

Para resolver este problema, verifica el valor hostPort de la especificación del pod en spec: containers: ports: hostPort. Es posible que debas cambiar este valor para otro puerto.

Error: No tiene disponibilidad mínima

Si un nodo tiene recursos adecuados, pero todavía ves el mensaje Does not have minimum availability, comprueba el estado del pod. Si el estado es SchedulingDisabled o Cordoned, el nodo no puede programar pods nuevos. Puedes verificar el estado de un nodo con la consola de Google Cloud o la herramienta de línea de comandos de kubectl.

kubectl

Para obtener los estados de los nodos, ejecuta el siguiente comando:

kubectl get nodes

Para habilitar la programación en el nodo, ejecuta lo siguiente:

kubectl uncordon NODE_NAME

Console

Sigue los siguientes pasos:

  1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.

    Ir a Google Kubernetes Engine

  2. Selecciona el clúster deseado. La pestaña Nodos muestra los nodos y su estado.

Para habilitar la programación en el nodo, realiza los pasos siguientes:

  1. En la lista, haz clic en el nodo deseado.

  2. En Detalles del nodo, haz clic en el botón Desvincular.

Error: Se alcanzó el límite máximo de Pods por nodo

Si todos los nodos del clúster alcanzan el límite de máximo de Pods por nodo, los Pods se detendrán en estado no programable. En la pestaña Eventos del Pod, verás un mensaje que incluye la frase Too many pods.

  1. Verifica la configuración de Maximum pods per node desde la pestaña Nodos en los detalles del clúster de GKE en la consola de Google Cloud.

  2. Obtén una lista de nodos:

    kubectl get nodes

  3. Para cada nodo, verifica la cantidad de Pods que se ejecutan en el nodo:

    kubectl get pods -o wide | grep NODE_NAME | wc -l

  4. Si se alcanza el límite, agrega un grupo de nodos nuevo o agrega nodos adicionales al grupo existente.

Problema: Se alcanzó el tamaño máximo del grupo de nodos con el escalador automático del clúster habilitado

Si el grupo de nodos alcanzó su tamaño máximo según la configuración del escalador automático de clústeres, GKE no activa el escalamiento vertical para el Pod que, de lo contrario, se programaría con este grupo de nodos. Si quieres que el pod se programe con este grupo de nodos, cambia la configuración del escalador automático de clústeres.

Problema: Tamaño máximo del grupo de nodos alcanzado con el escalador automático del clúster inhabilitado

Si el grupo de nodos alcanzó la cantidad máxima de nodos y el escalador automático de clústeres está inhabilitado, GKE no puede programar el Pod con el grupo de nodos. Aumenta el tamaño de tu grupo de nodos o habilita el escalador automático del clúster para que GKE cambie el tamaño del clúster de forma automática.

Error: PersistentVolumeClaims no vinculados

Unbound PersistentVolumeClaims indica que el pod hace referencia a una PersistentVolumeClaim que no está vinculada. Este error puede ocurrir si no se pudo aprovisionar el PersistentVolume. Puedes verificar que el aprovisionamiento falló, si obtienes los eventos de la PersistentVolumeClaim y los examinas en busca de errores.

Para obtener los eventos, ejecuta el siguiente comando:

kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0

Reemplaza lo siguiente:

  • STATEFULSET_NAME: el nombre del objeto StatefulSet.
  • PVC_NAME: el nombre del objeto PersistentVolumeClaim.

Esto también puede ocurrir si hubo un error de configuración durante el aprovisionamiento previo manual de un PersistentVolume y su vinculación a una PersistentVolumeClaim. Puedes intentar aprovisionar el volumen de nuevo.

Error: Cuota insuficiente

Verifica que tu proyecto tenga suficiente cuota de Compute Engine para que GKE escale verticalmente tu clúster. Si GKE intenta agregar un nodo a tu clúster para programar el pod y escalar verticalmente superaría la cuota disponible de tu proyecto, recibirás el mensaje de error scale.up.error.quota.exceeded.

Para obtener más información, consulta Errores de ScaleUp.

Problema: APIs obsoletas

Asegúrate de no usar APIs obsoletas que se quitan con la versión secundaria de tu clúster. Para obtener más información, consulta Bajas de GKE.

Error: “no se pudo asignar para el rango 0: no hay direcciones IP en el rango configurado”

La versión 1.18.17 y posteriores de GKE solucionaron un problema en el que los eventos de memoria insuficiente (OOM) generaban una expulsión incorrecta del Pod si el Pod se borró antes de que se iniciaran sus contenedores. Esta expulsión incorrecta podría provocar Pods huérfanos que continuaron teniendo direcciones IP reservadas del rango de nodos asignado. Con el tiempo, GKE se quedó sin direcciones IP para asignar a los Pods nuevos debido a la compilación de Pods huérfanos. Esto generó el mensaje de error failed to allocate for range 0: no IP addresses in range set, porque el rango de nodos asignado no tenía IP disponibles para asignar a Pods nuevos.

Para resolver este problema, actualiza tu clúster y los grupos de nodos a la versión 1.18.17 o posterior de GKE.

Para evitar este problema y resolverlo en clústeres con versiones de GKE anteriores a la 1.18.17, aumenta tus límites de recursos a fin de evitar eventos de OOM en el futuro y, luego, recupera las direcciones IP mediante quitar los Pods huérfanos.

También puedes ver las estadísticas de uso de direcciones IP de GKE.

Quita los Pods huérfanos de los nodos afectados

Puedes quitar los Pods huérfanos si vacías el nodo, actualizas el grupo de nodos o mueves los directorios afectados.

Desvío del nodo (recomendado)

  1. Acordona el nodo para evitar que se programen Pods nuevos en él:

     kubectl cordon NODE

    Reemplaza NODE por el nombre del nodo que deseas desviar.

  2. Desvía el nodo. GKE reprograma automáticamente los Pods administrados por implementaciones en otros nodos. Usa la marca --force para desviar los Pods huérfanos que no tienen un recurso de administración.

     kubectl drain NODE --force

  3. Desacordona el nodo para permitir que GKE programe nuevos Pods en él:

     kubectl uncordon NODE

Mueve los directorios afectados

Puedes identificar los directorios de Pods huérfanos en /var/lib/kubelet/pods y quitarlos del directorio principal para permitir que GKE finalice los Pods.

Soluciona problemas de finalización de recursos

Problema: El espacio de nombres está atascado en el estado Terminating





## Debug GKE Cluster Austoscaler issues with gcpdiag

















  
  

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.




  
This gcpdiag runbook investigates potential causes for GKE
Cluster Autoscaler failures while performing scale up or scale down operations.
It looks for the following error message in logs:
<ul>
  <li><strong>scale.up.error.out.of.resources</strong></li>
  <li><strong>scale.up.error.quota.exceeded</strong></li>
  <li><strong>scale.up.error.waiting.for.instances.timeout</strong></li>
  <li><strong>scale.up.error.ip.space.exhausted</strong></li>
  <li><strong>scale.up.error.service.account.deleted</strong></li>
  <li><strong>scale.down.error.failed.to.evict.pods</strong></li>
  <li><strong>no.scale.down.node.node.group.min.size.reached</strong></li>
</ul>







    


  
Google Cloud console

  
    
    
  1. Complete and then copy the following command. 
    2. 
       
    gcpdiag runbook gke/cluster-autoscaler --project=<var>PROJECT_ID</var> \\
    --parameter name=<var>CLUSTER_NAME</var> \\
    --parameter location=<var>LOCATION</var>
    
    
  2. Abre la consola de Google Cloud y activa Cloud Shell.
    3. 
    

Abre la consola de Cloud

    
  3. Pega el comando copiado.
    4. 
    
  4. Ejecuta el comando gcpdiag, que descarga la imagen de Docker gcpdiag y, luego, realiza verificaciones de diagnóstico. Si corresponde, sigue las instrucciones de salida para corregir las verificaciones que fallaron.
    
    5. 
  


  

    
  
    Docker
    
  
    Puedes  ejecutar gcpdiag con un wrapper que inicie gcpdiag en un contenedor de Docker. Se debe instalar Docker o Podman.
    
  
      
    
    1. Copia y ejecuta el siguiente comando en tu estación de trabajo local.
      
      curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
      
      
      2. 
      
    2.  Ejecuta el comando gcpdiag.
        
      ./gcpdiag runbook gke/cluster-autoscaler --project=<var>PROJECT_ID</var> \\
    --parameter name=<var>CLUSTER_NAME</var> \\
    --parameter location=<var>LOCATION</var>
      
      
      3. 

   
 
    

    



    


    Consulta los parámetros disponibles para este runbook.
    


    Reemplaza lo siguiente:
    

      
  
    • PROJECT_ID: Es el ID del proyecto que contiene el recurso.
      • 
  
  
  <li><var>CLUSTER_NAME</var>: Es el nombre del clúster de GKE de destino dentro de tu proyecto.</li> <li><var>LOCATION</var>: Es la ubicación en la que se encuentra el clúster de GKE de destino (esta es la zona para el clúster zonal o la región para el clúster regional).</li>

  

    

    Marcas útiles:
    

      
  
    • --project: El PROJECT_ID
  
    • --universe-domain: Si corresponde, el dominio de Trusted Partner Sovereign Cloud que aloja el recurso
      • 
  
    • --parameter o -p: Parámetros del runbook
      • 
  
  
    


    Para obtener una lista y una descripción de todas las marcas de la herramienta gcpdiag, consulta las instrucciones de uso de gcpdiag.
    


    




## Soluciona los problemas relacionados con las métricas de tu clúster que no aparecen en Cloud Monitoring {:#no_metrics}

Asegúrate de haber [habilitado la API de Monitoring](/monitoring/api/enable-api) y la [API de Logging](/logging/docs/api/enable-api) en tu proyecto. También deberías confirmar que puedes ver tu proyecto en la [descripción general de Cloud Monitoring](https://console.cloud.google.com/monitoring) en la consola de Google Cloud.

Si el problema persiste, verifica alguna de las posibles causas siguientes:

1.  Asegúrate de que habilitaste la supervisión en tu clúster.

    La supervisión está habilitada de forma predeterminada para los clústeres creados desde la consola de Google Cloud y desde Google Cloud CLI, pero puedes verificarlo si ejecutas el siguiente comando o haces clic en los detalles del clúster en [la consola de Google Cloud](https://console.cloud.google.com/):

    ```sh
    gcloud container clusters describe CLUSTER_NAME
    ```

    El resultado de este comando debe incluir "SYSTEM_COMPONENTS" en la lista de "enableComponents" en la sección "monitoringConfig", similar a lo siguiente:

    ```
    monitoringConfig:
      componentConfig:
        enableComponents:
        - SYSTEM_COMPONENTS
    ```

    Si la supervisión no está habilitada, ejecuta el siguiente comando para habilitarla:

    ```sh
    gcloud container clusters update CLUSTER_NAME --monitoring=SYSTEM
    ```

1.  ¿Cuánto tiempo pasó desde que se creó el clúster o se habilitó la supervisión?

    Puede tomar hasta una hora que las métricas de un clúster nuevo comiencen a aparecer Cloud Monitoring.

1.  ¿Hay un "heapster" o "gke-metrics-agent" (el colector de OpenTelemetry) que se ejecuta en el clúster en el espacio de nombres "kube-system"?

    Es posible que este pod no pueda programar cargas de trabajo porque el clúster se está quedando sin recursos. Para comprobar si OpenTelemetry o Heapster están en ejecución, puedes llamar a "kubectl get pods --namespace=kube-system" y buscar Pods con "heapster" o "gke-metrics-agent" en el nombre.

1.  ¿El plano de control del clúster puede comunicarse con los nodos?

    Cloud Monitoring depende de eso. Puedes ejecutar el siguiente comando para verificar si este es el caso:

    ```sh
    kubectl logs POD_NAME
    ```

    Si este comando muestra un error, es posible que los túneles SSH sean los que causan el problema. Consulta [esta sección](/kubernetes-engine/docs/troubleshooting#kubect_commands_stops) para obtener más información.

Si tienes un problema relacionado con el agente de Cloud Logging, consulta su [documentación de solución de problemas.

Para obtener más información, consulta la [documentación de registro](/logging/docs/).




## Problema: La autoridad certificadora raíz del clúster vencerá pronto {:#ca_expiring}

La autoridad certificadora raíz de tu clúster vencerá pronto. Para evitar que se interrumpan las operaciones normales del clúster, debes realizar una [rotación de credenciales](/kubernetes-engine/docs/how-to/credential-rotation).

## Error: “Instance 'Foo' does not contain 'instance-template' metadata” {:#instance-template-missing}

Es posible que veas el error “Instance 'Foo' does not contain 'instance-template' metadata” como un estado de un grupo de nodos que no puede actualizar, escalar ni realizar reparación automática de nodos.

Este mensaje indica que los metadatos de las instancias de VM, asignados por GKE, están dañados. Esto suele suceder cuando la automatización o las secuencias de comandos creadas de forma personalizada intentan agregar metadatos de instancia nuevos (como [`block-project-ssh-keys`](/compute/docs/connect/restrict-ssh-keys#block-keys)) y, en lugar de solo agregar o actualizar valores, también se borran los metadatos existentes.
Puedes leer sobre los metadatos de instancias de VM en [Configura metadatos personalizados](/compute/docs/storing-retrieving-metadata#custom).

En caso de que se borren algunos de los valores de metadatos críticos (entre otros: "instance-template", "kube-labels", "kubelet-config", "kubeconfig", "cluster-name", "configure-sh", "cluster-uid"), el nodo o el grupo de nodos completo podría quedar en un estado inestable, ya que estos valores son fundamentales para las operaciones de GKE.



Si los metadatos de la instancia se dañaron, la mejor manera de recuperarlos es volver a crear el grupo de nodos que contiene las instancias de VM dañadas. Deberás [agregar un grupo de nodos](/kubernetes-engine/docs/how-to/node-pools#add) al clúster y aumentar el recuento de nodos en el grupo nuevo, a la vez que acordonas y quitas los nodos del otro. Consulta las instrucciones para [migrar cargas de trabajo entre grupos de nodos](/kubernetes-engine/docs/troubleshooting/troubleshoot-node-pools#migrate-node-pools).



Para encontrar quién y cuándo se editaron los metadatos de la instancia, puedes revisar la [información del registro de auditoría de Compute Engine](/compute/docs/logging/audit-logging) o buscar registros con el [Explorador de registros](/logging/docs/view/logs-explorer-interface) con una búsqueda similar a esta:

```none
resource.type="gce_instance_group_manager"
protoPayload.methodName="v1.compute.instanceGroupManagers.setInstanceTemplate"
```

En los registros, es posible que encuentres la dirección IP y el usuario-agente del solicitante:

``` json
requestMetadata: {
  callerIp: "REDACTED"
  callerSuppliedUserAgent: "google-api-go-client/0.5 GoogleContainerEngine/v1"
}
```





Para obtener más información sobre los secretos en GKE, consulta [Cómo encriptar secretos en la capa de aplicación](/kubernetes-engine/docs/how-to/encrypting-secrets).

## Problema: Falló la actualización de la encriptación de secretos {:#secrets_encryption_update_failed}

Si falla la operación para habilitar, inhabilitar o actualizar la [clave de Cloud KMS](/kubernetes-engine/docs/how-to/encrypting-secrets), consulta la guía [Soluciona problemas de encriptación de Secrets de la capa de la aplicación](/kubernetes-engine/docs/troubleshooting/troubleshoot-secrets).