TOC
Kubernetes日志收集
Kubernetes可以帮助管理部署在Pod中的上百个容器的生命周期。它是高度分布式的并且各个部分是动态的。一个已经实现的Kubernetes环境通常涉及带有集群和节点的几个系统，这些系统托管着几百个容器，而这些容器不断地基于工作负载启动、毁灭；
当在Kubernetes中处理大量的容器化应用和工作负载时，主动进行监控和调试错误十分重要。在容器、节点或集群级别，这些错误都能在容器中看到。Kubernetes的日志机制是一个十分重要的组件，可以用来管理和监控服务以及基础设施。在Kubernetes中，日志可以让你跟踪错误甚至可以调整托管应用程序的容器的性能；
Kubernetes日志收集的难点
传统上，对于以本地服务器为中心的系统，应用程序日志存储在系统中的日志文件中。这些文件可以在定义的位置看到，也可以移动到中央服务器。但是对于Kubernetes，所有日志都发送到磁盘上/var/log的JSON文件中。这种类型的日志聚合并不安全，因为节点中的Pod可以是临时的也可以是短暂的。删除Pod时，日志文件将丢失。如果你需要尝试对部分日志数据丢失进行故障排除时，这可能是比较复杂、漫长的一个过程；
常见的日志解决方案
常见的日志解决方案无非就是四种，各有千秋，那么经过调研，第一种是目前最常见的一种Kubernetes日志的解决方案；
第一种，它是利用一个单一的进程以DaemonSet的方式运行在Kubernetes集群之上每个Worker工作节点运行一个副本，它的主要缺点在于不利于区分业务日志，因为它的收集目标的整个集群的一个节点上的所有的Pod的日志；
第二种，这种也是比较Low的一种方式，使用容器的都知道一个容器绝大部分都是用来运行一个进程的，那么对于这种日志收集方式呢，其实就是一个容器里运行两个application，一个是业务应用，一个是收集器，那么这种呢，也必须需要我们的应用能够将日志打印到指定目录下面的指定文件里面，比较耗费资源，但它的优点是比较利于去区分业务的日志；
第三种，这种是非常耗费资源的，其实和第二种类似，只不过第二种是一个Pod内部的一个容器运行了两个进程，那么对于第三种呢，它的实现方式会耗费巨大的资源，也就是一个Pod利用两个容器，一个是我们的业务应用，一个是我们的收集器，也就是所谓的SederCar，这种方式也是最耗费资源的一种方式了，因为它在一个Pod内部会启动两个容器，白白浪费的巨大的资源；
第四种，这种可能是最不理想的方式了，也就是需要开发人员接入，让我们的应用代码能够自动的将数据传输到elsticsearch里面，这种方式呢，会给开发人员带来不必要的繁杂工作；
总结
总的来说，DaemonSet方式比较简单，而且适合更加适合微服务化，当然，不是完美的，比如业务方想把业务日志打到控制台上，但是同时也想知道jvm的日志，这种情况下或许sidecar模式更好。但是sidecar也有不完美的地方，每个pod里都要存在一个日志收集的agent实在是太消耗资源了，而且很多问题也难以解决，比如：主容器挂了，agent还没收集完，就把它给kill掉，这个时候日志怎么处理，业务会不会受到要杀掉才能启动新的这一短暂过程的影响等。所以，我们实际使用中首选daemonset方式，但是提供了sidecar模式让用户选择；
Log-Pilot
