En esta página, se proporciona una descripción general de las opciones de registro disponibles en Google Kubernetes Engine (GKE).
Descripción general
Los registros de GKE enviados a Cloud Logging se almacenan en un almacén de datos dedicado y persistente. Si bien GKE almacena los registros, no lo hace de forma permanente. Por ejemplo, los registros de contenedores de GKE se quitan cuando se quita el Pod del host, cuando el disco en el que están almacenados se queda sin espacio o cuando se los reemplaza por registros más nuevos. Los registros del sistema se quitan de forma periódica a fin de liberar espacio para registros nuevos. Los eventos de clústeres se quitan después de una hora.
Agente de Logging de GKE
Para los registros de contenedores y del sistema, GKE implementa, de forma predeterminada, un agente de registros por nodo que lee registros de contenedores, agrega metadatos útiles y, luego, los almacena en Cloud Logging. El agente de Logging de GKE busca registros de contenedor en las siguientes fuentes:
Registros de salida y de error estándar de procesos en contenedores
Registros de entorno de ejecución de contenedores y kubelet
Registros para los componentes del sistema, como las secuencias de comandos de inicio de VM
Para los eventos, GKE usa una implementación en el espacio de nombres kube-system, que recopila eventos de forma automática y los envía a Logging.
Qué registros se recopilan
De forma predeterminada, GKE recopila varios tipos de registros de tu clúster y los almacena en Cloud Logging:
Los registros de auditoría incluyen el registro de actividad del administrador, el registro de acceso a los datos y el registro de eventos. Si deseas obtener información detallada sobre los registros de auditoría para GKE, consulta la documentación Registros de auditoría para GKE. No se pueden inhabilitar los registros de auditoría para GKE.
Registros del sistema, incluidos los que se indican en 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 los registros de la aplicación no se envíen a Cloud Logging:
- En el caso de los registros JSON, no se admiten claves JSON duplicadas.
stream
es una clave reservada en la canalización de registro de GKE. Una clavestream
en el registro JSON de la aplicación puede provocar un comportamiento inesperado y la eliminación de registros.- Cloud Logging tiene un límite de tamaño por LogEntry. Cualquier LogEntry que supere el límite de tamaño se descartará para los registros de jsonPayload y se truncará para los registros de textPayload.
De manera opcional, GKE puede recopilar tipos de registros adicionales de ciertos componentes del plano de control de Kubernetes y almacenarlos en Cloud Logging:
Los registros del servidor de la API incluyen todos los registros que genera el servidor de la API de Kubernetes (
kube-apiserver
).Los registros del programador incluyen todos los registros que genera el programador de Kubernetes (
kube-scheduler
).Los registros del administrador del controlador incluyen todos los registros que genera el administrador del controlador de Kubernetes (
kube-controller-manager
).
Para obtener más información sobre cada uno de estos componentes del plano de control, consulta Arquitectura del clúster de GKE.
Recopila tus registros
Cuando creas un clúster de GKE nuevo, la integración con Cloud Logging está habilitada de forma predeterminada.
Los registros del sistema y de las aplicaciones se entregan al Enrutador de registros en Cloud Logging.
Desde allí, los registros pueden transferirse a Cloud Logging, excluirse o exportarse a BigQuery, Pub/Sub o Cloud Storage.
También puedes configurar un clúster estándar para que solo capture registros del sistema y no recopile registros de aplicaciones. Tanto para los clústeres de Autopilot como para los Standard, los filtros de exclusión te permiten reducir el volumen de registros enviados a Cloud Logging.
Capacidad de procesamiento de registros
Cuando el registro del sistema está habilitado, un agente de Cloud Logging exclusivo se implementa y administra de forma automática. Se ejecuta en todos los nodos de GKE en un clúster para recopilar registros, agrega metadatos útiles sobre el contenedor, el Pod y el clúster y, luego, envía los registros a Cloud Logging mediante un agente basado en Flufluent.
Si algún nodo de GKE requiere más capacidad de procesamiento de registro predeterminada y tu clúster de GKE Standard usa la versión 1.23.13-gke.1000 o posterior del plano de control, puedes configurar GKE para implementar una configuración alternativa del agente de Logging está diseñado para maximizar la capacidad de procesamiento del registro.
Para obtener más información, consulta Cómo ajustar la capacidad de procesamiento de registros.
Recopila registros con fluentd o fluentbit personalizados
El agente de registro predeterminado de GKE proporciona una solución administrada para implementar y administrar los agentes que envían los registros de los clústeres a Cloud Logging. Los registros se recopilan mediante un agente basado en fluentbit.
Recopila registros auditd
de Linux para nodos de GKE
Puedes habilitar los registros de auditoría del sistema operativo detallados en los nodos de GKE que ejecutan Container-Optimized OS. Los registros del sistema operativo en tus nodos proporcionan información valiosa sobre el estado del clúster y las cargas de trabajo, como los mensajes de error, los intentos de acceso y las ejecuciones binarias. Puedes usar esta información para depurar problemas o investigar incidentes de seguridad.
Para obtener más información, consulta Habilita registros 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 de las operaciones con clústeres de Kubernetes y de GKE, consulta Registros de auditoría.
Control de acceso de Logging
Existen dos aspectos del control de acceso a los registros: el acceso a la aplicación y el acceso de los usuarios. Cloud Logging proporciona roles de Identity and Access Management (IAM) que puedes usar para otorgar el acceso adecuado.
Acceso a la aplicación
Las aplicaciones necesitan permisos para escribir registros en Cloud Logging, que se otorga mediante la asignación del rol de IAM roles/logging.logWriter
a la cuenta de servicio adjunta al grupo de nodos subyacente.
Acceso de lectura del usuario
Debes tener la función roles/logging.viewer
para ver los registros en el proyecto. Si necesitas tener acceso a los registros de acceso a los datos, debes tener el permiso de IAM logging.privateLogViewer
.
Para obtener más información sobre los permisos y los roles, consulta la guía Control de acceso. También puedes revisar las Prácticas recomendadas para los registros de auditoría de Cloud, que también se aplican a Cloud Logging en general.
Acceso del administrador de usuarios
Los roles de IAM roles/logging.configWriter
y roles/logging.admin
proporcionan las capacidades administrativas. El rol de IAM roles/logging.configWriter
es necesario para crear un receptor de registros que suele usarse con el fin de dirigir los registros a un proyecto específico o centralizado. Por ejemplo, te recomendamos usar un receptor de registros junto con un filtro de registros para dirigir todos los registros de un espacio de nombres a un bucket de registro centralizado.
Si deseas obtener más información, consulta la guía Control de acceso para Cloud Logging.
Prácticas recomendadas
- Registro estructurado: el agente de Logging integrado a GKE leerá documentos JSON serializados en cadenas de una sola línea y escritos en un resultado estándar o un error estándar y los enviará a Google Cloud Observability como entradas de registro estructuradas.
- Consulta Registro estructurado para obtener más detalles sobre cómo trabajar con un agente de Logging integrado.
- Puedes usar los filtros de registros avanzados para filtrar los registros según los campos del documento JSON.
- Los registros generados con glog tendrán los campos comunes analizados, por ejemplo,
severity
,pid
,source_file
,source_line
. Sin embargo, la carga útil del mensaje no está analizada y aparece tal como está en el mensaje de registro resultante en Google Cloud Observability.
- Gravedad: De forma predeterminada, los registros escritos en el resultado estándar están en el nivel
INFO
y los registros escritos en el error estándar están en el nivelERROR
. Los registros estructurados pueden incluir un camposeverity
, que define la gravedad del registro. - Exporta a BigQuery: Para realizar análisis adicionales, puedes exportar registros a servicios externos, como BigQuery o Pub/Sub. Los registros exportados a BigQuery conservan su formato y estructura. Consulta Descripción general del 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 Crea una política de alertas en una métrica de contador. Para obtener información detallada sobre las métricas basadas en registros, consulta Descripción general de las métricas basadas en registros.
- Informes de errores: para recopilar los errores de las aplicaciones que se ejecutan en tus clústeres, puedes usar Error Reporting.
Registros disponibles
Si eliges enviar registros a Cloud Logging, debes enviar registros del sistema y, de forma opcional, enviar registros desde fuentes adicionales.
En la siguiente tabla, se indican los valores admitidos para la marca --logging
en los comandos create y update.
Fuente del archivo de registro | Valor --logging |
Registros recopilados |
---|---|---|
Ninguno | NONE |
No se enviaron registros a Cloud Logging. No hay agentes de recopilación de registros instalados en el clúster. Este valor no es compatible con los clústeres de Autopilot. |
Sistema | SYSTEM |
Recopila los siguientes registros:
También recopila 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 son del sistema y que se ejecutan en nodos de usuario Este valor está activado de forma predeterminada, pero opcional para todos los tipos de clústeres. |
Servidor de la API | API_SERVER |
Todos los registros que genera kube-apiserver Este valor es opcional para todos los tipos de clústeres.
|
Programador | SCHEDULER |
Todos los registros que genera kube-scheduler Este valor es opcional para todos los tipos de clústeres.
|
Administrador del controlador | CONTROLLER_MANAGER |
Todos los registros que genera kube-controller-manager Este valor es opcional para todos los tipos de clústeres.
|
Conexiones de red del plano de control | KCP_CONNECTION |
Solo está disponible con la autoridad del plano de control de GKE. Registros de conexión de red entrante para instancias del plano de control de GKE Para obtener más información, consulta Cómo verificar las conexiones de Google con el plano de control del clúster. |
Eventos de SSH del plano de control | KCP_SSHD |
Solo está 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 ocurren cuando el personal de Google se conecta a las instancias del plano de control de tu clúster durante casos de asistencia o para otro acceso administrativo. Para obtener más información, consulta Cómo verificar las conexiones de Google con el plano de control del clúster. |
Registros habilitados de forma predeterminada en GKE Enterprise
Cuando creas un clúster de GKE nuevo en Google Cloud, los registros de cargas de trabajo están habilitados de forma predeterminada para todos los clústeres de Autopilot, pero se pueden inhabilitar.
Para los proyectos de la edición GKE Enterprise, los registros y las métricas útiles adicionales están habilitados de forma predeterminada si te registras en una flota mientras creas el clúster.
En la siguiente tabla, una marca de verificación () indica qué registros están habilitados de forma predeterminada cuando creas y registras un clúster nuevo en un proyecto con GKE Enterprise habilitado:
Nombre del registro | Autopilot | Estándar |
---|---|---|
Sistema | ||
Cargas de trabajo | - | |
Servidor de la API | ||
Programador | ||
Administrador del controlador | ||
Conexiones de red del plano de control | ||
Eventos de SSH del plano de control |
Los registros del plano de control (servidor de la API, programador y administrador del controlador) generan cargos de Cloud Logging.
Precios
Los registros del plano de control de GKE se exportan a Cloud Logging. Se aplican los precios de Cloud Logging.
Se te cobrará por los costos de almacenamiento acumulados cuando exportes registros a otro servicio de Google Cloud , como BigQuery. Para conocer los costos asociados con Cloud Logging, consulta Precios.
Cuota
Los registros del plano de control consumen la cuota de “Solicitudes de escritura por minuto” de la API de Cloud Logging. Antes de habilitar los registros del plano de control, verifica el uso máximo reciente de esa cuota. Si tienes muchos clústeres en el mismo proyecto o ya te acercas al límite de esa cuota, puedes solicitar un aumento del límite de cuota antes de habilitar los registros del plano de control.
Controles de acceso
Si deseas limitar el acceso dentro de tu organización a los registros del plano de control de Kubernetes, puedes crear un bucket de registros separado con controles de acceso más limitados.
Si los almacenas en un bucket de registros independiente con acceso limitado, los usuarios con acceso roles/logging.viewer
al proyecto no podrán acceder de forma automática a los registros del plano de control en el bucket de registros. Además, si decides borrar ciertos registros del plano de control debido a problemas de privacidad o seguridad, almacenarlos en un bucket de registros separado con acceso limitado permite borrar los registros sin afectar los registros de otros componentes o servicios.