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.
Los registros del sistema incluyen registros de las siguientes fuentes:
Todos los Pods que se ejecutan en los espacios de nombres
kube-system,istio-system,knative-serving,gke-systemyconfig-management-systemServicios clave que no están en contenedores, incluidos el entorno de ejecución
docker/containerd,kubelet,kubelet-monitor,node-problem-detectorykube-container-runtime-monitor.La salida de los puertos en serie del nodo, si los metadatos de la instancia de VM
serial-port-logging-enablese configuran como verdaderos A partir de GKE 1.16-13-gke.400, el agente de Logging recopila la salida del puerto en serie para los nodos. Para inhabilitar el registro de salidas de puertos en serie, establece--metadata serial-port-logging-enable=falsedurante la creación del clúster. El resultado de los puertos en serie es útil para solucionar fallas, arranques fallidos, problemas de inicio o de apagado con nodos de GKE. Si inhabilitas estos registros, podrías dificultar la solución de problemas.
Los registros de aplicaciones incluyen todos los registros generados por contenedores que no son del sistema y que se ejecutan en nodos de usuario.
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 Kubernetes Scheduler (
kube-scheduler).Los registros del administrador de controladores incluyen todos los registros que genera el administrador de controladores 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.
A partir de la versión 1.15.7 de GKE, puedes configurar un clúster estándar para capturar solo los registros del sistema y no recopilar los registros de la aplicación. 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 del registro
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 Ajusta la capacidad de procesamiento de los 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. Según la versión del plano de control de GKE, se usan fluentd o fluentbit para recopilar los registros. A partir de GKE 1.17, los registros se recopilan mediante un agente basado en fluentbit.
Los clústeres de GKE que usan versiones anteriores a GKE 1.17 usan un agente basado en fluentd. Si deseas modificar el comportamiento predeterminado de los
agentes fluentd, puedes ejecutar un agente fluentd personalizado.
Los casos de uso comunes incluyen los siguientes:
Quitar datos sensibles de tus registros
Recopilar registros adicionales que no se escriben en
STDOUToSTDERRUsar una configuración específica relacionada con el rendimiento
Usar un formato de registro personalizado
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 de auditoría 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
INFOy 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 del plano de control
Puedes configurar un clúster de GKE para enviar registros emitidos por el servidor de la API de Kubernetes, Scheduler y el administrador de controladores a Cloud Logging.
Requisitos
Para enviar registros emitidos por los componentes del plano de control de Kubernetes a Cloud Logging, se requiere la versión 1.22.0 o posterior del plano de control de GKE y la habilitación de la recopilación de registros del sistema.
Configura la recopilación de registros del plano de control
Consulta las instrucciones para configurar la asistencia de registro para un clúster nuevo o para un clúster existente.
Precios
Los registros del plano de control de GKE se exportan a Cloud Logging. Se aplican los precios de Cloud Logging.
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 tu 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.