es.davy.ai

Preguntas y respuestas de programación confiables

¿Tienes una pregunta?

Si tienes alguna pregunta, puedes hacerla a continuación o ingresar lo que estás buscando.

[Error] [Arriba] la conexión se agotó después de 10 segundos al intentar comunicarse con Fluentd en Kubernetes, falló cuando Fluent-bit intentó comunicarse con Fluentd en Kubernetes.

Estoy utilizando fluent-bit para recopilar registros y pasarlos a fluentd para su procesamiento en un entorno de Kubernetes. Las instancias de Fluent-bit están controladas por DaemonSet y leen registros de contenedores Docker.

[INPUT]
Name tail
Path /var/log/containers/*.log
Parser docker
Tag kube.*
Mem_Buf_Limit 5MB
Skip_Long_Lines On

También hay un servicio de fluent-bit en ejecución.

Name: monitoring-fluent-bit-dips
Namespace: dips
Labels: app.kubernetes.io/instance=monitoring
 app.kubernetes.io/managed-by=Helm
 app.kubernetes.io/name=fluent-bit-dips
 app.kubernetes.io/version=1.8.10
helm.sh/chart=fluent-bit-0.19.6
Selector: app.kubernetes.io/instance=monitoring,app.kubernetes.io/name=fluent-bit-dips
Type: ClusterIP
IP Families: <none>
IP: 10.43.72.32
IPs: <none>
Port: http 2020/TCP
TargetPort: http/TCP
Endpoints: 10.42.0.144:2020,10.42.1.155:2020,10.42.2.186:2020 + 1 más...
Session Affinity: None
Events: <none>

La descripción del servicio de fluentd es la siguiente:

Name: monitoring-logservice
Namespace: dips
Labels: app.kubernetes.io/instance=monitoring
 app.kubernetes.io/managed-by=Helm
 app.kubernetes.io/name=logservice
 app.kubernetes.io/version=1.9
helm.sh/chart=logservice-0.1.2
Annotations: meta.helm.sh/release-name: monitoring
 meta.helm.sh/release-namespace: dips
Selector: app.kubernetes.io/instance=monitoring,app.kubernetes.io/name=logservice
Type: ClusterIP
IP Families: <none>
IP: 10.43.44.254
IPs: <none>
Port: http 24224/TCP
TargetPort: http/TCP
Endpoints: 10.42.0.143:24224
Session Affinity: None
Events: <none>

Pero los registros de fluent-bit no llegan a fluentd y se obtiene el siguiente error:

[upstream] connection #81 to monitoring-fluent-bit-dips:24224 timed out after 10 seconds

He intentado varias cosas, como:

  • Volver a implementar pods de fluent-bit.
  • Redesplegar el pod de fluentd.
  • Actualizar la versión de fluent-bit de 1.7.3 a 1.8.10.

Este es un entorno de Kubernetes donde fluent-bit puede comunicarse con fluentd en la primera etapa de implementación. Además de eso, estas mismas versiones de fluent funcionan cuando las implemento localmente con el entorno de docker-desktop.

Mis suposiciones son:

  • Fluent-bit no puede administrar la cantidad de procesamiento de registro.
  • Los servicios de flujo no pueden comunicarse una vez que se reinician los servicios.

¿Alguien tiene alguna experiencia en esto o tiene alguna idea de cómo depurar este problema más profundamente?

Tags:  , ,

Answer

  1. Avatar for davy.ai

    A partir del mensaje de error, parece que Fluent-bit no puede establecer una conexión con Fluentd. Esto podría ser causado por varios factores; aquí hay algunos consejos para ayudarlo a depurar:

    1. Verifique si el servicio Fluentd es accesible desde los pods de Fluent-bit. Puede usar kubectl exec para ingresar a un pod de Fluent-bit y usar herramientas como ping, nslookup y telnet para probar la conectividad con la dirección IP y el puerto del servicio de Fluentd.
    2. Verifique si Fluent-bit está generando registros que coincidan con la etiqueta kube.*; si los registros no están etiquetados correctamente, Fluentd no los recogerá. Puede usar kubectl logs para ver los registros del contenedor de Fluent-bit y verificar si contienen los eventos de registro esperados.

    3. Verifique los registros del pod de Fluentd en busca de mensajes de error que puedan indicar por qué no se pudieron recibir los registros de Fluent-bit. Puede usar kubectl logs para ver los registros del contenedor de Fluentd. Asegúrese de que Fluentd esté escuchando en el puerto correcto y que tenga suficientes recursos para procesar los registros entrantes.

    4. Verifique si hay políticas de red, cortafuegos o grupos de seguridad que puedan estar bloqueando el tráfico entre los servicios de Fluent-bit y Fluentd. Puede usar kubectl describe para ver las políticas de red que se aplican a los servicios de Fluent-bit y Fluentd.

    5. Verifique si hay otras instancias de Fluent-bit ejecutándose en el clúster que puedan estar compitiendo por recursos con las instancias administradas por DaemonSet. Puede usar kubectl get daemonset para ver el estado de DaemonSet de Fluent-bit y verificar si hay pods que estén bloqueados en un estado de Pending.

    6. Finalmente, si ninguno de los pasos anteriores ayuda, es posible que deba profundizar en los archivos de configuración de Fluent-bit y Fluentd para ver si hay algún problema con su configuración. Puede usar kubectl exec para ingresar al contenedor de Fluentd y verificar sus archivos de configuración.

    Siguiendo estos pasos, debería poder identificar la causa raíz del problema y tomar medidas apropiadas para resolverlo.

Comments are closed.