Kubernetes 日志传输中的四大挑战

收集日志,并将数据发送到日志服务器,这一动作看起来简单,但其实并不是一件容易的事。比如:容器日志收集,就存在诸多挑战。日志传输,通常包含两大类:一个是主动方式;一个是被动方式。主动方式,是指整个进程主动向远程syslog服务器发送日志消息。通常,数据编码的格式是rfc5424。被动方式,是指部署每个进程的日志路径或文件模式。LogAgent会定期扫描,并将捕获的日志消息发送到日志服务器。

具体而言,容器日志收集面临着四大挑战:一、未能收集所有关键日志当出现问题时,pods可能会被删除或重新创建。因此,与pod/container相关联的日志文件将被快速删除/创建。借助LogAgent(如Fluentd或Logstash),我们可以定期扫描文件夹,或利用内置模式定义自动检测日志,并且默认扫描间隔为60秒(见下图)。扫描间隔太慢,将无法及时捕捉pod。

此前,在VM环境下,就不用担心会出现类似问题。当进程以某种方式重新启动时,日志文件可能会被改变,但不会被删除。最多只是感觉到日志收集速度变慢,但不会丢失关键日志。如何解决这一问题?我们可以通过Kubernetes云控制器功能来监控pod。每当启动pod创建事件时,立即通知LogAgent。honeycomb-kubernetts-agent是一个有机统一体。

这种日志记录行为是Kubernetes环境下的模式。尽管,云原生移动确实需要时间,但并不是每个应用都是最前沿应用,对于DB服务尤其如此。与VM环境相比,容器日志收集更灵活,Pod可以经常在不同的工作节点上移动。但是,谁都不希望每当K8s集群有一个pod更改时,就要重新加载或重新启动LogAgent,这绝对是一个新的挑战。

三、如何在不同的Namespaces下支持SLA为了让操作更简单,人们通常只部署一个LogAgent作为Kubernetesdaemonset。这代表每个Kubernetes工作节点有一个pod。如果这个pod需要重新加载或重新调度,它将影响这个工作节点中的所有pod。从K8sv1.12开始,每个节点可以运行100个pod。你需要确保LogAgent足够快,可以从所有pod中收集日志。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181019A0UPBE00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券