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中收集日志。