Acerca de los registros de GKE

En esta página se ofrece una descripción general de las opciones de registro disponibles en Google Kubernetes Engine (GKE).

Información general

Los registros de GKE enviados a Cloud Logging se almacenan en un almacén de datos persistente específico. Aunque GKE almacena registros, estos no se guardan permanentemente. Por ejemplo, los registros de contenedores de GKE se eliminan cuando se elimina su pod host, cuando se queda sin espacio el disco en el que están almacenados o cuando se sustituyen por registros más recientes. Los registros del sistema se eliminan periódicamente para liberar espacio para nuevos registros. Los eventos de clúster se eliminan al cabo de una hora.

Agente de registro de GKE

En el caso de los registros de contenedores y del sistema, GKE implementa de forma predeterminada un agente de registro por nodo que lee los registros de contenedores, añade metadatos útiles y, a continuación, los almacena en Cloud Logging. El agente de registro de GKE busca registros de contenedores en las siguientes fuentes:

  • Resultados y registros de errores estándar de procesos en contenedores

  • Registros de kubelet y del tiempo de ejecución del contenedor

  • Registros de componentes del sistema, como secuencias de comandos de inicio de una máquina virtual

En el caso de los eventos, GKE usa una implementación en el espacio de nombres kube-system, que recoge automáticamente los eventos y los envía a Logging.

Qué registros se recogen

De forma predeterminada, GKE recoge varios tipos de registros de tu clúster y los almacena en Cloud Logging:

  • Los registros de auditoría incluyen el registro de actividad de administrador, el registro de acceso a los datos y el registro de eventos. Para obtener información detallada sobre los registros de auditoría de GKE, consulta la documentación Registros de auditoría de GKE. Los registros de auditoría de GKE no se pueden inhabilitar.

  • Registros del sistema, incluidos los que se indican en la sección Registros disponibles.

  • Los registros de aplicaciones incluyen todos los registros generados por contenedores que no son del sistema y que se ejecutan en nodos de usuario.

    Las siguientes limitaciones pueden provocar que no se envíen los registros de aplicaciones a Cloud Logging:

    • En los registros JSON, no se admiten claves JSON duplicadas.
    • stream es una clave reservada en la canalización de registro de GKE. Una streamclave en el registro JSON de la aplicación puede provocar un comportamiento inesperado y que se eliminen registros.
    • Cloud Logging tiene un límite de tamaño por LogEntry. Las entradas de registro que superen el límite de tamaño se descartarán en el caso de los registros jsonPayload y se truncarán en el caso de los registros textPayload.

De forma opcional, GKE puede recoger tipos de registros adicionales de determinados componentes del plano de control de Kubernetes y almacenarlos en Cloud Logging:

  • Los registros del servidor de la API incluyen todos los registros generados por el servidor de la API de Kubernetes (kube-apiserver).

  • Los registros del programador incluyen todos los registros generados por el programador de Kubernetes (kube-scheduler).

  • Los registros del gestor de controladores incluyen todos los registros generados por el gestor de controladores de Kubernetes (kube-controller-manager).

Para obtener más información sobre cada uno de estos componentes del plano de control, consulta el artículo Arquitectura de clústeres de GKE.

Recogida de tus registros

Cuando creas un clúster de GKE, la integración con Cloud Logging se habilita de forma predeterminada.

Los registros del sistema y de las aplicaciones se envían al enrutador de registros de Cloud Logging.

Desde ahí, los registros se pueden ingerir en Cloud Logging, excluir o exportar a BigQuery, Pub/Sub o Cloud Storage.

También puedes configurar un clúster estándar para que solo registre los registros del sistema y no recoja los registros de aplicaciones. En los clústeres Autopilot y Estándar, los filtros de exclusión te permiten reducir el volumen de registros que se envían a Cloud Logging.

Rendimiento de registro

Cuando se habilita el registro del sistema, se implementa y gestiona automáticamente un agente de Cloud Logging específico. Se ejecuta en todos los nodos de GKE de un clúster para recoger registros, añade metadatos útiles sobre el contenedor, el pod y el clúster, y, a continuación, envía los registros a Cloud Logging mediante un agente basado en fluentbit.

Si algún nodo de GKE requiere más del rendimiento de registro predeterminado y tu clúster Estándar de GKE usa la versión 1.23.13-gke.1000 o una posterior del plano de control, puedes configurar GKE para que implemente una configuración alternativa del agente de Logging diseñada para maximizar el rendimiento de registro.

Para obtener más información, consulta Ajustar el rendimiento de los registros.

Recogida de registros con fluentd o fluentbit personalizados

El agente de registro predeterminado de GKE proporciona una solución gestionada para implementar y gestionar los agentes que envían los registros de tus clústeres a Cloud Logging. Los registros se recogen mediante un agente basado en fluentbit.

Recoger registros de auditd de Linux para nodos de GKE

Puedes habilitar registros de auditoría del sistema operativo detallados en nodos de GKE que ejecuten Container-Optimized OS. Los registros del sistema operativo de tus nodos proporcionan información valiosa sobre el estado de tu clúster y tus cargas de trabajo, como mensajes de error, intentos de inicio de sesión y ejecuciones binarias. Puede usar esta información para depurar problemas o investigar incidentes de seguridad.

Para obtener más información, consulta Habilitar registros de auditd de Linux en nodos de GKE.

Registros de auditoría de GKE

Para obtener información detallada sobre las entradas de registro que se aplican a los tipos de recursos Kubernetes Cluster y GKE Cluster Operations, consulta Registro de auditoría.

Control de acceso de registro

El registro del control de acceso tiene dos aspectos: el acceso a la aplicación y el acceso de los usuarios. Cloud Logging proporciona roles de Gestión de Identidades y Accesos (IAM) que puedes usar para conceder el acceso adecuado.

Acceso a aplicaciones

Las aplicaciones necesitan permisos para escribir registros en Cloud Logging, que se conceden asignando el rol de gestión de identidades y accesos roles/logging.logWriter a la cuenta de servicio vinculada al grupo de nodos subyacente.

Acceso a la vista de usuario

Debes tener el rol roles/logging.viewer para ver tus registros en tu proyecto. Si necesitas acceder a los registros de acceso a datos, debes tener el permiso de gestión de identidades y accesos logging.privateLogViewer.

Para obtener más información sobre los permisos y los roles, consulta la guía Control de acceso. También puedes consultar las prácticas recomendadas para los registros de auditoría de Cloud, que también se aplican a Cloud Logging en general.

Acceso de administrador de usuarios

Los roles de IAM roles/logging.configWriter y roles/logging.admin proporcionan las funciones administrativas. El rol roles/logging.configWriter es necesario para crear un receptor de registro, que se suele usar para dirigir los registros a un proyecto específico o centralizado. Por ejemplo, puedes usar un sumidero de registros junto con un filtro de registros para dirigir todos los registros de un espacio de nombres a un segmento de registros centralizado.

Para obtener más información, consulta la guía Control de acceso de Cloud Logging.

Prácticas recomendadas

  • Registro estructurado: el agente de registro integrado con GKE leerá los documentos JSON serializados en cadenas de una sola línea y escritos en la salida estándar o en el error estándar, y los enviará a Google Cloud Observability como entradas de registro estructuradas.
    • Consulta Registro estructurado para obtener más información sobre cómo trabajar con un agente de registro integrado.
    • Puedes usar filtros de registro avanzados para filtrar los registros en función de los campos del documento JSON.
    • Los registros generados con glog tendrán los campos comunes analizados, como severity, pid, source_file y source_line. Sin embargo, la carga útil del mensaje no se analiza y se muestra tal cual en el mensaje de registro resultante en Google Cloud Observability.
  • Gravedades: de forma predeterminada, los registros escritos en la salida estándar tienen el nivel INFO y los registros escritos en el error estándar tienen el nivel ERROR. Los registros estructurados pueden incluir un campo severity, que define la gravedad del registro.
  • Exportar a BigQuery: para hacer análisis adicionales, puede exportar registros a servicios externos, como BigQuery o Pub/Sub. Los registros exportados a BigQuery conservan el formato y la estructura. Consulta la información general sobre el enrutamiento y el almacenamiento para obtener más información.

  • Alertas: cuando Logging registra un comportamiento inesperado, puedes usar métricas basadas en registros para configurar políticas de alertas. Para ver un ejemplo, consulta Crear una política de alertas en una métrica de contador. Para obtener información detallada sobre las métricas basadas en registros, consulta el artículo Información general sobre las métricas basadas en registros.

  • Informes de errores: para recoger errores de las aplicaciones que se ejecutan en tus clústeres, puedes usar Error Reporting.

Registros disponibles

Si decides enviar registros a Cloud Logging, debes enviar registros del sistema y, opcionalmente, puedes enviar registros de otras fuentes.

En la siguiente tabla se indican los valores admitidos de la marca --logging para los comandos create y update.

Origen del archivo de registro Valor de --logging Registros recogidos
Ninguno NONE No se han enviado registros a Cloud Logging porque no hay ningún agente de recogida de registros instalado en el clúster. Este valor no se admite en los clústeres de Autopilot.
Sistema SYSTEM Recoge registros de lo siguiente:
  • Todos los pods que se ejecutan en los espacios de nombres kube-system, istio-system, knative-serving, gke-system y config-management-system.
  • Servicios que no están en contenedores, como el tiempo de ejecución de docker/containerd, kubelet, kubelet-monitor, node-problem-detector y kube-container-runtime-monitor.
  • Salida de los puertos serie del nodo, si los metadatos de la instancia de VM serial-port-logging-enable se han definido como true.

También recoge eventos de Kubernetes. Este valor es obligatorio para todos los tipos de clústeres.

Cargas de trabajo WORKLOAD Todos los registros generados por contenedores que no sean del sistema y que se ejecuten en nodos de usuario. Este valor está activado de forma predeterminada, pero es opcional para todos los tipos de clústeres.
Servidor de API API_SERVER Todos los registros generados por kube-apiserver. Este valor es opcional para todos los tipos de clúster.
Programador SCHEDULER Todos los registros generados por kube-scheduler. Este valor es opcional para todos los tipos de clúster.
Gestor de controladores CONTROLLER_MANAGER Todos los registros generados por kube-controller-manager. Este valor es opcional para todos los tipos de clústeres.
Herramienta de adaptación dinámica de grupo horizontal KCP_HPA

Exporta los registros de decisiones de recomendaciones atómicas y finales de cada objeto HPA de tu clúster de GKE.

Para obtener más información, consulta Ver eventos de la herramienta de adaptación dinámica horizontal de pods.
Conexiones de red del plano de control KCP_CONNECTION

Solo disponible con la autoridad del plano de control de GKE

Registros de conexiones de red entrantes de instancias del plano de control de GKE. Para obtener más información, consulta Verificar las conexiones de Google al plano de control del clúster.
Eventos SSH del plano de control KCP_SSHD

Solo disponible con la autoridad del plano de control de GKE

Genera registros de todos los eventos de SSH, como la aceptación de claves públicas y el cierre de sesiones, que se producen cuando el personal de Google se conecta a las instancias del plano de control de tu clúster durante los casos de asistencia o para otros accesos administrativos.

Para obtener más información, consulta Verificar las conexiones de Google al plano de control del clúster.

Precios

Los registros de GKE se exportan a Cloud Logging. Se aplican los precios de Cloud Logging.

Se te cobrarán los costes de almacenamiento acumulados cuando exportes los registros a otro Google Cloud servicio, como BigQuery. Para obtener información sobre los costes asociados a Cloud Logging, consulta la página Precios.

Cuota

Los registros del plano de control consumen la cuota "Solicitudes de escritura por minuto" de la API Cloud Logging. Antes de habilitar los registros del plano de control, consulta el pico de uso reciente de esa cuota. Si tienes muchos clústeres en el mismo proyecto o ya te estás acercando al límite de cuota, puedes solicitar un aumento del límite de cuota antes de habilitar los registros del plano de control.

Controles de acceso

Si quieres limitar el acceso a los registros del plano de control de Kubernetes en tu organización, puedes crear un segmento de registro independiente con controles de acceso más limitados.

Si los almacenas en un segmento de registros independiente con acceso limitado, los registros del plano de control del segmento no serán accesibles automáticamente para cualquier persona con acceso roles/logging.viewer al proyecto. Además, si decides eliminar determinados registros del plano de control por motivos de privacidad o seguridad, almacenarlos en un bucket de registro independiente con acceso limitado te permite eliminar los registros sin que afecte a los de otros componentes o servicios.