Tengo un clúster de nodo único k3s ejecutándose en una máquina. Todavía no tengo ninguna infraestructura de registro configurada y por ahora dejaría esto como una experiencia de aprendizaje futura.
En ese k3 ejecuto algunos trabajos cron que crean registros para cada uno de los trabajos en un archivo separado. Puedo observarlos en /var/log/containers/cron-job-*la máquina host. Estos registros desaparecen después de un cierto período de tiempo (successfulJobsHistoryLimit: 3). Las nuevas instancias de trabajo crean nuevos archivos de registro.
No puedo encontrar una herramienta sencilla que pueda observar ese directorio de registros, preferiblemente con un patrón de nombre de archivo, y transmitir/unir esos pequeños registros de trabajos en un único archivo de registro, incluidos los archivos nuevos que se están creando. No me importa si se pierde el nombre del archivo, solo quiero que las líneas de registro terminen en un archivo que sirva como archivo de todas las ejecuciones del trabajo.
¿Qué he considerado?
Podría simplemente agregar una secuencia de comandos para capturar esos archivos y agregarlos a un archivo de destino con un intervalo, pero tendría que realizar un seguimiento de qué archivos ya se han insertado en caso de que los trabajos no estén sincronizados o el intervalo cron cambie. También me gustaría ampliar esta funcionalidad para pods que son de "larga ejecución" y en este caso tendría que comenzar a rastrear líneas actualizadas en los registros.
Todos los ejemplos que he encontrado tratan sobre seguimiento en pantalla en tiempo real, que no es lo que necesito. Necesito múltiples colas en un archivo de registro de destino.
¿Algunas ideas? (También aceptaría algún tipo de ejemplo simple de enlace de registro de Kubernetes)
Respuesta1
Ofrezco una solución que ahora he elegido por mí mismo. No es la respuesta que estaba buscando, pero parece navegar con la corriente. Todavía tengo curiosidad por saber si esto podría manejarse mediante algún comando común de Unix.
De todos modos, esto es lo que hice:
La forma común parece utilizar una herramienta llamadafluido, que le permite recopilar registros de varias fuentes y transportarlos a cualquier lugar que considere adecuado: una especie de ETL para registros.
Elegí enviar los registros al servidor syslog porque ya tenía uno ejecutándose, pero puedes elegir cualquiera de los complementos de salida desde aquí:Complementos de salida. También hay un gran conjunto de complementos adicionales:Todos los complementos
Paso 1
Obtenga una configuración de Fluentd que tenga instalado el complemento remoto_syslog. No viene con la imagen oficial de la ventana acoplable, pero puedes configurarla tú mismo.
FROM fluent/fluentd:v1.14.0-1.0
USER root
# https://github.com/fluent-plugins-nursery/fluent-plugin-remote_syslog
RUN fluent-gem install fluent-plugin-remote_syslog
USER fluent
Cree la imagen y envíela a su registro.
Paso 2
A continuación, configure un manifiesto de implementación de Fluentd con notificaciones de volumen de solo lectura para acceder a los registros del pod. Los archivos reales residen en /var/log/pods/* y /var/log/containers contiene en realidad enlaces simbólicos. Necesitamos archivos reales. Esos registros son propiedad del root en la máquina host y un usuario con fluidez no tendrá acceso para leerlos. Necesitamos establecer algunos contextos de seguridad. Para que todo funcione, he utilizado el grupo raíz para fsGroup. Siéntase libre de profundizar más y encontrar/comentar la solución más óptima para este tema de seguridad.
apiVersion: apps/v1
kind: Deployment
...
spec:
...
spec:
securityContext:
fsGroup: 0
volumes:
- name: varlogpods-pv
persistentVolumeClaim:
claimName: pvc-var-log-pods
...
containers:
- name: fluentd
image: your/fluentd-image
Vea mi manifiesto completo en esta esencia:implementación fluida
Paso 3
Antes de implementar, también debe configurar fluent.confy describir algunas reglas allí.
El mío está configurado para coincidir con una línea de registro como esta:
2022-04-26T20:05:00.847016854+03:00 stderr F time="2022-04-26 17:05:00" level=info msg="processing 3 records ..."
Para obtener más información, consulte el complemento de cola:cola
<source>
@type tail
@id in_tail_container_logs
path "/var/log/pods/default_cron-*/*/*.log"
pos_file "/tmp/cron_.log.pos"
read_from_head true
tag cron
<parse>
@type regexp
expression /^(?<logtime>[^ ]*) .* level=(?<level>[^ ]*) msg="(?<message>[^"]*)"$/
time_key logtime
time_format %FT%T.%N%:z
</parse>
</source>
<match cron>
@type remote_syslog
host 172.16.3.10
port 514
protocol udp
severity info
program "fluentd"
hostname "k3sserver"
<buffer>
</buffer>
<format>
@type single_value
message_key message
</format>
</match>
Un atributo de configuración importante aquí es read_from_head trueel que lee los archivos de registro desde la parte superior. Es necesario para este escenario, dado que los registros del pod están rotando, queremos que Fluentd lea el registro del pod completo, no solo unas pocas líneas de actualización al final. Para un trabajo cron breve, el archivo de registro simplemente aparece y tail no informa ninguna línea inicial en él.
Etapa 4
Juega con la configuración e inténtalo, inténtalo de nuevo. No olvide reiniciar su implementación después de haber actualizado la configuración en configMap.